pendulum-hold-delay-36
Inverted pendulum swing-up · solvedexploration 9 of 9 agent attempts pass
Exploration task. Built after the paper's sweep to test whether a task can force a mechanism outside the catalogue (docs/exploration_new_mechanisms.md, docs/soft_arm_spec.md). Not part of the benchmark tiers or of the paper's main counts; the soft arm is reported in the paper as a plant outside the sweep, the other tasks are not; all sessions ran under the paper's protocol.
more
For the upright linearisation (unstable pole p = 3.13 rad/s) the delay margin of every linear time-invariant controller, Smith predictors and finite-spectrum assignment included, is at most 2/p = 0.64 s (Middleton and Miller, IEEE TAC 2007); this delay exceeds it, so no LTI design can hold the upright and only a nonlinear or time-varying law could (such laws exist in theory for arbitrary delay, Gaudette and Miller, but no constructive recipe is standard). Under the 2 N m torque limit the task may be infeasible; that is what it asks. The 22-sample sibling (pendulum-hold-delay) was solved 9/9 with a model-based predictor.
Gate. per-seed success is the `terminal` rung of this benchmark's ladder ['achievement', 'terminal'] (`--success-mode terminal`), not the evaluator's default flag; the task is solved when the success rate over the grader's held-out seeds is `>= 0.9`
Axes: dynamics:pendulum, actuation:torque-limited-swingup, sensing:delay-36-samples, gate:terminal-hold-150, exploration:new-mechanism, provable-limit:any-LTI-controller
Each video re-runs the attempt's final controller through the task's own evaluator on a public seed (never the grader's held-out ones). The table under each video is the official grade on the held-out seeds.
base| criterion | graded | needed |
|---|---|---|
| base:terminal | 1.000 | ≥ 0.900 |
The agent's final message
`/app/work/controller.py` now passes the gate. With the official evaluator on seeds 0–19 it succeeded on 20 of 20 under terminal mode. A separate run of my own simulator on 100 other seeds also succeeded on 100 of 100. **Why it works:** the plant is deterministic and the controller knows every torque it has sent. So it takes the 36-step-old measurement and replays the stored torques through the nonlinear model (RK4, zero-order hold). That recovers the current state exactly. The Middleton–Miller limit applies to LTI controllers; this replay is a nonlinear reconstruction that doesn't fall under it. History resets at `step == 0`. **Control law on the reconstructed state:** - **Swing-up:** energy pumping, `u = clip(K_E·(g + E_OFF − E)·sign(θ̇))`. Aiming slightly above upright energy (`E_OFF`) stops the pendulum stalling just short of the top, which was the main failure at first. - **Catch:** discrete LQR once the state is inside the ellipse `xᵀPx < C_IN`. I found by simulation that LQR stays stable under the ±2 torque limit up to about 100–200, so I set `C_IN = 90`. The gains are `K_E = 5`, `E_OFF = 0.3`, `C_IN = 90`, with LQR weights Q = diag(10, 1) and R = 1. A random search found many settings that scored 100%, and I picked a middle one rather than an edge case. The session used about 3 minutes of the 60. Scratch files (`sim.py`, `search.py`, `val.py`, `region.py`) are left in `/app/work`. They are not graded.
The controller reconstructs the current pendulum state by rolling the delayed observation forward with previously sent torques, then pumps energy toward the upright level until the predicted state enters an LQR value-function ellipse, where a discrete LQR stabilizes it.
Shown: public seed 0 (base); this episode passes the terminal rung. This episode: final_upright_error 1.44e-07, final_abs_velocity 7.16e-06, success_hold_steps 150, total_reward 15.
controller.py · agent transcript · trial pendulum-hold-delay-36__PLRyoaU