MPU6050 DMP sketch hangs sometimes?

[titous]

Hey everyone!

 

I've got my MPU6050 hooked-up to my Arduino UNO and have the DMP sketch running just find and dandy, sometimes...

 

At times, the code will hang at "Initializing I2C devices..."; at other times it runs as expected.  I'm having a hard time recreating the error; I don't think it's a hardware thing (loose wires perhaps since I'm still breadboarding) because I've got it sitting on my desk and without touching it the error comes up & then goes away with a simple re-compile of the sketch.

 

I've put some print statements in the initialize() function to see which sub-function might be causing the issue and I've narrowed it down to setClockSource()

 

Has anyone else experienced this or is this just on my end?

 

Thanks!

[dvonhausen]

I have read that the wire.h doesn't follow the correct i2c protocol exactly in that it doesn't handle double starts. The post I saw:

 

I’ve noticed that with the code provided from the guys at i2cdev, the DMP quaternion works great until there is almost any hang in the main loop between update reads to the FIFO buffer. I’m not sure what exactly is going on there, but it’s making me want to just implement a filter myself.

 

 

This is probably because the Wire.h lib is not up to it (drops in comms and if you need double start messages). I suggest you replace with this lib instead for all i2c comms: http://dsscircuits.com/articles/arduino-i2c-master-library.html

 

Dave

[titous]

hey dvon!

 

I'll look into what you've mentioned in a bit; in the mean time, the link you provided is 404 - is this the correct one?

 

I've done a bit more testing and it does look like the sketch is hanging in the setClockSource() function; I'll investigate it when I've got some free time.

[luisrodenas]

 

 

sketch is hanging in the setClockSource() function

Wierd. This has never happened to me. Let us know what you find.

 

 

 

 

DMP quaternion works great until there is almost any hang in the main loop between update reads to the FIFO buffer

This is another topic I think. I believe it does not have anything to do with the i2c library, but how the sensor and fifo buffer works.

Once you set the DMP to use fifo buffer, and its frecuency, you have to read the fifo at least at that frecuency, or it will overflow and then the errors appear. In my experience, if it overflows just once sometimes, its no big trouble, but if it overflows several times DMP's measures go crazy, reset, etc.

For example I am running DMP at 200Hz, so there is a measure every 5ms. I check and read fifo every 3ms and I have no problem at all.

So, configure your DMP's frecuency to one you can check fifo faster.

[titous]

Sure, I'll keep ya'll posted.  Quick question, you mention you're running DMP at 200Hz but it seems like I read a warning about that bandwidth being noisy, can you comment on that?

 

For example I am running DMP at 200Hz, so there is a measure every 5ms.

 

 

[luisrodenas]

At 200Hz the measure is a bit more noisy, but little difference.

For example in my application, a quadrotor with motors vibrating etc, when running DMP at 200Hz the noise is aproximately +- 0.1 or +-0.15 degrees.

Instead, when running at 100Hz, noise goes down to +- 0.05 degrees, sometimes a bit more.

 

For my aplication this noise is not relevant.

[titous]

A little update on the hanging issue: I've tracked it down to the first call of a I2C function, in most cases this occurs during the initialize() function which calls some sort of writeBits()

 

To get around this, I've put a bit of the standard I2C bus scanner into the code, right after the Wire.begin():

    // test the connection to the I2C bus, sometimes it doesn't connect
    // keep trying to connect to I2C bus if we get an error
    boolean error = true;
    while (error) {
        Wire.beginTransmission(mpu.getAddr());
        error = Wire.endTransmission(); // if error = 0, we are properly connected
        if (error) { // if we aren't properly connected, try connecting again and loop
          Serial.println("  ");
          Serial.println("Not properly connected to I2C, trying again");
          Serial.println(" ");
          Wire.begin();
          TWBR = 24; // 400kHz I2C clock
        }
    }
    Serial.println("Properly connected to I2C");

I also ended up writing my own library function getAddr() - if you want to try this code yourself, just replace that function with 104 (if you've got the AD0 pin low or 105 if it's high).

 

I'm hoping this will fix things; I haven't been able to confirm since I can't reproduce the hang on my own (it seems intermittent).

[roadrunner]

Have you encountered the issue again since implementing the fix??? I have the same issue and the fix above did NOT solve the problem for me. It still hangs on: 

setClockSource(MPU6050_CLOCK_PLL_XGYRO);

I've been using the MPU-6050 (on the GY-521 board) over the past year with an arduino (several different versions) and now a teensy 3.1 and I still get the same error. I've used used several MPU-6050 boards and each produces the same error, but randomly/intermittently like you are/were experiencing.

 

When I do encounter the problem, cycling the power on the MPU-6050 doesn't seem to fix the issue..it still hangs on "setClockSource." Reseting the main MCU doesn't seem to fix it either and I get the same error. I have to fully cycle the power on both the main MCU and the MPU-6050 to get it working again.

 

Have you had any other success or fails with this issue?

[titous]

 

Have you encountered the issue again since implementing the fix??? I have the same issue and the fix above did NOT solve the problem for me. It still hangs on: 

setClockSource(MPU6050_CLOCK_PLL_XGYRO);

I've been using the MPU-6050 (on the GY-521 board) over the past year with an arduino (several different versions) and now a teensy 3.1 and I still get the same error. I've used used several MPU-6050 boards and each produces the same error, but randomly/intermittently like you are/were experiencing.

 

When I do encounter the problem, cycling the power on the MPU-6050 doesn't seem to fix the issue..it still hangs on "setClockSource." Reseting the main MCU doesn't seem to fix it either and I get the same error. I have to fully cycle the power on both the main MCU and the MPU-6050 to get it working again.

 

Have you had any other success or fails with this issue?

 

 

so far my implementation seems to work; it's not so elegant but it does the trick

[luisrodenas]

I always used an Arduino Due and have never experienced this. Maybe it is a I2C bus communication problem, by that I mean: pull up resistor values, voltage translators, etc.

 

Anyway, if the problem is only that instruction :

setClockSource(MPU6050_CLOCK_PLL_XGYRO);

Skip it. It is not so important and should work fine without it.

[unisev]

I'm experiencing the initialize freeze, around 25% of time.

I've treated it by adding a Watchdog Timer that reboot the 328P, if 2 seconds reached, but I'll try your fix.

[unisev]

A little update on the hanging issue: I've tracked it down to the first call of a I2C function, in most cases this occurs during the initialize() function which calls some sort of writeBits()

 

To get around this, I've put a bit of the standard I2C bus scanner into the code, right after the Wire.begin():

    // test the connection to the I2C bus, sometimes it doesn't connect
    // keep trying to connect to I2C bus if we get an error
    boolean error = true;
    while (error) {
        Wire.beginTransmission(mpu.getAddr());
        error = Wire.endTransmission(); // if error = 0, we are properly connected
        if (error) { // if we aren't properly connected, try connecting again and loop
          Serial.println("  ");
          Serial.println("Not properly connected to I2C, trying again");
          Serial.println(" ");
          Wire.begin();
          TWBR = 24; // 400kHz I2C clock
        }
    }
    Serial.println("Properly connected to I2C");

I also ended up writing my own library function getAddr() - if you want to try this code yourself, just replace that function with 104 (if you've got the AD0 pin low or 105 if it's high).

 

I'm hoping this will fix things; I haven't been able to confirm since I can't reproduce the hang on my own (it seems intermittent).

 

This is not working for me, the sketch still freeze sometimes, but now in this new code section (exactly at the Wire.endTransmission).

[unisev]

I always used an Arduino Due and have never experienced this. Maybe it is a I2C bus communication problem, by that I mean: pull up resistor values, voltage translators, etc.

 

Anyway, if the problem is only that instruction :

setClockSource(MPU6050_CLOCK_PLL_XGYRO);

Skip it. It is not so important and should work fine without it.

 

This solution is not working for me... but I found something :

I think the freeze occur when you reboot the Arduino (for me it is a 328P) exactly at a precise moment, juste during another reboot that is not "complete".

 

Maybe a I2C issue (for example a connection appear allready opened...)

 

[unisev]

So I'm keeping my WatchDogTimer solution, this is satisfying me (328P reboot if no activity during 2s), and this is just adding 3 lines in the code :

#include <avr/wdt.h> // NEWLINE : include WatchDogTimer arduino lib

void setup() {
wdt_enable(WDTO_2S); // NEWLINE : Activate the WTD with a 2S counter (before MPU init)

mpu.initialize();

}

void loop() {
wdt_reset(); // NEWLINE : Prevent WatchDogTimer to reboot
}

There is another solution than "wdt_reset();" in the loop, you can deactivate WatchDogTimer at the end of setup section with "wdt_disable();".