# How to improve AHRS algorithm

I'm currently working on a project with multiple IMUs mounted on moving vehicle estimating their pose. I've just read about AHRS algorithms. So I have two questions about them:

1. Since my data is pre-recorded and I know some fixed axes and movements those IMUs can make, how can those algorithms be improved? There has to be ways, otherwise my project would end just taking an existing AHRS library... :)

2. What I don't get is, will AHRS algorithm work properly even if I'm driving and accelerating in a car? How can those algorithm estimate where e.g. gravity is applying, whilst being accelerated in multiple directions?

By the way: I'm using BNO055 Developer USB sticks at the moment, which already deliver a G-vector and linear acceleration data. Does anyone know how and how accurate BOSCH calculates them? Not sure if I can trust them, or if I have to take raw acceleration and gyro and come up with my one linear acceleration.

• IIRC there are some app notes on BNO055, at least I think I remember some info about the algorithms inside Apr 2, 2018 at 21:33
• @MrGerber do you might remember witch one? I assume you mean one of those bosch-sensortec.com/bst/products/all_products/bno055 I've checked "BNO055 USB stick user guide" as well as the BNO055 data-sheet itself. Apr 2, 2018 at 21:50
• Arte you using a closed source library from bosch for this? The "right" answer would be: You can't trust their source if they don't tell you how they do it and don't give hard numbers in their specification.
– GNA
Nov 5, 2020 at 22:05

## 1 Answer

What I don't get is, will AHRS algorithm work properly even if I'm driving and accelerating in a car? How can those algorithm estimate where e.g. gravity is applying, whilst being accelerated in multiple directions?

The answer is "Yes but no". As you already mentioned, there is no way for an IMU sensor to differentiate the constant gravity from a constant lateral acceleration. You can make a lot of assumptions. For example in a car, it is really unlikely that the gravity force will have a high component in the lateral direction because cars usually can't drive up walls. However, for example a plane or a drone has a much more diverse movement pattern. This can become difficult.

The general way is to assume, that accelerations will be of short duration. Most AHRS algos use the following assumptions and ideas:

1. Rotation around an axis can be calculated using a gyroscope and integrating its angular velocity over time. Due to offset errors this value will run away over time.
2. Accelation can be measured using the acceleromater (Well, that's obvious, right?). Therefore, it can measure the gravity vector which is constant over time. However short accelerations of your object will affect the measurement (Assuming there are no longer acceleration periods, due to physical limits).

The general pattern is: The accelarometer is used for the long time observation of the gravity vector. Because the gyroscope's integrated angular velocity is not good for determining rotation over a longer period. Howerver, you don't want the higher frequencies of acceletation in your data because linear acceleration would affect your AHRS estimation. Therefore you use a highly averaged accelerometer data and combine it with a short term angular estimation calculated by integration of angular velocity. This way you basically cancel out the negative effect of both measurements and are left with a long term stable grivity vector that also responds quickly on rotations due to the angular velocity measurement.

common Filter techniques to combine the data (buzzword: sensor fusion) are:

1. A complementary filter. Not very good. But easy to understand and implement
2. a load of proprietary algorithms that people sell for a lot of money.
3. My favourite: The Madgwick filter: https://x-io.co.uk/open-source-imu-and-ahrs-algorithms/ There is open source code available and a paper explaining the algorithm.

Also you have to note, that true AHRS is only possible for roll and pith using an IMU. You need an magnetic field sensor or some other sort of fixed reference to determine the yaw heading. IMU algorithms won't work there because the gyroscope drift will change the heading and there is no component in the gravitation field measured by the accelaration sensor that can cancel this out.

Madgwicks algorithm also includes the possiblility to use an magnetic field sensor.

I would recommend playing with a custom written complementary filter for getting a feeling of the matter because it's very easy to implement. However, for soemthing reliable, more complicated algorithms are advantageous.

• hahah 2.5 years after the question finally an answer! thank you for that. i agree with your answer :) Nov 5, 2020 at 22:05
• Well... Yeah. Maybe it'll help someone else. No clue how I got here, if it's this old. Hope you have solved your problem in the time ;)
– GNA
Nov 5, 2020 at 22:08
• exactly! i might should start to answer some of my old questions too. totally forogt about most of them. and thanks, i did :) Nov 5, 2020 at 22:09