ZMP, capture point, and the walking cookbook

In 1996 Honda showed P2 walking, the first stable humanoid biped. The math behind that demo: ZMP (Zero Moment Point). Twenty years later, MIT researchers refined it into the Capture Point. Both still appear in every modern humanoid controller. Even when the actual control is reinforcement-learned, the analysis vocabulary is ZMP / capture point. Here's the working knowledge.

Why walking is hard

A wheeled robot is always stable: gravity pulls down, the wheels push up, the contact patch is wide enough that the center of mass projects inside it.

A walking robot is only sometimes stable. During single-support (one foot on the ground), the support polygon shrinks to one foot's footprint. If the CoM projects outside that footprint, the robot tips. Walking is a continuous balancing act between "I'm safely planted" and "I'm falling forward and need to catch myself."

ZMP: the dynamics-aware support point

The Zero Moment Point is the point on the ground where the horizontal moments from gravity + inertia + applied torques sum to zero. Equivalently: the point where the ground reaction force can be applied as a single point force with no torque.

For a robot to be dynamically stable while walking, the ZMP must lie inside the support polygon at all times. ZMP outside → uncompensated moment → robot rotates and falls.

The ZMP shifts as the robot moves: leaning forward shifts ZMP forward; swinging an arm shifts it sideways. Plan a robot's motion to keep ZMP within the foot, and walking is stable.

Computing ZMP

For a robot with mass m, CoM at height z_c, and CoM acceleration \ddot{x}_c:

x_zmp = x_c − (z_c / g) · ẍ_c

The "linear inverted pendulum model" (LIPM) — assumes a constant CoM height. Surprisingly accurate for level ground walking; fails for stairs and aggressive maneuvers.

Generalizations include vertical CoM motion, multiple contacts (both feet on the ground), and non-flat ground. The classical Honda controller used LIPM ZMP throughout.

The walking pattern generator

The ZMP framework gave a recipe for generating walking trajectories:

1. Plan a sequence of foot placements.
2. For each step, define a target ZMP trajectory that stays inside the corresponding support polygon.
3. Solve for the CoM trajectory that produces that ZMP (using the LIPM equation).
4. Compute joint trajectories via inverse kinematics.
5. Execute on the robot's joints.

This was the architecture of every humanoid walker from 2000–2018. ASIMO, HRP, Atlas, all used variations.

Capture Point: the natural extension

ZMP tells you "is the robot currently stable?" Capture Point asks "if I want to stop, where do I need to put my next footstep?"

For a falling LIPM, the capture point is:

x_cp = x_c + ẋ_c / ω₀     where ω₀ = √(g / z_c)

This is the point on the ground where, if you place your next foot exactly there, the robot will come to rest standing on that foot. Step short of the capture point → keep falling. Step beyond → recoil backward.

Capture point gives a clean, intuitive control law: pick foot placements that match the desired CoM dynamics. Far cleaner than full-trajectory ZMP planning.

The N-step capture region

Sometimes one step isn't enough to recover. The N-step capture region is the area where the robot can come to rest within N steps. The 1-step capture region is small; the 2-step region is much larger; and so on.

Production controllers compute these regions in real-time and use them for footstep planning + reactive recovery (when pushed).

What ZMP/CP misses

• Tilted contacts: foot rolling on uneven ground. LIPM assumes flat support polygons.
• Multi-contact (parkour, climbing): when hands and feet share contacts. Centroidal momentum dynamics handle this; ZMP doesn't.
• Aggressive maneuvers: jumping, running, recovery from large pushes. Need full nonlinear dynamics.
• Compliance: real robots bend; pure rigid-body ZMP ignores this.

The 2024–26 RL revolution

Modern humanoid controllers (Tesla Optimus, 1X NEO, Boston Dynamics Atlas) use reinforcement learning more than classical ZMP planning. The RL policy outputs joint commands directly given proprioception + IMU.

But: ZMP / CP are still everywhere as analysis tools:

• Reward shaping: penalize the policy when the ZMP exits the support polygon.
• Footstep planning: high-level planner picks footsteps within the N-step capture region; RL fills in joint motion.
• Stability monitoring: check ZMP at runtime; trigger recovery behaviors if it exits.

Knowing ZMP/CP is required for reading any humanoid paper, even the RL ones.

Production-grade implementations

• OCS2 / Crocoddyl: open-source MPC frameworks with whole-body humanoid models. Plan trajectories with explicit ZMP constraints.
• Drake: MIT's framework. Includes humanoid examples with ZMP-based walking.
• OpenHRP: classical Japanese humanoid framework. Showing its age but still in use.

Hands-on path

1. Implement a 2D LIPM ZMP walker in Python (~150 lines). Plot the CoM trajectory and verify ZMP stays in the foot.
2. Add capture-point reactive footstep planning. Push the simulated CoM; watch the foot land at the capture point.
3. Move to a 3D humanoid in MuJoCo. Use OCS2 or hand-coded MPC.
4. Add an RL policy on top. Train on the same ZMP-aware reward.

Each step builds on the last. The journey from "I understand the equation" to "my humanoid stays upright" is several months — but the milestones are clear.

Exercise

In MuJoCo, simulate a 2D pendulum (single LIPM). Implement the capture-point recovery: when the pendulum tips forward, move the support point to the capture point. Verify the pendulum settles back to vertical regardless of initial perturbation. The intuition for "step where you're falling" is what humanoid walking depends on.

Next

Whole-body control for humanoids — the framework that turns ZMP-aware footstep plans into actual joint motion across 25+ DOF.