Comparison of Atlas Robot Controllers


This web page describes approaches to controlling the Atlas robot from Boston Dynamics in the DARPA Robotics Challenge used by the teams from IHMC, MIT, and WPI-CMU. These approaches are similar, so we are interested in exactly how they are similar and how they are different.

The core element shared by all three approaches is the use of Quadratic Programming (QP) to compute desired accelerations and contact forces on each tick of the controller.

IHMC Workshop

This workshop has some talks (on video) relevant to these controllers.

Special Issue on DRC Trials

This special issue of the Journal of Field Robotics has papers from all 3 groups.

Components and Issues

First, some info on the teams


Web Page, Videos, and Papers

Jesper Smith (IHMC), Sylvain Bertrand (IHMC), Peter Neuhaus (IHMC), Matthew Johnson (IHMC), Jerry Pratt (IHMC), and the IHMC team, "Momentum-based whole-body control framework - Application to the humanoid robots Atlas and Valkyrie", Talk at IROS 2014 Workshop

What happened at the DRC?

Atlas on obstacle course.

Atlas walking over uneven ground

Atlas walking

Atlas extreme balancing


Web Page, Videos, and Papers

What happened at the DRC?

Atlas walking

Atlas getting pushed around and [2]

Egress robustness test

Terrain walking

Fast walking on flat

WPI-CMU DRC Team (robot at WPI)

Videos, Talks, and Papers

What happened at the DRC?

Atlas getting pushed around.

Atlas walking

Boston Dynamics

Early version of Atlas walking over rough terrain.

Early version of Atlas walking over obstacles.

We have no idea how Boston Dynamics controls Atlas.

Static Vs. Dynamic Walking

The DRC emphasized minimizing risk and placing feet accurately. There was an incentive to go fast. However, the hard limit was an hour to do 8 tasks.

Consequently, the walking was relatively slow and static, and the controllers were designed to place each footstep at a target. Changing desired foot placement during leg swing in response to errors was not done by IHMC, MIT, or WPI-CMU.

However, our optimization algorithms can be used to walk much faster (see videos above) and to vary footsteps in response to errors. Future footstep locations can simply be made part of the set of variables that are optimized in choosing footsteps and center of mass trajectories.

How did the robot decide where to go?

ALL: Operator designates position and orientation, or object, to walk to.

Footstep planning.


Operator chose footsteps.

Stairs: Heels off stairs, Arms tucked in, Torso learning forward.


Flat ground: solve optimization problem that computes number and placement of footsteps subject to a variety of constraints (max forward/side step, foot yaw, etc.)

Terrain: Use perception to identify blocks in lidar data. Update block fits using library of tilted block patterns.

Stairs: Use perception to fit steps, plan footsteps relative to fit steps. Heels off stairs, Arms forward, Torso relatively straight up.


What we wanted: A* search including dynamics and risk in the criteria. W. Huang, J. Kim, and C. G. Atkeson, Energy-based optimal step planning for humanoids, ICRA 2013

What we did: A variety of foot step planners are implemented for different scenarios. In most flat ground walking cases, we use an A* based planner that uses an action set of more aggressive foot steps. Interpolation based planners are also implemented. We rely on their repeatability for certain tasks, such as sidestepping through an open door. Special purpose planners are implemented for the terrain and stair tasks.

Stairs: Splayed foot entirely on stair. Arms tucked in. Torso learning forward.

COM Trajectory planning.


Capture point in N steps. N = 3 or 4.


Did not explicitly compute a COM trajectory. Planned a ZMP trajectory w.r.t. footstep goals, use TV-LQR to compute an optimal cost to go on the COM state and acceleration.


Trajectory optimization (DDP) to stop in N steps, N = 2 in DRC, N = 3 for faster gaits now. LQR provides terminal value function. LIPM + Z.

Squared penalty on deviation from desired COP trajectory.

Replan every footstep.

Generating joint torques.

All do QP to find acceleration and contact forces.

Then compute torques using inverse dynamics.


Centroidal momentum thing, doesn't compute mass matrix.


Does recursive Newton-Euler to find torques.


Assume active inequality constraints change rarely, special case handles active constraint changes.

Fallback to Gurobi if homebrew solver fails to solve in N=15 iterations.

Do bottom half of equations of motion.


Using QuadProg with no special tricks.

Use weighted constraints, not prioritized hierarchy of constraints.

Use value function from DDP.

Structural change smoothing in QP.

Use estimated COM modeling error.

Controlling the hydraulics.


Corrected kinematics with link deformation models.

Backlash compensation.

Did valve control themselves.


Leg gains same form as WPI-CMU

Arm gains have friction and gravity compensation (not used in DRC finals).


Use BDI low level feedback controller. Gains hand tuned and globally constant in actuator coordinates. Use our own 2nd order filter designs.

Exception: Ankle swing and stance gains different.

State estimation.

Pelvis estimation similar (LIPM model)


Backlash compensation on joint velocity


Include LIDAR (but not at DRC).


Kalman Filter using LIPM process model.

Estimate external force/COM offset

How are the walks different?


Stomp, 2s/step, 1s SS, 1s DS


Did not explicitly enforce smoothness of contact transitions. Sometimes resulted in hard impacts.


Gentle footfall.

4s/step, 2s SS, 2s DS.


Do gentle touchdowns make walking easier or harder?

How much compliance do we have?

Are there differences in how the sensors were used?


COP used in state estimation


Foot sensor used as binary contact sensor


COP used in state estimation

State vs. output feedback story.

Arm Control


Used motion capture calibration to fix kinematics (details?)

Integrates difference of output and input


calibrate output encoders vs. input encoders on every run.

output -> state est.

Lowpass difference of output and input encoders, to correct what goes to feedback controller.



walking = manipulation?

control in joint space


Same controller used for walking and manipulation.

vision based tracking of thumb.


no vision feedback except through operator

separate IK controler.