Some of my recent missions show a dramatic difference between GPS and barometric altitude, An example is a mission that autonomously flew a series of horizontal circles. The GPS reading was at 112m but the barometer reading was 158m. This is a discrepancy of 41%, which seems extremely large. On other flights the difference is as low as 10%. But it seems to always be there.
My question: is this something that can be adjusted in parameters, or is it normal and I have to live with it??
I didn’t realize the QNH parameter existed. neat. It is very common for Baro and GPS altitudes to be different in small UAV applications. Here are some causes you might consider when improving your set-up:
GPS has relatively terrible vertical accuracy and it can wonder over the course of your flight.
GPS satellite geometry can change a lot from when you establish your Home altitude on the ground to when you are at flight altitude, possible seeing more sats on the horizon and reducing ground reflections and interference.
It is common for atmospheric pressure to change measurably over the course of a flight, less common on short flights.
Your propeller(s) might be changing the pressure in the air around your baro sensor, this might vary with throttle setting
Your velocity through the air might be changing the pressure around your baro sensor.
Given many small UAV autopilots have the baro sensor right on the board, it is easy for “cabin pressure” to not match outside pressure in a significant way, often caused by propeller effects, airspeed (dynamic pressure), or angle of attack/side-slip.
Would it be appropriate to try automatically setting QNH?
Two ideas immediately come to mind
use GPS reported altitude (depending on fix) to work back and automatically set QNH (likely a binary search, but relatively easy) so that your barometric altitude matches (at least initially)
use an internet connected ground control station (or companion computer) to get the current value online and then set the parameter
Your ideas for automatically setting QNH both make sense. Of course, you need to decide when it should get set, and how often. You might not want to reset the QNH param in the middle of flight for example. Also, how would you handle the step-inputs to the EKF? might be messy. Maybe it should be treated like an automatic calibration step with appropriate re-initialization of the EKF, home position, and system flags.
for most use cases I don’t think automatically setting QNH would have a big impact on relative height accuracy above home. The other contributors I list above are probably larger sources of baro altitude error above home.
I run my Pixhawk in its standard plastic case. I’ve never had it out of the case for any reason. It is mounted on the bottom plate of the F550 hexacopter where there is plenty of ambient airflow. I never drive it more than 11 mph, most of the time slower.
My knowledge of the pressure sensor in the Pixhawk is very limited. I have been flying this drone for several months but have been relying mainly on the GPS system. Once I flew it in Altitude mode where it uses the barometer instead of GPS to determine altitude, and this seemed to work fine at the time, but if I had switched to Position mode during the flight, it might have dropped like a rock. Glad I didn’t do that. Since then I haven’t paid much attention to it until looking at some of the mission logs where I spotted the large discrepancies.
Where I fly, the difference between QNH and QFE is 1.2mb because we’re about 100 feet above sea level. This cannot account for large differences, hence my suspicion that there is some parameter that is off.
For now I’m not going to use the barometer for any flight mode I’ll be using.
Go down to the multicopter section. In the ALTITUDE section of the chart, the sensor icon with the ++ indicates that the barometer or other height sensor is used in ALTITUDE mode to hold altitude. How else could it hold altitude if GPS is not used?
What they mean is: If you only have a baro and no GPS, you are able to enter altitude hold mode (but not position hold). If you have a GPS, you can enter both altitude and position hold mode.
If you only have a barometer, the position estimator (EKF2 by default) will use it’s measurements to estimate the vertical position (and won’t estimate the horizontal position).
If you also have a GPS, EKF2 will estimate the vertical position either with GPS or with baro measurements, depending on the parameters (baro is the default), and horizontal position with GPS.
If you enter altitude hold mode, the position controller will try to maintain the same vertical position (as reported by EKF2). The controller does not know or care how this vertical position estimate was computed.
If you enter position hold mode, the position controller will try to maintain the same vertical position as well as the same horizontal position. Again it uses the estimated position from EKF2. EKF2 does not change the sensors it uses depending on what the position controller is doing.
Thanks for providing the details on how altitude is determined. Although the EFK2 system uses multiple sensors to determine altitude, what I notice is that the GPS altitude is always equal to my setpoint, but barometer readings are not. It would seem that my particular system uses GPS data for altitude as top priority, and basically ignores the barometer reading. Once I saw all three the readings the same, but for the most part, GPS altitude and barometer altitude are different by a large margin.
My original question was aimed at trying to understand this large difference, and whether it is something I have to be concerned with.
Does the ‘standard plastic case’ mean the product case of Pixhawk itself? I meant another case or box to contain the Pixhawk product to protect ambient wind variation.
Then, strong wind by propellers are blowing into the case directly. As you know wind flow affect pressure. How about use some paper box and well sealing? But I don’t know the result.
