MPU-6050 and i2cdevlib "slide" for a while on turn on

[theBliz]

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 i2cdevlibhttps://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/Examples/MPU6050_DMP6/MPU6050_DMP6.ino  setting the output in the YPR mode

Code:

#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

Code:

#define OUTPUT_READABLE_EULER

I've tried also to execute the quaternion output mode

Code:

#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.

Thanks for reading, hope someone could help me 

 

[findftp]

Both my mpu6050's show the same result.

10 seconds of stabilisation and then pretty much stable.

 

Just put in a delay in your code

[theBliz]

findft thanks for the fast reply!

as I wrote 

 

 

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.

that's why I'm working on a project for university which must be "ready on the fly". So, as I turn on the platform, I don't have 10 second to let the MPU stabilize itself or the whole system will crash.

 

When I bought it I read on the datasheet that it has 30 ms for "time start" which is much more acceptable than the 10-15 s I need to stabilize mine.

Therefore I'm trying to understand what causes this problem.

 

Moreover (as you confirm) I'm not the only one having this problem and mostly it is solved with a delay time which i find not to be a solution but just a "palliative". 

 

It is possible that this problem haven't been solved considering that this is one of the most used MPU?

[Jeff Rowberg]

Hello,

 

This occurs due to gyro drift, particularly in the Z gyro axis since gravity can be used to compensate the others. The stabilization time after power-on is no doubt when using the raw measurements, but does not apply when using the DMP algorithm, which is far more complex. I have read that the DMP's internal auto-calibration routine requires 8 seconds of no motion in order to compensate for gyro drift.

 

You can affect this by making use of the internal offset registers though, and this will improve both raw measurements and the DMP. I recommend checking out this post:

 

http://www.i2cdevlib.com/forums/topic/91-how-to-decide-gyro-and-accelerometer-offsett/?hl=%2Bgyro+%2Bcalibration#entry257

[theBliz]

Hi Jeff,

thanks for the reply!

I don't know if you checked your github mail, but yesterday I wrote you some details attaching a jpg showing the problem I find.

My problem isn't about the calibration, which I have done few days ago following the post you suggest without any improvment.

After that I tried to use a sketch to automatically calculate the offset, but neither this worked well. 

I still have this 20 second delay time that the MPU seems to use to "stabilize" the data.

 

What concern me the the most is that some MPU users have this problems while others doesn't seems to be afflicted by that.

That's what made me think that I have setted something wrong in your library.

However I'm using the example sketch you provided on github without any modification.

 

I am out of ideas right now.

Thanks for any further help!

 

Ps: that's the jpg I attached on your mail. The problem is the one pointed out as "Auto Calibration". 

I'm not caring about the "drift" on Yaw, I will solve it with a Kalman filter later.

 

[luisrodenas]

Hi,

None of my MPUs show that behaviour, and I have like 10 of them working. It is true that yaw drifts for a while, but pitch and roll are almost perfect from turn on.

 

What arduino are you using?

What MPU board are you using? Squematic? Pins connected?

Have you changed anything in the library? Maybe fifo's frequency?

Do you have another MPU to try? (it is quite common to see broken MPUs)

[theBliz]

Hi luisrodenas,

 

I am using an Arduino Uno 

The MPU is the 6050 of the Invensense

The board where the MPU is mounted is a GY 512 (the one with the 2k2 pullup resistor)

I'm running it under Ubuntu.

The connection is

 

GY               Arduino

--------------------------

VCC             5V

GND            GND

SCL             A5

SDA             A4

XDA             n.c.

XCL             n.c.

AD0             n.c.

INT              D2 (interrupt 0)

(with n.c. i mean "not connected")

 

I didn't modify the library at all.

I changed the baudrate because at 38400 the serial break sometimes. So I put it at 115200.

I changed the offsets value, but even without this change the result is the same.

 

I tried both the library (the raw one and the DSP one) but they present the same problem.

 

I have just one GY 512 so I can't try to use another one.

However in those day I have found lot of MPU users with the same issue.

But they just see as an "Auto Calibration" routine and they just wait to have the value stabilized and then 

they work with it. 

 

My guess is that some MPU 6050 has some kind of setting that leed to this problem, but I can't figure it out yet.

 

If it could be helpfull I can post the sketch I use, but it is exactly the same in the i2cdevlib/Arduino/MPU6050/Example folder on github.

 

I have send a mail to the shop who sold me the GY 512 asking if I could have broken the board, but they told me that untill the led is working and the data are plottet there is no way that the MPU is damaged.

 

I am reading the register datasheet looking for some ideas, but I couldn't come up with nothing usefull.

 

Since I need to use it on an unstable system, I need the MPU to be ready at least in 1s. The time I'm having right now are not usefull.

 

Thanks for your attention,

this thing is driving me crazy

[Kuba]

Hi!

Did you manage to solve the problem?

I have exaclty the same problem with one of my MPU6050 (breakboard GY-87). It slides for about 6 seconds and after that the readings are constant.

 

On the other hand my second MPU6050 on GY-521 is working fine from the very begining right after start up.

 

I am using DMP.

[albert]

Hi, I would like to ask if my euler angle obtained from the mpu6050 dmp6 code, is different from the calculation from the quaternion vlaues i obtained from the code.

What can i do to solve the problem? the formula used is in this link
https://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles
Thanks

[elRadish]

Pretty late response :-)

I see the same behaviour when doing the zero-offset-calibration in a certain position, but then powering up the MPU in a very different position.