autotest: clear the simulated baro's drift offset before the next test

[peterbarker]

Summary

Resets barometer offset after landing in tests that play around with SIM_BARO_DRIFT to avoid nuking subsequent tests.

This does kind of raise the question as to why we don't reset the thing on disarm in the firmware itself...

Classification & Testing (check all that apply and add your own)

• Checked by a human programmer
• Non-functional change
• No-binary change
• Infrastructure change (e.g. unit tests, helper scripts)
• Automated test(s) verify changes (e.g. unit test, autotest)
• Tested manually, description below (e.g. SITL)
• Tested on hardware
• Logs attached
• Logs available on request

Description

SIM_BARO_DRIFT is a rate. Setting it back to zero stops the offset it has accumulated from growing, but leaves that offset in place for the life of the SITL process, and no parameter records it - so the context revert restores every parameter correctly and still cannot see or undo this.

A test which drifts the baro therefore hands the next test in its session an altitude estimate wrong by however far it drifted. That test sets home from the wrong estimate when it arms, leaving home and the EKF origin disagreeing, and every relative-altitude mission item it flies is displaced by the same amount.

Caught as Copter DO_CHANGE_SPEED failing after
AHRSSwitchBackendPositionReset, which drifts at -0.3m/s for 75s. The arithmetic in the captured log is exact:

drift ran 252.2s -> 327.8s = 75.6s at 0.3m/s = 22.68m
home fell 584.09m -> 561.41m, origin unmoved = 22.68m

so the mission's "20m relative to home" resolved 22.7m below the vehicle, which spent the leg descending at WPNAV_SPEED_DN. That capped its groundspeed at 2.09m/s against a commanded 4m/s, so it never reached the band the test was waiting for:

Failed to attain groundspeed between 3.5 and 4.5, reached 14.95

14.95 being the next leg's speed by the time the check timed out.

Recalibrate the barometer once the vehicle is landed, which absorbs the offset into a new ground reference. The helper refuses to calibrate while armed, since doing so in the air would make the ground read as minus the current altitude.

Only AHRSSwitchBackendPositionReset is shown to break a successor: it is the one which drifts for a full 75s. The other four callers accumulate far less and their successors currently pass either way -

test.Copter.EK3SrcSwitchPosDownReset,DO_CHANGE_SPEED   passes
test.Copter.ModeFlowHold,DO_CHANGE_SPEED               passes

• so those calls are preventative rather than fixes for an observed failure. They leak the same way and would bite a more altitude sensitive successor, and the test ordering already places drifting tests directly before others: upstream tests2b runs AHRSSwitchBackendPositionReset immediately before
  AHRSSwitchBackendPositionNEReset, and EK3SrcSwitchPosDownReset immediately before SIMCompare.

This is not load sensitivity. It is deterministic whenever the two tests land next to each other, which is only why it looked like a parallel-only flake:

test.Copter.AHRSSwitchBackendPositionReset,DO_CHANGE_SPEED

runs both in one SITL session and fails every time without this change, and passes with it. Under --parallel=32, 256 interleaved copies of DO_CHANGE_SPEED failed once per iteration in each of three iterations before, and 0/768 after.