humanoid-fast-handoff

`/app/work/controller.py` now clears the `fast` gate: the official evaluator passes 20 of 20 visible seeds, and my own in-process sweep passes 599 of 600 seeds (0–599), with the single miss at 14.99 m. **What was wrong with the inherited walker.** Its gait is a high-cadence shuffle whose limit cycle already runs at about 1.2 m/s, but it took 4 to 6 s to reach that speed, and the start-up time varied chaotically with the 1 cm initial noise. Mean distance was 15.0 m, so half the seeds landed just under the line. Every attempt to raise the terminal speed (higher target speed, more lean, speed-scheduled offsets, step timing, swing-knee flexion, abdomen assist, torso-priority torque allocation) toppled the robot, because both hips saturate at 120 N m on every swing and any extra demand cancels the stance hip's torso-pitch authority. **What I changed.** No structure, only five gains, each validated on 144 to 336 fresh seeds before being kept: | Gain | Before | After | Effect | |---|---|---|---| | `kp_t` / `kd_t` (torso pitch PD) | 394 / 48.5 | 250 / 47 | softer loop frees hip torque, faster start-up | | `pitch_d` | 0.0075 | 0.02 rad | slight forward lean | | `cd` with `v_d` | 0.41 / 0.69 | 0.52 / 0.71 | stronger offset feedback permits a higher speed offset | | `cv_lat` | 0.34 | 0.30 | removed the remaining lateral trips | Mean distance went from 15.0 m to 15.8 m and the minimum over 600 seeds from 14.1 m to 14.99 m. The docstring documents the gait's limits and the role of eac…

The controller in `/app/work/controller.py` probably does not meet the 0.9 gate. On three sets of 24 held-out seeds it passed `fast` on 83%, 96% and 96% of seeds, about 92% on average. The stated gate needs 0.9 on the grader's seeds, so a pass is possible but not certain. I'm stopping because the 60-minute budget is nearly spent by `date`. **What I changed:** only the numbers in `PARAMS`. The inherited controller reached about 14.8 m in 15 s, just short of the 15 m `fast` threshold. The built-in tuner scored every candidate `fast` or not `fast`, so it found nothing. I wrote my own random local search, `search.py`, that scores on distance travelled instead. That found parameters that clear 15 m on most seeds. The control law is unchanged. **What went wrong:** - The remaining failures are early falls at roughly step 40, where the robot pitches forward by about 1 rad. - I tuned on seeds 0–7. A second set of parameters, tuned on seeds 100–123, did no better on average, so I kept the first. I only ran the nominal scenario (`standard_v0`) and did not test the perturbation scenarios. The original controller was 40–42% on `fast`, with most failures just under 15 m.