Fable OSI Speedgoat overloading fix — validation report

2026-07-03 · model_ColumnSetup_00 · target IISL · base rate 2048 Hz (488.28 µs budget per tick)

1. The problem, reproduced on the target

The fable OSI + authority-factor runtime stopped the Speedgoat with a CPU overload when the dd pause switch was flipped to resume and the indicator started evaluating. Reproduction (actuator disconnected): the target ran 30 s paused with TET ≈ 50 µs, then died 5 s after resume with

Overload limit (0) exceeded in 0.000488281s (tid=0) rate with 1 overloads
TETMax = 780.2 us   (budget 488.3 us)

The 5 s delay is diagnostic: it is exactly when the 5 s slow-spectral ring first fills and the whole slow pipeline — two 2048-pt FFTs, medians over the 99×17 spectra ring, classification, residual branch and the 25×99 prediction grid — landed in a single base-rate tick, on top of the fast-path work and the TSE stiffness update that always shared the same tick (64 divides 256). The same burst design also explains the “sometimes it works until the fast drop” observation: whichever event first stacked the heavy branches into one tick (ring fill, calibration finalize, trips + prediction) pushed that tick over 488 µs.

2. The fix: time-sliced scheduling, identical arithmetic

No algorithm was weakened. fable_osi_runtime.m now executes one bounded pipeline phase per base-rate tick after each 0.125 s step boundary and publishes at a fixed 56-tick (27 ms) latency — negligible against the 0.125 s step cadence and the 0.25–0.5 s fast-trip spec:

Supporting changes:

• Stiffness estimation (TSE) decimated per the accepted trade-off: updates every 256 samples (8 Hz instead of 32 Hz), staggered to tick 128 of the OSI step so its 4×4 SVD + 3×3 pinv never share a tick with an OSI phase. Per-update accuracy unchanged; convergence is ~4× slower. (It did not have to be removed.)
• Indicator always on: the pause switch no longer feeds the OSI enable. The old OSI Runtime Mode Sum computed en = 2·dd_pause_enable − osi_gain_enable (the enable was subtracted — a sign bug); it is deleted and en now comes straight from the enable switch.
• New OSI Margins Scope on the slow (b_st), fast (b_fast) and selected (b_osi) indicators; the previous setup had no scope for the slow/selected margins, and with the pause wiring bug the outputs a scope would show were frozen at NaN. The three signals stay in File-Log columns 13, 15, 12.

3. Arithmetic equivalence (bitwise)

test_fable_runtime_equivalence compares the time-sliced runtime against the desktop fable_osi/fable_auth pair, sample-aligned across margins, branches, trips, authority and decisions:

4. On-target verification (physical Speedgoat, no actuator)

145 s protocol covering the calculation cases: always-on indicator from t = 0 (paused), first calibration + finalize at ~30 s, resume at 40 s (regime change → second calibration + finalize), authority law active at 60 s, pause again at 80 s (indicator keeps running), resume at 96 s, run to 145 s.

5. Programmatic overload test (no target needed)

OSI_tests/overloadin_test/run_overloading_test.m compiles the current runtime and the frozen pre-fix reference to host MEX, streams a 90 s worst-case signal through both, times every tick, and maps the worst host phase onto target microseconds using measured anchors (pre-fix: 793 µs host ↔ 780 µs target; worst per-phase scale 2.1 from the slow-FFT phase). PASS requires the predicted worst tick under 75% of the budget. Current runtime: PASS (predicted ≈ 330 µs conservative vs 278 µs measured; pre-fix predicts ~1700 µs and fails loudly). Run it before any target run after touching fable_osi_runtime.m.

6. Ten synthetic closed-loop cases: pre-fix vs time-sliced

The fable_synthetic_suite ground-truth bench (known true chordal margin at every update). Copperwood = pre-fix burst, blue = time-sliced, black dashed = true margin.

7. Actual data cases (hardware records)

The three saved records replayed through both implementations, step-aligned:

8. Authority factor: scale the PID gains or the command signal?

Keep multiplying the command signal (the existing Apply OSI gain Product), for three reasons:

1. Safety semantics. When authority sheds during an event, multiplying the output instantly attenuates everything the controller has already built up — including the integrator state. Scaling the gains only changes how future error is processed: the accumulated integrator output keeps driving the actuator at full strength until it discharges, so an oscillation is arrested more slowly. For a stability-protection device the immediate effect is the point, especially on the fast-drop path.
2. The prediction math assumes it. The fable authority-planning curve evaluates margins for α·L(jω) — a scalar on the whole open loop. Multiplying the command is exactly that; scaling the gains matches it only in steady state.
3. Steady-state equivalence. With a constant factor the two are the same linear loop, so nothing is gained by moving it.

One caveat to watch: during a long deep shed the integrator can wind up (its output is attenuated while the error grows), which can overshoot when authority recovers. The fable law’s slow, latched recovery largely absorbs this; if it ever shows in tests, the right fix is back-calculation anti-windup on the PID using the post-product command — not moving the multiplication to the gains.

9. Files touched

• control_and_HS/OSI/fable_osi_runtime.m — time-sliced scheduler (arithmetic unchanged)
• model_ColumnSetup_00.slx — en wiring (always-on indicator), TSE decimation/stagger, OSI Margins Scope
• OSI_tests/fable/test_fable_runtime_equivalence.m — mid-step sampling + record paths
• OSI_tests/overloadin_test/ — overload regression test, frozen pre-fix reference, this comparison + report
• simulink_changes.md, OSI_tests/fable/fable_simulink.md — documentation