guided_above_terrain_posvelaccel_sub.lua integrates its position target
forward by the time since the last callback. When a callback arrived
later than 2/RUN_HZ it substituted 1/RUN_HZ for the real interval:
if (dt > 2.0 / RUN_HZ) then
dt = 1.0 / RUN_HZ
end
so a callback 243ms late advanced the target by 50ms and the remaining
193ms was discarded. The position target then falls behind the clock,
and the vehicle - which tracks that target accurately - covers less
ground than the commanded speed implies.
Measured from a failing Sub.GuidedAboveTerrain run under autotest at
--parallel=16, over the 60 simulated seconds the test watches:
GUIP updates 1047 at 17.2Hz (nominal 20Hz)
late callbacks 76 of 1047 (7.3%), worst 243ms
time discarded 5.82s, so 55.08s integrated of 60.90s elapsed
distance 27.90m of an expected 30.00m, +-1.00m -> failed
The dataflash shows the loss is upstream of the controller, not in it:
the script commanded 0.495m/s and the position controller achieved
0.442m/s against a desired 0.443m/s - it tracked what it was given to
within 0.001m/s, and what it was given was slow.
Cap the step at a fixed MAX_DT instead, so ordinary jitter is
integrated honestly and only a real stall is bounded. Pinning the
simulation speedup was tried first and is not a fix: at
context_set_speedup(10) the run still lost ground, reaching 28.93m,
because it reduces how often callbacks are late without changing what
happens when they are.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Peter BarkerandClaude Opus 5
805fa9f8d0