Barometric altitude sensor equations

I have attached an Excel sheet that I made with the equations needed to design a barometric altitude sensor.


For lower altitudes and for small altitude deltas, one can assume that there is a linear relationship between pressure and altitude. Please see the attached Excel sheet for more details.

The SCP1000 pressure sensor seems like a very good candidate for a pressure sensor:
http://www.sparkfun.com/commerce/product_info.php?products_id=8161


The manufacturer gives these data:

Resolution: 3 Pascal (the fineness to which the sensor can be read - nothing to do do with the accuracy)
Relative accuracy (how close to the real pressure the sensor measurements are) over temp range +10C to +40C and 600 hPa to 1200 hPa: +/- 50 Pa. (It is not given in the datasheet if this is sensor to sensor or for the same sensor)

The manufacturer does not give noise data. However sources on the Internet may indicate that the sensor has an inherent noise of +/- 50 Pa.

Datasheet: http://www.sparkfun.com/datasheets/Components/SCP1000-D01.pdf

Sample code: http://www.sparkfun.com/datasheets/Components/SCP1000-D01.pdf

Another guy using the sensor for a variometer for paragliding: http://www.pixelproc.net/varios.html

The noise may be filtered out using an averaging filter however. Even a kalman filter and two sensors may be used.

baro_height_measurement_unit.xls

Views: 5269

Comment by Paul Bizard on December 29, 2009 at 1:16pm
It could be interesting to use this relationship for a dynamic model Hn+1 = F(Hn, Pn+1) that could be used in a simple Kalman filter: short term information = atmospheric pressure and noisy long term information = GPS altitude.
Comment by UFO-MAN on December 29, 2009 at 1:42pm
Hi Paul.

A GPS + a barometric sensor would probably be a good sensor pair (however UBLOX RS232 data accuracy (?), and even precision (?) have been reported to possibly be off by some people doing tests in 4 samples * sec ^-1 mode).

In addition a second or even a third pressure sensor that are sampled with evenly offset time intervals would give lower (faster) response times.

The input to the kalman filter with three pressure sensors could be PS1(t0), PS2(t0+1xSi), PS3(t0+3xSi)
t0 being time, Si being sample offset interval. PS(tx) being the sample reading taken at time tx

Then the dynamic model could increase time resolution to Pn+(1/3xSi) using the max sample speed that can give highest resolution and lowest noise of the sensor. I guess we can assume a linear fall / sink rate over time wich since we deal with RC airplanes with low speed, low mass, and low thrust to weight ratios. This would make the dynamic model linear and a numerical integration based on a multiply would be needed.

I would say we could be using the sensor for two scenarios:
*Landings (need fast response and a way to filter out noise)
*Altiude hold (need fast response, but also GPS in case of wind noise etc).

The weighting could be adjusted differently in LANDING_MODE and in ALT_HOLD modes.

I would also say that temp. correction based on a polynomial determined by curve fitting or a table based method should be implemented, as these sensors output vary nonlinearly with temperature and average pressure.

In case we have a spare I2C or TWI port on the UDB, this should be possible to implement w/o taking up analog ports.

UFO_MAN
Comment by Paul Bizard on December 29, 2009 at 2:57pm
Yes, it looks interesting.

I've read about Pete's UBLOX RS232 data accuracy test. I did some tests a couple of years ago with my EM406 and I found a lot of noise, but the mean value was real good, deviation was down to a few meters.
So the poor UBLOX data accuracy is disappointing.

The altitude would of course be the Kalman filter state, but this state could be augmented with some kind of sensor error (bias ?). This would lead to 4=1+3 states.

Propagation each 1/3xSi and then Correction with the 3 pressure sensors each Si and Correction with the GPS each second for example.

But would the computational load be excessive for the UDB ?

Paul

Developer
Comment by Ryan Beall on December 29, 2009 at 3:12pm
I imagined something simple like this:

Ki_alt = 0.001;

alt_error = baro_altitude - gps_altitude

altitude = altitude + alt_error*Ki_alt;
Comment by UFO-MAN on December 29, 2009 at 3:13pm
Hi again Paul. Quite interesting if we could get this working. Then automated landings could be possible.

I might be wrong, but to my understanding there are free CPU cycles left in the UDB even with the latest MatrixPilot sw running.

Alternatively, the height sensor could as well have its own CPU. The GPS data could be taken from the same GPS source as the UDB takes its GPS data from (via serial output, I2C or direct GPS RS232 tap via a buffer).

What someone with access to a Ublox GPS should do is to sample data on the ground (on a large open field for example) and determine average values as well as std. deviation over a large amount of samples.

What method did you use when you tested?

UFO_MAN

Developer
Comment by Ryan Beall on December 29, 2009 at 3:23pm
You can acomplish safe but hard landings with nothing more than baro altitude as long as you keep your airspeed slow on final. Its more like a carrier landing but most aircraft can handle it. Basic idea is to just cut throttle at about 10ft and the fly an airspeed to the deck.
Comment by UFO-MAN on December 29, 2009 at 3:45pm
Hi Ryan. Sounds worth trying!

What about detecting the air cushion under the aircraft that is caused by the ground effect. When the pressure increases due to the ground effect, the autopilot increases the aicraft attitude to +10 degree to slow down. This is what I see many experiences pilots do just before touchdown to get the speed down. May even be coupled with a pitot tube for airspeed.

UFO_MAN

Developer
Comment by Ryan Beall on December 29, 2009 at 3:54pm
Yeah that's the idea in a flare, however there is no sense-able pressure due to ground effect. The best way to account for flare is to use a sonar range finder for higher accuracy near the ground.
Comment by UFO-MAN on December 29, 2009 at 3:58pm
Hi Ryan, I have read that the data from ultrasonic rangefinders are erroneous when landing on grass (large errors in range readings due to reflections). Most of us land on grass and not on concrete.

Do you have any experience with using ultrasonic rangefinders for landing on grass?

UFO_MAN

Developer
Comment by Ryan Beall on December 29, 2009 at 4:15pm
No, but I have heard that about the ultrasonics. The other option are laser and optical flow. Both of wich are overkill if your aircraft can take the "crash" landing. Which all of mine can so.... There are also the newer 10K$ RTK GPS modules....

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service