The Cartwheel controller

Posted:   |   More posts about simulation

The Cartwheel 3D framework by S. Coros et al. is one of the few physics-based controllers for humanoid characters with freely available source code (Apache 2.0). This fact made it a good starting point for our own research into humanoid motion. However, the focus of the Cartwheel project is on being a tool for animation, rather than on controlling actual robots.

We have tried to make a minimal version of the Cartwheel framework. In particular, we have tried to cleanly decouple the controller from the physics engine. The controller gets the full state of the robot and outputs joint torques, the physics simulation uses these to step forward in time and provide the controller with the new robot state. This will allow us to experiment with different physics engines, easily add sensor or motor noise, or run the controller within frameworks like Gazebo.

Another change we made to the controller is the way the maximum virtual force on the root is calculated. The original controller would reduce the force once the foot started lifting of the ground, which we found to be a source of chatter (i.e. torque spikes). We have replaced this by a calculation based on the center-of-pressure concept, which always limits the force to a safe values. This significantly reduced the torque spikes. In addition, it allows us to run the controller in "magnetic boots" mode, which is very useful for debugging.

The video above shows the walk cycle generated by our version of the Cartwheel controller. The simulated robot weighs 47 kg, with each leg contributing 8.1 kg. In the figures below, joint angles, velocities, torques and power are shown (for one step). The dashed lines mark the times when the stance foot switches. Data is shown for the left foot, which is first the swing foot and then the stance foot.


As per the goal of the original authors, the motion looks very natural. There are, however, a number of issues:

  • The torque curves still contain spikes and other high-frequency content. Trying to clip or low-pass filter the motor torque causes the controller to fail. Since an actual motor controller would likely not have the required bandwidth (nor would that be desirable), the controller as-is cannot be used on a physical robot.
  • The controller wastes energy by speeding up the robots center of gravity during one half of a step, then slowing it down again during the next half.
  • The swing leg is not fully extended when it makes contact with the ground.
  • The controller uses the next foot position as a way to control the center of mass velocity. While this is a legimitate and powerful concept, it is rather hard to accommodate additional requirements, e.g. from trying to walk on ground that is not perfectly flat.

We will try to address these issues in our next-generation controller, which is currently being researched.