Fallen with a Table Above: ROOF Teaches Humanoids to Make Room Before Standing

· Editorial Team estimated
humanoid fall recovery reinforcement learning contact guidance whole-body control

When a humanoid falls beneath a low obstacle, getting up is not a standalone skill: it must create clearance and organize support at the same time, because rising too early drives the obstacle further down. ROOF uses reinforcement learning with contact-supported geometric escape guidance, rewarding incremental reduction of robot-obstacle overlap without prescribing an escape path. A learned motion prior plus posture-dependent support and joint-stall costs shape one policy that handles the whole sequence from proprioception alone. Simulation recovery reaches 88.5% under plates that can only be lifted (18.9% without geometric guidance) and 98.6% under free plates with randomized size, mass, and placement; on a Unitree G1 the policy recovered in 95 of 150 attempts across seven real obstacle scenes.

Paper · arXiv:2610.42097

Humanoid fall recovery is usually framed as standing up from the floor: given flat ground and a known posture, learn a rising motion. Real environments are less polite. Something is often overhead — a desk, a chair, a shelf, a stack of boxes. The problem then becomes coupled. The body needs room to rise, and room can only come from moving or pushing the obstacle, yet rushing to stand drives the shoulders and back into it and jams things worse.

ROOF targets exactly that coupling. It does not assume the robot knows where the obstacle is, and it does not hand it a prescribed escape route.

Core innovation

Reward reduced overlap, not a particular maneuver. The central design is a geometric guidance term that rewards incremental reduction of the overlap volume between robot and obstacle, without specifying how to reduce it. The distinction matters. Prescribe “roll left” and the policy learns only to roll left. Reward overlap reduction and the policy can discover pushing, wedging, sidestepping, and twisting on its own, and those solutions transfer to arrangements it has never seen.

One policy, three phases. The system must learn when to clear the obstacle, how to establish stable support, and when the rise can be completed. These are coupled in time, and training them separately then stitching them together usually fails. ROOF covers the whole sequence with a single policy and switches phases through reward shaping rather than a state machine.

Posture-dependent support and joint-stall costs. Rewarding overlap reduction alone invites cheating, such as forcing through in a configuration that cannot bear load. A posture-dependent support term pushes toward genuinely load-bearing shapes, while a joint-stall cost discourages trading displacement for stalled joints — a maneuver that works in simulation and burns motors or gearboxes on hardware.

Proprioception only. The policy uses no external vision. It works from proprioception alone, which is the pragmatic choice: after a fall, cameras are often occluded, misoriented, or pointed at the floor. Contact becomes the sensor.

A learned motion prior supplies the starting distribution. Exploring the long sequence of fall, clear, and rise from scratch is hopeless. A learned motion prior keeps exploration near plausible human motion, and the cost terms above shape the final behavior.

Results

  • In simulation, 88.5% recovery under plates that can only be lifted, versus 18.9% without geometric guidance.
  • 98.6% recovery under free plates with randomized size, mass, and placement.
  • On a Unitree G1, 95 successful recoveries out of 150 attempts across seven real obstacle scenes.
  • The real scenes include furniture and multi-object arrangements that were absent from training.

The 18.9% to 88.5% comparison carries the paper. It shows the gain comes from the geometric guidance term rather than from a stronger RL algorithm. The 98.6% free-plate result says that when the obstacle can be pushed aside the problem collapses to an easier one; the hard case is the plate that can only be lifted.

The hardware number deserves a plain reading: 95 of 150 is about 63%, which is not product-grade reliability. Given zero-shot transfer to unseen furniture arrangements with proprioception only, it does show the approach works. It also honestly exposes the remaining sim-to-real gap.

Limitations

At 63% real-world success, roughly one attempt in three fails, and a failed humanoid recovery can cause secondary damage. That is not yet deployable. Proprioception-only sensing means the robot must discover the obstacle by contact, and the abstract reports no recovery time; blind probing could be slow and could damage either the obstacle or the robot. Seven scenes remain a small sample, with floor material, obstacle stiffness, and slopes uncovered. No comparison against other fall-recovery methods appears, so the relative standing of 88.5% is unclear. The support and stall terms are hand-designed, with no sensitivity analysis on their weights. The 55 hardware failures are also not broken down by phase.

Industry implications

For humanoid makers, this fills an underrated safety case. Current demonstrations happen on open floor, while customer sites are full of desks, racks, conveyors, and stacked goods. A robot that walks and carries well but cannot get up from under a table will not pass site acceptance. The reward design here can be reused directly in a recovery module, and it requires no extra perception hardware.

There is a training-paradigm consequence as well. Rewarding reduced geometric overlap rather than demonstrating escape trajectories cuts the data requirement sharply: nobody has to teleoperate a catalogue of awkward escapes. For teams trying to cover long-tail failure modes, that is a cheaper way to scale, and the same recipe should extend to being stuck in a corner or tangled in cabling.

The last lesson is about proprioception. At the moment vision is least trustworthy, joint current, IMU, and foot contact are enough to drive a complex maneuver. That argues for treating proprioception as a primary sensor in safety-critical behavior rather than a backup, which has direct implications for sensor suites and compute allocation.