Technology explainer
How Do Humanoid Robots Keep Their Balance While Running?
A running humanoid repeatedly estimates its posture and momentum, predicts future foot contacts, and commands whole-body forces before its motion becomes unrecoverable. Fast sprinting proves a narrow capability, while safe stopping, disturbance recovery, payload handling, endurance, and repeatability determine real-world usefulness.
A running humanoid stays upright by repeatedly estimating where its body is moving, predicting where it will fall, and placing or loading the next foot so that the ground can redirect that motion. Sensors measure body rotation, joint position, and contact forces; a controller turns those measurements into target joint torques; actuators must deliver them before the robot’s momentum carries it beyond recovery.
The control loop in 30 seconds
- Estimate the body’s state. The robot combines inertial, joint, and foot-force measurements to infer its posture and velocity.
- Predict the next loss of balance. A motion planner estimates where the centre of mass and feet will move over the next few steps.
- Choose contact and force. It adjusts the landing position, timing, body lean, and push from each leg.
- Command the whole body. Motors coordinate hips, knees, ankles, torso, and arms while respecting torque, friction, and joint limits.
- Correct continuously. Every new measurement updates the plan, often hundreds or thousands of times per second at the lowest control layers.
Running is controlled falling
Standing is possible when the body’s centre of mass projects safely inside the area supported by the feet. During running, that simple static rule is repeatedly violated. The body moves beyond the current foot, and there may be a flight phase in which neither foot touches the ground. The robot remains viable because its next contact arrives in the right place and at the right time to redirect momentum.
A useful mental model is not “keep the torso perfectly vertical.” It is “keep the future motion recoverable.” A runner leans, rotates, and lets the centre of mass move outside the current support region. Balance means controlling those motions so that the next footstep and ground force can catch them.
What must the robot sense?
| Measurement | Typical source | Why it matters |
|---|---|---|
| Body rotation and acceleration | Inertial measurement unit with gyroscopes and accelerometers | Reveals pitching, rolling, turning, and rapid disturbances |
| Joint angle and speed | Encoders at hips, knees, ankles, arms, and torso | Shows the robot’s internal configuration and limb motion |
| Ground contact and load | Force or torque sensors in feet and joints | Confirms touchdown and estimates how the ground is pushing back |
| Terrain and obstacles | Cameras, depth sensors, or lidar | Supports foothold planning before contact |
| Motor condition | Current, voltage, temperature, and torque estimates | Prevents commands that exceed hardware or thermal limits |
No sensor is perfect. Accelerometers also feel the robot’s own motion, gyroscopes drift, feet may slip, and visual data arrive with delay or uncertainty. State estimation combines these sources with a motion model. The aim is to infer quantities the robot cannot measure directly, including the position and velocity of its centre of mass and whether a foot is firmly supporting the body.
Step by step: one running stride
- Push-off. The supporting leg applies force to accelerate the body forward and upward while the controller keeps the foot within its friction limit.
- Swing. The other leg moves toward a planned landing location. The knee bends for clearance, while the torso and arms counter unwanted angular momentum.
- Flight, if present. With no ground contact, the robot cannot change the path of its centre of mass very much. It can reposition limbs and rotate parts of the body, but the landing plan becomes critical.
- Touchdown. The foot meets the ground with a controlled position, angle, and velocity. Force rises rather than appearing as an ideal instantaneous impact.
- Load acceptance. The leg bends and produces torque to absorb energy, prevent collapse, and redirect the body into the next stride.
- Replanning. Measured contact timing and force update the estimate. If touchdown came early, late, or on a slippery patch, the controller changes the next step.
Why foot placement matters so much
If the body is moving forward faster than expected, landing the next foot farther forward can create a braking moment. If it is falling sideways, widening or shifting the step can place support under the predicted motion. Controllers often use ideas related to a capture point: the position where a foot could stop or redirect a simplified falling body.
That simplified calculation is valuable, but a real humanoid robot has many moving joints, flexible structures, actuator delays, and limits on where a leg can reach. Advanced planners therefore consider several future contacts, not just one. Model predictive control repeatedly solves a short-horizon optimisation problem, applies the first command, then solves it again with updated measurements.
How the robot converts a plan into motion
A high-level planner may request a target speed and route. A gait layer selects step timing and footholds. A whole-body controller then distributes the required motion and forces across many joints while maintaining contacts and respecting constraints. Fast motor controllers finally regulate current, torque, speed, or position at each actuator.
These layers must agree. A beautiful foot trajectory is useless if the hip motor lacks the torque to produce it. A strong push is unsafe if the foot-ground friction is too low. Joint limits, motor temperature, gearbox backlash, battery voltage, structural flex, and communication delay all reduce the set of physically possible corrections.
What do the arms and torso contribute?
They do more than make the motion look human. Swinging arms can counter angular momentum created by the legs. The torso can lean into acceleration, rotate to stabilise heading, or shift mass sideways. These motions let the controller manage orientation without asking the feet and ankles to solve every disturbance alone.
Yet upper-body movement has a cost. Accelerating the arms consumes energy and may interfere with a carried object. A work robot holding a heavy tool has different balance options from an empty-handed sprint robot, so locomotion performance cannot be separated from payload and task.
Where does machine learning fit?
Engineers can design controllers from physical models, train policies in simulation, imitate recorded motion, or combine these methods. Reinforcement learning can discover coordinated responses across many joints and expose a policy to random pushes, delays, friction values, and terrain during simulation. The resulting controller may be more adaptable than one hand-tuned trajectory.
Learning does not remove physics or safety engineering. A simulated policy can exploit unrealistic contact, perfect sensors, or actuators stronger than the real machine. Deployment requires model randomisation, hardware testing, safety constraints, fall detection, and a conventional low-level control system capable of enforcing limits.
How does a robot recover from a disturbance?
- Ankle strategy: adjust foot torque for small, slow disturbances while contact remains secure.
- Hip and torso strategy: rotate larger body segments to manage angular momentum.
- Step strategy: move the next foot to expand or relocate the support region.
- Multiple-step recovery: use several rapid steps when one reachable foothold cannot absorb all the momentum.
- Protective fall: when recovery is impossible, reduce impact and protect people and critical hardware.
The controller also needs to recognise that recovery has failed. Continuing to drive powerful joints during a fall can make an impact more dangerous. Safe stopping and power reduction are therefore part of balance, not an afterthought.
Why running fast is easier to demonstrate than working safely
A prepared straight track removes many uncertainties. The surface is level, the direction is known, obstacles are absent, and the run is brief. Engineers can tune a narrow gait close to the machine’s torque and stability limits. A workplace instead demands turning, stopping, stepping around people, crossing changes in friction, carrying loads, opening doors, and repeating the task as the battery and motors warm.
| Sprint demonstration | Useful real-world locomotion |
|---|---|
| Known flat lane | Changing surfaces, ramps, gaps, and clutter |
| Maximum forward speed | Safe acceleration, turning, stopping, and yielding |
| Seconds of operation | Repeatability over hours and changing battery state |
| No payload or narrow task | Tools, packages, or physical interaction |
| Failure can end the run | Failure must protect nearby people and equipment |
NewTqnia reported how Tiangong Ultra covered 100 metres in 9.39 seconds, then needed padded barriers at the finish: A Humanoid Robot Ran 100 Metres in 9.39 Seconds. The result demonstrates rapid forward locomotion and major year-to-year improvement, but it does not establish safe deceleration, endurance, or robust operation around people.
A successful run does not reveal the whole controller
Video and finish time cannot show whether a robot used onboard autonomy, external computation, a preplanned trajectory, learned control, or some combination unless organisers and developers disclose the system. Nor do they reveal fall rate, repeated-trial distribution, power use, actuator temperature, or how often human intervention was required. Robustness should be measured across many trials and disturbances, not inferred from the best run.
The mental model to remember
A running humanoid does not eliminate falling. It manages a sequence of falls by estimating motion, predicting future support, placing a foot, and shaping ground force before recovery becomes impossible. Sensors make the estimate, planning chooses the next contact, whole-body control coordinates the machine, and actuators determine whether the correction arrives in time.
First appeared in
A Humanoid Robot Ran 100 Metres in 9.39 Seconds
