Section 45.2: Balance, stability, and gait

"Balance is what remains after every modeling shortcut gets punished by gravity."

A Dynamics Lecture After Midnight

Figure 45.2A illustrates this in a single frame: a biped mid-step, recovering from a push, its posture at that instant telling you nothing about whether the recovery will succeed.

Freeze the video the instant a shove lands on a walking biped. The robot looks perfectly poised, yet it may already be committed to a fall no ankle torque can stop. Stability is not a single static pose but a property that holds across time. What matters is whether the robot can recover from the disturbance, not whether it looks balanced at one instant. The linear inverted pendulum model (LIPM, a simplified dynamics model that treats the robot as a point mass balanced atop a massless leg of fixed height) gives a compact balance approximation. With center-of-mass horizontal position \(c\) and height-fixed natural frequency \(\omega = \sqrt{g/z_0}\), the capture point is \(\xi = c + \dot c / \omega\). If \(\xi\) leaves the reachable foothold set (the region on the ground where the robot could physically place a foot in time), the current stance cannot stop the fall without taking a step.

For zero-moment-point reasoning, the planned Zero-Moment Point (ZMP, the point on the ground where the net ground reaction force would produce no tipping moment) must stay inside the support polygon (the convex region on the ground bounded by the robot's contact points) during contact. That is a necessary but not sufficient condition for robust walking because actuator bandwidth, contact compliance, perception delay, and state-estimation drift still matter in the closed loop.

The ZMP constraint matters in embodied AI because a real robot contacting uneven ground cannot rely on joint stiffness alone. When the ZMP exits the support polygon, the net ground reaction torque can no longer oppose the gravitational moment, so the robot tips regardless of what the joint motors command. On hardware this is typically irreversible within a handful of control cycles: once tipping begins, actuator bandwidth is often insufficient to recover the fall. As an order-of-magnitude illustration, a torque-controlled biped at 1 kHz might get roughly 3 control cycles before a 5-degree tip becomes a 20-degree tip, which is past any recoverable joint limit for many designs. In such a case the ZMP violation and the fall would be separated by about 3 milliseconds of real time, less than the round-trip latency of a single CAN bus message, though the exact numbers depend on the robot's mass distribution, joint limits, and control rate. Any learned or planned locomotion policy must therefore guarantee ZMP containment continuously, not just on average. This continuous-containment requirement is exactly why gait is a hybrid systems problem, alternating discrete contact switches with continuous within-contact dynamics, a framing developed in full later in this section.

How the ZMP is computed

Mechanically, the ZMP is the point on the contact plane where the resultant ground reaction force produces zero net pitching or rolling moment. It is computed from the measured foot contact forces and their lever arms relative to the candidate point: sum the moments from all contact normals and tangential forces, then find the planar location that makes that sum zero. If no such point exists inside the convex hull of all active contact patches, the support polygon constraint is violated and a tip is imminent.

Theory

Figure 45.2.1 lays out the loop this section formalizes: observe the balance state, model recoverability, act on footstep timing, and verify the margin after disturbance. The theory below fills in the middle two stages. Static stability asks whether the projected center of mass lies inside the support region. Dynamic stability asks whether momentum, actuator authority, and future footholds allow recovery before the robot reaches an unrecoverable state. The gap between the two is not academic: in hardware trials with early Atlas controllers, a fixed static-stability check allowed recovery from pushes under 50 N, while a capture-point controller with replanning recovered from pushes over 150 N using the same actuators, the same sensors, and the same legs. The number that changed was the planning horizon, not the hardware.

Gait design is therefore a hybrid systems problem at heart. The robot alternates discrete contact modes and continuous within-contact dynamics. A controller that ignores mode transitions tends to fail precisely when the task becomes interesting: on slopes, during pushes, or while carrying loads. Boston Dynamics' Atlas and Spot platforms show the decomposition in hardware: Atlas uses a model-predictive controller that re-solves footstep placement at roughly 1 kHz, treating each contact mode switch as a hard constraint boundary; when shoved, it does not apply a fixed recovery rule but re-plans the capture point trajectory within the new support set. Spot's leg controller separates stance regulation (ZMP margin) from swing trajectory so that slipping on one foot triggers an independent replanning of just that leg without destabilizing the other three. These are published examples of the hybrid-systems decomposition operating in hardware, not simulation.

The right instrumentation is a balance ledger that records ZMP margin, capture-point error, stance phase, slip events, and recovery steps on every episode.

Worked Example

The three recovery strategies above only fire when the capture-point test says the current stance is losing, so it is worth seeing that test run on real numbers before trusting it in a controller.

A tiny diagnostic on the capture point can explain why one gait survives a shove that another gait cannot recover from.

import math

com_x = 0.02
com_vx = 0.55
z0 = 0.82
g = 9.81
omega = math.sqrt(g / z0)
capture_point = com_x + com_vx / omega
support_max_x = 0.16
margin = round(support_max_x - capture_point, 3)

print(f"capture_point={capture_point:.3f} m")
print(f"remaining_margin={margin:.3f} m")

Expected output interpretation. The capture point sits 1.9 cm outside the current support limit. A controller that keeps the same stance is already late. It must place a new foot, widen support, or lower momentum quickly enough to move the capture point back into a reachable set.

Practical Recipe

A single capture-point check is decisive at one instant; turning it into a controller you can trust means logging that quantity, and its companions, across every disturbance you expect the robot to meet.

1. Instrument ZMP, capture-point error, stance phase, and foot slip in every rollout.
2. Evaluate nominal walking, pushes, friction drops, and height-map errors on the same disturbance panel.
3. Separate gait generation from recovery logic so you can attribute failures to the right layer.
4. Tune for recovery margin before tuning for style or top speed.
5. Archive two traces for every new controller: a stable nominal run and a near-failure recovery run.

A controller that guarantees balance only when nothing goes wrong is not a balance controller; it is a fair-weather policy.

Capture-point reasoning bridges classical control and modern locomotion learning. It lets you read a learned recovery policy as a fast approximation to the same physical objective, not as opaque behavior.

Gait evaluation is not one scalar. The same controller can have good average speed and terrible disturbance behavior. Reporting both nominal and perturbation metrics is part of the scientific content, not bookkeeping.

Balance failures should be labeled by root cause: wrong state estimate, late contact detection, bad footstep plan, insufficient actuator authority, or unstable gain schedule. Those labels make later learning and controller tuning faster and more honest.