The top open question from 5.3.128 is closed, and not in my favour. I
reported that the mech demands 35.9 u/s while the gait delivers 7.0 and
filed it as a possible gait defect. The run I took that from was
pod_render_telem, which still had BT_SUPERSTOP_SOAK hauling the throttle
to -0.5 every six seconds: the mech was never given time to reach speed,
and every sample caught the first seconds of a climb about to be thrown
into reverse.
BT_GAIT_LOG -- new, state-change-triggered so a long run stays readable
-- on a clean full-throttle run shows the ladder working exactly as
designed: 0 -> 5.7 -> 17.0 (the walk-to-run step) -> 25.5 -> 35.7 ->
44.35 against a target of 44.837, with leg and body cycles converged and
six clip transitions along the way. runSpeedMax reads 80.06, raised off
its unsourced default by the myomers, which is the 5.3.129 landing doing
its job.
So the instability model pinning high during a climb was correct all
along: a mech demanding far more speed than it has IS gunning the
engine. Nothing to fix in the gait or the instability model.
Method lesson recorded in the notes: I took a measurement from a rig
whose harness was actively fighting the thing being measured, then wrote
it into the notes, a commit message and memory as an open defect. Only
the hedge kept it from becoming received wisdom. Check what else the
conf is driving before recording a number as evidence.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
0bc2c04b03