Go Down

Topic: GY-521 seems to go crazy. (Read 224 times) previous topic - next topic

elpidiovaldez

I have set up a GY-521 and am using the example MPU6050_DMP6 from Jeff Rowbergs library to test it.  At first things seem to be good, but after about 30 seconds the 6050 seems to go mad (the sensor is completely stationary during this time).  Below is an example of the output:

Code: [Select]

Initializing I2C devices...
Testing device connections...
MPU6Initializing I2C devices...
Testing device connections...
MPU6050 connection successful

Send any character to begin DMP programming and demo:
Initializing DMP...
Checking hardware revision...
Revision @ user[16][6] = 4D
Resetting memory bank selection to 0...
>*......>......
//           X Accel  Y Accel  Z Accel   X Gyro   Y Gyro   Z Gyro
//OFFSETS    -1170,   -2019,    3510,      47,      12,     -23
Enabling DMP...
Enabling interrupt detection (Arduino external interrupt 0)...
DMP ready! Waiting for first interrupt...
aworld     0.00  -19.00-5164.00
aworld    -2.00  -29.00-3798.00
aworld     0.00  -37.00-2792.00
aworld    -1.00  -43.00-2055.00
aworld     0.00  -49.00-1508.00
aworld     0.00  -52.00-1108.00
aworld    -2.00  -51.00 -820.00
aworld    -2.00  -52.00 -606.00
aworld    -4.00  -51.00 -450.00
aworld    -5.00  -53.00 -338.00
aworld    -4.00  -55.00 -253.00
aworld   -10.00  -54.00 -185.00
aworld    -9.00  -55.00 -139.00
aworld    -5.00  -56.00 -101.00
aworld    -3.00  -56.00  -84.00
aworld    -5.00  -53.00  -69.00
aworld    -3.00  -50.00  -47.00
aworld    -8.00  -51.00  -37.00
aworld   -13.00  -51.00  -26.00
aworld    -9.00  -57.00  -22.00
aworld   -11.00  -55.00  -20.00
aworld   -10.00  -51.00  -22.00
aworld    -7.00  -53.00  -20.00
aworld    -9.00  -53.00  -23.00
aworld    -3.00  -50.00  -23.00
<snip>
aworld    -7.00   12.00  -17.00
aworld    -7.00   13.00  -21.00
aworld    -4.00    9.00  -18.00
aworld     0.00   10.00  -22.00
aworld    -3.00   10.00  -19.00
aworld     1.00    8.00  -16.00
aworld -542.00-23755.00-22329.00
aworld   -15.00-1873.0016350.00
aworld -750.0016411.00 8099.00
aworld -344.00 -118.00-11722.00
aworld -281.00 -349.00-29057.00
aworld 14114.00-19967.0024524.00
aworld   364.00  -65.0020460.00
aworld    84.00 -198.00-20657.00
aworld   170.00  224.0013402.00
aworld   -76.00 -286.00 -294.00
aworld   413.00   67.0027100.00
aworld    12.00   -8.00-2141.00
aworld   271.00  -92.0014225.00
aworld -3034.00-9647.0011275.00
aworld   416.00  -66.0020322.00
aworld   455.00  426.00-9674.00
aworld     9.00  -57.00-3382.00
aworld 1464.0017179.00  885.00
aworld   356.00 -156.00-29542.00
aworld -100.00  -98.0030158.00
aworld   -39.00  -58.00-2893.00
aworld -20808.00-24551.0016463.00
aworld -111.00 -225.0014824.00
aworld -218.00  176.0019046.00
aworld    63.00  -25.00-11728.00
aworld -3462.0020140.0016404.00
aworld    79.00  203.00-6997.00
aworld    79.00  -24.00-7731.00
aworld    60.00 -317.00-27547.00
aworld   439.00   79.0032229.00
aworld -100.00   -7.00-27580.00
aworld -242.00  320.00-26840.00
aworld   109.00  -63.00-10528.00
aworld   218.00 -163.0021450.00
aworld -19464.00-27907.0011731.00
aworld -22151.0031614.00-16217.00
aworld -153.00  -55.00-17379.00
aworld   378.00  198.0023346.00
aworld    92.00 -112.0031175.00
aworld -6416.00-21037.00-17698.00
aworld -121.00  -42.00-17632.00
aworld   401.00 -329.0011414.00
aworld   -36.00  465.00-13342.00
aworld   100.00  243.0023850.00
aworld -20545.00-4314.00-17280.00
aworld   269.00 -342.00 -683.00
aworld 11487.0015488.0028658.00
aworld -18585.00-22834.0012397.00
aworld -159.00  -61.00-32683.00
aworld   160.00 -116.00-22892.00
aworld   185.00  139.0019634.00
aworld   119.00  -63.00-10808.00
aworld 8789.00-31484.00-29049.00
aworld     3.00 -113.0013675.00
aworld -401.00 -254.00-6120.00
aworld    65.00 -444.00-3512.00
aworld 21523.00-18673.00-7640.00



One theory that occurs to me is that I have a duff board as decribed in this article : Bad-MPU6050

Is there any simple way of confirming that the board is bad without removing the capacitor (I am loath to try and test the capacitor on the board in case the meter voltage damages the 6050) ?

Another theory is that the problem is due to having the MPU6050 mounted vertically instead of horizontally (X points down and Y to the right).  I did not think this would be a problem, but no I have doubts.

I also tried the visualisation kit: Visualisation.  This shows the sensor responding to movements, but the motion is not quite correct.  I tried initialising in the horizontal position too, but it did not improve anything.

Any guidance would be welcome.


zwieblum

Does the non-DMP version of the code work?

elpidiovaldez

The non-DMP code does seem to be more reliable.  I tried MPU6050_raw from Jeff Rowberg's examples.  It did not crash or do anything strange, but since it only prints raw accelerometer and gyro values instead of ypr I am not sure that the values are right.

I tried DMP using the newer MPU6050_6Axis_MotionApps20.  That seems to be a lot better.  It does not go completely mad after about 20 seconds, but it does hang after a while.

On a hunch I lowered the sample rate by calling mpu.setRate(15) after mpu.initialize().  It is difficult to be sure but I think it runs longer without hanging at this rate.  I also noticed the occasional bad value as shown below:

Code: [Select]
05:35:20.607 -> ypr:    -0.10   -0.03   -0.01
05:35:20.640 -> ypr:    -0.10   -0.03   -0.01
05:35:20.673 -> ypr:    -0.10   -0.03   -0.01
05:35:20.706 -> ypr:    -0.10   -0.03   -0.01
05:35:20.740 -> ypr:   180.00    0.00    0.00
05:35:20.740 -> ypr:    -0.10   -0.03   -0.01
05:35:20.773 -> ypr:    -0.10   -0.03   -0.01
05:35:20.806 -> ypr:    -0.10   -0.03   -0.01
<hangs>


I will try to find some code that fuses the raw acc. and gyro data in a filter to see if that is usable.  It sucks that the does not work though.

 

elpidiovaldez

I have now done a LOT more testing and a lot more Googling.  It appears that the issue of the communication with the MPU6050 sensor and the Arduino is well known.  It also appears to be related to reading the FIFO in the sensor, but nobody ever seems to have found exacly what or how to fix it.  The culprit seems to be the I2C bus failing. 

However, for me, the issue is NOT solely with the DMP.  I used a non-DMP based implementation by Jarzebski.  This runs a lot longer but also hangs eventually.  The I2C bus is certainly to blame, but is this a problem with the MPU6050 or is it a problem with my specific hardware.  So many people seem to have encountered this problem that it is difficult to decide.

Are there any people out there who use Jeff Rowberg's library with DMP and DO NOT experience unreliability ?


elpidiovaldez

Solved !  It must be the connections. I took the same Arduino and the same MPU6050 and made the 5 connections between them on a breadboard with single core wire. Powered by USB.  It works perfectly using the standard Wire library, Jeff Rowbergs's MPU6050 library and his MPU6050_DMP6 example.  I also changed the include to to use the more recent firmware, "MPU6050_6Axis_MotionApps_V6_12.h".  It has been running for an hour now without a glitch.

So:
  • Not Jeff Rowberg's library
  • Not a bug in the I2C library
  • Not logic level conversion issues
  • Not a dodgy GY-521 board or the cheap Chinese Arduino


Just plain old cruddy soldering or crimp connectors !  Sadly I still have to find the root cause.

elpidiovaldez

I feel obliged to add this for the benefit of all the other, many people who are struggling with unreliable mpu6050 sensors.

tl;dr  Everything works on a small compact breadboard, but when deployed there are frequent hangs and bad data.  The issue is NOT connectors as I previously thought.  Rather the issue is the length of the SDA and SCL wires.  More than 8-10cm gives me problems. Solution: Add 100 Ohm series resistors on SDA and SCL near the Arduino. The resistors damp 'ringing' on longer lines.

I found this solution due to SgtWookie in this thread.  The idea of adding series resistance in I2C lines is a known thing in electronic engineering forums, although the actual value is normally found by trial and error (usually 30 - 200 Ohms).  I have not seen it discussed on hobbyist forums. 

Originally I thought that the unreliability was due to a bug in Jeff Rowberg's MPU6050 library or in Wire.h.  These issues are discussed thoroughly in this thread.  It appears that way, because the errors can be traced to failed calls to  getFIFOCount, but that is a symptom not a cause.  The hangs are due to I2Cdev::readBytes which does not implement a timeout.  Even that is a just a symptom.  The underlying problem is that the I2C bus has electrical noise causing readBytes to enter an infinite loop. 

This problem is insidious because many compact implementations will work fine (for example on a breadboard).  It might seem very mysterious to a non-electronic engineer that unreliability creeps in with identical connections, albeit slightly longer wires.  I solved all my problems with a pair of 100 Ohm resistors.  Others may need different values, and if that does not work there are other electrical issues such as shielding from noise, coupling between SDA and SCL and more.

jremington

#6
Dec 15, 2019, 05:56 am Last Edit: Dec 15, 2019, 06:03 am by jremington
Thanks for tracking that down and posting a solution! Note that simply using lower valued pullup resistors (e.g. 2.7K) can often fix such problems.

As we often try to warn people on this forum, the I2C bus was designed for chip to chip communications on a single PCB, and not for modules connected by long, loose wires.

But those warnings usually fall on deaf ears. I've bookmarked your thread to pass on.

Go Up