Section 46.8: Advanced humanoid dynamics and contact mechanics

"Operational space is the wish. Whole-body control is the bill."

A Field-Tested Control Loop

Why The Specialist Layer Matters

Slow the earlier warehouse fall down to a single millisecond and you find a fork: the same foot that was a stable anchor is now a slipping liability, and whichever model the controller trusts in that instant decides whether the robot recovers or hits the floor. That fork is a friction-cone question in disguise (a contact force is only physically realizable if it stays inside the cone of directions the floor's friction can support; the section below on centroidal dynamics defines this precisely). This section adds the mechanical depth required to reason about that instant like a serious humanoid researcher: reduced-order models for planning, full multibody dynamics for execution, contact mode reasoning, and controllers that remain stable when hands, feet, hips, and torso all matter. Figure 46.8A captures the core difficulty: balance, payload, contact, and recovery must all be coordinated at once, which is why whole-body control cannot be decomposed into hand motion or footstep motion alone.

The key abstraction is a hierarchy of models. A planner may reason over center of mass, centroidal momentum, footstep locations, and hand contact targets. A whole-body controller then maps those targets into joint torques or position commands while satisfying contact, friction, joint, actuator, and balance constraints, drawing on the operational-space control foundations from earlier in this chapter. Figure 46.8B lays out this hierarchy end to end: the task planner hands centroidal references to the whole-body QP, which commands the humanoid hardware, while contact perception closes the loop back to both stages at each control tick.

Centroidal Dynamics And Balance

For a humanoid of mass \(m\), center of mass position \(c\), total linear momentum \(l\), and angular momentum \(k\), the centroidal dynamics summarize the whole robot as:

$$\dot c = \frac{1}{m}l, \qquad \dot l = mg + \sum_i f_i, \qquad \dot k = \sum_i (p_i - c) \times f_i + \tau_i.$$

The contact point \(p_i\), contact force \(f_i\), and contact torque \(\tau_i\) are the bridge from geometry to behavior. If the required force exits the friction cone, the plan is not merely suboptimal. It asks the robot to push on the world in a direction the world will not support. A centroidal plan that looks elegant on paper becomes a fall on hardware the moment friction runs out.

Consider a concrete case: an Atlas-class humanoid (roughly 80 kg) carries a 10 kg box with both hands. Accelerating the center of mass at \(0.3\,\text{m/s}^2\) horizontally requires a total linear momentum rate of \(\dot l \approx 27\,\text{N}\). On a surface of friction coefficient \(\mu = 0.6\), each of the two foot contacts supplies at most \(0.6 \times \frac{(80+10) \times 9.81}{2} \approx 265\,\text{N}\) of horizontal friction, well above the demand. Now suppose a foot begins to slide and effective \(\mu\) drops to \(0.15\) (polished floor, wet tile). The per-foot limit falls to roughly \(66\,\text{N}\), and the angular momentum term from the shifted payload can push the required force outside the reduced friction cone. The centroidal planners in the MIT Humanoid and in Boston Dynamics Atlas research check this feasibility constraint before committing to a step.

That control loop assumes each contact holds a single fixed role, but the moment a task asks the robot to walk and manipulate at once, those roles start trading places, and the loop must reason about limbs as reconfigurable resources.

Contact-Rich Loco-Manipulation

Loco-manipulation begins when walking and manipulation stop being separable. A carried load reshapes the support polygon (the convex hull of all ground contact points, which bounds where the center of mass can sit without tipping), the feasible torso motion, the footstep plan, and the hand force budget at once. Opening a door couples all four: one hand pulls, one foot repositions, the torso rotates, and the controller holds balance while the hinge imposes a moving constraint.

A serious system therefore treats limbs as resources. A hand may be an end-effector, a brace, a sensor, or a temporary support. A foot may be a locomotion contact, a push contact, or a stabilizing anchor. The whole-body control literature calls this role-switching behavior the limb-as-resource abstraction (see, e.g., Sentis and Khatib, 2005; Hutter et al., 2016), and interlimb coordination is the policy that assigns these roles over time.

This abstraction matters because a humanoid has a fixed torque budget across all joints. Committing a limb exclusively to one role (e.g., always treating a foot as a locomotion contact) wastes support capacity during manipulation and leaves recovery options unavailable when a perturbation arrives. In one sim-to-real carry study on the Unitree H1, fixing every limb to a single role produced a fall rate of roughly 1 in 3 trials under an 8 cm payload shift; enabling role-switching in the QP's active constraint set brought that fall rate below 1 in 20 under the same perturbation, though the exact ratio is specific to that platform and perturbation and should not be read as a universal constant. On a real robot, the consequence is a fall or a dropped payload that a correct role assignment would have prevented.

Mechanically, the whole-body QP treats each limb contact as an optional constraint. The solver activates or deactivates contact force variables depending on which roles the policy assigns at a given instant. A foot declared as a stabilizing anchor adds a normal-force inequality to the QP; the same foot declared as "free" adds nothing. The interlimb coordination policy therefore acts as a discrete mode selector. It reconfigures the QP's active constraint set at each planning horizon, so the controller can shift support from feet to hands and back as the task evolves.

Since that contact-schedule mismatch is where most sim-to-real carry policies break, the practical recipe below front-loads the contact schedule and its feasibility checks before any policy is trained.

Practical Recipe

1. Start with a constrained task, such as pick, carry, place, or door traversal.
2. Write the contact schedule and identify which contacts are required, optional, or forbidden.
3. Plan footsteps, hand contacts, and object motion with centroidal feasibility checks.
4. Use Drake, MuJoCo, MJX, Isaac Lab, or Pinocchio to verify dynamics and constraints.
5. Train or adapt a policy only after the model-based baseline exposes the physical limits.
6. Evaluate with pushes, payload changes, object pose shifts, friction changes, and perception latency.

# Minimal evidence schema for whole-body humanoid research.
from dataclasses import dataclass, asdict

@dataclass
class HumanoidTrial:
    task: str
    contact_schedule: list[str]
    controller: str
    perturbation: str
    metrics: dict[str, float]

    def as_row(self) -> dict[str, object]:
        return asdict(self)

trial = HumanoidTrial(
    task="carry object while stepping over a low obstacle",
    contact_schedule=["left_foot", "right_foot", "left_hand_object", "right_hand_object"],
    controller="centroidal planner plus whole-body QP",
    perturbation="payload shifted by 8 cm during mid-step",
    metrics={"com_error_cm": 3.4, "max_foot_slip_cm": 0.7, "recovery_time_s": 0.42},
)
print(trial.as_row())

Expected output interpretation. The printed record is valuable because it binds the contact schedule, controller class, perturbation, and recovery metrics into one artifact. If the same carry task later fails on hardware, this exact schema tells the team whether the miss came from contact planning, controller feasibility, or disturbance recovery.