Loiter and landing flare seem to use EKF origin altitude

I had a recent flight where the there was a significant (~12m) offset between the EKF origin altitude and the home altitude. I’m not sure what caused this or if it is a problem in and of itself, since the home altitude was correct and normal mission items maintained the proper altitude, but it caused problems with loiter-to-altitude and the landing flare.

The landing starts with a loiter to altitude, which went to the correct altitude (relative to home), but did not exit until the plane had completed several revolutions. It looks like it only eventually exited because it detected it was stuck, since it printed “Loiter to alt was stuck at 174”. Note that 174 was approximately the origin altitude (in decimeters) at the time. (Edit: From looking at the code, this is the AMSL altitude, which just happened to look like the origin altitude in decimeters)

After the loiter completed, the landing flare began when the origin altitude went below LAND_FLARE_ALT, causing it to flare much higher than desired.

It looks to me like ArduPilot is mistakenly using the origin altitude instead of the home altitude in several places, and nobody noticed because they are usually nearly the same. (Edit: this is wrong, see next post)

Here is the log file from the flight: https://drive.google.com/file/d/1AnYQRX5r4g9cJfgvzMHT71t6pErIHI_V/view?usp=sharing

1 Like

I noticed that the EKF origin (XKF1.OH) matches the GPS altitude (GPS.Alt) when on the ground, despite the fact that the EKF vertical position (XKF1.PD) is ~12 meters when on the ground. For some reason, the EKF thinks it is not at the origin (vertically) despite the GPS saying it is. I believe this explains the behavior I observed, since the code does a conversion to AMSL using the EKF origin while calculating the altitude relative to home.

I suspect AP_NavEKF3: fixed getLLH alt for local origin height · ArduPilot/ardupilot@92f2515 · GitHub might fix this; I was still running 4.3.1beta1.

2 Likes