MPU6050_DMP6 Example Improvements about i2cdevlib

[jrowberg]

Funny you should bring up the expected FIFO size; in the code I have in the current working tree, that line is actually changed to this:

accelgyro.getFIFOBytes(fifoBuffer, min(fifoCount, 128));

...for that very reason.

You could read the FIFO directly in the interrupt handler, but I've always read that the code inside interrupt handlers should be absolutely as tight as possible, since it blocks other stuff from happening. A delay of 1000 would indeed cause the current implementation to overflow, but hopefully that sort of thing would be unlikely in anyone's project.

The best solution I can think of is that the FIFO count is read inside the interrupt (which is a fast 2-byte I2C read), and the FIFO itself is read in packet-sized chunks (42 bytes) whenever there is at least 42 bytes available. That way, the interrupt handler is still doing very little, but it updates the known FIFO count on every interrupt pulse. The actual FIFO reading would be done whenever the FIFO count is big enough instead of itself waiting for an interrupt to trigger, while the FIFO count would be updated in real-time.

In this case, the FIFO buffer could be just 42 bytes, since we always only ever read that much at once, and if there are 2 or 3 or 10 packets' worth of data in the FIFO, then we'll just keep reading in the loop() method until the available FIFO count falls back below 42 (and mostly likely down to 0 if our code is efficient). Sound good?

[wolfmanjm]

sounds OK to me, although in my case I think I'll actually read the 42 bytes in the interrupt so I always have the latest data available. Of course it needs to be locked so it can't change while I am using it.

So as I understand it the MPU puts 42 bytes at a time into the fifo, does it raise the interrupt when 42 bytes are in there, or everytime it writes to the fifo?
If there were two 42 byte packets in there (84) bytes, I presume I'd get two sets of readings the oldest first?
The real question is when the interrupt is raised, every byte written or every packet of 42 bytes written?

[jrowberg]

Based on the data captured from the MPU-6050EVB ant attached AVR board running the official MotionApps 2.0, I'm pretty sure the interrupt fires when the DMP is done with its calculation, but before the FIFO is necessarily ready. Check this out:

http://www.i2cdevlib.com/tools/analyzer/1

Scroll down to line 271 to see the beginning of the pure interrupt detection/FIFO read cycle. There is a repetitive cycle of INT_STATUS read, then FIFO_COUNT reads until the count = 42, then a 42-byte FIFO read. This goes on and on until the capture stops.

There are two ways to interpret this data. One is that the interrupt fires first, prompting the code to (1) read the interrupt status to reset the INT pin, and then (2) wait for a 42-byte packet before reading it. This is how I interpreted it, because why else would they be reading INT_STATUS at all?

The other way to interpret it is that they are simply monitoring FIFO_COUNT for >= 42 bytes, and as soon as they see it, the code (1) reads the FIFO and then (2) reads the interrupt status pin to reset the INT pin. This doesn't make a whole lot of sense, but it would probably work just as well. I imagine there would be many more FIFO_COUNT reads before 42 bytes arrive if this were the case though.

The only part that doesn't quite fit with the original interpretation is that there is about 6ms between each INT_STATUS read and the next FIFO_RW read (when the data is actually available), whereas there is only about 250ns between the FIFO_RW and the next INT_STATUS read. I would expect most of the time to pass between finishing the FIFO read and checking the next INT_STATUS if my assumptions are correct.

I still need to learn more about this chip. :-) Unfortunately the data sheet doesn't even acknowledge the existence of the DMP registers or bitfields, let along explain how they work.

[mikegreen]

Howdy,
First, Jeff - thanks... your work on the MPU6050 is the only reason I have what I have so far working...

Related to this thread - I find once I get the arduino uno cranking with some other logic (controlling an LCD, some LEDs, and some trying some graphic output), I overload the FIFO buffer constantly.

While I guess this isn't terrible as it traps and resets it - do you know if we can adjust the sampling rate on the output of the IMU to slow down? I only need 10-20hz, it appears it is doing much, much more out of the box.

Happy new year and thanks again,

Mike

[jrowberg]

Hi @mikegreen! Fortunately this is quite easy to do. Line 261 (currently) of the _MotionApps20.h file contains one hex value which can be modified to change the output rate:

https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050_6Axis_MotionApps20.h#L261

That should take care of it for you.

[mikegreen]

Thanks Jeff! Worked like a charm. Ardo is much happier now. One day I'll learn to program and write more efficient code.. until then, slower sampling it is :-)

happy new year!

[andig]

@jrowberg: adjusting sample rate via MPU6050/MPU6050_6Axis_MotionApps20.h#L261 is understood, but shouldn't a call to mpu.setRate after mpu.dmpInitialize do the same? Or does the DMP ignore the "normal" register settings? I'm honestly lost how to differentiate between DMP and non-DMP operations- if there is any add-on reading a link would be highly appreciated.

[jrowberg]

@andig: the DMP does by and large ignore the "normal" register settings. There is unfortunately zero documentation from InvenSense on how this works, at least which I have access to. It is possible that some of their later code provides some info, but the DMP is still pretty locked down.

The DMP output rate is controlled by a particular chunk of memory in the volatile memory space used to store the DMP binary. This any pretty much all other DMP-specific settings are controlled in this same block of memory rather than directly through registers.

[dannyhoffman6]

@jrowberg

Hi Jeff,

Firstly, thank you for your time and effort with this code, my project wouldn't be possible without it. I have an application where I am tracking the movement of a baseball bat. I am reading the centripetal acceleration (aaWorld.x) and the angular velocity (gz). I am having issues with the FIFO overflow. I manipulate the aaWorld.x data quite a bit and store it an a large array, which I believe makes the code too inefficient and gives me a FIFO overflow. It is not acceptable for me to decrease the sampling rate. Here is what I am trying to accomplish: I want to read angular velocity from the gyro sensor, when it feels rotation, the code will store the data from both the gyro sensor and the accelerometer into two arrays containing 50 values each. The max of both of these arrays will be computed and then displayed to a seven-segment display. I have accomplished this task using just a gyroscope(ITG3200), however, the fused sensor is proving to be much more difficult. Do you see any issues with what I am trying to accomplish? Is there anyway to get rid of the fifo buffer, and still use the acceleration with gravity removed (aaWorld)? I can post my code upon request.

Thank you so much,

Daniel Hoffman

[jrowberg]

Closing ancient issue for cleanup.