Hi there,
I'm currently trying to get the MPU6050 with DMP running an a raspberryPi in a bare metal environment. Based on the motion-driver-5.1.3 library code I was able to successfully upload the DMP binary firmware to the MPU6050 and get it configured to output data onto the FiFo.
For the moment I've only activated the RAW_ACCEL feature. This gives a correct FIFO packet size of 6 bytes. 2 bytes for each axis.
However, when looking at the raw data and even after converting them into float representations they do not make any sense to me. The values are changing weird even if the MPU6050 is not moved. I would expect some jitter but at least the axis pointing down should give a concrete greater value than the other two axis...
This is the raw output from the FiFO:
I - MPU6050DMP: 0x82 0x42 0x7F 0xFF 0x82 0x42
I - MPU6050DMP: 0x5F 0xFF 0x82 0x7A 0x5F 0xFF
I - MPU6050DMP: 0x82 0x7A 0x5F 0xFF 0x82 0x7A
I - MPU6050DMP: 0xFD 0x90 0xFF 0x7E 0x47 0x98
I - MPU6050DMP: 0x7F 0xFF 0x80 0x87 0x7F 0xFF
I - MPU6050DMP: 0x80 0x87 0x7F 0xFF 0x80 0x87
I - MPU6050DMP: 0x5F 0xFF 0x81 0x25 0x5F 0xFF
I - MPU6050DMP: 0x81 0x25 0x5F 0xFF 0x81 0x25
I - MPU6050DMP: 0xFD 0x6E 0xFF 0x9E 0x47 0xDA
I - MPU6050DMP: 0x7F 0xFF 0x7E 0x91 0x7F 0xFF
I - MPU6050DMP: 0x7E 0x91 0x7F 0xFF 0x7E 0x91
I - MPU6050DMP: 0x5F 0xFF 0x7F 0xCE 0x5F 0xFF
I - MPU6050DMP: 0x7F 0xCE 0x5F 0xFF 0x7F 0xCE
I - MPU6050DMP: 0xFD 0xA6 0xFF 0xD0 0x47 0xE0
I've already tried different MPU6050 chips to see if it is a hardware issue or not. All behave the same. So I guess a software issue is the case. Is there any possibility to check the proper function of the DMP firware loaded onto the chip. The loading verifies that each byte stored onto MPU6050 is as expected but there might be some miss-configuration taking place afterwards. How could one check that the MPU6050 DMP is configured correctly? Are there some registers that could be requested from the MPU or some memory address that could be requested from the DMP to verify this?
Thanks in advance for any hint and support.
BR
Schnoogle
Hi Schnoogle,
Unfortunately the DMP is closed property so you have to rely on the dmp-functions in the motion-library.
However, I have experienced them to be good (at least for the MPU6500).
How have you configured the device?
You can try set the sample rate to something super slow, and not pull off the data from the fifo, and let's see how the fifo count is building up over time, to verify that it is indeed only 6-bytes at a time that is pushed (and e.g. not quaternion-data you get).
Footnote: You need to be aware that you must configure the DMP to +/-4g and +/-2000dps when you enable quaternions.
Hi egholm,
thanks for your response. I just thought there might be a function not yet part of the motion driver source code that gives some sort of "validation" with respect to the DMP.
However, I pretty much ported the source-code of the motion driver library and following the motion_driver_test.c sample application to set up the DMP, but only set the accel feature to be active.
Looking at the FIFO counts without reading anything from it, it grows by 6 bytes on each interrupt.
The configuration is done like this:
1. do the default config of the MPU6050 ->
1.1. reset the device
1.2. send 0x0 to PWR_MGMT_1 to wakeup the device
1.3. set gyro to +/- 2000dps
1.4. set accel tp +/- 2g
1.5. set Lpf to 42Hz
1.6. set sample rate to 50Hz
1.7. disable fifo for any sensor
1.8. disable bypass mode
2. do the DMP specific configuration
2.1. enable gyro/accel sensor
2.2. setup accel and gyro to be pushed to FiFo
2.3. set sample rate to 100Hz
2.4. load the DMP firmware -> verify the bytes send to the device are valid
2.5. set the orientation matrix
2.6. enable DMP feature SEND_RAW_ACCELL (only)
2.7. set FiFo rate to 100Hz
2.8. enable Dmp state -> this activates the DMP interrupt and resets and activates the FiFo
After this the Interrupt is triggered as expected and the data provided is as in my first post, but this data does not make any sense to me as the MPU6050 is lying on the table without any movements.
I also ported the "self_test" function which does not pass in my environment.
As the accel data is able to be read in "raw" mode from the device without the DMP image loaded to the chip I do assume some issues in my config or during upload of the DMP image. Are there any checkpoints or values that could be read from the DMP registers which should have a known value right after uploading the image and setting the PRGM_START_ADDR which I guess would kick of the DMP firmware ???
Thanks in advance.
BR
Schnoogle
Hi there,
it's me again... So I further cross checked the behaviour and checked what the FIFO would be if no feature is active at all. At having set a very low FIFO rate the fifo is growing by 24 BYTES :O
I'm wondering now what this 24 bytes would be..
If I do activate the RAW_ACCEL feature the FIFO is growing by 30 bytes... exactly 6 bytes more (which seem to be the added accel values.
If I do activate RAW_ACCEL and RAW_GYRO the FIFO grows by 36 bytes which also makes perfectly sense...
BUT what are the initial 24 bytes? In none of the examples/motion_driver_test.c file is this mentioned...
What is even more weird to me - if I know add the 6x_LP_QUAT feature the FIFO size is now growing by 40!!! bytes.
Even if I enable the 6x_LP_QUAT feature ONLY the FiFo size grows by 28 bytes... This would mean the quaternion just adds 4 bytes to the FIFO which absolutely makes no sense to me - it should be 16 bytes! So my assumption would be the initial 24bytes may contain some "padding" values? which are used to some extend by the quaternion values? That would lead to a 12byte offset in the FIFO if the QUAT feature is enabled... but again I'm confused where those 12 bytes come from and what they may contain... and whether my assumptions are correct...
Any further hint would be much welcome...
BR
Schnoogle
Hi Schnoogle,
Strange, indeed. According to inv_mpu_dmp_motion_driver.c#dmp_enable_feature() there is no combination of the features that would result in a 24 bytes packet:
dmp.packet_length = 0;
if (mask & DMP_FEATURE_SEND_RAW_ACCEL)
dmp.packet_length += 6;
if (mask & DMP_FEATURE_SEND_ANY_GYRO)
dmp.packet_length += 6;
if (mask & (DMP_FEATURE_LP_QUAT | DMP_FEATURE_6X_LP_QUAT))
dmp.packet_length += 16;
if (mask & (DMP_FEATURE_TAP | DMP_FEATURE_ANDROID_ORIENT))
dmp.packet_length += 4;
I just ported their motion-library to a 64-bit architecture, and there I had to be cautious with the sizes of long which they assumed were 32-bit, whereas with my compiler they became 64-bit.
Could there be any such issues with your system here? (although the value coming from the fifo register is independent of architecture...)
No, not likely...
Your setup looks good, although I reckon you could do step 1 and then jump directly to 2.4 and forward (or maybe not ;))
I'm out of ideas for now... Sorry.
And your are not likely to get a decent answer from TDK/InvenSense - they are silent as the grave (at best).
Hi egholm,
thx a ton for your efforts. What a shame for TDK/InvenSense, not supporting the developers they request to register with many details to get access to their resources and then being left alone :(...
However, I was able to dig deeper into the root cause by enabling just a single feature. The code that enables one feature does also disable the other once. Having started fresh I thought not running the disabling part, but the enabling only could give a hint whats going wrong and it did. My disabling code was somehow buggy and did write the wrong bytes to the specific memory address of the DMP firmware... However, after fixing this the whole thing is know working like a charm. The FIFO count is always as expected and the data contained in the FIFO does make sense at all :)
Thanks again for your support and kicking some ideas where to look ;)
BR
Schnoogle
Schnoogle,
That is indeed good news! Congrats! :)
// Egholm