In this entry, I would like to describe my struggle with the dynamic model of the quadruped. Based on two articles from MIT, IIT and mostly by changing the code available on the MIT’s repository for Cheetah robots I could run the Balance Controller in the VREP simulation program. Generally, a simplified mathematical model of the quadruped is presented as a cost function and then is solved by QPOASES solver in order to get the forces that have to be applied on each leg tip.

The code is written in C++ and communicates with VREP by ROSinterface. The communication is synchronized, meaning the C++ code waits for the simulation to complete a single step (the computer I ran it on is really old and slow).

The simulation model is created from imported SolidWorks Parts. They are modified by the simulation software to minimize the triangle count and thus make the simulation execution time shorter. Joints – special parts available in the simulation can act as passive joints or motors with different control loops. In my case, all the joints were set to torque mode. Having the model prepared, I created the simulation script responsible for controlling the torque on each motor (PD controller) and ROS communication. My assumption was to make the simulation script mimic the software running on each of the motor controllers. This allowed to separate the high level solver code and low level motor drivers software in the same way it is implemented on a real robot.

While trying to run the original Balance Controller, I stumbled upon a few problems. First, I had different zero-angle positions and angle increment directions compared to the minicheeta (cheetach III ?) robot. It was not possible to run the code without modifications.

I decided to check each component of the simulation separately. First, I checked if my leg Jacobian is derived properly by simply commanding a 1N of force in each axis and observing the reaction of the leg. The position were updated as the leg moved under the influence of joint torques. The next main problem were the coordinate frames of the legs. I did not know if there are four different coordinate frames (if so how are they oriented?) or the leg tip’s positions are expressed in the body frame. I used the body frame for that purpose.

Once that was settled up, I created a script in vrep that could visualize the forces acting on the end effectors of each leg. That helped a lot while debugging. I could easily determine if I’m computing the right placement of each joint (forward kinematics) and if the end effector is in the right spot. It was the time when I saw a problem with yaw angle. As long as the robot’s coordinate frame was aligned with the world frame, the model seemed to work. However, when the yaw angle was changed the robot kept losing the stability. It turned out to be an issue with the rotation matrix about yaw axis. The problem was that the authors of the code wanted to express everything in the world frame, whereas I tried to do it in the body frame. After fixing this last issue, the model started to work as expected. Right now I’am able to command roll, pitch and yaw angles as well as translations (through whole body PD controller). Below you can see two videos of the quadruped simulation (I recorded it a few weeks back, and I wasn’t planning to post it, so sorry for the poor quality)–I hope they’ll help to visualize the idea.

There is a lot going on right now with the motor drives. I’ve found a major bug in the software, and I’m also designing a newer improved version of the BLDC controllers. I hope I’ll write about them soon.

See You ;)

Peter.