Questions about kalman filter implementation

[kostas1507]

Hey, I have been going through the kalman filter code recently and I have a few questions have came up about the way it is implemented here.

1. Firstly, I don't understand why the state vector is not two dimensional. The third dimension (presumably representing acceleration) is apparently never used and I think is unnecessary. It is not possible to predict acceleration using a three dimensional state vector with only an accelerometer and obviously acceleration is never updated since it can not be mapped to a barometer measurement using the H matrix. Because of this, my understanding is that the acceleration dimension of the state vector always remains 0. I would like to know if there is any reason to complicate the code and use three dimensions on the state vector instead of two, am I missing something?

2. Second and more important question, just for reassurance: It looks like you are using the kalman filter in its pure (linear) form. However neither acceleration/pitch nor pressure can be linearly mapped to earth frame acceleration and altitude respectively. Especially the conversion from barometric pressure to altitude is highly non linear. This is normally taken care of through the use of either linearization (EKF) or the Unscented Transform (UKF) which is not done here. I understand that under some circumstances it is not problematic to use linear kalman filter eventhough non linear functions are involved but I mention this here to either get confirmation that this has been proven through testing and simulation to be reliable and accurate in different environments or to point out that it should. Implementing UKF or EKF at least for the update step is relatively trivial and I think could improve accuracy as I am particularly worried about the highly non linear (exponential) conversion function from pressure to altitude which under the right (wrong) circumstances could give consistently inaccurate results. Of course I have trust that this is known to the team that developed this filter and it is likely that I am overexaggerating the danger. I would just like to make sure that this has been confirmed to give accurate results (how was it confirmed?)

I understand I am being picky and probably over-stressing the problem but my team and I are developing a kalman filter for our own flight computer and we will not get a chance to test it in a real flight before the competition so I would like to make sure that we will get satisfactory results and that are both correct and confirmed by the cats flight computer.

3. Lastly I would like to know if the simple integration of the gyroscope measurements to get the rotation angles is at all problematic under particular circumstances and if it ever has issuses with drift/inaccuracies!

[kostas1507]

Ok for (1) I understand now that the third dimension is meant to represent the accelerometer offset but since the offset does not change during the flight, I don't understand why not just subtract it from measured z acceleration. I also have not been able to find where it is initialized

[jbinz]

Hi Kostas,

thanks for your message and I am very sorry to answer so late, I've only seen just now that message.

1. Yes, the third dimension is the accelerometer offset. As you can see in the prediction step, we only substract the estimated acceleration as you suggest. During the calibration and ready phase, we estimate the accelerometer offset through the KF and once we detect liftoff, we lock the accelerometer offset. This allows us to recalibrate the accelerometer offset with every bootup.

2. Yeah this is a question we asked ourselves too during development. The goal of our flight computer is to reliably detect apogee and main. Hence, the robustness of our algorithm is the most important aspect. One could implement an EKF, linearizing the measurement function and using this in the kalman filter, which may give a better estimate. Now, for the linear acceleration, the filter is implemented such that acceleration is given a lot of weight during the thrusting phase. Later, when the rocket is arching over, the acceleration weight is negligible compared to the barometric weight, hence the linear form is a good approximation.

For the barometer, if we assume a gaussian noise distribution, you are right that this assumption is not true anymore when transforming that measurement with the barometric height formula. However, we have observed time and time again, that this simplification does not impact the filter performance.

So in conclusion, an extended KF might be a better solution for total accuracy but then a simple 1 dimensional filter (only using height, velocity and acceleration in z direction) is anyway not the best choice as rotations in x and y also need to be taken into account. For our main goal, i.e. detecting apogee and main reliably however, the linear 1D KF is more than enough. If you want to have a ground truth of your flight, then looking at the raw data, including gyro and acceleration in 3D is a more sensible approach which captures the flight much better.

3. The rotational filter in our code is an experimental feature. It is not used for anything currently and is only logged. We have it there to collect information and it might be used one day for two stage rockets to send an abort signal if the pitch angle is too large before firing the second stage.

And yes, this filter does pretty much dead reckoning, so it does suffer from drift. However, if you calibrate your gyro properly the filter does okayisch for around 2 minutes before it drifts fully away.

I'm again sorry for the late answer!

Best,

Jonas