What do you think of fusing an accelerometer (Integrated and tilt-compensated) with a pressure sensor to get the vertical velocity of an aircraft? I was thinking about trying this with a complimentary filter.
Has anyone done this? Are there any other methods? Any suggestions would be appreciated.
There are no such things as dumb suggestions or questions!
Also, I would appreciate links to other posts. I haven't found any till now.
That has been done several times and discussed on model rocketry forums, although altitude is usually more of interest than velocity.
I've attached one contribution by David Schultz (whose web pages seem to be no longer on line). You can probably find a copy on one of the web snapshot sites.
KalmanApogeeII.pdf (615 KB)
Perfect! Thank you so much! I’ll have a read through the document.
I need the vertical velocity so that I can calculate an estimate of the vertical wind in a turbulent atmosphere.
The velocity calculation is part of the published algorithm, but differentiating altitude with respect to time works too.
@jremington Yes, that makes sense.
I've tried my best to read through the paper you gave me and what he has done is use the Kalman Filter. Therefore, I have been doing some further research on Kalman Filter. Since I already know how a 1-Dimensional Kalman filter works and I have used it a lot for smoothing on MATLAB. It wasn't too difficult to grasp it.
However, I'm not 100% sure that I understood it fully. Where I, kind off, got lost is the fusing of the GPS/pressure sensor with the Accelerometer.
As I understand it, the Accelerometer data gets put into the state equation already filtered:
x(k) = Fx(k-1) + Bu(k-1)+w(k-1)
Where u(k-1) gets replaced by a filtered acceleration, a(k-1) and w(k-1) gets neglected since a(k-1) is already filtered.
Since, Position is 3 dimensional, from the GPS we would get (Px, Py, Pz). This is all relative to the North East Down (NED) Frame. Therefore, I am assuming that the accelerometer has to produce acceleration data with respect to the NED axis.
My question is:
The paper describes a 1D problem, not 3D, so only one accelerometer axis is relevant (or the total magnitude).
The acceleration data are not "already filtered", they are used with the system model to provide one estimate of the altitude. The pressure data provide another altitude estimate, and those estimates are combined by the filter using the filter-derived weights. You need to look at the C source code to see exactly how this is done.
The Kalman filter can be thought of as a way to calculate the weights for a standard weighted average of two or more variables. Given a system model, it can be proven that the Kalman filter weights are the best possible, but only in terms of that particular model, which may not be correct.
I think the best explanation of the Kalman filter is given in Dan Simon's "Optimal State Estimation". But it is a popular textbook, so it is an order of magnitude overpriced.
jremington:
The paper describes a 1D problem, not 3D, so only one accelerometer axis is relevant (or the total magnitude).
Yes, I know, but since I have a GPS module, I thought I might aswell fuse the GPS (Also to gain a learning experience). I could also do separate Kalman filters for each axis. So, for this case I would need to convert the sensor body frame of the IMU to the NED frame, is this correct?
The acceleration data are not "already filtered", they are used with the system model to provide one estimate of the altitude.
I read this in another paper, maybe I didn't understand it fully. I have added a screenshot below. Or maybe you misunderstood what I wrote. I meant that you can't replace u(k-1) with an unfiltered accelerometer.
Reference: Introduction to Kalman Filter and Its Applications | IntechOpen
You need to look at the C source code to see exactly how this is done.
You are right, I will look at it again.
I think the best explanation of the Kalman filter is given in Dan Simon's "Optimal State Estimation". But it is a popular textbook, so it is an order of magnitude overpriced.
I have seen you posted this in another post. My university has a copy in the library. I'll see if I can borrow it tomorrow.
For now, I'm just trying to simulate the Kalman filter in MATLAB with some data before trying to program it in Arduino.
Thanks again for your reply.
I could also do separate Kalman filters for each axis.
I doubt very much that would be useful. You need to do the full 3D calculation, which is a pretty complicated problem, given that the accelerometer data are in the body frame of reference, while the GPS altitude and pressure sensor data are in the world frame.
David Schultz' site had some other Kalman filter models that included Matlab code. I imagine you can find it on the Wayback Machine or other web snapshot service. home.earthlink.net/~schultdw/
That's why I was wondering if you know how to efficiently convert the body frame of the accelerometer to the world frame (NED)?
I'll look at the link, thank you.
I hope I'm asking the right questions and not being irritating.
To convert between frames of reference, you can use either a rotation matrix or quaternion operation.
It is a dynamic operation for the filter you propose, since the filter necessarily includes orientation, and that is a major complication.
I think you are getting way ahead of yourself, and need to set some reasonable goals for the immediate project. Consider describing what you are actually trying to do, with what sort of flying object.
Attempting to estimate altitude from acceleration, as measured for example in a hobby drone, won't work at all, as discussed here.
I take the scaled values and send them through a Kalman filter before sending them to the rest of the calculations.
I use a SimpleKalmanFilter GitHub - denyssene/SimpleKalmanFilter: A basic implementation of Kalman Filter for single variable models.. A nice thing is to look at the cpp code to get an idea of how the math works.
float SimpleKalmanFilter::updateEstimate(float mea)
{
_kalman_gain = _err_estimate/(_err_estimate + _err_measure);
_current_estimate = _last_estimate + _kalman_gain * (mea - _last_estimate);
_err_estimate = (1.0 - _kalman_gain)*_err_estimate + fabs(_last_estimate-_current_estimate)*_q;
_last_estimate=_current_estimate;
return _current_estimate;
}
jremington:
To convert between frames of reference, you can use either a rotation matrix or quaternion operation.It is a dynamic operation for the filter you propose, since the filter necessarily includes orientation, and that is a major complication.
Since a complimentary/Mahony/Madgwick filter gives us the Euler angles/Quaternion representation, the rotation matrix shouldn't be such a complicated issue, right? Or is it a complete different type of rotation matrix?
Also, as I understood the Madgwick paper, he produces a prediction of the orientation of the earth frame relative to the sensor frame. Is it not possible to use this method to predict the orientation of the world frame relative to the sensor frame?
I think you are getting way ahead of yourself, and need to set some reasonable goals for the immediate project. Consider describing what you are actually trying to do, with what sort of flying object.
You are probably right...
The flying object: a general aviation aircraft (e.g. Cessna 172 or Piper PA28) that would fly around 50m/s (100 knots).
Goal of the project: measure and report the eddy dissipation rate and send critical turbulent data (for smallest A/C type) to a server.
requirements: True airspeed (TAS), angle of attack (AoA), GNSS location, Altitude, Vertical velocity, Vertical acceleration, Pitch and Roll.
Idahowalker:
I take the scaled values and send them through a Kalman filter before sending them to the rest of the calculations.
That's exactly what I was thinking before when I mentioned filtered accelerometer.
I use a SimpleKalmanFilter GitHub - denyssene/SimpleKalmanFilter: A basic implementation of Kalman Filter for single variable models.. A nice thing is to look at the cpp code to get an idea of how the math works.
I haven't looked at the code properly but its probably the same as this:
I have already done this by hand. It works great.
I have also used this library for my Air speed sensor. I am happy with the results.
jremington:
Attempting to estimate altitude from acceleration, as measured for example in a hobby drone, won't work at all, as discussed here.
Yes, but does that also include the fusion? I would assume that integrating an accelerometer would just unnecessarily increase the constant resulting in a drift. My assumption is that an accelerometer measures the acceleration better than the derivative of, lets say a static pressure sensor. But a static pressure sensor would probably measure the position better than an accelerometer. So using the best of both worlds you would have an accurate estimate.
p(k) = p(k-1) + v(k-1)dt + 0.5a*dt^2
Don't forget a key word that has been used. This keyword is a hint of accuracy issues. The keyword is
Hobbyist
Idahowalker:
Don't forget a key word that has been used. This keyword is a hint of accuracy issues. The keyword isHobbyist
I don't know what you are trying to imply with that. I am definitely not a professional, I am just trying to learn this for my thesis and so that I can expand my knowledge. I appreciate all the help that I am getting.
Oh. I mean hobby IMU's are at the bottom of the barrel in regards to quality and accuracy of the devices, automotive IMU's are middle of the road, and military grade IMU's are at the high end is what I meant.
Ah okay. Sorry, I misunderstood that 
. That's exactly part of the project, to make it economical feasible for any pilot to buy and therefore making general aviation safer. Mostly theoretical of course.
We pilots already have Vertical Speed Indicators in the plane fed from a Static port on the side of the plane (or 2, one one each side).
More modern setups also feed the tube into a digital display and it appears as a rolling tape display on a screen.
You can see the current altitude on the right, with an indicator to its right of the rate of change in feet per second in this Garmin G5 example.
Yes, but does that also include the fusion?
Please read the material in the link, and make sure that you understand it before firing off such questions.
It would be a good idea for you to estimate, in actual practice, the errors in the individual operations before planning a grand fusion scheme.
To get the vertical velocity from the accelerometer requires integration, after subtracting the acceleration due to gravity, and is extremely error prone.
To get the vertical velocity from the GPS and the pressure sensor requires differentation, which enhances the errors in the individual measurements by at least a factor of sqrt(2).
