Jump to content
I2Cdevlib Forums
anistor

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

Recommended Posts

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!

 

 

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.


Share this post


Link to post
Share on other sites

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.

 

 

 

 


 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×