Comparison of Atlas Robot Controllers

IHMC, MIT, and WPI-CMU


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


IHMC

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


MIT

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.

IHMC

Operator chose footsteps.

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

MIT

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.

WPI-CMU

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.

IHMC

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

MIT

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.

WPI-CMU

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.

IHMC

Centroidal momentum thing, doesn't compute mass matrix.

CVXGEN

Does recursive Newton-Euler to find torques.

MIT

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.

WPI-CMU

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.

IHMC

Corrected kinematics with link deformation models.

Backlash compensation.

Did valve control themselves.

MIT

Leg gains same form as WPI-CMU

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

WPI-CMU

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)

IHMC

Backlash compensation on joint velocity

MIT

Include LIDAR (but not at DRC).

WPI-CMU

Kalman Filter using LIPM process model.

Estimate external force/COM offset


How are the walks different?

IHMC

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

MIT

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

WPI-CMU

Gentle footfall.

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

Questions

Do gentle touchdowns make walking easier or harder?

How much compliance do we have?


Are there differences in how the sensors were used?

IHMC

COP used in state estimation

MIT

Foot sensor used as binary contact sensor

WPI-CMU

COP used in state estimation

State vs. output feedback story.


Arm Control

MIT

Used motion capture calibration to fix kinematics (details?)

Integrates difference of output and input

WPI-CMU

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.


Manipulation

IHMC

walking = manipulation?

control in joint space

MIT

Same controller used for walking and manipulation.

vision based tracking of thumb.

WPI-CMU

no vision feedback except through operator

separate IK controler.