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.
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.
I hadn’t, since I felt it was unsafe to fly, and the log shows that the copter was not attempting to follow desired sonar alt (CTUN.DSAlt). As far as I know, the EKF does not use the sonar in any way with my current settings: EK2_ALT_SOURCE = 0, EK2_RNG_USE_HGT = -1. My other copters have these settings as well, and I’ve never seen EKF altitude attempt to follow the sonar reading unless one of these params is enabled.
That said, I could do a flight with rangefinder disabled when I get a chance to go out to a grass field if we think it would be educational.
I was never able to verify exactly what the problem was, but I strongly suspect it was related to the rangefinder I was using. At some point, I swapped it (Maxbotix sonar) for a more expensive but more reliable lidar.
I did find, though, that Arducopter still fuses lidar readings into the EKF for altitude control even when EK2_ALT_SOURCE = 0 and EK2_RNG_USE_HGT = -1. A side effect of this is that it tends to follow terrain even when terrain following is off, and can cause some undesirable altitude behavior if the rangefinder has poor readings and its EKF parameters aren’t tuned to reject them (EK2_RNG_M_NSE and EK2_RNG_I_GATE).
Thanks for your answer!!. You are right, I you use the range finder in the EKF2 for altitude control, when it is not measuring properly, the control will be complete bad. Last year I was testing a Maxbotix sonar (7 meters range) with Arducopter 3.3 and that was terrible, altitude from the sonar very noised, even using the pre-filtering they suggest on the web site (Maxbotix web site).
Now, I am using a LidarLite v3 from Garmin with good estimations (below 25 m) and Arducopter 3.5.3. I have tested the Octocopter with the Lidar v3 several times, everything fine, of course I have put the EKF2 only to use it below 5 meters altitude.
These are the parameters I am using:
EK2_ENABLE=1;
EK2_ALT_SOURCE=0;
EK2_IMU_MASK=0;
EK2_RNG_USE_HGT=20;
EK2_ALT_M_NSE=4;