Hi I'm new to Arduino and I'm trying to use a 6DOF IMU (the MPU-6050) along with the i2cdevlib.
I've been able to set the libraries and to execute a sketch in order to calculate the offset of the IMU
starting from the raw data.
Now I'm trying to execute the example code that i found on the github of the i2cdevlib https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_DMP6/MPU6050_DMP6.ino setting the output in the YPR mode #define OUTPUT_READABLE_YAWPITCHROLL with and without my offset parameters.
In both sketches I found the same issue.
The data on the serial shift from the initial position for 5-8 second showing an increment of several degrees (depends on the cases but usually there are 12-25 degrees) of the YPR angles without moving the IMU.
The same thing happen with the Euler angles #define OUTPUT_READABLE_EULER.
I've tried also to execute the quaternion output mode #define OUTPUT_READABLE_QUATERNION which i don't know how to read (I'm just started learning about this) but the value I read on the serial seems to stay "stable".
I might solve this with a delay from the turn on which allow me to see of how much degrees the IMU "virtually moved" and then subtract that value to future reading (such as another offset) but i find this not usefull since I need the IMU to have the right angles on the turn on.
The problem I found is shown in the image below, which is a plot of YPR angles.
As shown I find an "Auto Calibration" time of 10:20 second every time I use the sketch (the example in i2cdev github folder).
Basically I can use i2c library without much problem.
I had settled the offset right and checked the i2c comunication.
I've tried without using manipulated data but just the RAW ones.
Changed the VCC for my MPU from 3.3V to 5V (since the gy-251 has pullup resistor 2k2).
However the problem is still there, but I don't have any other ideas.
I could easily solve this with:
let go the sketch for 25 seconds
read the actual YPR value and save them as a new offset
subtract the new offset from each new reading I do
but this is not the best solution since I don't have 25 second because I'm working on a device that need an "instantaneus" calibration (or almost).
I thought it could be something wrong with my MPU (maybe I might have damaged it somehow) but then a guy answered me on a forum telling me that he owns 2 of those MPU and both of them present this "delay" and that it is normal.
However the datasheet of the MPU-6050 says that this delay should be of 30ms, which is obviously way better than the one I have.
I'm out of ideas and I hope to find in this forum large experience the solution to my problem
Nobody knows exactly how that DMP algorithm works. If you can disassemble it, tell us about it.
Without some kind of magnetometer, there is no reference orientation for the "yaw". The pitch and roll can be "calibrated" by assuming that the device is not moving and that the direction of the apparent acceleration is "down". Or "up". The DMP code is going to start with some arbitrary orientation, and start to integrate the measured gyro rates. Even if the device is stationary, there is going to be a non-zero gyro rate, which is going to cause the apparent orientation of the device to change. After a "short" period of time, the algorithm will "realise" that the direction of gravity is not moving, so the device is not really rotating, so the apparent rotation is due to an offset error in the measured gyro reading, and it will adjust ( i.e. re-calibrate ) the gyro offset accordingly.
If the device is sitting flat on the desk, this process will take longer for the yaw axis. The reason for this is simple. If the device really was rolling or pitching from side to side, the gravity direction would change in a very obvious way, and if you assume it is not really moving, the gyro offset correction required to eliminate the apparent movement, is very quickly determined. But if the device was really actually rotating, as if on a record turntable, then the apparent gravity direction would not be changing at all, even though the device was rotating. So, a gyro offset error in the yaw direction cannot be readily compared against a reference orientation derived from the accelerometer reading. In fact, it is not obvious how it adjusts the gyro offset rate, at all. But it does explain, at least partly, why it takes longer.
Try this. Try turning it on, and not moving it, but putting it at an angle, before you turn it on, so that there is a substantial non-zero component of the gravity vector in all three axial directions. If the device is tilted, then the apparent yaw caused by the change in the gyro offset will become more quickly apparent, because the gravity direction would be changing, if that were the case.
What you wrote about the magnetometer is true but it's not related with my problem.
What you describe it's the "drift" of the YPR, which might be solved with filtering the
datas (with a complementary, kalman...).
I am doing a kalman's filter right now, but this will only reduce the drift after the "Auto
Calibration" period.
I have already tried the test you suggest, but it doesn't reduce the "Auto Calibration" time
needed by the MPU.
What I'm wondering (and can't understand) is why some MPU present this problem and some
other doesn't.
It looks like there is some wrong settings in those MPU's.
What you describe it's the "drift" of the YPR, which might be solved with filtering the
datas (with a complementary, kalman...).
No, it won't.
Filtering will solve the noise problem, it won't solve the problem of the gyro giving you a non-zero value when it is actually not rotating, the only way to solve that problem is to have an alternative orientation reference of some kind.
As explained above, both the accelerometer and gyroscope data are prone to systematic errors. The accelerometer provides accurate data over the long term, but is noisy in the short term. The gyroscope provides accurate data about changing orientation in the short term, but the necessary integration causes the results to drift over longer time scales.
The solution to these problems is to fuse the accelerometer and gyroscope data together in such a way that the errors cancel out. The standard method of combining these two inputs is with a Kalman Filter, which is quite a complex methodology. Fortunately, there is a simpler approximation for combining these two data types, called a Complementary Filter.
This is not my problem.
As told before
The problem I found is shown in the image below, which is a plot of YPR angles.
As shown I find an "Auto Calibration" time of 10:20 second every time I use the sketch (the example in i2cdev github folder).
this is the problem.
The MPU isn't ready to work properly before 10:20 second.
What I would like to do is to cut off this "Auto Calibration" time somehow, since some users doesn't have such a long period for
the "Auto Calibration". Their time is maximum 1 second in the worst case.
And they don't use magnetometer or external references.
Just the MPU6050 and Arduino.
