hopper-brisk-robust

That stopped background task was an old wait loop, polling the log of an earlier parameter search that I had already killed. Nothing depended on it, so I'm not restarting it. The submitted `/app/work/controller.py` is unchanged and still passes the full gate on the visible seeds.

That stopped background task was an old wait loop, polling the log of an earlier parameter search that I had already killed. Nothing depended on it, so I'm not restarting it. The submitted `/app/work/controller.py` is unchanged and still passes the full gate on the visible seeds.

The 60 minutes are up and the controller does **not** pass the gate, so it will score zero. On the visible seeds 0–9 it fails two of the requirements: | Requirement | Result (seeds 0–9) | |---|---| | Nominal, reaches 10 m in 8 s (≥ 0.9 of seeds) | 1.00 ✅ (never falls) | | Low friction | 1.00 ✅ | | Weak motors | 1.00 ✅ | | High gravity | 1.00 ✅ | | Heavy torso | **0.60 ❌** | | Nominal mean return ≥ 2500 | **2398 ❌** (about 11.6 m) | **What's in `/app/work/controller.py`:** a linear state-feedback law, `u = clip(K @ s, -1, 1)`. `s` is the 11-value Hopper observation, each value scaled by a typical size and clipped, plus a foot-contact flag and a constant. That makes it two control laws, one for stance and one for flight, with no timing clock. The 3×13 gain matrix `K` was found by CMA-ES, a search that uses no gradients and no neural network. Each candidate was scored on all five plants (nominal plus the four changes). The docstring explains what each group of gains does. **How I got here:** 1. **Hand-built hopping logic, tuned automatically:** the search always settled on standing still (return about 1050, no forward motion). 2. **Why that design fails:** the hip and knee can only rotate backward, and the hip sits at its 0 limit in stance. So the knee can barely crouch, and the crouch-then-thrust stance I'd designed can't work. 3. **Linear law, first stage:** I left out most of the per-step survival bonus, so the search was paid for forward progress rather than for standing.…

The final controller is in place at `/app/work/controller.py`, verified with the official evaluator on the same file. **Outcome.** The gate is not fully met. The submission passes the nominal plant and two of the four sibling scenarios, and fails weak motors and low friction. | Scenario (seeds 0-4, official evaluator) | brisk rate | return mean | |---|---|---| | standard_v0 | 1.00 | 2672 (gate 2500: pass) | | heavy_torso_20 | 1.00 | | | gravity_high_10 | 1.00 | | | weak_motors_20 | 0.00 | | | low_friction_30 | 0.00 | | On seeds 0-9 the same three scenarios are 10/10, with nominal distance about 13.4 m. **What the controller does.** A stance/flight state machine with no learning. In stance the hip holds torso pitch with a PD loop, the knee compresses then thrusts with a constant torque, and the ankle balances the thigh angle over the foot and adds a toe-down push when the hopper exceeds its target speed. In flight the hip holds attitude, the knee pre-bends for landing, and the ankle sets the sole parallel to the ground with a toe-up offset. The docstring explains each gain. **What I found along the way.** The foot sits behind the hip whenever the torso leans forward, positive ankle torque rocks the body onto its heel, and the long foot acts as a third leg segment. The heavy leg means the hip cannot reposition the foot in flight, so leg placement comes from stance-end ankle pushes. The resulting gait is very parameter sensitive: a multi-scenario evolution strategy over 18 …

The controller in `/app/work/controller.py` does not pass the gate, and this submission will score zero. On visible seeds 0–4 it stays upright on 4 of the 5 scenarios but reaches only about 8.3 m on the nominal plant (return 2032 against the 2500 needed). The gate needs 10 m on 90% of seeds in every scenario. **Official evaluator results (seeds 0–4, brisk mode):** | Scenario | Alive | Brisk (≥10 m) | |---|---|---| | standard_v0 | 5/5 | 0/5 (~8.3 m, return 2032) | | heavy_torso_20 | 5/5 | 0/5 | | low_friction_30 | 5/5 | 0/5 | | weak_motors_20 | 3/5 | 3/5 | | gravity_high_10 | 5/5 | 0/5 | **How it works:** each joint gets a sine-wave oscillator (about 1.5 Hz) plus feedback: - **Hip:** a pitch PD keeps the torso inside ±0.2 rad. In stance, pushing the thigh backward both rights the torso and drives the body forward. - **Knee:** held mostly straight, so the leg acts like a stiff pogo stick. - **Ankle:** the oscillation gives a toe-down push that launches each hop, and a speed term leans the body forward when it is going too slowly. The docstring explains every gain. I tuned the 18 gains with a black-box search (CMA-ES) across all five scenarios; no network or policy was trained. **What went wrong along the way:** - Every search that rewarded survival settled on the robot standing still (return about 1040). That was true for the contact-switching controller and for a plain linear feedback law. - Scoring distance only, with the oscillator structure, produced real hopping withi…