I’d like to address a critical concern in ArduPilot that I believe needs discussion.
During extended flights, many of us encounter altitude drift due to varying pressure conditions. Because the barometer is misinterpreting the copter’s altitude, it results in erroneous EKF altitude calculation.
The issue here is that flight routes are planned assuming consistent altitudes. Yet, due to weather and pressure variations, the copter’s altitude ends up differing each time the route is flown. This unpredictability can lead to accidents, posing a particular risk for less-experienced ArduPilot users.
While manual corrections can be sent over time, this method often demands an extra ground barometer.
I’m initiating this topic to explore the feasibility of implementing a correction mechanism leveraging GPS. This could involve periodic corrections at predefined intervals, provided we have a strong GPS lock.
I look forward to hearing your insights on this matter.
I think your understanding of the altitude control system is at a pretty low-level…
The altitude control is an EKF that uses all sensors (IMU/Baro/GPS/LiDAR/etc.) - not just barometer. There is also documentation on how to setup baro-drift compensation for multirotors already:
Thanks for your constructive feedback, i dont consider my understanding pretty low level, while I dont consider myself an expert, I understand a few things.
What you are mentioning of baro-drift compensation is for wind gusts hitting the barometer (short term corrections) I am not refering to this kind of short term drifts, this is a BIG drift over a long time.
I understand you could set the EKF primary source to GPS but that has its drawbacks as well because GPS altitude is not stable.
I am borrowing this image from a log from @Vaclav_Demeter to try to explain more in detail…
If you wanted to continue to use BARO as a primary source and update it periodically with GPS delta, a Lua script could be employed to provide updates to BARO_ALT_OFFSET when the delta exceeds a threshold value and GPS fix quality is good.
Thanks for the suggestion @Yuri_Rage ! That is a good idea, i will definetely try it.
Although I think this should be part of the calculated altitude for ardupilot, in my opinion it is wrong to have an erroneous calculated altitude by that many meters at any point in flight.
I think this should be an option (maybe even the default one) for all ardupilot users, not only the ones who know how to use Lua Scripts.
That is my opinion, I am opening this discussion to see what other users think. Listen to the developers, see if this is a possibilty and how we could help implement it.
An option is to change EK3_SRC1_POSZ,1 (Baro)
to EK3_SRC1_POSZ,3 (GPS)
and you might need to also set EK3_SRC2_VELZ,1 to ensure Baro is used if needed.
This would require some testing on your behalf, to see if your GPS unit is suitable, and check if altitude is reset to 0 if you land and disarm then arm and fly again.
There is also an RCx_OPTION,65 to Disable GPS so you can test what happens if you do lose GPS. Obviously use with caution.
Would it also be worth considering the use of some other source of altimeter data such as a laser range finder (or sonar or radar depending on your use case)?
Thank you for the suggestions! I will try this week and let you know how it went with HERE3+
@Leonardthall what is your opinion in implementing a correction to the calculated height for the general code? I think its something all users could benefit from and it would bring no drawbacks that i can think of.
I think for my use case i can solve it with some of the great suggestions made here, but I dont understand why keep getting that prolonged error in general, when it could be solved. Is there something im overlooking?
Sorry, I don’t understand what you are suggesting. We must have a long term reference.
Baro has long term pressure variation and can also move up and down significantly with airspeed.
GPS can vary as you gain and loose satellites and atmospheric propagation varies due to moisture in the atmosphere for example (RTK base station takes care of most of the GPS problems).
You can’t use a lidar range finder because ground altitude is changing all the time.
Are you just talking about having a ground pressure parameter you can update?
Im suggesting that long term reference from baro, is adjusted using a GPS average (only taking into account the values that have good fix) when baro has a big drift over time.
For example keeping an average value of the last X seconds/minutes of the GPS altitude and Baro Altitude, if there is a gap Greater than X, adjust the calculated height with that gap Delta. That way we still use Baro as main source for Altitude calulation but we fix the long term error.
No, because like with baro GPS suffers mostly from long term drift, in fact it is even worse because due to constellation changes there can be a step error change.
Depending on current meteorological conditions either drift may be greater.
IMHO it would be better if we were able to supply Ardupilot with current ground conditions, maybe by extending tracker firmware to be able to act as integrated tracker, RTK base and meteo station.
What is a realistic range for an RTK base station? I only ask because if the drone is flying long enough that baro and GPS drift are an issue, I wonder it may be flying far enough that the RTK base may be too far away. Just a curiosity, nothing else.
I don’t see that parameter in the latest 4.4 or 4.5 builds. I do see BAROx_GND_PRESS for each barometer, and those are read-only. Unless I’m missing something, there is no way to dynamically update the altimeter setting in current firmware unless you modify BARO_ALT_OFFSET as a workaround.
GPS doesn’t drift as a function of time. A 3D Fix or DGPS Fix may “wander” slightly (1-3m, on average), and there is a possibility of “jumps” of similar magnitude as satellites go in and out of view. It may still be preferable, depending on application, to use a GPS altitude source as primary, and certainly viable if a good RTK Fixed solution can be reasonably expected for the duration of flight (greatly mitigating position error/jumps).
RTK base stations are typically most accurate within 20km, and I’ve experienced excellent performance out to 40km. Recommend not exceeding 40.
Exactly GPS doesnt drift over time, and we have HDOP and VDOP, aditional to satelite number and 3D FIX, to know how accurate the readings are. So we could only take into account the accurate readings to make the adjustment.
I know Using RTK or a ground barometer is a solution to manually update the baro alt offset, but the idea here is that maybe we dont need that. And all ardupilot users could have a much more “real” height estimate than today.
The problem with your approach, as others have alluded, is that once the craft is airborne, the barometer is more susceptible to error due to wind, gusts, turbulence, and speed-induced pressure variations, making a simple instantaneous calculation unreliable. Additionally, automatically changing the altimeter setting would not be best practice at all for those needing to integrate with other aircraft.
I do think that a Lua script could be employed to periodically update the altitude offset, given some appropriate safeguards/filtering and possibly user confirmation. But your use case seems to lend itself more toward simply using a GPS altitude source rather than correcting the barometric one.
I do think that we should remove the read-only restriction from BAROx_GND_PRESS and update the plug-in to update those values at user discretion.
I think it would be viable, I understand it would not be easy becauser there are many factors to account to but it would be a more trustworthy altitude measurement.
Maybe the solution is not sending corrections directly, instead give more weight to GPS Altitude into EKF altitude estimation?? Im not sure if today EKF blends baro and gps, or just goes with the Primary source.
Again my objective is to create a dialogue, see what other users think, what developers think, and how we could solve this " incorrectaltitudemeasurement " over prolongued flights in time and distance.
I’ll update the plugin, but no need to remove read-only restrictions. Once you know the BARO1_GND_PRESS you can calculate the value for BARO_ALT_OFFSET based on the ground station baro readings.
