Advice on IMU 6 axis

[matb]

Hello everyone,

I am seeking guidance over a client project.
The goal of the product is to tell pitch and roll degrees with left and right indications. (-10° on the left and +10° on the right)
We are seeking 0.5° accuracy in a dynamic environment (farmland)

We selected a BMI088 for the job. It is pretty good in temperature compensation (on an horizontal surface).

Now let's get to the harder part : Filters !

I selected 3 filters for the moment :
- Kalman
- Complementary
- Madgwick

Regarding an article point of view everyone seems to recommend the Kalman filter because it's "better in specific conditions" but they don't explicitly list these conditions.

I am wondering if implementing every algorithm is worth it because how can I now which one tells the "best" value. I will just have 3 values that will be (hopefully) a little bit different.
To compare them I was thinking of running them all at once so they have exactly the same values at the same time. I can't tell how much computational power that will require...

Do you have recommandations to start this project efficiently ?

I can't seem to find any guidance but from my understanding robotic, drones, wearable objects should use IMUs so I am surprised there are no training in building a product like this.

[MarkT]

Why not use a unit that does the work for you like the BNO-055?

[Doctorandus_P]

There is no single sensor nor filtering technique that works "ideally" for farm equipment.

For example, imagine you are plowing a field, and the left wheels of the tractor are riding on a relatively smooth surface, while the right wheels are in the previously plowed groove. Rocking of the tractor will mostly be around a circle with it's center point at the location of the contact surface between the ground and the left wheels. When it reaches the end of the field and turns around, it's left wheels will be in the previously plowed groove and movements of the tractor are mirrored. This may require different filter settings, and it is also dependent on where the sensor is located. (Right or left side of the tractor, how high above the ground?

Sensors are cheap. It is probably a good idea to mount at least two of them on the tractor (or whatever you call your farm equipment) One sensor on the left side, and the other on the right side.
BMI088 is a 6-axis sensor. Rotation of all sensors should be very similar for all sensors, or else the tractor itself bends or breaks. But linear acceleration measured by the censors can be very different, depending on where the sensors are mounted on the farm equipment.

[matb]

Why not use a unit that does the work for you like the BNO-055?

Well from a cost per board point of view an all included IMU is not in the price bracket. BMI088 is 3.31€ for 500 the BNO-055 is 6.88€ for 500.
From a business point of view that's a lot different. Thanks for the recommandation anyway.

There is no single sensor nor filtering technique that works "ideally" for farm equipment.

For example, imagine you are plowing a field, and the left wheels of the tractor are riding on a relatively smooth surface, while the right wheels are in the previously plowed groove. Rocking of the tractor will mostly be around a circle with it's center point at the location of the contact surface between the ground and the left wheels. When it reaches the end of the field and turns around, it's left wheels will be in the previously plowed groove and movements of the tractor are mirrored. This may require different filter settings, and it is also dependent on where the sensor is located. (Right or left side of the tractor, how high above the ground?

Sensors are cheap. It is probably a good idea to mount at least two of them on the tractor (or whatever you call your farm equipment) One sensor on the left side, and the other on the right side.
BMI088 is a 6-axis sensor. Rotation of all sensors should be very similar for all sensors, or else the tractor itself bends or breaks. But linear acceleration measured by the censors can be very different, depending on where the sensors are mounted on the farm equipment.

Yes you are right I will have 2 sensors at least. Regarding the last part why should I worry that the linear acceleration could be different ? The 2 sensors should be mirrored with a little error between them ?

[janoc]

Why not use a unit that does the work for you like the BNO-055?

Well from a cost per board point of view an all included IMU is not in the price bracket. BMI088 is 3.31€ for 500 the BNO-055 is 6.88€ for 500.
From a business point of view that's a lot different. Thanks for the recommandation anyway.

Consider how much is the development time and tuning (which are not trivial!) going to cost you vs. the 3€ extra for the more advanced sensor. That may well be saving pennies in the wrong place.

Considering the filter - all those 3 approaches will work for what you need.

Madgwick works explicitly in quaternions, so if you are only interested in pitch and roll it may be overkill for your needs plus you will need to convert from quaternions to Euler angles for display. Complementary filter may be the simplest to implement (relevant if you are going to do it on a low power MCU) but usually doesn't perform as well - it is basically blending/weighted average of data from multiple sensors with some fixed weight ratio. Kalman filter is the same basic idea but instead of fixed weights uses dynamically estimated gain.

If you decide to use multiple sensors you will also need to fuse the values from them - and also to calibrate them, both relative to the machine/vehicle and each other if you want to have reasonable results.

[Doctorandus_P]

Regarding the last part why should I worry that the linear acceleration could be different ? The 2 sensors should be mirrored with a little error between them ?

A single movement (rotation) of the tractor, can be registered as a horizontal G-force on one sensor, while it results at a vertical G-force on the other sensor. Combining data from multiple sensors is not trivial. Translateral motions will register the same on all sensors, while roational motions can register very differently depending on sensor position relative to the center of rotation. And most movements will be a combination of translateral and rotation.

[Infraviolet]

"BNO-055"
Be careful, it does the work for you but sometimes it does so poorly.
In particular, if you want to use the compass to get an absolute angle for something as versus the north direction, its self-calibration quickly uncalibrates itself when used in devices where there are metal objects or megnetic items within tens of cm of it.

Whereas for these constantly present items within the same reference frame as the sensor, if you take the raw magnetometer readings and apply manually calculated offsets to them as calibration, it can track north consistently over tme and not need to be regularly shaken around to recalibrate the internal calibration methods.

The BNO-055 is a good sensor, but I'm noting this because I had real trouble with it as a compass until I started using raw magnetometry readings from t and applying my own calibration to those sintead of trusting its internal calibration routines.

For magnetometry atleast I'd be very surprised for any method to get within 0.5 degrees, even 5 degree accuracy for finding north can be hard to achieve despite calibrations. Real world magnetic fields are just too messy.

[matb]

What exactly do you imagine with the calibration step ?

Like put the sensor in -1g on x axis for exemple, keep the raw value then apply +1g and create an f(x) = ax+b equation so that 1g = 1000 and -1g = -1000 ?

"BNO-055"
Be careful, it does the work for you but sometimes it does so poorly.

That's why I was thinking of doing the "smart" work on my side.

Considering the filter - all those 3 approaches will work for what you need.

Madgwick works explicitly in quaternions, so if you are only interested in pitch and roll it may be overkill for your needs plus you will need to convert from quaternions to Euler angles for display. Complementary filter may be the simplest to implement (relevant if you are going to do it on a low power MCU) but usually doesn't perform as well - it is basically blending/weighted average of data from multiple sensors with some fixed weight ratio. Kalman filter is the same basic idea but instead of fixed weights uses dynamically estimated gain.

If you decide to use multiple sensors you will also need to fuse the values from them - and also to calibrate them, both relative to the machine/vehicle and each other if you want to have reasonable results.

So to summarize :
- Madgwick : quaternions → need to transform to Euler, "overkill"
- Complementary : easiest but "doesn't perform well", hard to find the weight ratios
- Kalman : Same idea but the initial ratios are very important or it will take some time to have the filter auto-tuned enought to be usable

[SiliconWizard]

The hard part of course, whatever method you use, is to "isolate" the part of the acceleration on each axis due to gravity from linear acceleration due to motion.
It could be as simple as a low-pass filter, but with this simple approach, obviously the less susceptible it will be to motion/vibration and the slower it will be to react to change of angles.

I suggest looking at the source code for some drone projects, that's the kind of thing they routinely do and they manage to do it reasonably well.

[Siwastaja]

That's why I was thinking of doing the "smart" work on my side.

Note that depending on requirements, this could be years of work for a large team. There are companies dedicated to inertial navigation (even just something as "simple" as dynamically responsive inclinometer), so outsourcing something that just works might be a good idea.

[matb]

The hard part of course, whatever method you use, is to "isolate" the part of the acceleration on each axis due to gravity from linear acceleration due to motion.
It could be as simple as a low-pass filter, but with this simple approach, obviously the less susceptible it will be to motion/vibration and the slower it will be to react to change of angles.

I suggest looking at the source code for some drone projects, that's the kind of thing they routinely do and they manage to do it reasonably well.

That's what I was thinking a low pass filter and maybe a moving average but that would delay potentially quite a bit the real movement and changes.
I don't know if drones are really similar as from what I can imagine they have high frequency noise from motors and the like while tractors would have low frequency noises from road and machine motors.

Do you have some projects in mind that could be usefull at least to review and read about ?

That's why I was thinking of doing the "smart" work on my side.

Note that depending on requirements, this could be years of work for a large team. There are companies dedicated to inertial navigation (even just something as "simple" as dynamically responsive inclinometer), so outsourcing something that just works might be a good idea.

I would be alone on the project and it's due in march    . What you are saying is quite scary. I, for the moment, have a solid I2C communication and I'm will be starting the complementary filter.

And that would only be the prototype part, I also need to industralize almost 40 units for march...

[Berni]

Complementary filters are a good starting point for IMUs since they are simple to implement and understand.

Then you can tack on some extra smarts onto the filter to improve it. For example when you see a total acceleration that is significantly different from 1g then you can be certain there was some outside acceleration happening (or the tractor is in freefall after falling of a cliff, but in that case you have more serious problems). So since you know accelerometer readings in that time are going to be unusable you can just not feed those readings into the filters to avoid messing them up.

A good simple trick is to make your filters in a way where you can tune their time consonant while running. This way you can increase the time constant when you detect too much external acceleration, so the filter mostly just holds its previous value, then afterwards lower the time constant again so that it starts following the accelerometer again.

Another thing to watch out for is vibration. The tiny sub milimeter vibrations can actually carry a lot of acceleration inside them, so it is very important how you mount it to a tractor. They tend to have a lot of vibrations everywhere. You might end up with accelerometer readings being full of noise from engine vibrations.

[Siwastaja]

I would be alone on the project and it's due in march    . What you are saying is quite scary. I, for the moment, have a solid I2C communication and I'm will be starting the complementary filter.

And that would only be the prototype part, I also need to industralize almost 40 units for march...

Of course this sort of timetable is impossible. If you are a super mega experienced rockstar with prior experience on all the related fields, and reuse your older work, it could be just barely possible, and your paycheck would be also massive. But then you wouldn't be asking for help. Just design-for-manufacturability, choosing components/suppliers/BOM, a prototype round and then the first 40-unit production run would be in range of approx. 6 months, assuming no problems with component availability, and that includes none of the firmware work let alone algorithm work.

Your best bet is to find a product which already does what you need and put in in a box of yours.

[janoc]

So to summarize :
- Madgwick : quaternions → need to transform to Euler, "overkill"
- Complementary : easiest but "doesn't perform well", hard to find the weight ratios
- Kalman : Same idea but the initial ratios are very important or it will take some time to have the filter auto-tuned enought to be usable

The complementary filter will likely work just fine - you take most of the data from the gyro and compensate the drift using the accelerometer. Once you tune the ratios it will keep working because the parameters of your vehicle and sensors likely don't significantly change. An inclinometer on a slow moving tractor is not exactly rocket science and you probably doesn't need to be 1-2 degrees accurate either. Most likely you will only need that the values are stable, in a reasonable ballpark and not jumping all over the place as the machine is moving.

Kalman filter doesn't start with ratios but estimates about how noisy your measurements and process are (think means + covariances). The ratio is calculated on the fly (Kalman gain).

If you want to be fancy, you can always use extended or unscented Kalman filter or particle filtering too - however, for your use case it is most likely a massive overkill, since you have a system that regular Kalman filter models well.

There isn't a magic solution to this, though - you are always estimating some values from noisy data and integrating multiple sources to compensate for  the gyro drift and accelerometer noise, no matter how much math you throw at it.

[SiliconWizard]

The really hard part is inertial navigation, in the sense of estimating speed and displacement from the IMU. It definitely requires sophisticated approaches and some people have spent a whole PhD on this (still with unperfect results).
But the OP is only after orientation angles relative to ground, at least if I got it right (may have missed something though). Which is already a bit less challenging. 0.5° of accuracy looks challenging already, but you actually need much better than this to properly estimate displacement (which is the big challenge) - you can calculate what a given estimated angle error would give in terms of error in estimating displacement (which requires integration), it adds up very quickly.

A complementary filter, which combines acceleration and gyroscope, is where to start, it's easy to implement, doesn't require much computation at all and mainly has one coefficient to tweak.
My approach would be to prototype this to evaluate the kind of error you're able to get - feasability phase. This phase can likely be completed within 2 months - but a completed device ready for production? I wouldn't bet a dime on it. I'd count 3 to 6 months.

[matb]

The really hard part is inertial navigation, in the sense of estimating speed and displacement from the IMU. It definitely requires sophisticated approaches and some people have spent a whole PhD on this (still with unperfect results).
But the OP is only after orientation angles relative to ground, at least if I got it right (may have missed something though). Which is already a bit less challenging. 0.5° of accuracy looks challenging already, but you actually need much better than this to properly estimate displacement (which is the big challenge) - you can calculate what a given estimated angle error would give in terms of error in estimating displacement (which requires integration), it adds up very quickly.

A complementary filter, which combines acceleration and gyroscope, is where to start, it's easy to implement, doesn't require much computation at all and mainly has one coefficient to tweak.
My approach would be to prototype this to evaluate the kind of error you're able to get - feasability phase. This phase can likely be completed within 2 months - but a completed device ready for production? I wouldn't bet a dime on it. I'd count 3 to 6 months.

Yes that's it 0.5° accuracy relative to ground. That's the specs in the requirements. I will see from there.
At first I think I'm going to focus on static degree values (like 5, 10, 20, 30°) to have a starting point. Then I will probably lose hair on dynamic filtering in "real" environment.
From there I might go around in my car with the sensor just to play with it (don't have a tractor neither a land to play).

From the feedback I'm a little skared I'm no expert it's the first time I actually use a 3D accelerometer. Might seek external help to take on some part.

[Siwastaja]

Even with "just" pitch&roll (inclinometer), 0.5deg accuracy in high vibration, highly dynamic environment is not that easy-peasy (2deg is easy). Personally, years ago, I implemented the simplest "most of the data from gyro, slowly moving average from accelerometer" using Euler angles in a few hours and it works (well incorrectly because Euler angles are the wrong thing to do, but for small angles that doesn't matter), but definitely not to the 0.5deg requirement in difficult environment. This 0.5deg requirement is alone challenging to achieve using inexpensive MEMS accelerometers even in fully static environment (consider noise, temperature, aging drift and hysteresis), so the remaining error budget for the dynamic part is smaller (maybe 0.2 deg). The thing is, cheap MEMS gyros are not accurate even to a few minutes, so you can't just make the accelerometer coeffs arbitrarily low; you'd need to choose between gyro drift, or longer maintained acceleration showing as incorrect inclination. And then, gyros would show sensitivity to acceleration, and accelerometers again sense centripetal force.

Turns out, even just for inclinometers, I have seen large projects with long timeframes and many algorithm developers.

[SiliconWizard]

The really hard part is inertial navigation, in the sense of estimating speed and displacement from the IMU. It definitely requires sophisticated approaches and some people have spent a whole PhD on this (still with unperfect results).
But the OP is only after orientation angles relative to ground, at least if I got it right (may have missed something though). Which is already a bit less challenging. 0.5° of accuracy looks challenging already, but you actually need much better than this to properly estimate displacement (which is the big challenge) - you can calculate what a given estimated angle error would give in terms of error in estimating displacement (which requires integration), it adds up very quickly.

A complementary filter, which combines acceleration and gyroscope, is where to start, it's easy to implement, doesn't require much computation at all and mainly has one coefficient to tweak.
My approach would be to prototype this to evaluate the kind of error you're able to get - feasability phase. This phase can likely be completed within 2 months - but a completed device ready for production? I wouldn't bet a dime on it. I'd count 3 to 6 months.

Yes that's it 0.5° accuracy relative to ground. That's the specs in the requirements. I will see from there.
At first I think I'm going to focus on static degree values (like 5, 10, 20, 30°) to have a starting point. Then I will probably lose hair on dynamic filtering in "real" environment.
From there I might go around in my car with the sensor just to play with it (don't have a tractor neither a land to play).

To get any kind of relevant measurements, a car is probably not a very convenient environment. Both for the study phase and for future validation, I would recommend setting up a test fixture in lab.

Anyway, if you want to get a rough first idea, what you can use first, before making any prototype, is your phone or tablet. (All have an accelerometer, but make sure it has a gyroscope as well, many do.)
I've used the app HyperIMU to test some IMU algorithms. It streams sensor data over UDP, which is easy to read with a few lines of code.

[matb]

Even with "just" pitch&roll (inclinometer), 0.5deg accuracy in high vibration, highly dynamic environment is not that easy-peasy (2deg is easy). Personally, years ago, I implemented the simplest "most of the data from gyro, slowly moving average from accelerometer" using Euler angles in a few hours and it works (well incorrectly because Euler angles are the wrong thing to do, but for small angles that doesn't matter), but definitely not to the 0.5deg requirement in difficult environment. This 0.5deg requirement is alone challenging to achieve using inexpensive MEMS accelerometers even in fully static environment (consider noise, temperature, aging drift and hysteresis), so the remaining error budget for the dynamic part is smaller (maybe 0.2 deg). The thing is, cheap MEMS gyros are not accurate even to a few minutes, so you can't just make the accelerometer coeffs arbitrarily low; you'd need to choose between gyro drift, or longer maintained acceleration showing as incorrect inclination. And then, gyros would show sensitivity to acceleration, and accelerometers again sense centripetal force.

Turns out, even just for inclinometers, I have seen large projects with long timeframes and many algorithm developers.

From my tests in an industrial oven the BMI088 shows basically no drift in temperature. Accelerometer values are constant and the gyroscope doesn't drift very much.
Yes the accuracy in a dynamic environment will be challenging ...

The really hard part is inertial navigation, in the sense of estimating speed and displacement from the IMU. It definitely requires sophisticated approaches and some people have spent a whole PhD on this (still with unperfect results).
But the OP is only after orientation angles relative to ground, at least if I got it right (may have missed something though). Which is already a bit less challenging. 0.5° of accuracy looks challenging already, but you actually need much better than this to properly estimate displacement (which is the big challenge) - you can calculate what a given estimated angle error would give in terms of error in estimating displacement (which requires integration), it adds up very quickly.

A complementary filter, which combines acceleration and gyroscope, is where to start, it's easy to implement, doesn't require much computation at all and mainly has one coefficient to tweak.
My approach would be to prototype this to evaluate the kind of error you're able to get - feasability phase. This phase can likely be completed within 2 months - but a completed device ready for production? I wouldn't bet a dime on it. I'd count 3 to 6 months.

Yes that's it 0.5° accuracy relative to ground. That's the specs in the requirements. I will see from there.
At first I think I'm going to focus on static degree values (like 5, 10, 20, 30°) to have a starting point. Then I will probably lose hair on dynamic filtering in "real" environment.
From there I might go around in my car with the sensor just to play with it (don't have a tractor neither a land to play).

To get any kind of relevant measurements, a car is probably not a very convenient environment. Both for the study phase and for future validation, I would recommend setting up a test fixture in lab.

Anyway, if you want to get a rough first idea, what you can use first, before making any prototype, is your phone or tablet. (All have an accelerometer, but make sure it has a gyroscope as well, many do.)
I've used the app HyperIMU to test some IMU algorithms. It streams sensor data over UDP, which is easy to read with a few lines of code.

I was trying to find some kind of sphere where you can move every axis independently but to no success. A gimbal as it appears to be called. [Edit image is messed up and taken from] https://en.wikipedia.org/wiki/Gyroscope

[Berni]

No need for any fancy gimbals for testing.

You can do most of it by just putting it into a cube shaped case so that you can set the cube down in various orientations on a table and this gets you accurate 90 degree angles in all the possible directions. If you want to also check for 0 you can use a bubble level to level out your table to perfectly level.

Testing it in a car can be pretty relevant still since you can asses how well it handles vibration and bumps. Fix it firmly to some soild part of the car body so that you get the full view of all the vibrations (like firmly zip tie it to a seat rail or roof rack or something) and go collect some data while driving on various types of surfaces. Ofcrouse you would at some point also want to strap it to a real tractor and collect a test recording of that.

And yes the drift of your gyroscope is most critical. This is because those angular velocity readings get integrated over time to get absolute angle. So even if you have a very teeny tiny amount of drift that drift will accumulate over the course of a few minutes into a large angle error. The more stable the gyro is, the less you have to rely on the inherently noisy accelerometer data to correct for the drift.

[Siwastaja]

Remember that gyros also have g-sensitivity (incorrectly named, should be a-sensitivity and that's the problem), and vibration rectifies into an offset error, which as nonlinear component is hard to compensate for, and then there is hysteresis. You see none of these at play when you test the drift/offset in stationary setting (well g-sensitivity you do see, but only at 1g).

[liaifat85]

You can take a look at this.
https://www.st.com/content/st_com/en/campaigns/ism330dhcx-imu-machine-learning.html
This is industrial graded.

[tokamak]

I can possibly help you,

Your choice of BMI088 is acceptable, given its performance and temperature compensation on a horizontal surface. Each filter has its strengths.

Kalman Filter (KF)
This filter is known for its optimal performance in systems with well-defined noise characteristics. It's excellent for linear systems but can be computationally intensive.

Complementary Filter
It is simpler and faster, but it blends accelerometer and gyroscope data but might not offer the precision you need in dynamic conditions.

Madgwick Filter
It is popular in the community for its ease of implementation and exemplary performance in many scenarios, especially for lower computational power requirements.

Given your requirement for 0.5° accuracy in a dynamic environment, I recommend an Extended Kalman Filter (EKF) instead of the traditional Kalman Filter. The EKF can handle non-linearities better, making it more suitable for real-world IMU data where perfect linearity is rare.

The EKF is designed to manage the non-linearities in IMU data, providing more accurate estimates.
It adjusts to changing conditions dynamically, maintaining accuracy even in less predictable environments like farmland.

Over the past seven years, I have developed and refined an EKF-based solution that has proven highly effective in various challenging environments. My experience extends beyond EKFs to include Unscented Kalman Filters (UKFs), Square Root Unscented Kalman Filters (SUKFs), and other higher-order fusion algorithms. These advanced methods leverage sophisticated mathematical models for even greater accuracy and reliability.

I suggest running a comparative analysis of the three filters you mentioned alongside the EKF.
Implement all four filters (Kalman, Complementary, Madgwick, and EKF) to process the same sensor data in real time. This will allow you to compare their performance directly.
Test the computational requirements of running all filters simultaneously. Depending on your hardware, you must optimize the code or choose the most efficient filter.
Define clear performance metrics, such as accuracy, computational load, and responsiveness. Use these to evaluate which filter best meets your requirements.

What I would suggest is as follows.
Implement the filters and run them parallel to the test data.
Conduct tests in the environment (farmland) to gather real-world data.
Compare the outputs using the defined metrics and choose the filter that best balances accuracy and efficiency.

Failing that, leveraging my EKF-based solution and my expertise in UKFs, SUKFs, and other higher-order fusion algorithms can provide several benefits for your project.
Achieve the 0.5° accuracy you require, even in dynamic and unpredictable environments.
My solutions have been tested and validated across various applications, ensuring they meet high-performance standards.
With my extensive experience, I can offer valuable insights and support throughout the implementation process, helping to streamline development and optimize outcomes.
By following this approach and considering my EKF-based solution, you can ensure that you select the most suitable filter for your specific application, providing reliable and accurate pitch and roll measurements.
Feel free to reach out if you need further assistance with the implementation or have any questions.