TUM-Aries-Lab / exosuit-python / 35581371874
88%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 9
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 87.435% (+1.0%) from 86.42%
35581371874

push

github

NGierden 
Pace the loops on a schedule so the configured rate is the real one

All three loops slept a whole period after doing their work, making every
iteration take the period plus however long the work took. The loop therefore
could never reach its configured rate: a bench run measured 78.6 Hz against
the 100 Hz configured, with a median period of 11.04 ms made of 10 ms of sleep
and 1.04 ms of work.

That is not a tidiness point. BasicConfig is handed the configured value, and
hip-controller derives its notches and baseline window from it -- as the
comment where it is constructed already warns -- so a loop quietly running a
fifth slower than it claims mistunes the entire filter chain. It would have
mistuned it during the assist test that comes next, on top of a 126x command
change nobody has felt yet, which is exactly the kind of confounding we have
been avoiding elsewhere.

Sleeping only the remainder holds the cadence and stops the error accumulating
across ticks. A local simulation of the two schemes with 1 ms of work gives
84 Hz the old way against 96 Hz the new.

After a tick that ran long the schedule restarts from now rather than from
when it should have been. Catching up would fire a burst of back-to-back
iterations, which is the opposite of what a control loop wants once it has
already fallen behind -- and those bursts would themselves show up as the
stutter this is meant to remove.

This is separate from the polling fix, which addressed the ragged tail: that
took ticks over 20 ms from 14.1% to 4.4% and the worst case from 229 ms to
113 ms, but left the median untouched at about 12 ms, because the median was
never the polling. It was this.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

668 of 764 relevant lines covered (87.43%)

0.87 hits per line

Coverage Regressions

Lines Coverage ∆ File
57
84.1
2.07% exosuit_python/exosuit.py
1
96.55
0.4% exosuit_python/motor.py
Jobs
ID Job ID Ran Files Coverage
1 35581371874.1 9
87.43
GitHub Action Run
Source Files on build 35581371874