This might be a common knowledge, but in the last months I haven't seen a similar post. Maybe someone new to barometers might be interested in this data.
The GPS receivers return altitude data, but this is inaccurate. The error margin depends on the satellite constellation geometry and whether or not you have SBAS DGPS on. I was under the impression that the error was 5-10 meters, but as it turned out, I was wrong.
Recently, I embedded a BMP085 barometer in my autopilot board and operated it with this library: http://code.google.com/p/bmp085driver/
Barometers can be and are effectively used to calculate altitude, once initialized and zeroed.
So the figure above displays a short manual flight whose altitude is measured both by a barometer and a GPS. The barometer is zeroed upon power-up. The GPS altitude is zeroed, based on the altitude returned before taxiing. It is the time between 20 and 30 seconds. The plane lands at 150 seconds in the exact same place it took off. However, the GPS altitude measurement has already drifted 16m away.
This goes to show that GPS should not be used for altitude measurement, unless a very coarse albeit offset-free measurement is required.
A barometer is a much more accurate and fast device to extract altitude, when operated correctly.
Comments
Let me add another link to your list,
http://basicairdata.blogspot.it/search/label/altitude
Barometric altitude is easy to use but unfortunately typically it is not so accurate to allow a safe final approach to land for a UAS. Relative accuracy of barometric altitude is higher. If two or more airplanes are flying in the same airspace then their altitude readings will be practically identical.
I don't even know what built in algorythm is using your barometric unit, but the results cannot be so accurate. If the unit, as I suppose, is using the cabin temperature, you have a wrong compensation. In the case you intend to use a temperature compensation mechanism for altitude is needed to know the outside air temperature. Real size planes use OAT/TAT probes . A good point is also that of Tom Yochum that mention differences in coordinate systems and other GPS issues. To make an esteem of overall performance also this aspect should be considered, of course numerically.
A viable way is to use both the data from the GPS and from the barometer to feed a digital filter that considers the model of the measurement process itself, as many Kalman filters. In many cases the uncertainty of this output is littler than that of single sensors.
@Georacer:
You are correct that as satellites come into and out of view the GPS position solution can "jump". The slow variation of a few meters is the result of normal noise in the measurements.
DGPS essentially corrects the ionospheric delay. Without DGPS (SBAS) you would see the normal position variation in the 10-15 meter range.
I 'm posting this link here also for reference and storage purposes: http://www.borgeltinstruments.com/GPSvsPressurealtitude.pdf
@ Ondrej,
This is strange: The GPS altitude has the same downwards drifting as the barometer altitude as before. I don't think I have an adequate explanation for this at the moment.
@b nevins,
For our run-of-the-mill GPS receivers, I don't think that they incorporate Kalman filtering or a memory model larger than a few seconds. So, leaving it sit for any amount of time, wouldn't ameliorate the situation.
I remember a test I had run a while back, only with the GPS receiver. I powered it up and let it stay steady. The position fix was visually accurate on google maps but would drift over the course of 5 minutes towards south-east by a few meters. This result was repeatable.
I think as the satellite constellation moves on the sky, the measurement falls under some discretization and drift, while new satellites are acquired, others move out of sight and others change position in the sky.
Essentially, this is what the ground station DGPS systems compensate.
I was just noting in both logs that the GPS was bias to a higher altitude in the beginning of the flight than it was at the end. Before takeoff, it was trying to correct altitude while it was still on the ground. I'm wondering if you let it sit for longer before takeoff, like 10 minutes after it has a 3D fix before taking off if it is able to correct that error so the takeoff and landing height were closer.
This is Sonar vs. RelAlt taked from GPS line in my log file.
@b nevins,
If you are referring to my log, let me tell you a bit more about the data extraction procedure.
I turn the GPS on, along with other equipment and log data every 0.065ms. Of course, GPS data gets updated every second. All that is dumped into a .txt file.
Afterwards, and before processing, I manually remove from the file the lines where there is initially no GPS fix and also the lines where there is no DGPS fix. I recognize those by not having a time and date data. I think this is the judging factor.
The rest is what you see in the first post. The GPS altitude jumps twice before take-off, which means that the constellations are changing quite fast or the atmosphere does and that my receiver can't tell what's happening up there. It's to be expected by a $25 receiver, in my opinion (UP501 model).
I'm curious if your GPS had a poor initial fix of its own altitude. If you ran a second flight without turning the GPS off if you had the same drift.
Yeah, every time when im looking into logs the baro is sliding down or up. And question is if you are flying without sonar have APM calculation with GPS alt and comparing with baro alt? Or if someone know how is working in Stabilise, Alt hold and Loiter?
Be careful about sonar. I have tested it extensively on quadcopter,APM2.5 with and Without EMI protections, with and without LC filter, with and without props noise and the result remains the same: very unstable sonar reading with spikes.
You can also see it on the graph above posted by Ondrej.
For me i fot so much erratic loiter or alt hold with the sonar that i have disconnected it.
We will have to wait for less noise sensitive sonars...unfortunately.
-
1
-
2
-
3
-
4
of 4 Next