MPU6050+HMC5883L - put compass values in FIFO while DMP is enabled

[anistor]

Hi all,

 

I managed to connect the compass as slave and then read its data from EXT_SENS_DATA registers. I even managed to configured the mpu to place the EXT_SENS_DATA in the fifo, so now I can get all the raw sensors, including compass into the fifo - but the DMP was not enabled up to this point.

 

The next challange is to activate DMP and place the DMP quaternion output in the fifo and also put the compass data in the fifo. Anyone knows how can I achieve this? I found an older post regarding reading compass value from EXT_SENS_DATA while DMP is on - I've tried that and it does indeed work. But I need more than that. I would like to place the compass output in the fifo together with the dmp output. But it seems to me that when DMP is enabled it will take over the fifo config and whatever other sensor raw values were previosuly configured to go into the fifo will not be honoured. Also, in which order would the data be placed in fifo with respect to the dmp data?

 

Thanks!

 

 

[luisrodenas]

I couldn't achieve this and I don't know if it is even possible. If you achieve something let us know.

[anistor]

Hi luisrodenas,

 

My current experience with the DMP is limited to the MPU6050_6Axis_MotionApps20.h sample which works for me nicely, without a mag. Next, I would like to try MPU6050_9Axis_MotionApps41.h, but I do not have an AK8975C compass, so I would need to tweak the code to correctly init the HMC5883L instead of the AK8975C. In my view, after the compass init is done it should not longer matter what compass is used (well, except for range/calibration details - TBD later). What just happens is that 6 bytes of mag data magically arrive from the slave and are placed in the EXT_SENS_DATA registers. I assume the DMP would pick them up from there. Unfotunatelly there is no documentation about how the DMP gets the mag data, so I'll need to try it out.

 

I think you already did a nice job setting up the HMC5883L compass on top of the 6 axis sample (http://www.i2cdevlib.com/forums/topic/111-arduino-example-sketch-to-read-magnetometer-while-dmp-is-on/) - many thanks for it!

 

But, according to line 117 of https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/MPU6050_9Axis_MotionApps41.h#L117 , the DMP can provide magnetometer data also. Maybe it just spews it out in the fifo ... maybe it also fuses it. Not sure what it actually does, the info on the net (including invensense site) is very unclear... But I would be happy to get it out anyway.

 

So, what do you think regarding the chances of achieving with MPU6050+HMC5883L the same results as with a MPU6050+AK8975C (or MPU9150) from the MPU6050_9Axis_MotionApps41.h code? When you say you could not achieve this, have you actually tried the route described here or something else?

 

Thanks!

[anistor]

I'll do a quick hack on top of MPU6050_9Axis_MotionApps41.h and let you know.

[luisrodenas]

I haven't tried to put magnetometer data in fifo, but I think many people has tried without success.

What I tried and searched a lot was a way to fuse magnetometer data IN the dmp's algorithm, my conclusion was that it is not possible and MPU9150's library also fuses mag data at host processor, not with DMP. This was my conclusion after a few days looking for info, but I am not 100% sure of this.

 

Btw, what is the advantage of putting mag data in fifo if you still have to fuse it outside?

[anistor]

Having the mag data in the fifo helps frame it with the rest of the data so when it is later retrieved from fifo to perform the 6+3 fusion we get data that was measured at (nearly) the same time instant, or certainly closer together than in the case the mag is read after the 6 axis is fetched from the fifo.  But the difference might be so minute it might not be worth the hassle.

 

After hacking the MPU6050_9Axis_MotionApps41.h, as I said before, I was able to successfuly get HMC5883L data in the fifo while on DMP mode. But, the 16bit values seem unrealistically high. Maybe it's a byte order problem? Need to investigate further.... They are neither constant nor random. They seem to react correctly with the orientation of the sensor so I'm definitelly close to something.

 

Or maybe I'll just stop here and give up on DMP altogether. It was already a very frustrating experience. And I just realised that my Arduino sketch already uses more than half of the 32kb available flash space of my arduino pro mini. I still need to add mag fusion, gps and barometer and drive a 4 line text lcd, so I'm afraid I'll be out of space very soon. Probably the best thing to do is to just return to the point I was a few weeks ago and get raw data from the mpu+mag+baro+gps (about 9kb), implement the AHRS (Madgwick algorithm ia about 13kb) and I'm still left with about 9kb of extra space that I can use for driving the lcd and maybe even add a bluetooth module.

[Evgen4Life]

Hi, everybody!

I've got the same problem: compass vaues are unavailable when DMP is enabled in MPU6050+HMC5883L configuration.

Using MPU6050_9Axis_MotionApps41.h with my correction. But EXT_SENS_DATA_XX registers are always empty, and values from FIFO buffer are incorrect (MPU6050::dmpGetMag returns {0, 0, 65519} even if i2c slave is configured to wrong address).

When DMP is disabled, HMC5883L becomes available in bypass mode and its i2c address is 0x1E.

Please help me with MPU6050_9Axis_MotionApps41.h. Perhaps it would be usefull for me to get hacked version of MPU6050_9Axis_MotionApps41.h.

[NonConformalMapping]

Has anyone made any progress with this "hacked" version of MPU6050_9Axis_MotionApps41.h? I mean, a version that can handle the Honeywell magnetometer?

[johny]

I am currently facing the same problem. Does anybody make any progress with it?

[dsptech]

I see that this a very old thread but in these days I'm facing the thread subject.

Using an MPU9250 and the Invensense motion driver (6.1), I'm able to put compass data in the fifo while DMP is enabled, without hacks on the original DMP firmware.
I achieved this result by changing the original fifo reset function: the slave 1 fifo bit must be enabled before activating the fifo and dmp features in user control register.
The resulting saved record is: 8 byte of compass data (compass status1 + 6 bytes of true data + compass status 2) followed by the original DMP record.

Another way: the slave 1 fifo bit can be enabled after the FIFO and DMP enabling (for example: elsewhere in the user code), but a proper fifo purge is required to discard the incomplete records and gain the correct sync against the FIFO.

These solutions work on my device using 200 hz DMP sample rate + 100Hz compass sample rate (every compass sample is repeated two times in FIFO, gestures enabled and quaternion disabled), but them are totally undocumented and more testing is needed, so, I would like to know if anyone use similar solutions and if there are know issues.
Regards.

 

 

 

 

 

 

 

[Ridwan Kabir]

Hi Anistor,

Could you access the raw values of the magnetometer? If yes, can your please share your code? I am facing problems regarding this.

[Ridwan Kabir]

Hi Anistor,

Could you access the raw values of the magnetometer? If yes, can your please share your code? I am facing problems regarding this.