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
With a quick glance of the u-blox 6 datasheet (the GPS type used by the ardupilot), I see that it communicates packets of data to the autopilot in the syntax of NMEA messages, which was expected.
It is a reasonable assumption that the arduplane software receives the VDOP value, decodes it, maybe use it, and then dumps it, not storing it anywhere.
Two options come to mind.
1. Tamper with the arduplane firmware code to write the VDOP values to the dataflash file.
2. Listen to the NMEA sentences in parallel with another microcontroller and fiddle with them as you see fit; storing them to an onboard SD card is an option.
None of the above is a day-log project.
I took those measurements using my own autopilot board. I was receiving the full GSA NMEA message which included the VDOP metric. I just didn't send it in the onboard SD card and thus it is now lost.
RelAlt is (badly named) the GPS altitude fused with measurements from the barometer and accelerometer. It should be a more informed guess of your vehicle's altitude. It should not necessarily start from 0, it is not relative altitude.
@Jose,
I did a typo there. I meant 20Pa, which is 0.2hPa error is 20Pa, which still gives 1.7m of error by your method. I know I got better performance by this sensor. Maybe there is still something in that datasheet that I read wrong.
@Jorge,
Unfortunately I didn't keep logs of the VDOP measurement, so I can't comment on that. What would be a good value for VDOP for your standards?
Georacer Quote
""Temperature inside the cockpit would indeed rise. Roughly speaking, about 5oC in the first 2-3 minutes after powerup and then stay steadily there. As we all know, ventilation isn't an option with the BMP085 sensor, since air currents mess up the measurements pretty bard."
You are measuring anyway the cabin temperature that is not the same of outside air temperature . To compensate for temperature deviation, for example, from standard ISA model you need to know the atmospheric temperature. Cabin temperature is anytime different from the outside air temperature.
Georacer Quote
"It advertises an accuracy of 200Pa"
200 Pa of error on pressure is orrible!
Use the calculator a this link http://www.digitaldutch.com/atmoscalc/ rather than routines at the link I previously sent.
Try 16.7 m altitude => 101125 Pa
Try then 0 m => 101325 Pa
We have a variation of pressure of 200Pa in 16.7m
It seems not so accurate :-))
About sensor fusion, yes, I know that it's the best of both worlds, and a Kalman filter backed with a good model would probably be the best solution, but it's black magic for me, as of now.
I used the Bosch BMP085 hardware solution that ardupilot uses. Actually, I bought the breakout board of the sensor from 3DR. It incorporates a barometric sensor and a thermometer. It advertises an accuracy of 200Pa, but I can't find the resolution figure right now. The datasheet is pretty well-written.
http://www.adafruit.com/datasheets/BMP085_DataSheet_Rev.1.0_01July2...
I modified this library, and used it more or less as-is to calculate barometric altitude. It follows exactly the datasheet pseudocode.
The reason I modified it was that the sensor needs 35ms in the highest accuracy setting to execute the measurement and only then be read for its value. Thus I needed to break the prepping/reading procedure in two, since I couldn't let my autopilot stall for 35ms, waiting for the measurement to be prepared.
Temperature inside the cockpit would indeed rise. Roughly speaking, about 5oC in the first 2-3 minutes after power up and then stay steadily there. As we all know, ventilation isn't an option with the BMP085 sensor, since air currents mess up the measurements pretty bard.
A more involved heatsink installation would be required. But, on the other hand, wouldn't altitude reset after the sensor heats up work just the same?
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.
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.
@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).
-
1
-
2
of 2 Next