Topic hub

Legged and humanoid robots

How walking robots stay upright and move. Gaits and contact schedules, ZMP and the capture point, centroidal dynamics and MPC, learned locomotion policies, and how to tell a demo from a product.

Updated 14 Nov 2026 · legged locomotion, gait, zero-moment point, capture point, linear inverted pendulum, centroidal dynamics, model predictive control, quadruped, humanoid, reinforcement learning

Overview

Legged robots trade the simplicity of wheels for access to stairs, rubble, kerbs and gaps. Humanoids add the promise of working in spaces built for people. Both are hard to control for one reason: the body is not bolted to anything. The base is underactuated, and the only way to push it is through contact forces at the feet. Those forces can only push, never pull, and they must stay inside the friction cone or the foot slips. This hub is for engineers working on locomotion controllers or evaluating legged robots for a site.

Key ideas

Gaits and contact schedules

A gait is the schedule of which feet touch the ground and when. A slow quadruped walk keeps three feet down most of the time, so the projection of the centre of mass (CoM) can stay inside the support polygon. That is static stability: the robot would not fall if it froze. A trot moves diagonal pairs of legs together. The support polygon shrinks to a line, and balance depends on motion, which is dynamic stability. Bounding and galloping add flight phases with no feet on the ground. Bipeds have at most two feet down and a small support area, so practical walking is dynamic. Most controllers fix the contact schedule ahead of time and plan forces and footholds around it.

ZMP and the capture point

The zero-moment point (ZMP) is the point on the ground where the contact forces produce no tipping moment about horizontal axes. For a flat foot it must stay inside the support polygon, or the foot starts to roll on its edge. Vukobratović and Borovac review 35 years of its use. Kajita et al. (2003) model the robot as a linear inverted pendulum, with the CoM at constant height z_c above the ground. The CoM then accelerates away from the ZMP at a rate set by ω = sqrt(g/z_c). They plan the CoM motion with preview control over future ZMP references. Pratt et al. (2006) asked where the robot must step to come to rest. For the same model the answer is the capture point, the CoM position plus its velocity divided by ω. Stepping there is the basis of push recovery.

stance foot(support polygon)ZMP pCoMvelocity vheight z_ccapture pointnext footholdpendulum model:x’’ = omega^2 (x - p)omega = sqrt(g / z_c)capture point:x + v / omegaxz
The linear inverted pendulum seen from the side, x forward and z up. The centre of mass moves at constant height z_c. It accelerates away from the ZMP, which must lie inside the stance foot. Stepping onto the capture point, x plus v divided by omega, brings the pendulum to rest.

Centroidal dynamics and model predictive control

The full dynamics of a legged robot have dozens of states. Orin, Goswami and Lee (2013) showed that the total linear and angular momentum about the CoM, the centroidal momentum, changes only through gravity and contact forces. That gives a small model that still captures what matters for balance. Di Carlo et al. (2018) went further for the MIT Cheetah 3 and treated the body as one rigid body. They planned ground reaction forces over a short horizon as a convex model predictive control problem, then mapped those forces to joint torques. Planning on a reduced model and tracking with a whole-body controller is a common structure for model-based locomotion.

Learned locomotion policies

Reinforcement learning in simulation now trains many walking controllers. Hwangbo et al. (2019) trained a quadruped policy entirely in simulation and ran it on the physical robot, which followed velocity commands and recovered from falls. Lee et al. (2020) trained a controller that uses only proprioceptive signals and took it outdoors through mud, snow, rubble and vegetation. Rudin et al. (2021) ran thousands of robots in parallel on one workstation GPU and, according to the authors, trained flat-terrain walking in under four minutes and rough-terrain walking in twenty. The policy maps joint states, base motion and commands to joint targets at a fixed rate. It is fast and handles terrain well, but harder to inspect or bound than an MPC.

Where to start

The dynamics hub and control hub cover the background. Simulate an arm in MuJoCo teaches MuJoCo, which several of the locomotion tools below build on. PID control explains the joint-level loops that every legged controller still sits on. The robot learning hub and simulation hub cover training and transfer. See Spot and Go2 in the robot table.

Tools and platforms

Tool What for Licence
Pinocchio Fast rigid-body and centroidal dynamics with derivatives BSD-2-Clause
Crocoddyl Optimal control for contact sequences BSD-3-Clause
OCS2 Switched-system MPC used for legged robots BSD-3-Clause
Isaac Lab GPU-parallel robot learning framework, where the legged_gym environments now live BSD-3-Clause and Apache-2.0
MuJoCo Playground Robot environments and large-batch RL training on MuJoCo Apache-2.0
unitree_sdk2 Low-level and high-level control of Unitree robots BSD-3-Clause

Common mistakes

  • Taking a video as evidence of a product. Look for a datasheet, a price, a support contract and named customers.
  • Tuning gains on a model with ideal motors. Joint friction, torque limits and latency decide whether a controller works.
  • Ignoring the friction cone. A plan that needs more sideways force than μ times the normal force will slip.
  • Training a policy without randomising mass, friction and motor strength, then blaming the hardware.
  • Reading a single success rate. Ask over what terrain, how many trials and whether a human was ready to catch the robot.

Going deeper

Latest news on this topic

Recent papers

  • Runtime Safety and Emergency Stops on a Full-Size Humanoid: Deployment Lessons and a Case for Graduated Force Authority

    M. Conway, Y. Zhang, A. Devaraj et al. · arXiv cs.RO · digest

    The paper describes the safety layer the authors built into their open-source autonomy software for a Unitree H1-2 humanoid. The layer runs apart from the control software, checks every joint command against position, velocity and torque limits, and stops the robot when the state estimate goes stale or the hard-wired e-stop is pressed or unplugged. In push tests on the physical robot with a model-predictive lower-body controller, the robot never recovered its balance, the operator hit the e-stop every time, and because stopping removes balance control the robot fell. Joint limits chosen for manipulation were also exceeded in ordinary walking and triggered the same stop. The authors argue that next to an operator or a battery pack, falling may do more harm than whatever caused the stop and propose granting force authority in stages with a named responsible party, which is a position argued from the deployment rather than a tested method.

  • BlinkMimic: Training a Humanoid Motion Tracker in Minutes on a Single GPU

    F. Chen · arXiv cs.RO · digest

    BlinkMimic trains a single whole-body tracking policy for all 40 LAFAN1 motion clips on a simulated Unitree G1 in 3.4 minutes on one RTX 4090, averaged over three seeds and measured until a stated return threshold is met with no failed clip. It builds on earlier work that trains the policy by backpropagating through a world model fitted to parallel simulation data, adding a step size that drops once training has progressed, resets triggered by failures of the deployed policy, and GPU graph capture of each whole iteration. A leave-one-out ablation assigns each component to iteration cost, iterations needed to fit the motions, or iterations needed to clear the last failures. There is no hardware test, so treat it as a fast loop for developing tracking policies rather than evidence of transfer to a real robot. Code and per-seed results are public.