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.
This workshop has some talks (on video) relevant to these controllers.
This special issue of the Journal of Field Robotics has papers from all 3 groups.
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 getting pushed around and [2]
Atlas getting pushed around.
Early version of Atlas walking over rough terrain.
Early version of Atlas walking over obstacles.
We have no idea how Boston Dynamics controls Atlas.
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.
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.
Capture point in N steps. N = 3 or 4.
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.
All do QP to find acceleration and contact forces.
Then compute torques using inverse dynamics.
Centroidal momentum thing, doesn't compute mass matrix.
CVXGEN
Does recursive Newton-Euler to find torques.
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.
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.
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
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
State vs. output feedback story.
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.