humanoid-robust

The walking controller is done and passes the gate on every scenario I tested. On 120 seeds per scenario, none of them used for tuning, all 600 episodes stayed upright for the full 15 s and every one passed the 3 m gate. | scenario | seeds 30–149 | shortest distance (3 m needed) | |---|---|---| | standard_v0 | 120/120 | 9.25 m | | heavy_torso_20 | 120/120 | 8.92 m | | low_friction_30 | 120/120 | 10.31 m | | weak_motors_20 | 120/120 | 9.48 m | | gravity_high_10 | 120/120 | 9.34 m | The official evaluator on seeds 0–4 gives success 1.0 on all five scenarios. It also reaches `brisk` (≥ 8 m) every time, though not `fast` (15 m). **How it works** (`/app/work/controller.py`): - **Start:** both legs on the ground for 0.3 s while the robot settles. - **Stepping:** the legs swap every 0.105 s, a fixed rhythm that doesn't wait for foot contact. The result is a quick shuffle at about 0.6–0.7 m/s. - **Foot placement:** the swing leg is aimed using how far the body is from the standing foot and how fast it is moving. This is what keeps it balanced forwards and sideways. - **Torso:** the standing leg's hip holds the torso slightly upright and pointed straight ahead. - **Knees:** nearly straight on the standing leg, bent to lift the swing foot. - **Abdomen and arms:** held stiffly in a neutral position. - **Weaker motors:** commands are scaled by each motor's actual strength, which offsets the weaker motors up to the ±0.4 limit. The hand-set version stepped every 0.36 s and fell within …

The walking controller is done and passes the gate on every scenario I tested. On 120 seeds per scenario, none of them used for tuning, all 600 episodes stayed upright for the full 15 s and every one passed the 3 m gate. | scenario | seeds 30–149 | shortest distance (3 m needed) | |---|---|---| | standard_v0 | 120/120 | 9.25 m | | heavy_torso_20 | 120/120 | 8.92 m | | low_friction_30 | 120/120 | 10.31 m | | weak_motors_20 | 120/120 | 9.48 m | | gravity_high_10 | 120/120 | 9.34 m | The official evaluator on seeds 0–4 gives success 1.0 on all five scenarios. It also reaches `brisk` (≥ 8 m) every time, though not `fast` (15 m). **How it works** (`/app/work/controller.py`): - **Start:** both legs on the ground for 0.3 s while the robot settles. - **Stepping:** the legs swap every 0.105 s, a fixed rhythm that doesn't wait for foot contact. The result is a quick shuffle at about 0.6–0.7 m/s. - **Foot placement:** the swing leg is aimed using how far the body is from the standing foot and how fast it is moving. This is what keeps it balanced forwards and sideways. - **Torso:** the standing leg's hip holds the torso slightly upright and pointed straight ahead. - **Knees:** nearly straight on the standing leg, bent to lift the swing foot. - **Abdomen and arms:** held stiffly in a neutral position. - **Weaker motors:** commands are scaled by each motor's actual strength, which offsets the weaker motors up to the ±0.4 limit. The hand-set version stepped every 0.36 s and fell within …

`/app/work/controller.py` walks forward and stays up on most seeds. It does not clearly clear the 0.9 gate, so the task may not count as solved. I tested it on 15 seeds (10–24) that the parameter search never used: | Scenario | `forward` success rate | |---|---| | `standard_v0` | 1.00 | | `heavy_torso_20` | 1.00 | | `low_friction_30` | 1.00 | | `weak_motors_20` | 0.80 | | `gravity_high_10` | 1.00 | `weak_motors_20` is below the 0.9 gate on this sample. With 15 seeds a single failure moves a rate by about 0.07, so the true rate could land on either side of 0.9. I also tried a later search candidate. It was no better: the weak-motors rate rose to 0.93 but `gravity_high_10` fell to 0.80. I kept the first one. On the visible seeds the controller reaches about 6 m of forward progress per episode and returns around 5400 on `standard_v0` seed 0. It walks well past the 3 m `forward` rung, but I did not measure it against `brisk` (8 m) or `fast`. **How it works.** It is a hand-structured stance/swing state machine in the style of SIMBICON, with no learning. The docstring in `controller.py` explains each gain. - **State machine:** the stance leg alternates by timer or by swing-foot touchdown. - **Stance leg:** it keeps the torso upright by feeding torso pitch and roll back to the stance hip torque. - **Swing leg:** the swing foot is placed from the centre-of-mass offset and velocity error. - **Other joints:** the abdomen and hip yaw hold heading, and the arms are held in a fixed …

The 60-minute budget is nearly spent (started 23:33, now 00:12 with the last tuning and variant rounds showing only noise-level changes), so I'm stopping here with an honest report. **Outcome: the submission does not pass the gate.** The final controller at `/app/work/controller.py` keeps the humanoid stepping for about 4 s on average and up to 9 s, but never the full 15 s, so the `forward` rung is 0/5 on every scenario. Final evaluator numbers on seeds 0 to 4, standard plant: | metric | value | |---|---| | alive / forward rate | 0 / 0 | | mean episode length | 274 steps (4.1 s) | | mean mass-centre progress | 1.3 m | | flight fraction | 10 % | The four sibling scenarios also fail 5/5. **What the controller is.** A hand-designed Raibert-style stepping controller, no learning. A step clock alternates stance and swing legs. The stance leg holds the pelvis attitude through its hip torques and supports the weight with a gravity feed-forward plus a soft knee PD. The swing leg is placed by a capture-point law relative to the mass centre, computed in the body's heading frame, with the swing hip position estimated from the stance foot and leg forward kinematics and converted to hip angles by a knee-compensated virtual-leg inverse kinematics. Twelve gains were searched with the tune tool over ten rounds. The docstring documents every constant. **Findings that mattered, in order of impact.** - The feet are spheres with no ankle, so standing is impossible and balance comes only fr…