Altitude is calculated from multiple sources (EKF anyone?) with a weight to a primary source that can be set by user (EKx_ALT_SOURCE). It can be Baro, Rangefinder, GPS or external. (Rangefinder is generaly not in use, only is special cases (optical flow navigation). If you have a good GPS you can set your primary alt source to GPS, because barometric altitude in ardupilot is always QFE based, it can drift during flight if the barometric pressure changes.
Primary source change.
Yes, EKF can change primary alt source if the the actual primary source become invalid or erroneous. BUT it also can switch back to the selected source if heals. For example if you select GPS, the primary alt source will change to BARO if EKF does not see GPS update for 500ms or accuracy degrades and switch back if it see gps update within 500ms and the accuracy is OK.
That’s a pretty interesting inside on how the code works. Excellent info!
A number of people have suggested GPS such as Drotek (I have one), or any other GPS that are l1/l2 F9 GPS . How good are they for long flights? I have never tested them for like 4 hour flights the author of this thread is doing.
lastly, the barometer inside the Arudpilot FC such as Cube etc. How good of quality are they compare to a more traditional technology used in commercial space?
This Ardunio system you are designing sounds pretty interesting. I am assuming it has been tested by you thoroughly as always…
An M8 gps is good enough with multi constellation settings no need for F9.
Pressure sensors used in quality FC’s (Not the racer craps) are good enough to use as height source.
The software is work in progress, since I did not had time to test it in long flights yet.
Hi Darad,
I have had a look at your log “Plane crash log - air pressure decreasing.BIN” from your flight on the 12th of March 2020.
The first thing to tell you is that ArduPilot most definitely did not switch from using GPS altitude to barometric altitude. The whole flight was conducted using GPS as the primary altitude source just as you had configured, with only the IMU doing some (small) degree of smoothing of the altitude estimate.
The flight started with a GPS altitude of 190m above sea level. This set both the EKF origin altitude and the home altitude. According to google earth the true altitude of the ground at the takeoff location is 194m above sea level, so the GPS was in pretty good agreement with google earth. Note that relying on that with a M8 is a bit dangerous. It was OK in this flight, but sometimes a M8 will be off by more than 20m, especially when close to the ground.
There were 273 waypoints in the mission, and they were all set as “global position, relative altitude” reference frame, meaning the target altitude for each waypoint was an altitude relative to the home height of 190m.
The crash occurred at waypoint 235, which had a target altitude of 88.36m. That means the target altitude was 278m above sea level (that is 190 + 88).
When the plane hit the tree the GPS was reading 275m above sea level. The height controller did know it was 3m low, and it was in the process of trying to climb a small amount.
According to google earth the height of the ground at the point of the crash is 235m above sea level.
After hitting the tree the GPS altitude dropped from 275m to 243m above sea level and the barometer showed a similar drop. That puts the tree as around 32m tall (very approximately, there could be other reasons for the drop in altitude reading).
So basically the mission didn’t take good account of the change in terrain altitude. As far as I can tell ArduPlane did do what it was told to do in the mission.
One unfortunate thing is that the SRTM terrain data that ArduPilot normally uses for a terrain following mission doesn’t extend past a latitude of 60 degrees. You didn’t have terrain following turned on anyway, so it didn’t try to use it, but it would be a nice way to do this sort of mission if we fix the database to include higher latitudes.
I’m sorry for your crash, and I hope the above helps explain what happened.
Cheers, Tridge
thank you for information and accurate analysis. I will now try to clarify my own pondering about this “altitude challenge”.
Im not using SRTM terrain data. I use National Land Survey of Finland DEM data. It’s accurate enough 10m x 10m grid. We use own custom made flight planning software which uses DEM and makes our flight going smoothly over the terrain. Flight altitude in those crashes was set 40 meter.
We have separate datalogger in the plane, which is not connected to autopilot. Logger has own GPS unit and own barometer.
Here is datalogger altitude statistics of the 12th of March 2020 crash flight.
This is a quite a long message and I will make my summary here.
FC GPS unit is showing different altitude than separate datalogger GPS
Both GPS units are Ublox one freq receivers.
FC baro and datalogger baro behaves same way. Plane altitude is going down.
Waypoints are about 40 meter altitude from ground, we have checked that several times. And further more, both of those crash flight was successfully conducted with the very same flight plan next day, when this “odd behavior in the plane” was vanished. And flight altitude was 40 meter after over the whole flights.
So, where is the problem; in FC or between my screen and chair ?
Well, Since I don’t know the logger and don’t see the raw data. I can rely only on the log.
The data from the log :
Takeoff height (Origin alt): 189.97m
Time of impact (Based on the accelerometer data) : 3387.6 sec
at 3387sec, right before the impact altitude data from the log :
Target altitude (Waypoint 235, 88.36 meters)
GPS altitude : 276.07Meter (-origin = 86.1 meters)
BARO1 and Baro2 altitude : 84.6 meters (less than .02 difference between the two baro)
AHRS.Alt : 274.59 (-origin = 84.6 meters) Coming from Baro
TECS.h : 85.74m coming from ekf…
Barometer was not used during navigation, since EK2_ALT_SOURCE was 2.
It seems that in the worst case scenario plane was 5 meter below the 88.36 target altitude at the time of the crash.If 5 meter difference cause a crash that seems awful small room for error…
@Eosbandi Is there any way we can use his separate data logger raw data and the FC data mapped together and synchronized the time line and notice the difference? Just thinking out loud…
One data has to be wrong “or” one tree grew 50 meters higher over time since the last survey
@Eosbandi, I uploaded the datalogger file “Datalogger data 13.3.2020 crash flight” under folder “Kittilä - crash 2020”. Beginning of the file is data description. Hopefully you will find out something. I’m running out of ideas to solve this issue.
@UAVSkies, we are using custom made datalogger - pretty simple solution
OK, it seems baffling. Everything from this on is only theory.
If I look at the full dataset it seems that either the logger gained a solid negative bias, or the FC-GPS gained positive one. (Datasets are decimated to 1Hz update rate and synced on gps timestamp)
The difference is not constant and there are 8-10 second periods where the logger altitude seems frozen.
Also if you lot the logger alt - FCGPS alt it seems quite strange
Altough you can see the trend, but it is all over, and even recovers at the third quarter of the flight.
So I’m officially baffled. It can be an intermittent noise, or strange multipathing. I’m wonder how the two gps are configured. the FC GPS is set for 5Hz and multi constellation, but I don’t know anything about the logger…
@Darad@Eosbandi ok so I am not the only who is lost from the beginning
We need more info on the logger. You pointed out something which is the refresh rate. Are both systems using the same refresh rate?
I recently bought Seagull logger for geo mapping which uses its own GPS for geo tagging. I am not sure what @Darad has custom designed, without all the info i guess its impossible to troubleshoot this anomaly.
Yes. We have the same phenomena where the plane altitude continued to go down over time. In 1 particular case even more than 50 meters. We only use baro altitude. Now since the trend is always down, its hard to explain by barometric pressure. Then it should be up sometimes as well. We usually experience somewhere between 10 to 15 meters, always down. Flight time mostly around 50 minutes.
It looks a bit like something adds or subtracts a small amount from some reference over time.
It also seems, the higher the altitude we fly, the more this difference gets.
Our datalogger is a normal Arduino micro controller which is just reading the sensor data via serial interface. There is no extra logic in the logger, it is dummy logger reading raw data from sensors. Data storage is SD card and after the flight we manually move the data to PC for post processing.
If it’s needed, I can send the logger source files to @Eosbandi, but I don’t believe this will help us.
My theory is that FC is somehow tuning GPS altitude value. In this current situation GPS was set as primary alt source. Is it possible that EKF or IMU or something else can tune or affect to FC GPS alt value?
Below there are three previous comments which makes me think like that.
@Eosbandi ”Altitude is calculated from multiple sources (EKF anyone?) with a weight to a primary source that can be set by user (EKx_ALT_SOURCE). “
@tridge :” The whole flight was conducted using GPS as the primary altitude source just as you had configured, with only the IMU doing some (small) degree of smoothing of the altitude estimate.”
@Verloop :“Yes. We have the same phenomena where the plane altitude continued to go down over time.”
As far as I understood, logger GPS, logger baro and FC baro correlates to each other and they have consensus. Only FC GPS differs from these three other sensors.
no, the GPS message in the ArduPilot logs is the raw GPS data. It cannot be influenced in any way by other subsystems like the EKF
I’d also note that the BARO alt vs GPS alt did not just go in one direction in this flight. This is the comparison, with home alt subtracted:
How tall were the trees at the crash site? Got a photo?
Also, what height above sea level do you have in your terrain data for the crash site and the takeoff site?
You need to give out all the info correctly before people lose interest around this issue:
@tridge is the man that writes Arduplane code!!. So he knows everything inside out.
I was under the impression you are using some kind of separate GPS based data logger separate from FC and its external GPS.
Apparently, as you are not using telemetry, you are storing data log via an Arduino board which I don’t understand why, when the log files are already stored inside the SD card which you can retrieve after the flight.
What am I missing here?
Please properly explain your setup, along with some wiring diagrams, parameter files etc. so others can better understand this issue.
p.s. Not sure if your Finland DEM data file help anyone to further troubleshoot this issue.
In this case, the baro altitude increased , which means the real altitude (GPS) decreased. It looks like a linear increasing difference. This happens many times, always in the same direction.
It has been pointed out many times here that that ardupilot is NOT changing its altitude reference to barometric pressure alone without indication; it is working as intended. The simple reason is our atmosphere changes pressure, sometimes equivalent to tens of meters per hour. The trend of barometic pressure change may also be temperature dependent on the sensor if it has not normalized prior to takeoff. Software temperature compensation only does so much. In manned aviation, nearly ever airport has a weather reporting station with a barometer so that pilots adjust their altimeter in order to maintain a safe absolute altitude reference.
While GPS units are not the most precise, they are significantly more accurate than barometric pressure on long flights. A GPS having ~3 meters of altitude error will still be much closer to the norm on flights over an hour when atmospheric pressure changes. Modern multi-constellation GNSS units are still rather accurate in Z. Theoretically you would see variances in both directions, however due to the weather patterns, you may often not be in flyable weather when GPS/Baro altitudes diverge in the other direction you don’t commonly see. The “noise” you see with the GPS altitude moving up and down several meters is usually a function of new satellites sending signals through different atmospheric conditions.
The logs and posts above show nothing out of the ordinary to me at all. If anything, there’s a mission planning or TECS tuning issue that has caused this incident, not an altitude reference incident. If you need more precision, move to RTK.
