Balance: centre of mass, support polygon, ZMP and capture point

Stage 1 · Foundations · ~35 min · Before this: 01 Degrees of freedom · Maths: F = ma, an exponential · numbers from the repository as of 2026-10-29

Why does a robot stay up, and when must it take a step? Four ideas answer that: where the centre of mass is, the area the feet cover, where the ground pushes back, and where the robot would have to step to stop. Marvin Bot’s walking policy (the learned controller that drives its joints) never computes them, yet they explain every fall and every recovery step it makes.

You will learn

• Static balance: the centre of mass (CoM) projection must lie inside the support polygon.
• Dynamic balance: the zero-moment point (ZMP), the linear inverted pendulum and the cart-table model.
• The capture point: how far a push carries the robot, and why Marvin Bot’s 30 N·s push requirement needs a step.

The idea in one picture

Stand still and lean forward slowly. Nothing happens until the point straight below your centre of mass passes your toes; then you must step. The centre of mass is the average position of all the robot’s mass, weighted by mass. The support polygon is the smallest convex shape that contains every point where the feet touch the ground, like a rubber band stretched round the soles.^[2] Standing still, the robot is balanced if the CoM’s vertical projection (the point on the floor straight below it, where a plumb line from the CoM would touch) lies inside it.

Moving changes the rule. Think of carrying a tall tray of drinks: walk off briskly and the glasses tip backwards. When the body speeds up or slows down, the point where the ground’s push acts (the centre of pressure, which on flat ground is the same point as the zero-moment point, ZMP) moves away from the point below the CoM. That point, not the CoM, must stay inside the feet. And a push gives the body speed that must be soaked up before the robot can stop, sometimes only by taking a step. Playground A shows the static and accelerating cases from above; Playground B shows a push from the side.

Playground A: feet from above

Top view, robot facing up the screen, its left on your left. Feet 0.24 × 0.11 m, hips 0.20 m apart, the ankle 0.09 m from the heel. Drag the CoM dot (or use the sliders). Origin: the point midway between the hip joints.

How to read this picture: orange shapes are the feet on the ground, the green outline round them is the support polygon, the blue dot is the point below the CoM and the violet dot is the ZMP. Each “margin” readout is the distance from that dot to the nearest green edge: positive means inside (balanced), negative means outside (tipping).

Presets

Marvin Bot today (stance) Single support, CoM shifted Mid-stride Narrow stance Accelerating forward

Feet

Support

Both feetLeft onlyRight only

Step width (between foot centrelines)

0.20 m = feet under the hips, Marvin Bot's stance.

Left foot ahead by

Step length; the right foot moves back by the same amount.

Centre of mass

CoM forward

CoM to the left

CoM acceleration forward

Speeding up forward moves the ZMP backward, towards the heels (the tray-of-drinks effect; formula below).

CoM acceleration to the left

CoM height z

CoM margin (static)

–

ZMP position (fwd, left)

–

ZMP margin (dynamic)

–

Support area

–

feet in contactsupport polygonCoM projectionZMP

Try this

1. Press Marvin Bot today. The CoM margin reads about 109 mm: the CoM is 109 mm in front of the heels, its closest edge. The repo’s MuJoCo standing check computes the same distance (see “How Marvin Bot does it”).
2. Switch to Left only without moving the CoM. The margin goes negative: before lifting a foot the robot must shift its CoM about 0.1 m sideways over the other foot. That sway is in every step.
3. Back on both feet, raise the forward acceleration to 2 m/s². The ZMP moves 0.14 m behind the CoM. At about 1.5 m/s² it reaches the heels: a harder start would tip the robot backwards even though the CoM is well inside.

From first principles

Static balance

Gravity pulls down at the CoM with force m·g (m the mass in kg, g = 9.81 m/s²). The ground can only push up, and only where the feet touch. If the robot does not move, the ground’s total push must act straight under the CoM, otherwise the two forces, equal but not in line, twist the robot over (a “couple”). The ground’s push can act anywhere inside the support polygon but nowhere outside it, so: static balance ⇔ CoM projection inside the support polygon. The distance to the nearest edge is the static margin.

Centre of pressure and ZMP

The ground pushes on every square millimetre of the sole. Add those pushes up and they act like one force at one point, the centre of pressure (CoP). For a robot on flat ground the zero-moment point is the same point: the point on the ground about which the horizontal moments of gravity and inertia cancel.^[1][2] The ZMP idea, from Vukobratović’s work in the late 1960s, gives a balance rule for walking: if the ZMP computed from the planned motion stays strictly inside the support polygon, the feet will not tip over their edges.^[1]

The linear inverted pendulum and the cart-table

To get numbers, physicists shrink the robot to its simplest possible version: a ball balanced on a stick, like balancing a broom upright on your palm. Model the robot as all its mass at the CoM, on a massless telescopic leg from the CoP, with the CoM held at a constant height z. Then the horizontal motion obeys:^[3][2]

ẍ = ω² (x − p), ω = √(g / z)
equivalently p = x − (z / g)·ẍ (cart-table form)

x is the CoM’s horizontal position (m), ẍ its acceleration (m/s²), p the CoP/ZMP position (m), z the CoM height (m) and ω the pendulum’s natural rate (1/s). If the CoM is ahead of the CoP, it accelerates forward: the pendulum falls. To accelerate forward, the robot moves its CoP behind the CoM, by (z/g)·ẍ. Kajita and colleagues called this the linear inverted pendulum mode, and used the “cart on a table” picture to plan walking: choose a ZMP path inside the footprints, then compute a CoM path that produces it.^[3][4] For Marvin Bot, z ≈ 0.71 m gives ω ≈ 3.7 s⁻¹ (per second): left alone, a lean grows by a factor of about 2.7 (the number e) every 0.27 s. That is why a tall robot has only a few tenths of a second to react. A lower CoM gives a larger ω: it tips faster (a short pencil is harder to balance on a fingertip than a long broom), but a given push also carries it less far before it can be stopped, as Playground B shows.

The capture point (divergent component of motion)

In plain words: if someone shoves you, there is one spot on the floor where, if you put your foot there, you come to a stop with no further steps. That spot is the capture point. A harder shove moves it further away; if it lands beyond your toes, you must step.

The maths: split the pendulum’s motion into a part that settles and a part that runs away. The runaway part is

ξ = x + ẋ / ω and it moves as ξ̇ = ω (ξ − p)

ẋ is the CoM’s velocity (m/s). ξ is the capture point:^[5] if the robot puts its CoP exactly on ξ (by stepping there or by shifting pressure within a foot), the CoM comes to rest above it. If ξ lies outside the reach of the CoP, it runs away from the CoP exponentially and the robot must step before it is too far.

Go deeper: the same idea under other names

Englsberger and colleagues call ξ the divergent component of motion (DCM) and build walking controllers on it;^[6] Koolen and colleagues turned it into “N-step capturability”: can the robot stop in 0, 1 or 2 steps?^[7] Biomechanics found the same quantity in human balance and called it the extrapolated centre of mass.^[8]

A push is an impulse J (N·s): force times duration. By conservation of momentum it changes the CoM’s velocity by Δv = J / m, whatever part of the body it hits (as long as it is short). The capture point then jumps ahead of the CoM by Δv / ω.

Playground B: a push from the side view

“R14” is requirement 14 in the repo’s list (docs/requirements.md): recover from a 30 N·s push while standing (N·s, newton-seconds, measures a push by force times how long it lasts: 300 N for 0.1 s is 30 N·s). The robot stands with its CoM over its feet; a short push gives it a velocity. The ankle can move the CoP anywhere on the sole (an idealised “ankle strategy”). If the capture point leaves the sole, the robot needs a step. Press a preset, then ▶ Replay to watch it.

Presets

Marvin Bot today: R14 push, one step R14 push, ankle only Largest push without a step Training push (0.5 m/s) R14 push sideways

Robot

Mass

40.97 kg with shells; 40.00 kg bare.

CoM height z

0.706 m in the stance, from the URDF (see below).

Push

Impulse J

R14: recover from 30 N·s while standing.

Direction

ForwardBackwardSideways

Response

Strategy

Ankle onlyAnkle + one step

Step lands after

Time from the push to the swing foot touching down.

Longest step allowed

An assumption, not a repo number: foot-centre travel the leg can manage.

▶ Replay

CoM velocity after push

–

ω = √(g/z) · time constant

–

Capture point ahead of CoM

–

Sole edge ahead of CoM

–

Largest push, no step

–

Step needed at touchdown

–

CoM x(t)capture point ξ(t)CoP p(t)sole

Try this

1. Press R14 push, ankle only: 30 N·s on 41.0 kg is 0.73 m/s, the capture point lands 0.197 m ahead of the CoM, but the toes are only 0.131 m ahead. The robot falls. Switch to Ankle + one step: it recovers with a step of about a third of a metre (foot-centre travel).
2. Now slide Step lands after from 0.30 to 0.60 s. The required step grows from ~0.32 m to ~0.72 m: the capture point runs away exponentially, so reacting fast matters more than stepping far.
3. Lower the CoM height to 0.5 m. ω rises and the same push needs a shorter step: a crouch helps push recovery, but it costs knee torque (page 05).

Why the policy never computes any of this

Marvin Bot walks with a neural-network policy trained by reinforcement learning (trial and error in simulation, page 16), not with a ZMP planner. The policy sees joint angles, velocities, the pelvis’s angular rate and gravity direction, and outputs joint targets; it is rewarded for following velocity commands and penalised for falling. It is trained with random pushes, a technique from massively parallel legged training.^[9] Nothing in it computes a ZMP or a capture point. But physics does not change: a policy that survives a push must, implicitly, move its CoP to the toes and then step near the capture point. These models are how you read its behaviour, predict how hard a push it can survive, and choose training settings.

How Marvin Bot does it

In the repo

• Requirement R14 (docs/requirements.md, “should”): recover from a 30 N·s push while standing. At 41.30 kg that is a CoM velocity of 30 / 41.3 = 0.73 m/s (0.74 m/s at 40.35 kg bare).
• CoM height. We loaded the generated URDF in MuJoCo with the repo’s own check_standing.py builder, placed the robot in robot.yaml’s stance and read the whole-body CoM: 0.706 m above the floor, 4 mm ahead of the hip line, for the 40.35 kg bare model. The shells (0.95 kg, mostly on the torso) raise it slightly, so this page uses 0.71 m. (docs/decisions.md, 2026-10-29, says the CoM rose 78 mm with the taller body.)
• Static margin. sim/mujoco/check_standing.py reports the distance from the CoM projection to the edge of the feet’s bounding box: 110 mm in our run of the stance; robot.yaml’s comment says 106 mm (from an earlier model). Playground A’s default gives 109 mm.
• Pushes in training. The walking environments push the robot every 5–10 s by setting the pelvis velocity to a random value up to ±0.5 m/s in x and y (sim/isaaclab/marvin_bot/tasks/velocity_env_cfg.py). At 41.3 kg, 0.5 m/s is about 21 N·s: two-thirds of R14.
• Step-up check. sim/mujoco/check_step_up.py requires the CoM to lie at least 2 cm inside the supporting foot (1 cm sideways): a static-balance test exactly like Playground A.

With R14’s push, the numbers say: capture point 0.195 m ahead of the CoM against 0.131 m of foot ahead of it (forward) and 0.155 m to the outer edge of the far foot (sideways, both feet down). Neither direction can be saved by the ankles alone; forward needs one step of roughly 0.3 m if it lands 0.3 s after the push. Without a step, the idealised ankle strategy handles about 20 N·s forward and 24 N·s sideways. Real ankles do worse (finite torque, the foot rolls before the CoP reaches the edge), and swinging the arms and torso (the “hip strategy”, modelled with a flywheel by Pratt et al.^[5]) does a little better.

Trade-offs and alternatives

Approach	How it balances	Strength	Weakness
ZMP preview control[4]	Plans a CoM path whose ZMP stays in the footprints	Predictable, well understood	Needs flat feet, accurate models; slow, careful gaits
Capture point / DCM control[6]	Controls ξ directly; steps where ξ goes	Push recovery built in	Still a simplified model; footstep planner needed
RL policy (Marvin Bot)[9]	Learned from millions of simulated falls and pushes	Handles rough ground and stairs with one network	No explicit guarantee; only as robust as its training pushes and randomisation

Design levers that change balance: a lower CoM raises ω (faster recovery, but more knee torque); larger feet move the edges out (but catch on stairs; Marvin Bot’s foot is 0.24 m, about the length of a 25 cm tread); wider stance helps sideways pushes; faster stepping (stronger hips, lighter legs) shortens the step needed.

Where sources and the repo disagree

Not a disagreement with a source, but a gap inside the repo: R14 asks for 30 N·s (≈0.73 m/s), while the training pushes go up to 0.5 m/s (≈21 N·s). Our model says 30 N·s needs a reactive step, so a policy may need larger training pushes before R14 can be claimed. Also, robot.yaml’s stance comment gives a 106 mm margin and our run of the current URDF gives 110 mm; the comment predates the latest mass changes.

Decisions you can make here

• Training push range: to meet R14, the training pushes probably need to reach ≥ 0.73 m/s (they stop at 0.5 m/s today) and the evaluation should measure recovery steps, not only falls. Trade: harder pushes make training slower and can make the walk stiffer and more cautious.
• CoM height and stance: a lower crouch needs a shorter recovery step, but the bent knee carries more torque and heats up sooner (page 05).
• Foot size and stance width: bigger feet and a wider stance give bigger margins, but a longer foot catches on stair edges and a wider stance makes each sideways weight shift longer.

Your decision noteCopy

Built from your settings above. Paste it into an issue, a design discussion or an AI assistant session.

Where this leads. Balance is a job for the whole machine: sensors must notice the lean, the computer must decide, and the motors must react within a few tenths of a second. Page 03 follows that chain from battery to policy; pages 04 and 05 ask whether the motors are strong enough.

Further reading

• Tedrake, Underactuated Robotics, “Humanoid robots”: CoP, ZMP and the ZMP planner, derived carefully.
• Pratt et al., Capture Point (2006): short and readable; the flywheel model of the hip strategy.
• Koolen et al., Capturability, Part 1 (2012): the formal version: 0-, 1- and N-step capturability.
• Rudin et al., Learning to walk in minutes (2021): the training recipe Isaac Lab’s locomotion tasks grew from, pushes included.

Sources

1. M. Vukobratović and B. Borovac, “Zero-moment point — thirty five years of its life”, Int. J. Humanoid Robotics, 2004 — used for: ZMP definition, history and the balance condition.
2. R. Tedrake, Underactuated Robotics (MIT 6.832), “Humanoid robots” — used for: CoP/ZMP equivalence on flat ground, support polygon, the constant-height pendulum equation.
3. S. Kajita, F. Kanehiro, K. Kaneko, K. Yokoi and H. Hirukawa, “The 3D linear inverted pendulum mode”, IROS 2001 — used for: the linear inverted pendulum model.
4. S. Kajita et al., “Biped walking pattern generation by using preview control of zero-moment point”, ICRA 2003 — used for: the cart-table model and ZMP preview control.
5. J. Pratt, J. Carff, S. Drakunov and A. Goswami, “Capture Point: a step toward humanoid push recovery”, Humanoids 2006 — used for: capture point definition, flywheel (hip strategy) extension.
6. J. Englsberger, C. Ott and A. Albu-Schäffer, “Three-dimensional bipedal walking control based on divergent component of motion”, IEEE T-RO, 2015 — used for: DCM, ξ̇ = ω(ξ − p).
7. T. Koolen, T. de Boer, J. Rebula, A. Goswami and J. Pratt, “Capturability-based analysis and control of legged locomotion, Part 1”, IJRR, 2012 — used for: N-step capturability.
8. A. L. Hof, M. G. J. Gazendam and W. E. Sinke, “The condition for dynamic stability”, J. Biomechanics, 2005 — used for: the extrapolated centre of mass in human balance.
9. N. Rudin, D. Hoeller, P. Reist and M. Hutter, “Learning to walk in minutes using massively parallel deep reinforcement learning”, CoRL 2021 — used for: RL locomotion training with random pushes.