I have several copters running AC 3.4.6 on a Pixhawk 2 (early batch). One of them has some issues with altitude estimation which I am struggling to understand. The EKF altitude immediately diverges from the baro and GPS altitudes, causing altitude runaways in alt hold-enabled flight modes. Take this one minute flight for example:
Here, during a constant altitude loiter hover, the EKF altitude (CTUN.Alt, red) inexplicably goes down, causing the copter to try to climb to the desired altitude, which has not changed (dark pink). You can see the baro and GPS altitudes (green, yellow) follow each other up as the copter climbs until I take over in Stabilize. At the point of divergence, the EKF barometer position innovation (light pink) drops and never stays near 0 afterwards. Eventually, the EKF freaks out and jumps the altitude back up to 0, only to start the process over again as soon as I reenter Loiter mode.
Here’s a few things I checked:
- All three IMU’s are consistent in Z direction and seem to show accelerations that agree with the changes in baro alt.
- Both barometers and GPS are in agreement
- POS.Alt follows the EKF alt (ie, it’s wrong)
4. At the point of divergence, EKF vertical velocity disagrees with the changes in EKF vertical position!
Given these findings, I am wondering what is causing the EKF altitude to be so very wrong. I am interested to know what it’s basing its estimation off of. This phenomenon is repeatable on this copter.
Attached is the log for this flight.
ekf altitude estimation error short.bin (866.8 KB)
On a related note, can anyone explain to me what the difference between CTUN.Alt and POS.Alt is? I’ve seen them diverge in some of my longer flights, and have found that they are used for different things, but I can’t find any documentation that spells it out.
Thanks in advance for any insights.