jrowberg / i2cdevlib

I2C device library collection for AVR/Arduino or other C++-based MCUs
http://www.i2cdevlib.com
3.95k stars 7.51k forks source link

MPU6050 on RP2040 reads strange results when offsets are set #715

Open maxomous opened 2 years ago

maxomous commented 2 years ago

Hello,

I am using the mpu6050_DMP_V6.12 example to retrieve the yaw, pitch and roll angles using 'OUTPUT_READABLE_YAWPITCHROLL'.

The results are very responsive until I attempt to set the offsets or call the CalibrateAccel() / CalibrateGyro() functions provided.

After setting offsets, the readings become somewhat erratic (it almost seems that the different axes are interfering with each other) and there is a noticeable lag when settling.

I have also noticed that calling PrintActiveOffsets() prints out just the set x values for x, y & z, e.g. Acc. X = 1000, Y = 1000, Z = 1000 Gyro. X = 10, Y = 10, Z = 10

I have checked using all of the get#AccelOffset() and get#GyroOffset() functions and it seems like the correct values are being set, but PrintActiveOffsets is somehow reading the x value 3 times. I'm not sure if this in relation to the first issue but I thought it may help in diagnosis.

Thanks in advance, Max

maxomous commented 2 years ago

I should note, I am running it on a raspberry pi pico hence using the RP2040 code in the link

ZHomeSlice commented 2 years ago

The Calibration uses a PID (minus the D) loop to land the calibration. setting the offset instantly has an effect on the next reading. When the MPU6050 is level and stable the calibration samples the sensors and shifts the offsets to get Zeros on 5 of the 6 axis and adjusts Accell Z to show 1g. your issue with not calibrating is unusual and your results: Acc. X = 1000, Y = 1000, Z = 1000 Gyro. X = 10, Y = 10, Z = 10 for offsets are not normal after calibration. I have not used this on a raspberry pi pico yet, so I'm not sure of the resulting changes to make this work. I am interested in seeing what you discover and your final results. Thank you Z

alphatech56 commented 1 year ago

May be this is result of bug in int8_t I2Cdev::readWords() #719 ?