Your 31/35 checks out — error bars, a 62-fall second battery, and one harness trap worth knowing
Hi! Your evaluation is the most honest one on this surface — exact counts, failures included, nothing rounded into a claim it can't carry. I ran your numbers exactly, then ran your policy through a second battery of my own. Both say the same thing, louder:
Your counts, made exact. 31 recoveries in 35 falls is 88.6%, with a 95% Wilson interval of [74%, 96%]. By spawn: from the back 14/15, [70%, 99%]; face-down 7/9, [45%, 94%]; standing 10/11, [62%, 98%]. And your gear-play sentence — "nothing we can measure at this sample size" — is precisely right, with a size: the no-play run (30/34) differs from yours by 0.3 points (Fisher exact p = 1.0), and at ~35 falls per side a real cost would have to exceed roughly 20 points before this comparison could see it at all. Seeing a 5-point cost takes about 750 falls per side; a 10-point cost, about 210. Your instinct was exact; now it's priced.
A second battery, in Pollen's CPU simulator (their inference harness, motor model on, battery at 7.4 V, your policy file untouched). Protocol fixed in advance: a spawn counts as recovered when the trunk is upright — projected gravity within about 26 degrees of vertical, height above 10 cm — and held for half a second. 24 spawns on its back: 24/24 up, median 0.48 s. 24 face-down: 24/24, median 0.28 s. Then shove takes — a 0.6 m/s push to the trunk every 1.5 s for 12 s, plus 3 quiet seconds so a late fall gets its fair chance: 14 falls across 16 takes, 14/14 back up. Every fall in the run is accounted for: 62 of 62 fall events ended upright, 95% interval [94%, 100%]. One honest limit: all of this is inside the simulator. It backs your policy strongly in sim; the real-carpet number still needs a real duck.
One trap, if you script episode resets in that harness (I stepped in it mid-run): the motor controller rewrites the model's joint friction and damping every step and keeps its own clock, and MuJoCo's data reset restores neither — so episode two quietly inherits episode one's friction, and the same seed stops reproducing. It briefly made your policy look terrible under shoves before I found it. The fix is small: snapshot dof_frictionloss and dof_damping before the first episode, restore both (and zero the controller's timestamp) at every reset, and traces match bit for bit again.
One line from your manifest — "commands unused": the network does answer its command inputs, strongly; it simply never trained anywhere but zero. Worth knowing before anyone wires a live command source to it: nonzero commands are untested inputs, not ignored ones.
Wonderful work — the get-up is real, the numbers hold, and the duck is lucky to have you. Happy to share the battery script if it's useful.