Go Down

Topic: Altitude estimation from barometer and accelerometer , fusion algoritm (Read 10809 times) previous topic - next topic

frenky81

Hi all, im developing a autopilot from drone (copter) application , for now the copter fly good and have a stabilization in all 3 axis computed from a imu with 3 axis accelerometer 3 axis gyroscope 3 axis magnetometer , but now the problem is to stabilize the drone in the aLtitude .

I have a barometer that give me the altitude estimation but this is not enought because barometer have some drift and the sample rate is not enought fast for have a good stabilization so i thought to fuse the accelerometer z axis with the barometer datas for have a clean and fast altitude estimation.

for get a dynamic z accelerometer data i have calculated a static gravity values from quaternion and i have subtract it from the accelerometer value (calibrated value). The problem is that i can not have a estimation on vertical position because accelerometer is really unstable with noise ( also after low pass filter ) and a offset generate a error in the velocity calculation and of course in the vertical position.

Someone had this problem ? what's the solution ?

jremington

It is not possible to calculate position using consumer-grade accelerometers; they are too noisy. More information here: http://www.chrobotics.com/library/accel-position-velocity

frenky81

so is there no alternative ? i have seen in many autopilot they say to use barometer with z acceleration fusion with a kalman filter and get a usable altitude estimation value . maybe are they using only the acceleration ?

look these below

https://www.youtube.com/watch?v=4ijo_821TQI
https://www.youtube.com/watch?v=Zc9jg1y08ew

MarkT

The noise isn't the issue, its the drift you have to cancel.  Kalman filter is the optimal
solution to any model estimation problem, but they are complex and you need to
sort out your variance matrices and so forth.

Easier is to use the altimeter to slowly derive the correction factor for the z-acceleration
Using a PID loop.  Treat the correction factor to the IMU as the PID output, and the
difference between IMU and altimeter height estimates as the control input.

You make the PID coefficients small enough to keep its reponse slow and then that
averages out the error from the altimeter, and only have the short-term drift from
the IMU left (long term drift is cancelled out).

Remember to do all the height stuff in the global coordinate system, not the local one.

[ BTW you shouldn't low-pass filter the acceleration vector, just integrate it twice (this
automatically low-pass filters but doesn't lose information) ]
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Chagrin


jremington

Quote
The noise isn't the issue, its the drift you have to cancel.
Why not post some code, and show us how it is done?

MarkT

Basic integration:
Code: [Select]

#define MS 10   // lets say update every 10ms
float dt = MS / 1000.0 ;  // dt in seconds
unsigned long next_t = 0L ;
float velocity = 0.0 ;
float position = 0.0 ;
float correction = 0.0 ;

void loop ()
{
  if (milis () - next_t  >= MS)
  {
    next_t += MS ; // prepare for next time
    float measured_z_accel = ....... ;  // here get the (upwards) z component in m/s/s
    // now integrate twice, subtracting gravity and adding  the dynamic correction
    velocity += (measured_z_accel - 9.8 - correction) * dt ;
    position += velocity * dt ;

    altimeter_pos = ...... ; // get the altimeter reading
    correction = pid_loop (altimeter_pos - position, dt) ;  // run PID loop
  }
  ...
}
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

jremington

Well, that is a start!

The most difficult part is the estimation of the Z acceleration. As the CHRobotics link demonstrates (albeit with some numerical errors), errors in the estimated pitch and roll angles of the craft of just one degree lead to incorrect subtraction of the acceleration due to gravity, and to nonsensical position estimates within a minute or so. As a result of sensor noise, that level of error is the best you can currently expect from consumer grade IMUs.

I agree that proper weighting of the barometric and accelerometric contributions, in the iterative fashion suggested, should lead to a better estimate of the altitude.

michinyon

Quote
so is there no alternative ?
Use GPS.    Fusion of barometer and gps altitude.  Forget about accelerometer.

GPS altitude is not all that good but better than nothing,    and will enable compensation for variations in atmospheric pressure.  Also the "noise" is not distributed in a proper random way.

MM81

Hi.

I am also very interested in this topic. Could anyone make some steps forward?
Anyone succeeding in combing barometer and accelerometer?

The readings I get from my barometer are noise but after applying a running average filter, that seems be OK. However, there still some open issues regarding accuracy and long term fluctuations. if I just could combine my current measurement with another eternal sensed data, that would greatly improve results.
 

Thank you. ciao
Marco

jremington

See this paper for a successful approach http://home.earthlink.net/~david.schultz/rnd/2004/KalmanApogeeII.pdf

MM81

Quote
See this paper for a successful approach http://home.earthlink.net/~david.schultz/rnd/2004/KalmanApogeeII.pdf
Hi.

Thank you!

Will go trough it and get back as soon as I will encounter some difficulties or questions will arise.

ciao
M.

wwbrown

Are you worried about the drift caused by changes in weather?  If so that drift can be handled by using a barometer on the ground to measure the changes and then use the difference in the atmospheric pressures to calculate the altitude difference between the ground station and the AV.

MM81

no that does not worry me. Swings in meteorological parameters, such as mean press, change over a time period which is greater then my flight time (battery charge). What I am interested in solving is, instead, the accuracy, reactivity and precision of the measured pressure data when fused with another sensor.

The barometer alone, won't serve much as that is very unreliable and prone to a wide range of ambient disturbances or measurm. errors. TO make a decent altitude hold I need and want something more robust, which the barometer alone cannot give me.


MarkT

GPS altitude is probably worse than the barometer in the short term.

You probably need to fuse all three, accelerometer for timescales of a few seconds, barometer for seconds to
a minute, averaged GPS to correct long term drift.

Collect some graphs of the output data from a barometer and GPS in realistic conditions and look at
them?
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Go Up