EK3_OGN_HGT_MASK bit 3 incorrect behavior

[pavloblindnology]

Bug report

Issue details

If 3rd bit of EK3_OGN_HGT_MASK is set together with 1st bit (EK3_OGN_HGT_MASK=5) and vertical position is taken from barometr (default parameters), copter climbs periodically indefinitely. The plot below shows 10x SITL simulation with real altitude (barometer or gps) jumping at regular intervals, while the controller (and EKF) altitude remaining constant. The real alt increases as copter periodically thinks it's below desired altitude (100m) and simply turns on the throttle to keep it.

The reason is in readGpsData here

ardupilot/libraries/AP_NavEKF3/AP_NavEKF3_Measurements.cpp

Line 693 in 5144341

if ((frontend->_originHgtMode & (1<<2)) == 0) {

When 3rd bit is set, Ardupilot doesn't use ekfGpsRefHgt to convert GPS alt to local alt. But it still updates ekfGpsRefHgt in correctEkfOriginHeight. And the innovation used in the latter is constantly non-zero.

The jumps in alt are introduced by the 5-sigma check here. If the check is removed, the alt rises smoothly and with acceleration.

ardupilot/libraries/AP_NavEKF3/AP_NavEKF3_Measurements.cpp

Line 817 in 5144341

if (ratio < 25.0f && gpsAccuracyGood) {

It seems the cure is to always use ekfGpsRefHgt to convert GPS alt to local alt in readGpsData. Tested and it worked ok.

Version
Copter-4.3.7

Platform
[ ] All
[ ] AntennaTracker
[*] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type
octa

Hardware type
SITL

Logs
BIN log

[peterbarker]

We've just merged a fix for this - thanks @pavloblindnology

[ddomit]

We've just merged a fix for this - thanks @pavloblindnology

Thanks for this, is it already in a stable or beta version i can test?

Does ":Apply corrections to local position" mean that it will update the home altitude accordingly? i have tried using it set to 1, but when it comes back to home its sometimes 10 meters off...

Log:
https://drive.google.com/file/d/1oEntDXzGjo2kmv54ihtVaRBwAyEa0qKx/view?usp=drive_link