Why would an artificial horizon's roll axis be different on ground and in flight?

Question

Sorry, if I'm a bit verbose here, but since I don't understand the problem, I have difficulties to describe it.

I created an artificial horizon using an Adafruit precision 9 DoF sensors and their AHRS SW pack, which is quite sophisticated using Kalman Filters and Covariance matrices for fusion. On my dev table, everything works fine. Roll, pitch, yaw, tilt compensated heading, even if I shake it. I clipped it onto my shaver to simulate vibration, everything OK! Hence, I believe its not a HW or SW problem.

The problem occurs when I mount the device onto my ultra light aircraft. Pitch and Yaw/compass course remain OK, but roll becomes strange. When I turn, the roll axis moves into the right direction, but not enough (say 30° instead of 45) and even if I keep turning at the same bank angle, the roll axis displayed moves back to horizontal. As I said, when I turn the sensor from 0° to 45° on the ground, it rolls from 0 to 45 and stays there!

So the only difference is, IMHO the fact that on my dev table, things are pretty stable, while in the air, the sensor moves at 180 Km/h and in curves there might be some issues from centrifugal forces, which dilute the accelerator values and the Kalman filter tries to correct the Gyro rate by an exorbitated accelerometer value, which are normalized, showing 0.99g when flat on the table.

Any suggestion ?

Answer 1

The problem

As already pointed out in some of the comments, this is a structural problem of using an IMU-only AHRS unit. This unit cannot distinguish between acceleration due to centrifugal force, and acceleration due to gravitational forces (of earth).

For example imagine that you fly level, and then roll into a coordinated turn. The short-term roll-rotation will be picked up by the gyroscope, however in the coordinated turn itself the AHRS only "sees" a constant acceleration through its local z-axis (because you are in a coordinated turn). The gyroscopes on the other hand, will not see any movement at all. Therefore the filter will (over time) assume level flight. In essence, you cannot distinguish between gravitational forces and centrifugal forces in forward flight with the accelerometer alone.

Ways to solve this problem

I am aware of two ways of fixing this problem:

1. Buy a good gyroscope: If you buy a very good gyroscope, you can simply use its measurements and completly omit the accelerometer. However even good MEMS Gyroscopes still have considerable drift (typically you will notice an roll-angle drift after a couple of minutes). If you are willing to spend your life savings (I belive the price tag is 250k$) on a Ring Laser Gyroscope, you can also solve your problem. Fun fact: A couple of flat earthers bough one of these devices and ultimatively measured the earths rotation...

2. If you are on a Budget however, it may be cheaper (and more reliable) to give your algorithm some sort of velocity feedback. Typically, this is either a GPS unit (which not only produce a measurement of position, but also a velocity measurement), or a velocity measurement based on a pitot tube. With this measurement available, the centrifugal force can be calculated and be accounted for.

Implementation

How can you implement this in software? Well either you take existing projects from any of the common flight controllers like Ardupilot, or betaflight and adapt these to your needs (not knowing your hardware, I cannot tell you how labor-intensive this will be). Or you try to program your own estimation unit based on your IMU and velocity sensor. Before you try to figure out everything by yourself, I would recommend to first take a look at existing Software, which already implements everything necessary. In a nutshell, you just have to program a relatively simple Kalman filter based on the known equations of motion of a 6-DoF point which also estimates the gyro offsets. A very good example of how such a filter is designed can be found on the PX4 project (yet another flight control stack), which details how their Kalman filter is built up. One (open access paper) detailing such an implementation can be found here. I would regard this as the state of the art, and how one would commonly address this problem. The block diagram is displayed here:

Another implementation hinging on a simpler complementary filter, is described in this paper. Based on some minor assumptions it removes the centrifugal force via the airspeed, and uses the centrifugal-force-free acceleration as an input to a complementary filter. Although the used IMU is very high quality, and no algorithm for bias and drift compensation is used, you might get this to work with some adjustments. The block diagram is quite compact:

Disclaimer: I have no affiliation nor contact with any of the authors of the aforementioned papers. I do not own any of the images displayed here, these are directly taken from the papers. P.S.: Interestingly enough, I also came across this link which offers some bounty for an open-source software implementation of such an AHRS unit.

Answer 2

Disclaimer: I am not familiar with the Adafruit software. My experience is more related to the filter software by Sebastian Madgwick.

MEMS gyros are poor in comparison with state-of-the-art fiber gyros which shows in their level of noise and bias. The result is drift: Random walk from noise plus a steadily increasing error from the integration of the rotation rate bias over time. To compensate, the software will compare the orientation with the direction of gravity and nudge the orientation such that the horizon is perpendicular to gravity. This works nicely on the ground but fails as soon as the sensor is subject to a rotation which will add centrifugal acceleration.

That the roll axis moves initially with the roll movement is due to the fact that with every integration step the Kalman filter will apply only a percentage of the correction suggested by the gravity vector. Over time, this correction will then move the indicated horizon parallel with your wings. This is a bit as if you pull the cage knob of a mechanical gyro but that pulling will only move the roll axis a small fraction each time.

If you have the possibility to change the software, I would suggest to set the gravity correction to zero in the Kalman filter and to carefully calibrate the sensor before each flight. Second, add a button that allows to set the horizon to level so you can reset the horizon when you fly wings level. This is how the old mechanical artificial horizons work, too.

Trying to make the gravity correction conditional on the magnitude of the gravity vector will now run into problems with the noise of the accelerometer. You might have success by lowpass filtering the accelerometer and only when you see more than 1g in the filtered signal will you drive the gain in the Kalman filter to zero.

There are much better sensors around than what Adafruit uses, but they are more expensive. However, when you consider the time you sink into working with them, the better performance might well be worth the price. Maybe half of the cost is caused by factory calibration, but then they come with individual compensation tables which will greatly improve their accuracy.

Answer 3

To whom it may concern. Since I have started the question, let me now report the solution. Take it w/ a grain of salt, because it works for a micro light ACFT and nothing else. The problem is sufficiently well described here above, hence I just talk about the solution. Other than on the ground, the accelerometer(ACM) undergoes additional forces in curved flights (mainly centrifugal); hence the solution is eliminating the additional force b4 the ACM is used to correct the Gyro by the means of a Kalman Filter. I will calculate an example, using v= 160Kts and B=30° Bank. all in [m,Kg,s,rad] The radius of such a curve calculates [F1]: r=v² / g / tan(B) = 82.3² /9.81/0.577 =1197m. The centrifugal acc calculates [F2] ac= v²/r = 5.65 m/s However, since we are looking for the bank angle, we are stuck in a vicious circle, because we need the bank angle for calculating the a.m. formulas! So what is the solution? Well the solution is in the circular velocity, or rate of turn (RoT). RoT= g * tan(B)/v; in our case 9.81 * 0.577/82.3 = 0.0688 = 3.94°/s. Now the trick! If we know the RoT, we can calculate B by solving the equation to B=arc tan(RoT * v/g). But how do we know our RoT?? Well we just read our Gyro z-Axis! We now substitute in [F1] and [F2] B by the formula above getting: ac= g* tan( arctan(RoT*v/g)) hence ac=RoT * v. V we read from IAS or GPS (there are caveats around it) and RoT from the Gyro z-Axis. Making the proof: reading 160Kts from IAS and 3.94 DPS from Gyro gives us the well known 5.65 m/s acceleration of the centrifugal force. Since the accelerometer measures the gravity, we need to convert the ac (5.65 m/s) into g by dividing it by 9.81 m/s. Hence the additional g-force of the centrifugal force calculates: gc= 5.65/9.81= 0.575g. To finally, we just subtract the 0.575g from the ACM y-axis value before we feed it into the Kalman Filter and by the above magic, the artificial horizon now shows a constant bank angle when flying a curve, good enough for me in an ultra light ACFT. Yours hk