Hello, in line with my previous inquiries regarding altitude estimation, I am trying to figure out what the difference between EKF altitude (CTUN.Alt in the logs) and POS.Alt is, why they diverge, and what functions each one serves.
Here’s an example of an unexpected interaction between the two:
This is a 25 minute flight in Guided mode, where I send my copter to hover at 4 waypoints of the same altitude using the MAV_CMD_NAV_WAYPOINT Mavlink message from a companion computer. You can see the POS.Alt (green) drift downwards as the drone hovers. When the next waypoint message is sent, it sends the same target altitude, but the drone ascends, even though the CTUN.Alt (red) has remained constant. From this, I figure that the mavlink command uses POS.Alt for its waypoint altitudes, but the controller uses CTUN.Alt for altitude hold, and their divergence causes unreliable waypoint altitudes.
What is the (programmatic) difference between CTUN.Alt (EKF alt) and POS.Alt?
What functions are each one used for? E.g., I find that POS.Alt is used for waypoints from Mavlink and precision landing calculations, and EKF is used for the actual altitude control.
2a. Why not use EKF altitude for everything?
Why does POS.Alt have a downward trend that slowly goes away? I see this in multiple drones.
Would appreciate any insight or a point in the right direction.
I found that the POS.Alt is exactly equal to TERR.CHeight, minus the home relative offset. Looking into the AP Terrain library, I found that CHeight is “relative height above terrain.” This, I suppose, means that POS.Alt is absolute height above terrain. This made me suspect that terrain information may be responsible for the downwards drifting seen in POS.Alt. The terrain data in the logs don’t really support that, but I ran an experiment anyways:
Drone 1 flew with the same configuration as above, but with TERRAIN_ENABLE = 0.
Drone 2 flew with TERRAIN_ENABLE = 1, plus a long range lidar rangefinder, as the copter should use the lidar for terrain height as long as the rangefinder reading is good (as I understand, anways).
Both of these flights had the same downwards drifting as before, easily visible in this snip (TERR.CHeight is shown instead of POS.Alt):
Worthy of note, though, is that the CHeight remains very stable, except for certain discrete periods where it gets trimmed downwards. But I still can’t find what is causing this. There is no sensor reading I’ve found that correlates with these downslopes, and I can’t find any evidence that the relative altitude datum is changing, so I remain stumped on the issue.
This is a problem as both waypoint navigation and precision landing use POS.Alt, which can significantly diverge from EKF altitude!
Hi @Anubis, coming back on this,just trying to understand how the EKF is really calculated. I have a TFMini Range finder, running Arducopter 3.5.5 TERRAIN_ENABLE set to 1 and as I can see on the graph, the calculated value seems to follow the Baro Alt very closely, seems to ignore the Range Finder Alt. Any suggestion about this?
The EKF altitude does not necessarily start at 0; it is relative to the EKF origin, which can be different than the home/ground altitude. You should find that the rangefinder and EKF altitude follow each other, but may have some constant offset. This offset is posted by the ORGN.Alt log message (there’s two, one is for home alt offset, the other is EKF alt offset).
The NKF5.HAGL field shows the EKF altitude above ground level. If everything is working properly, it should be the same as your rangefinder reading.
Hi all - I’m having what I think are similar issues - although in my case, in Guided mode, TERR.CHeight stays at the target elevation but the actual elevation drops (reflected by CTUN.Alt and RFND.Dist1). For what it’s worth, POS.RelHomeAlt stays close to TERR.CHeight but POS.RelOriginAlt roughly follows the drop. Is there a good source somewhere that describes how these altitudes are derived and relate to each other? (2nd question - I’m assuming that Origin Alt and Home Alt don’t actually vary during flight - is that true or is it using some elevation map from somewhere?)
