MPU-6050 - angle drift

Question

Setup

• Windows 7 Entreprise
• MPU-6050 : GY-521 breakout
• Arduino Nano (chinese) with CH340 FTDI driver
• Arduino IDE 1.6.12
• Library for the gyro

---

Problem

When I run my code, the MPU will detect the angles at a good enough accuracy, but when I leave it on the table, the MPU starts drifting. Its not anything major, yet, but on something like a rocket guidance system, these values can srew up many things.

---

Actual questions

• Is this a common problem?
• Why is this happening?
• What is the best way to solve it?

---

Note

I'll include the code if you guys really need it, but I doubt its the problem because multiple codes have had the same problem.

Please do not recommend any other gyros.

Answer 1

Is this a common problem?

Yes it is. The drift is a common problem.

Why is this happening?

The drift results, in general, from the fact that to calculate the angles it is made an integration. The errors and noises present in the inicial variable before integration (in this case angular velocity) will be "summed" over time. For simplicity, let's say your gyro is perfect with noise free but it has a small offset , and lets considere only rotation in one axis, meaning:

Ang_Velocity(x) = Real_Ang_Velocity(x) + offset_x

if this was the case, the sensor standing still should output only:

Ang_Velocity(x) = 0 + offset_x

now using the integral over time results in an output of:

Angle(x) = int[Ang_velocity(x)] = offset_x * t

For example note that using a simple 0.01 offset over axis x, causes the sensor to output 1rad angle after 100 seconds and in fact the sensor didn't move at all.

Taking this as example the sources of errors I'm aware of are:

• offset: already talked
• scale factor: is the relation between input and output
• scale factor linearity: sometimes the scale factor at slow speeds are not the same as speed increases.
• temperature: (not 100% sure!) this changes the sensitivities of axis. Majority of digital sensores already come with an integrated temperature sensor. If not auto compensated, there will be probably information on the datasheet to guide you how to compensate for this. If your application will not take high temperature variations, it is common sense to let the sensor achieve thermal internal stability and then do a simple calibration.
• Random Walk: This is probably the hardest to process. In general is assumed that the noise is a normal distribution with mean of zero and a certain variance (white noise). If that was true, the integral over time, as time increases would go to zero (because the mean is zero). However, the noise is usually not evenly distributed in the spectrum, causing the integral to not tend to zero (Brownian noise).

way to solve it?

The first two are simple using calibration. You must do a series of tests at diferent rotation speeds to determining the non-linearities, offsets (at zero speed) and scales factors for each axis. Then your sensor equation of the module should take acount for this facts. Usually the sensor datasheets describes the equation to be used. Take a look at IMU_Zero in the repository you gave.

As for the other two, it depends on the application. Typically the temperature will be considered stable after a few working minutes. If temperature is important datasheet will probably be your best friend.

As for random walk. The most common use to take into account corrections of this is to use an accelerometer (and in some cases magnetometer) and apply a sensor fusion algorithm generally denoted as AHRS. Some examples go as:

• Sebastian Magdwick - Open source IMU and AHRS algorithms
• Extended Kalman Filter
• Direction Cosine Matrix filters
• Complementary filters

If you really want to model the noise of the sensor to improve the result, you probably should search for Allan variance but you will need a lot of basis in stochastic processes and statistical theory

Some devices like yours already have an Motion processor built-in, that makes a similar application of (probably) one of these filters. See examples MPU6050_DMP6.ino

If you just want an implementation, just google for AHRS arduino. Github as a lot of examples used by other sensors that are easy to adapt. For instance and this

More information on IMU errors

Answer 2

The change in yaw (rotation of the x-y plane around the z-axis) is not drift or an error that needs to be nullified. I set my MPU-6050 on the kitchen table and collected the axis outputs over a six and one half hour period. The pitch and roll values were rock solid over the entire period. The Yaw values, however, constantly change at an extremely linear rate of 0.25 degrees per minute. That's 15 degrees per hour. The planet you are on is rotating at that rate. This is not a coincidence.