MPU6050 yaw pitch roll problem


I use a mpu6050 (with arduino uno) in order to measure the yaw pitch roll of a vehicle (car).

The ypr seems to be correct when not accelerating/breaking and not turning left/right; I made some test at the ofice on my desk.

While testing the circuit in the vehicle, I notice that:

  1. Accelerating/braking the vehicle modifies the pich measure from +10°to -10°, which is not the real angle pitch degree variation of the vehicle;

  2. Turning left/right modifies the roll measure (and also the yaw which normal in that case) really too much regarding the real roll angle.

see code in attachment.

What is wrong? Any idea?



inclinometer.ino (13.4 KB)

What is wrong? Any idea?

Nothing is wrong. This is the expected behavior. The accelerations due to gravity and those due to other forces are equivalent.

You can't directly measure tilt (for example) while you are accelerating, but with some considerable mathematical effort, it is possible to estimate tilt in such a situation.

jremington: This is the expected behavior. The accelerations due to gravity and those due to other forces are equivalent.

this is absolutely correct - and this scientific finding actually was Einstein's first step to his Theory of Special Relativity 8-)


thanks for your feedback.

What do you mean by considerable math effort? Do you know how to proceed (or links, posts, articles)?



I don't know about the MPU6050 but you're at least supposed to have an absolute external reference, e.g., 3D Compass values. Anyway, the MPU6050 (and even the MPU9150 providing a comapss) are outdated.

I'm succesfully using another IMU providing an onboard cpu for Kalman filtering and sensor fusion to do the required maths for you: manual:

you'll just have to poll the I2C register to read heading, pitch, and roll (or read by Serial).

What do you mean by considerable math effort? Do you know how to proceed (or links, posts, articles)?

You need a good filter (either the complementary filter or a Kalman filter) to estimate absolute orientation. The theory is taught in advanced engineering and aerospace navigation college courses. My favorite textbook is Dan Simon's Optimal State Estimation.

A filter that works well with your IMU and the Arduino is RTIMULib. As pointed out above, you will need a magnetometer too.

Or you can buy the BNO055 sensor, which is self contained, with a built in ARM processor doing essentially the same thing as RTIMULib.

Hi ArthurD & jremington,

thanks for your feedback.

I'll go for a bno055...




I get a bno055 from arduino

I still have the same proble; Roll measure are still influenced by "turning acceleration".

I'm using the NAxisMotion library (from arduino)

here is part of the code


NAxisMotion mySensor;   

I2C.begin();                    //Initialize I2C communication to the let the library communicate with the sensor.
 //Sensor Initialization
 mySensor.initSensor();          //The I2C Address can be changed here inside this function in the library
 mySensor.setOperationMode(OPERATION_MODE_NDOF);   //Can be configured to other operation modes as desired
 mySensor.setUpdateMode(MANUAL); //The default is AUTO. Changing to MANUAL requires calling the relevant update functions prior to calling the read functions



What did I wrong?

best regards


Provide some data in support of your conclusion.

Here is some data( data on xls sheet and graph on next sheet)

I logged the yaw, roll of a (farm) tractor ridding at (around 8km/h) on field.
The captor is well secured at the cab floor.
Data are logged each 100ms.

The followed path is ridding 200m then turn left (about 180°) in order to go back again 200m then turn left about 180 ° and so on.

So each time I turn 180° , we can see a very great yaw variation (normal) but also a greater roll variation (around 15°) compared to the “mean” roll which is bouncing between -4/+4° (due to terrain roughness). (610 KB)

YawVsRoll.txt (289 KB)

I'm not familiar with the library you are using.

I looked at the yaw versus roll plot, and the data do suggest the built-in filter may not be working as well as it could.

If so, the problem may be due to incorrect choice of the relative weights of the gyro data versus the accelerometer data. During a sharp turn, the gyro data should be weighted more heavily than the accelerometer.

It is likely that the filter built into the BNO055 is a Kalman filter, but of course the system model would be wrong for your particular test case. To implement an optimal Kalman filter, the entire system (including the target vehicle and the vehicle's expected motion in 3D) must be modeled correctly.

If you want to optimize a Kalman filter for your application, you need an open source version such as RTIMUlib.

Hello jremington,

So I guess that you’re using another bno055 library, which one? Would this library give better result for my application?

For which application do you use an imu?

You said “…the entire model must be modeled correctly…”.
In my particular application, a roll is always accompanied with a “lateral” acceleration (see picture).

How should I proceed to solve my problem?


I don’t use a library. I access the BNO055 directly with I2C routines and just read the Euler angle registers.

The BNO055 will not function correctly if you have not performed the built in calibration routine (with the BNO055 in its final resting place), and you also have to monitor the calibration status to see that it remains calibrated. If you have not done so, you cannot trust the data it provides.

If you want to take a look at the routines I use, I’ve appended BNO055 autopilot code that I used for an autonomous electric boat. This code is intended for Atmel Studio 4 and not Arduino, but it would not be difficult to adapt it to the Arduino environment.

The BNO055 works as well as any other consumer grade IMU I’ve tried, including those from CHRobotics. If it doesn’t work for your application (when used properly) you may need to write a more sophisticated Kalman filter. The reference is in post #5. (161 KB)


i will try based on your project, it will take some days (elapsed) in order to implement and test it. Anyway I will come back on the forum in order to give you some feedback.




by the way how do you proceed to calibrate the bno055?

by the way how do you proceed to calibrate the bno055?

I followed the instructions in the BNO055 data sheet.


I did some calibrations and the measure are better when cailbration’s status are " 3 3 3 3 " (System, Gyro, Accle, Magn).
Unfortunately these calibration’s status don’t remain at that good level (3333) for a long time. After a few minutes, it drops to System:0 G:1, A:2: M:1 (not always these values but each time very low figures )
I have to “shake” it to get again a good/better status, but again lost after a 2-3 minutes.
With this bad status, roll measure (the one which is important for my project) is untrustable!

I’m quite disappointed and I don’t know what/how to do to have a good roll measure.

Any idea is welcome.



Yes, the calibration procedure is a mystery, although my unit does not seem to be as badly behaved as yours. Are you exposing it to different magnetic fields or nearby iron objects AFTER calibration?

If the BNO055 doesn't work in your application, you might try one of the modules from CHRobotics. The owner, Caleb, is responsive to questions and might work with you.

No, the sensor is kept at the same place (tractor cab).

My application needs accuracy and precision (at least 0.5° of precision) for the roll measure in the range -5° to +5° at 10Hz. Is the BNO055 suitable for this purpose?

The consumer grade IMU sensors that I know of are accurate to about 1 degree at best, and then only after very careful calibration of both the accelerometer and magnetometer and frequent recalibration of the gyro offsets (which depend strongly on the temperature).

If you need reliable measurements more accurate than that, your best bet may be a commercial grade IMU. But they are very expensive.

I suggest to communicate with the very knowledgeable owner of CHRobotics and discuss your particular application.