Skip to main content

Model Predictive Control for Dynamic Walking

Duration: 65 min · Level: Advanced · Module: 3. Bipedal Locomotion & Whole-Body Control · Focus: MPC, locomotion, optimization, control

ZMP planning answers "can I support the motion I already chose?" Model Predictive Control asks a more powerful question: "of all the motions I could choose over the next half-second, which one is best — and does it keep me safe the whole way?" That shift, from planning a trajectory once to re-solving an optimization at every control tick, is what unlocked running, stair-climbing, and genuine push recovery on legged robots. This lesson teaches you how MPC is structured, why it scales painfully from quadrupeds to humanoids, and the centroidal trick that makes humanoid MPC tractable.

The MPC idea: optimize a window, act, repeat​

Model Predictive Control plans over a finite horizon of future states, executes only the first step of that plan, then throws the rest away and re-solves at the next tick with fresh state. The optimization at each tick has a recognizable shape:

Minimize a cost over a horizon of N steps, subject to the robot's dynamics, friction-cone constraints (a foot can only push, not pull, and only within the limits of friction), and joint limits — and solve it fast, at 100 to 1000 Hz.

Re-solving constantly is the whole point. Because the controller re-plans from the measured state every few milliseconds, a disturbance that ZMP control could not anticipate simply becomes the new starting condition for the next solve. The plan bends around the push instead of breaking.

Where contact gets interesting​

A walking robot's hardest constraint is that it makes and breaks contact with the ground. Classical controllers fix the contact schedule in advance — left foot down now, right foot down later — and plan within it. Contact-implicit MPC does something more ambitious: it treats the contact schedule itself as an optimization variable. The solver decides which foot touches the ground and when, which means it can discover new gaits automatically rather than executing a human-designed one.

The proof that convex MPC could run dynamically in the real world came from the MIT Cheetah 3 (Di Carlo et al., IROS 2018). It used convex MPC at 500 Hz to achieve stable 3D running at up to 6 m/s, re-planning in real time over rough terrain. The lesson for humanoid builders: the convex formulation matters because convex problems solve reliably and fast, which is what makes "re-solve every 2 ms" feasible.

The humanoid problem is harder than the quadruped problem​

You cannot simply scale Cheetah 3's controller up to a humanoid. Three things change qualitatively:

  • More joints. A humanoid has 40+ joints versus a quadruped's twelve. The whole-body inertial properties are richer and the optimization is larger.
  • Coupled upper body. A quadruped's body is essentially a rigid trunk. A humanoid swings arms, turns a torso, and carries payloads — and upper-body dynamics couple back into leg control. Wave an arm and you perturb the very balance the legs are maintaining.
  • A smaller support base. Two feet, often nearly in line, give a far smaller and frequently-changing support polygon than four spread paws.

Solving a full 40-DOF nonlinear MPC at kilohertz rates is, in general, too slow.

Centroidal MPC: plan small, execute large​

The dominant escape is a two-layer decomposition. First, reduce the humanoid to its centroidal dynamics — the 6-DOF motion of the center of mass and the total angular momentum about it (the formal object is laid out in Orin et al., Centroidal Dynamics of a Humanoid Robot, Autonomous Robots, 2013). Crucially, the centroidal model captures how contact forces move the whole body without tracking every joint, so it is small enough to optimize over a horizon in real time.

The architecture is then:

  1. Centroidal MPC (high level): plan CoM trajectory, momentum, and contact forces over the horizon. This is the small, fast optimization.
  2. Whole-body QP controller (low level): take the centroidal plan as a reference and solve for the full joint commands that realize it — distributing the planned contact forces across the actual legs and respecting every joint limit. (This whole-body layer is the subject of Lesson 3.4.)

This split is the single most important structural idea in modern model-based humanoid control: a cheap predictive model decides the strategy (where the mass goes, how hard each foot pushes), and a per-tick QP handles the execution (which motor does what).

You do not write the solver​

A practical note that saves months: the hard numerical machinery already exists as mature open-source libraries. PINOCCHIO (LAAS) computes rigid-body dynamics and the analytical derivatives MPC needs; CROCODDYL (LAAS) provides optimal-control solvers built on it; and Drake (MIT) offers a full modeling, optimization, and simulation stack. Together they deliver sub-millisecond solve times for humanoid MPC. For a first build, you are integrating and tuning these tools, not re-deriving the dynamics from scratch — spend your effort on the cost function, the constraints, and the contact model, where the behavior actually lives.

Putting it into practice​

Stand up a minimal centroidal MPC for a planar (2D) biped and watch it walk by re-solving.

  1. Choose the reduced model. Represent the robot by its CoM position, CoM velocity, and the contact forces at each foot. Write the centroidal dynamics: CoM acceleration equals the sum of contact forces over mass, plus gravity.
  2. Set the horizon. Pick N steps (e.g., 0.5 s at 100 Hz = 50 knots). At each knot you have CoM state and per-foot force as decision variables.
  3. Add the constraints. Enforce the friction cone at each foot (force inside the cone, normal component non-negative — a foot pushes, never pulls) and bound the forces by actuator limits.
  4. Write the cost. Penalize deviation of CoM velocity from a desired forward speed, plus a small penalty on force magnitude (energy). This is the reward-shaping analogue you will see again in RL.
  5. Close the loop. Solve the QP, apply only the first force command, advance the simulated state, and re-solve from the new state. Repeat.
  6. Test the headline benefit. Mid-walk, inject a velocity disturbance (a simulated push). Because the controller re-solves from the perturbed state, watch it recover — something your Lesson 3.1 ZMP planner could not do. Then increase the friction-cone angle (slippery floor) and observe the plan automatically choosing gentler forces.

Key takeaways​

  • MPC plans over a finite horizon, executes one step, and re-solves every tick (100–1000 Hz) from the measured state — which is exactly why it recovers from disturbances ZMP control cannot.
  • Every solve respects dynamics, friction-cone, and joint-limit constraints; contact-implicit MPC even optimizes the contact schedule, discovering gaits automatically.
  • MIT Cheetah 3 proved convex MPC at 500 Hz could run dynamically (up to 6 m/s) on rough terrain — convexity is what makes real-time re-solving reliable.
  • Humanoids are harder than quadrupeds (40+ joints, coupled upper body, small support base); the fix is centroidal MPC for strategy feeding a whole-body QP for execution.
  • Build on PINOCCHIO, CROCODDYL, and Drake (sub-millisecond solves) rather than writing the dynamics and solvers yourself; invest your effort in cost, constraints, and contact modeling.

References​

  • Dynamic Locomotion in the MIT Cheetah 3 Through Convex Model-Predictive Control — Di Carlo et al. (2018). IROS 2018
  • Centroidal Dynamics of a Humanoid Robot — Orin et al. (2013). Autonomous Robots

← Previous: 3.1 Locomotion Foundations: ZMP, CoM, and Linear Inverted Pendulum · Next: 3.3 Reinforcement Learning for Locomotion →

Part of Module 3: Bipedal Locomotion & Whole-Body Control.