Technology
How Robots Move Like Humans: Whole-Body Control Explained
Whole-body control (WBC) is the real-time optimization algorithm that coordinates all 30-40 joints of a humanoid robot simultaneously. Here is how it works: from quadratic programming and task priorities to contact management and how modern companies integrate WBC with learned AI policies.
A humanoid robot's ability to walk into a warehouse, pick up a box, pivot, and place it on a shelf without falling over requires coordinating 20-40 joints simultaneously in real time. The software system that makes this possible is called whole-body control (WBC): a class of algorithms that treat the entire robot body as a single unified system, distributing motion tasks across every limb while maintaining balance.
Whole-body control is one of the most computationally demanding problems in robotics. It runs at update frequencies of 200-1,000 Hz, solves constrained optimization problems in milliseconds, and must handle contact forces from the ground, objects, and the environment simultaneously. Understanding how WBC works explains why humanoid robotics was stuck in research labs for decades and why it has suddenly become commercially viable in the 2020s.
AI-generated image
Whole-body control fuses sensor data, motion planning, and torque commands across every joint in real time. Credit: AI-generated illustration
Key Stats
1 kHz
Joint control loop frequency
200 Hz
Whole-body planner update rate
30-40
Degrees of freedom (humanoid)
<5 ms
Target WBC solve time per cycle
How Whole-Body Control Works
Traditional robot arms are controlled in isolation: each joint has a position or velocity target, and a PID controller adjusts motor current to hit that target. This works fine for a fixed-base arm bolted to a table. For a legged robot that must balance while moving, it fails immediately. Moving one leg shifts the robot's center of mass, which changes the forces needed at every other contact point. Everything is coupled.
Whole-body control addresses this by building a complete dynamic model of the robot and using it to compute joint torques that satisfy multiple simultaneous objectives. A typical WBC stack has three layers running at different frequencies:
• Task specification (high level, ~50 Hz): Defines what the robot should do: walk forward at 1.2 m/s, reach for an object at position X, maintain a specific hand orientation. Tasks are expressed as desired accelerations or forces in Cartesian space.
• Whole-body planner (mid level, ~200 Hz): Solves a constrained optimization problem: given all the tasks, find joint accelerations (and resulting torques) that best satisfy them while respecting physical constraints. Constraints include joint torque limits, joint velocity limits, and contact forces that stay within friction cones (so feet don't slip).
• Joint-level controller (low level, ~1 kHz): Takes the commanded torques from the planner and sends current commands to the actuator motors, using feedback from joint encoders and torque sensors to close the loop at very high frequency.
The optimization at the planner level is typically formulated as a quadratic program (QP): minimize a cost function (deviation from desired task accelerations) subject to linear constraints (dynamics, torque limits, contact conditions). Modern QP solvers can handle the 30-100 variable problems that humanoid WBC requires in under 1 millisecond on current embedded hardware, which is what makes the 200 Hz update rate practical.
The Friction Cone Constraint
One of the most important constraints in WBC is that contact forces must stay inside the friction cone: the robot's foot can push against the floor but cannot pull it (no adhesion) and cannot push sideways harder than friction allows. Violating this constraint causes slipping. WBC encodes this geometrically as a cone-shaped constraint on the foot contact force vector, ensuring the planner never commands a gait that would slip under nominal floor conditions.
Under the Hood: Task Priority and Contact Management
When multiple tasks conflict, WBC needs a way to decide which one wins. The standard approach is a task hierarchy with strict or soft priorities. A strict hierarchy means higher-priority tasks are satisfied exactly before lower-priority tasks get any budget. A soft hierarchy uses weighted costs in the QP objective, where higher-priority tasks get larger weights.
Typical task priority ordering for a walking humanoid:
• Priority 1 (absolute): Joint limit enforcement, torque saturation. The robot cannot exceed its hardware limits regardless of what any task asks for.
• Priority 2 (very high): Center of mass control and balance. Keeping the center of mass over the support polygon is almost always the highest-priority Cartesian task.
• Priority 3 (high): Swing foot placement. The foot needs to land in the right place at the right time for the gait to stay stable.
• Priority 4 (medium): Hand/end-effector tasks. Reaching for objects, maintaining grasp orientation, tool use.
• Priority 5 (low): Posture regulation. Keeping joints near their nominal positions when all higher-priority tasks are satisfied.
AI-generated image
Single-leg balance while reaching is a canonical WBC challenge: the robot must coordinate hip, knee, ankle, spine, and arm joints simultaneously to maintain stability. Credit: AI-generated illustration
Contact management is the other core challenge. As the robot walks, contacts are made and broken at high frequency: each step involves a foot going from swing (no contact) to heel strike to flat foot to toe-off. The WBC must know the current contact state precisely to set up the right constraints. A foot that is labeled as "in contact" in the model but is actually swinging will produce wildly wrong torque commands.
| Control Approach | Update Rate | Handles Full-Body Coupling | Scalability | Typical Use |
|---|---|---|---|---|
| PID per joint | 1-5 kHz | No | Very high | Fixed-base arms |
| ZMP/capture point | 100-500 Hz | Partial | Medium | Early bipeds (ASIMO era) |
| Whole-Body Control (QP) | 200-1,000 Hz | Yes (full model) | Medium (compute-intensive) | Modern humanoids |
| Model Predictive Control (MPC) | 50-200 Hz | Yes (with horizon) | Low (very compute-intensive) | Research, Boston Dynamics |
| Reinforcement Learning (policy) | 50-500 Hz | Yes (implicit) | High (inference only) | ETH Zurich ANYmal, new humanoids |
Who's Building on Whole-Body Control
The WBC research tradition traces back to pioneering work at MIT, Stanford, Carnegie Mellon, and ETH Zurich. But the commercial players building on these foundations have taken different approaches:
Boston Dynamics (Atlas)
The canonical WBC showcase. Atlas uses a combination of model predictive control (MPC) and whole-body control to achieve its acrobatic maneuvers. The 2023 all-electric Atlas uses highly backdriveable electric actuators that make force control far more precise than the hydraulic predecessor. Commercial availability announced for 2025, targeting Hyundai factory use cases.
Agility Robotics (Digit)
Digit runs a custom locomotion controller built on WBC foundations, with a focus on practical warehouse deployments. Amazon has piloted Digit units for tote movement. Agility is operating a 10,000-robot-per-year factory in Salem, Oregon, targeting commercial deliveries at volume in 2025-2026.
Figure AI (Figure 02)
Figure 02 (65+ DOF) uses a control architecture that integrates vision-language models for task understanding with a WBC-based motion execution stack. The integration of high-level semantic reasoning with low-level whole-body control is Figure's core technical differentiator. 70 units deployed at BMW as of early 2025.
Unitree (H1, G1)
Unitree has published WBC research alongside its hardware, contributing open-source locomotion controllers. The H1 (47 DOF, 47 kg) and G1 (43 DOF, 35 kg) are priced in the 6,000-0,000 range, dramatically below Western competitors, making them the dominant platform for academic WBC research globally.
What Industry Impact Looks Like: When WBC Meets Learned Policies
The most active research frontier in humanoid control is the integration of reinforcement learning (RL) with traditional WBC. Pure WBC requires a precise dynamics model of the robot: every mass, inertia, and joint friction must be characterized accurately, and the model must match the real hardware. This is expensive to obtain and breaks down when hardware wears or when the robot encounters objects that change its effective dynamics (like carrying a heavy load).
Reinforcement learning, trained in simulation and transferred to real hardware through sim-to-real techniques, can produce locomotion and manipulation controllers that are robust to model uncertainty and unexpected perturbations. ETH Zurich's ANYmal robot famously demonstrated RL-trained locomotion that could navigate outdoor terrain, snow, mud, and rubble without relying on an explicit terrain model.
The hybrid approach most commercial humanoid makers are converging on uses WBC for the low-level torque control (where physics is well understood and model accuracy is achievable) and RL for higher-level task policies (where the complexity of the real world makes explicit modeling intractable). The RL policy outputs desired Cartesian trajectories or contact schedules; the WBC controller converts those into joint torques in real time.
Key Technical Challenges Remaining in WBC
• Unknown contact timing: Predicting exactly when a foot will touch an uneven surface is hard; WBC controllers that rely on scheduled contact times can fall when the surface is unexpected.
• Payload variation: Picking up objects of unknown weight changes the dynamics model mid-task. Adaptive or online estimation approaches are needed.
• Deformable surfaces: Sand, foam, grass, and soft flooring change contact mechanics in ways that fixed-friction-cone models do not capture.
• Compute efficiency: Solving a 100-variable QP at 1 kHz requires purpose-built hardware or clever approximations. Most commercial robots use custom silicon or FPGA acceleration for the inner control loop.
Frequently Asked Questions
Is whole-body control the same thing as the robot's AI?
No. WBC is a control system that handles real-time motion execution and balance, not the "thinking" layer. Most humanoid systems have separate stacks for perception (cameras, lidar, depth sensors processing the environment), task planning (deciding what to do next), and motion control (WBC). The AI components, whether vision-language models, reinforcement learning policies, or classical planners, sit above WBC and feed it motion targets.
Why did humanoid robots need WBC when simpler methods existed?
Older approaches, like the Zero Moment Point (ZMP) control used in Honda's ASIMO, worked but produced slow, rigid, flat-footed walking that fell apart the moment the robot encountered an uneven surface or had to move its arms dynamically while walking. ZMP controllers treat balance and arm motion as separate problems. WBC treats them as one coupled problem and finds solutions that are both dynamically consistent and reactive to disturbances. The tradeoff is far higher computational cost, which is why WBC only became practical in the 2010s as embedded compute caught up.
How does WBC know what the robot's body is doing?
State estimation. Every joint has an encoder measuring its angle and often a torque sensor or current sensor measuring the force it is applying. An inertial measurement unit (IMU) in the torso measures linear acceleration and angular velocity, giving the robot a sense of its own orientation in space. A Kalman filter or similar estimator fuses all this sensor data into a consistent estimate of the robot's full state: every joint angle, velocity, and the position and velocity of the base (torso) in the world frame. The quality of state estimation directly limits the quality of WBC performance.
What hardware runs WBC at 1 kHz on a humanoid?
Current humanoids use a combination of onboard computing platforms: a higher-power general-purpose computer (typically running on an x86 or ARM SoC with a discrete GPU for perception tasks) handles the perception, planning, and WBC planner layers. The inner joint control loop at 1 kHz runs on dedicated real-time microcontrollers or FPGAs within each actuator module, communicating over EtherCAT or similar deterministic industrial networks. Figure AI, Unitree, and others have published details suggesting they use custom actuator electronics with integrated compute for the inner control loops.
What's Coming Next in Robot Motion Control
The near-term trajectory for humanoid motion control points toward tighter integration between learned high-level policies and model-based WBC lower layers. The next 12-24 months will likely see commercial humanoids handling a wider range of manipulation tasks (not just pick-and-place but assembly, tool use, and surface interaction) as WBC stacks become better calibrated for unknown contact and variable loads.
The longer-term frontier is eliminating the explicit WBC model entirely in favor of end-to-end trained controllers that learn physics directly from data. Several academic groups, including researchers at Berkeley, CMU, and Stanford, have demonstrated this on quadruped robots. Extending it to humanoids with dexterous hands introduces a scale of complexity that purely learned controllers have not yet handled reliably.
The Bottom Line: Whole-body control is the core technology that separates humanoid robots that can work in the real world from those that only work in a lab; every commercial humanoid operating in a factory today runs some version of it, and the competition to make WBC faster, more robust, and easier to deploy is where the real technical differentiation happens in 2025-2026.
For buyers and operators evaluating humanoid robots, WBC performance translates directly into how gracefully a robot handles unexpected situations: a slippery floor, a heavier-than-expected box, a bump from a passing forklift. The specs to watch are not just degrees of freedom and payload capacity, but update rates, fall recovery behavior, and how the robot behaves when its model assumptions break down in real deployments.