EKF2: Height reference vs Range Aid semantics can cause altitude drift/jumps (Flow+Range, Multi-EKF) #3
Description
In several indoor / low-altitude setups (Optical Flow + Range Finder, no GNSS), altitude can look rock-solid while hovering, but starts drifting or stepping once the vehicle crosses the conditional range aid thresholds (speed/height) or when switching EKF instances.
It feels like the same state (local_position.z) changes meaning depending on which knob is active (EKF2_HGT_REF, EKF2_RNG_CTRL, MPC_ALT_MODE, multi-EKF selector). That makes altitude control hard to reason about and hard to tune.
This is not just a tuning issue: it looks like a semantic coupling / state-machine effect between “height reference selection” and “range aiding gating”.
Symptom A — indoor Flow + Range: “hover ok, translate drops, stop recovers”
- Hover in Position mode: altitude is stable.
- Translate ~5 m/s for ~20 m: estimated altitude drops by a few meters, vehicle follows it.
- Stop: altitude slowly climbs back.
This is reported in upstream PX4 as PX4/PX4-Autopilot#24338 (and related discussions like PX4/PX4-Autopilot#24058, PX4/PX4-Autopilot#24653).
Symptom B — multi-EKF + HGT_REF=Range: “instance switch causes huge Z jump”
- With
EKF2_MULTI_*enabled, different EKF instances can initialize with tens–hundreds of meters of Z offset. - When the selector switches instances,
vehicle_local_position.z“teleports”, causing aggressive altitude correction.
Reported upstream as PX4/PX4-Autopilot#24206.
Expected behavior
- If a range finder is valid and configured as “conditional range aid”, I expect no silent semantic jump in the altitude state used by the controller when the range aid toggles on/off (speed/height thresholds).
- If reference switching is intended, I expect it to be continuous (bias/offset handled) and observable (explicitly reported to logs / estimator status).
- With multi-EKF, I expect consistent Z origin/semantics between instances (or at least a safe handover).