My Skywalker X-5 equipped with a MiniAPM 3.1 controller running latest ArduPlane V3.4.0.
ALT_MIX is still present in Mission Planner “Full Parameter List”, but missing in the documentation http://ardupilot.org/plane/docs/parameters.html. Obsolete?
ALT_OFFSET is present in both lists.
So far I have had no use of above parameters, and they are probably not going to help in the situation I shall try to describe.
Some days ago I run a mission high up in the mountains with my trusted X-5. Planning the mission I had to calculate the waypoint altitude in order to clear the highest mountain top. I suspected there might be some BARO height error, so I added 120m to the highest point, just to be safe. The flight started near MSL, ab. 3m above sea level.
Looking at the log after the flight, I noticed a discrepancy of 50m at the altitude of 880m - GPS altitude was 830m and BARO 880m (programmed waypoint height). Furrther investigation revealed that there was a linear function between the GPS altitude and BARO elevation, i.e. BARO indicating ab. 6% higher than GPS. I have seen this tendency before in other missions, resulting in one narrow escape. Now I became curious and looked at some other X-5 logs and also logs from my TekSumo with the same controller. About the same 6% scaling error showed up in all the logs! Except for my Bixler 2, Pixhawk Lite with Arduplane V3.5.2 - only ab. 2% scaling for a some flights.
All my BAROs are covered with foam, and I have not seen more than 2-3m BARO drift due to temperature/QNH during long flights, up to 20 minutes.
Please have a look at the graph below for the X-5 flight.
It has been argued in many posts that the GPS altitude may be incorrect and unreliable, but in this particular flight I think it is correct. Look at the picture below: The GPS indicates that the plane is at 762m ASL and altitudes from the maps aligned pretty good to the (foggy) horizion - suggesting that the M8N GPS is OK.
I know I am late to the table, and that FW updates for APM are discontinued. Still, would it not be nice to have a scaling parameter for BARO to compensate for this type of scaling error - both for APM and Pixhawk (1&2)? It will not take care of other height estimate errors like air pressure/temperature drift, but should make a better basepoint for a particular controller.
This is not a big issue for me now, but it may be problematic that the “inflated” BARO height results in missions not reaching the programmed altitude, specially in case of high altitude flying. It would have been better the other way around. I understand that other functions are at play here (based on EKF), but I guess GPS input is not used in altitude estimations?
The video may show some more detail about the flight. At 2:44 you can enjoy the look at the result of a bad AutoTune in calm weather - a bit too agressive pitch PID setting for windy conditions :-). PID values are now lowered manually for the next flight…
Happy flying!
Regards Jan
) the baro device temperature is more dependent on controller heating up inside the plane and in the controller case. I think the temperature inside the plane will only slowly change because of outside temperature and the influence of the big battery heating up during flight. BTW, the outside temperature decrease with height is only ab. 0.5°C pr. 100m (called “Lapse Rate”).
- have a nice day!
) the baro device temperature is more dependent on controller heating up inside the plane and in the controller case.
), it is likely to occur in winter season (because, in arudupilot, max temp. for calculating baro alt is defined as 35C).
