# IMU Roll Angle - Correct when Stopped, Wrong when Moving

I have been using an MPU6050 (3 axis gyro, 3 axis accel, built in motion filter called DMP) on a car axle to measure axle angle when driving. On a long banked corner (2 degrees) the sensor reads 0 degrees while moving (~40km/hr), but when stopped it reads correctly (2 degrees). The physical axle angle is the same though in both scenarios.

I believe the lateral force from going through the corner is affecting the sensors interpretation of which way gravity is, and is adjusting the roll angles accordingly. See image;

Can anyone comment on how this might be solved?

For example;

1. Using a sensor with a magnetometer?
2. Using a sensor with a different filter?
3. Is this solveable at all or just an inherent factor of MEMS sensors?

Time is a critical factor at the moment in my project.

Edit 1: I've come across this thread where the OP seemed to have the same issue with MPU6050 and went to the BNO055 with some luck but had calibration issues. Then said the problem was solved with MPU9250 and RTIMULib (open source filter) in the last post. I wonder if adding in a magnetometer helped as it gives a fixed 3D reference point which is not affected by acceleration forces. Or perhaps he tweaked the algorithms in RTIMULib to get his desired output. I have yet to delve into the motion-fusion/filter algorithms. To date I have just been letting the MPU6050 do that internally in the DMP. Any thoughts on these potential solutions?

• a²+b²=c² , i.e., F[sensed]² = F[gravity]² + F[lateral]². If F[sensed] and F[gravity] are known you can calculate the magnitude of F[lateral] (but not its direction). Commented Aug 15, 2017 at 11:28
• Thanks JimmyB. Currently the algorithms are done automatically in the DMP of the sensor so I cannot alter these. But if I need to implement by own algorithms/filter than I will take this into considerations. Commented Aug 16, 2017 at 1:21

It is certainly solvable.

My guess is that the filter doesn't trust the gyroscope readings and absolute values from the accelerometers very much due to the noise and offset issues inherent in MEMS sensors and so when it gets a steady state with gravity slightly stronger than expected and a constant rate of turn it assumes that they are offsets and cancels them out. A different filter combined with a calibration process at startup could help with this but you may end up needing better sensors.

However getting this sort of thing to work correctly and reliably isn't normally quick or easy. If time is critical I can't think of any quick fix for this that doesn't involve throwing money at the problem and purchasing a far higher quality IMU and positioning engine software.

• Thanks Andrew. I'll take your advice into account. I've also added an 'Edit 1' at the bottom of the original post referring to another user who seemed to solve their issue. Do you have any comments on this, such as using a magnetometer to help with the issue? Commented Aug 16, 2017 at 1:27
• A magnetometer will help a little since it will show you that you are indeed turning, more inputs into the filter will always help assuming you set the filter up correctly and have the CPU power needed. However you do have to ensure that your filter allows for a large error in the readings, compasses placed inside or under large steel boxes aren't the most precise sensors around. Again calibration can be a big help here but will only get you so far. e.g. you'll always see small deviations driving past large metal objects, not a lot you can do about that. Commented Aug 16, 2017 at 7:59

I think you can solve your problem. But you need to use your own sensor fusion algorithm instead of DMP (Digital Motion Processor). Because you can't change every single value of DMP, its more like blackbox. Also, as far as I remember DMP's data rate is 200Hz or less.

You can easly use complementary filter on your system. It provides you to change the rate of Accelerometer and Gyroscope effect on your system and much more data rate (depending on your MCU). Considering your limited time, you can probably find complementary filter codes for your MPU6050 on Github.

• Thanks Batu. From yours and other replies I am beginning to think implementing my own filter is the next step to test. I've also added an 'Edit 1' at the bottom of the original post referring to another user who seemed to solve their issue. Can you comment on this, in terms of a magnetometer possibly helping solve the issue as well? Commented Aug 16, 2017 at 1:28
• You're welcome, actually the main reason of using a Magnetometer in the system is yaw (usually z axis) axis compensation, because when you use only Accelerometers as absolute sensor, you dont have any reference in yaw axis because of your gravity and yaw on the same axis, so you can not compensate it. But of course you can use magnetometer for all 3 axis and it will reduce the effect of Accelerometers on your system. In my opinion, you should try complementary filter with 6050 first. After that if you need a Magnetometer you can easly implement it to your complementary filter algorithm. Commented Aug 16, 2017 at 5:54

Some further research is giving me more insight into how others solve the problem. Primarily using a method to calculate the centrifugal acceleration, and then compensating for it.

These solutions come from William Premerlani in the fixed-wing UAV community.

Using only Accel and Gyro; http://diydrones.com/forum/topics/centrifugal-compensation-with-only-gyros-and-accelerometers