Whole-body control coordinates a robot’s contacts, floating base, legs, arms, torso and posture so several tasks can be executed without violating dynamics or hardware limits. Instead of commanding each limb independently, it resolves a shared set of variables such as joint acceleration, contact force, position or torque.
The name covers several architectures. A controller may solve a quadratic program from a rigid-body model, use hierarchical task priorities, track centroidal quantities, decode a learned full-body command or combine these layers. The real interface and constraint handling matter more than the label.
Read this with the kinematics and dynamics guide and contact-control comparison. Whole-body behavior depends on state, contact and actuator evidence that must be validated together.
Whole-body control solves a coupled robot problem
Moving one humanoid arm changes the center of mass and angular momentum. A foot contact limits base motion and creates a wrench that supports the body. A hand contact can add another closed-chain constraint. Treating these actions as independent joint trajectories can create conflict or loss of balance.
A whole-body controller chooses commands that satisfy shared dynamics while reducing task errors. The output can be desired joint acceleration, velocity, position, torque or a combination passed to lower-level servos. State clearly which layer closes the final actuator loop.
State and contact estimation define the problem
The controller needs joint state, floating-base pose and velocity, contact state and often external wrench. IMU, encoders, force sensors, vision and kinematic contact constraints contribute. Delay or frame error can make the solver enforce a physically wrong contact.
Use contact probability or a state machine with well-defined transitions rather than assuming every planned foot is firmly planted. Monitor slip, early impact and missed contact. During transition, blend objectives and bounds so the command does not jump between incompatible models.
| Input | Controller use | Failure mode | Evidence |
|---|---|---|---|
| Base state | Balance and task frames | Drift or latency | External motion reference |
| Joint state | Kinematics and limits | Offset or velocity noise | Encoder validation |
| Contact state | Constraint selection | False support or missed touch | Force and kinematics |
| Contact geometry | Friction and wrench bounds | Wrong normal or polygon | Calibrated surface model |
| Actuator state | Torque and speed feasibility | Hidden saturation | Drive telemetry |
Contact constraints create the feasible set
Planning and control through contact require unilateral normal force, friction and kinematic consistency. The Underactuated Robotics contact chapter explains why contact mode is both a discrete and continuous problem. A foot can push a floor but cannot pull it.
Approximate friction cones or pyramids must use conservative coefficients appropriate to the surface. Center-of-pressure and contact-wrench bounds depend on foot geometry and load distribution. If the estimated contact violates these bounds, the solver may return an attractive but physically impossible command.
Tasks need priorities, weights and tolerances
Typical tasks include stance-foot pose, hand pose, center of mass, torso orientation, gaze and nominal posture. Hard constraints protect feasibility; soft objectives trade errors. With weighted optimization, units and scale affect priority. With hierarchical optimization, higher levels are preserved while lower levels use remaining freedom.
Document which tasks can yield and by how much. An exact hand pose may be less important than keeping a foot stable, while a tool task may demand orientation accuracy but allow translation along one axis. Use tolerances and slack penalties that reflect the actual operation.
Centroidal quantities summarize balance motion
The center of mass and centroidal momentum provide a compact description of the body’s overall motion. Contact wrenches change linear and angular momentum. A controller can track desired centroidal behavior while a whole-body mapping distributes the result to joints and contacts.
Centroidal control does not eliminate full-body constraints. Joint limits, self-collision, swing-foot clearance and actuator capability still matter. Model and estimate error can produce contact-force mismatch, so compare predicted and measured support behavior during pushes, payload changes and arm motion.
Optimization-based WBC exposes constraints explicitly
Tools such as Drake support multibody dynamics and mathematical optimization used in robot control research. A quadratic program can minimize task and effort costs subject to equations of motion, contact, acceleration, torque and joint bounds at each control step.
The result is local to the current state and modeled contact. Solver time and numerical conditioning must fit the control deadline. Log status, iterations, residuals and active constraints. Define a bounded fallback for infeasibility or timeout instead of reusing a stale high-energy command.
| Design choice | Benefit | Risk | Verification |
|---|---|---|---|
| Weighted tasks | Simple tradeoffs | Unit-sensitive priority | Scale sweep |
| Hierarchical tasks | Strict priority | Higher computation | Conflict tests |
| Hard contact bounds | Physical feasibility | Model mismatch | Slip and force tests |
| Torque constraints | Protect actuators | Conservative performance | Telemetry comparison |
| Slack variables | Avoid infeasibility | Hidden violation | Slack threshold alarms |
Learned whole-body control changes the command interface
The current GR00T Whole-Body Control repository demonstrates a learned humanoid control stack and identifies separate source-code and model licensing. A learned model may predict compact or full-body action representations that are decoded and executed by another controller layer.
Do not describe a vision-language-action model as directly commanding raw joint torque unless the documented stack does so. Record observation history, action rate, decoder, low-level interface and safety filters. Test distribution shift, recovery and out-of-domain commands separately from successful demonstrations.
Contact transitions are harder than steady stance
Lifting a foot removes constraints and available support wrench; touchdown adds them after an uncertain impact time. Hand contact may arrive early or late. Transition logic must coordinate trajectory, force ramp, task priority and estimator state without discontinuity.
Test slow transfers before dynamic motion. Vary surface height, friction and timing, and measure impact force, slip, base error and command saturation. A controller that balances in a fixed stance has not yet demonstrated robust walking or manipulation through contact.
Actuator limits must remain visible to the solver
Joint torque, speed, current, temperature and transmission limits change with operating state. If the optimizer assumes unavailable torque, lower layers saturate and the predicted dynamics become wrong. Rate limits and communication delay also shape the achievable command.
Use calibrated output-side limits where possible and monitor saturation feedback. Reduce task demands when margin falls rather than allowing integrators or optimization slack to grow silently. Validate across battery voltage, payload, warm joints and degraded communication.
Validate tasks, disturbances and fallback states
Build tests from static stance to coordinated reach, contact transitions, locomotion and external disturbance. Compare desired and measured base motion, contact wrench, task errors, friction margin, joint limits, actuator saturation and solver health. Repeat across payload, floor and state-estimator variations.
Fault tests should include lost contact, stale state, sensor dropout, optimization timeout and drive fault. Independent protective functions and workspace limits remain necessary. A controller that appears compliant or balanced in nominal conditions is not automatically a validated safety function.
- Define the actual command and feedback interfaces.
- Validate timestamps, frames and contact state.
- Separate hard constraints from soft task objectives.
- Monitor solver, slack and actuator saturation online.
- Test contact transitions and bounded fallbacks explicitly.
Frequently asked questions
Is whole-body control only for humanoids?
No. It also applies to quadrupeds, mobile manipulators and other robots whose contacts and subsystems must be coordinated.
Does WBC always output joint torque?
No. Depending on the stack, it can output acceleration, velocity, position, contact force, torque or a command decoded by lower layers.
What is the difference between task weights and priorities?
Weights trade objectives in one cost and are sensitive to scale; hierarchical priorities preserve higher-level tasks before optimizing lower levels.
Can a learned policy replace contact constraints?
It may learn contact behavior, but deployment still needs state validation, actuator bounds, failure detection and independent protection appropriate to the risk.
What should be logged during WBC tests?
Log state and contact estimates, task errors, contact wrenches, commands, saturation, solver status, timing, slack and fallback transitions on one clock.
Whole-Body Control Boundary Note
Whole-body control is only as reliable as its state, contact, model, solver timing and actuator interface. Use independent protective limits and validate nominal, transition, disturbance and fault behavior on the complete robot.