AHRS and KF quetions

[avsaase]

Hi,

Cool project! I'm trying to build something similar but written in Rust and targeting the Raspberry Pi Pico. It's still early days and I'm now trying to figure out the altitude/vertical speed estimation algorithm.

I currently have something similar to your KF2 filter without acceleration input but the response to vertical speed changes is not as fast as I want. I'm considering adding an IMU and AHRS to obtain vertical acceleration and use this as an input in the altitude KF, similar to your KF3+ filters (excellent write-up btw!).

I noticed your project uses the Mahony AHRS. This filter, and also the Madgwick AHSR, is known to be susceptible to attitude drift when there is horizontal acceleration because it's not able to distinguish this from gravity. I haven't done any tests myself but I imagine this would be a problem when making turns in a thermal. If the AHRS incorrectly estimates you're flying level then the acceleration felt in the turn is fed into the altitude KF, leading to an over estimation of the vertical speed. I'm curious how you managed to solve this problem, or if it's not a problem at all in practice.

Your altitude KF includes an acceleration bias term. Is this to capture this bias in the vertical acceleration cause by attitude drift of the AHRS? Or does it serve another purpose?

[har-in-air]

Attitude drift in the IMU algorithm is because the accelerometer can only be used for orientation in a 1g environment. There is a threshold window within which the acceleration sensor data is used to correct the gyro. Outside this only the gyro is used. So in sustained acceleration, the attitude will start drifting depending on the quality of the gyro.

Yes if you add centrifugal forces from a tight turn, you will add an acceleration component to the vertical acceleration. You would need a parallel algorithm that detects this situation (IMU+GPS ?) and takes the acceleration out of the computation, fading back to only pressure sensor data. Or if you have high rate GPS samples, fade towards the vertical velocity from the GPS. I was always travelling to fly and not flying enough to be able to test out potential improvements. And now have not flown for a few years, so ...

After calibrating the accelerometer, there will still be a small net vertical acceleration value in a 1g environment due to drifting sensor parameters caused by calibration issues, temperature, mechanical stress etc. This will be integrated to result in a non-zero vertical velocity that wants to increase all the time. So the algorithm continuously estimates this offset. That is why the vario takes a second or two to settle down when you turn it on.