AutelicaLearnRope-net climbing

Can a simulated humanoid climb a rope net?

A rope net is the kind of place a legged robot will eventually have to cross: soft, irregular, all contact. We filmed a person climbing one, measured the net from the same footage and asked how much of that climb a humanoid can reproduce.

By AutelicaUpdated 8 min read

The short answer

From one three-drone capture of a person climbing a 3.9 m rope-net pyramid, a Unitree G1 retargeted to the climb keeps its hands and feet on the ropes in 91–93% of hold frames (against 12–31% when the person’s hand and foot positions are copied directly), with 95th-percentile joint speeds falling from 15–22 to 2.0–2.8 rad/s. That is kinematic. In MuJoCo physics, a G1 policy trained on the climb finishes the 27-second on-net part of it in 6 of 6 runs when a support force at the pelvis is capped at 1× body weight (it uses 0.56× on average), climbs 1.17 m above its start (from 1.46 to 2.63 m) with half that cap, and does not climb without support. The net in physics is simplified: it is rigid, grasps are springs and the ropes do not collide with the robot.

01The climb we captured

On October 17, 2026 we filmed one person in a public park with three consumer drones for about eighteen minutes (the full capture). Part of that was three climbs up a rope-net pyramid around a 3.87 m pole, 30 to 36 seconds each, with the highest hand hold at 3.45 to 3.68 m. From the same footage we measured the person’s 3D body and the net itself, and built the net, the ground and the nearby objects into a MuJoCo scene.

We looked for published work on a humanoid robot climbing a rope net, in simulation or on hardware, and did not find any. The closest is ladder climbing, for example LadderMan (arXiv 2606.05873), where rungs are rigid and evenly spaced. A rope net is neither, and it moves when you pull on it.

02Step 1: put the climb on the robot

The first attempt copied where the person’s hands and feet were onto a G1. It looks wrong straight away. The G1 is 1.32 m tall and reaches about 0.72 times as far as the person, so a hold that the person reached sits somewhere in the air for the robot. The limbs miss the ropes, and the solver flails to chase targets it cannot reach.

The fix was to treat the holds as the thing to preserve. The retarget keeps the person’s hold sequence and timing, and moves each contact to a point on the measured net that the robot can reach (a median shift of 9 to 14 cm).

Kinematic replay (no physics), climb 3. Left: the person’s hand and foot positions copied directly. Right: the same holds, moved to points on the net the robot can reach. Simulation render.
Unitree G1, kinematicClimb 1Climb 2Climb 3
Hold frames (per limb) more than 5 cm off the net88% → 9%69% → 7%72% → 8%
Hold-to-rope distance, median / 90th percentile10.3 / 17.7 → 0 / 3.0 cm8.4 / 19.0 → 0 / 2.6 cm8.5 / 25.8 → 0 / 3.8 cm
Joint speed, 95th percentile15.0 → 2.8 rad/s19.4 → 2.2 rad/s22.4 → 2.0 rad/s
Highest hand hold of the person (reference)3.45 m3.57 m3.68 m

The same retarget on a Unitree H1-2, which is closer to human size (the retarget scales the person by 0.94 to 0.98, depending on the climb), does slightly better: limbs are off the net in 4 to 8% of hold frames, with the 90th-percentile hold distance at 0.4 to 4.0 cm.

03Step 2: how much help would it need?

A kinematic climb says nothing about whether the motors can hold the body there. Before training anything, we asked a simpler question for every frame: what is the smallest upward force at the pelvis that lets a G1, within its published joint torque limits, hold that pose on those holds?

Smallest support force, share of body weightClimb 1Climb 2Climb 3
Median over the climb, holds copied → re-planned62% → 44%27% → 0%52% → 8%
Frames needing less than 25%26% → 26%37% → 63%29% → 46%

Re-planned holds make the climb much cheaper to hold, and climb 2 needs no support for most of its frames. None of the three is cheap everywhere: the hard frames are where the robot hangs from its arms while moving a foot, and the G1’s wrists (about 5 N·m) and shoulders (about 25 N·m) are weak for that.

04Step 3: physics

We then trained a G1 policy in MuJoCo on climb 3 and tested it with a support force capped at four levels, 6 runs each. The support is a force at the pelvis, with a smaller torque, that pulls it toward the reference pose, up to the cap. Each level has one nominal run and five with randomised friction, mass, motor gains, control delay, sensor noise and start state (no pushes). The test covers the 27 seconds of the climb spent on the net, from a start with the pelvis at about 1.5 m. In this environment the net is rigid, grasps are abstract springs that engage near the scheduled holds (no fingers are simulated), and the ropes do not collide with the robot, so it is a coarse stand-in for a real net.

Physics simulation (MuJoCo), the same trained policy and the same climb. Left: support force capped at 1× body weight. Middle: 0.5×. Right: none. Only the left one reaches the top.
Three bar charts. Left and middle: for each of three climbs, the share of hold frames off the net drops from 69–88% to 7–9%, and 95th-percentile joint speed from 15–22 to 2–2.8 rad/s. Right: pelvis height reached in physics is 3.42 m with support up to 1× body weight (6 of 6 finish), 2.63 m at 0.5×, about 1.5 m at 0.25× and with none, against a 3.47 m reference.
Left and middle: kinematic quality for the three climbs. Right: physics, climb 3, highest pelvis height while still following the reference (within 0.5 m of it), median of 6 runs per support cap (one nominal, five with randomised conditions). The climb starts on the net at about 1.5 m.
Support cap (× body weight)General tracking policyTrained on the climb
1×0 of 6 finish; falls at 2.9 s, 1.66 m6 of 6 finish the 27 s climb, 3.42 m; 0.56× used on average
0.5×0 of 6; falls at 0.4 s0 of 6; falls at 6.0 s, 2.63 m
0.25×0 of 6; falls at 0.4 s0 of 6; falls at 1.9 s, 1.49 m
None0 of 6; falls at 0.35 s0 of 6; no climb (1.46 m)

Training on the climb is what makes the difference at full support: a general motion-tracking policy for the G1, tested in the same environment with the same grasps and support, falls within three seconds. The trained policy climbs the whole net and, on average, leans on 0.56 times its body weight. That is far more than the 8% median that the static check says climb 3 needs, for two reasons: the policy has to move and accelerate the body, not just hold poses, and its hands and feet latch onto only about half of the scheduled hold frames, so the support carries it through the rest. With half the support it climbs 1.17 m above its start, to 2.63 m, before falling. Without support it does not climb.

05What we take from it

  • Reach and grip decide this task, not the motion data. The person’s climb is fine as a reference once the holds are re-planned to the robot’s size. What stops the G1 is arm length and wrist and shoulder torque. A larger humanoid, or one with stronger wrists and shoulders, starts from a better place, and the H1-2 retarget already reaches better.
  • The support force is a useful difficulty measure. Per-frame support needed, and the cap at which a policy still finishes, say how far a robot is from a climb in numbers that can be tracked across robots and training changes.
  • The measurements carry over. The net geometry, the holds the person used and the timing all come from the same footage, so the scene and the reference agree with each other without hand placement.

06Limits

  • Everything robot-related on this page is simulation. No robot has climbed this net.
  • The physics net is simplified: grasps are springs at scheduled holds, the ropes do not collide with the robot, and the net is rigid, so it does not sag or swing under the robot’s weight the way a real one would. Results with a real net will be worse.
  • One person and three climbs of one net; the physics results are on one climb, with 6 runs per support level.
  • The support force acts at the pelvis and pulls toward the reference pose. A real robot would need a harness or gantry for that, and the test measures how much help the robot needs, not a way to climb.
  • The re-planned holds follow the person’s sequence. A robot that chose its own holds might climb with less help.

Questions

Can a humanoid robot climb a rope net?

Not unassisted yet, in our tests. In MuJoCo physics, a Unitree G1 policy trained on a captured human climb finished the 27-second on-net climb in 6 of 6 runs with a pelvis support force capped at its body weight (using 0.56× on average), climbed about 1.2 m with half that cap, and did not climb without support. The net was simplified: rigid, with grasps as springs and no rope collisions.

How do you retarget a climbing motion to a smaller robot?

Copying the person’s hand and foot positions fails: the G1 reaches about 0.72 times as far, so holds end up in mid-air and limbs miss the ropes in 69–88% of hold frames. Keeping the person’s hold sequence and timing but moving each contact to a reachable point on the measured net (a median 9–14 cm) brought that to 7–9%, with joint speeds dropping from 15–22 to 2.0–2.8 rad/s at the 95th percentile.

Has anyone published humanoid rope-net climbing before?

We searched in October 2026 and did not find published work on a humanoid climbing a rope net, in simulation or on hardware. The closest published work is on humanoid ladder climbing, where the rungs are rigid and regularly spaced.

What does the capture provide for a climbing task?

The person’s 3D body over the whole climb, the geometry of the net and the ground measured from the same footage, the holds and their timing, retargeted motion for the Unitree G1 and H1-2, and a simulation scene with the net, from three consumer drones and no markers.