DMP 6-axis fusion on Arduino (working w/ link to code)

Noah, IMHO this is exactly how it should be done for true hardware independence and for applications that do not require on-the-fly code modification: -

o Configure DMP using some GUI.
o Dump 'compiled' config(s) to MPU via I2C.
o Trivial reads from MPU. Maybe a config swap from time to time.

Anyone else think this is a good approach for light-weight host code? I am going to have a play with this idea in preference to using the Embedded Motion Apps which is considerably bigger than my entire application code including floating point sensor fusion and actuator control.

Dave.

I this approach requires a deep knowledge of the internal device structure and configuration registers.
It should be good if InvenSense would release a good paper about this....everybody is waiting I think.

Anyway, noah approach is an alternative. Approach is interesting, but how do you know if your configuration is using 9 DOF approach or 6 DOF approach?
Is this information part of the configuration or it is stored elsewhere...

I would give it a try with my microprocessor to see what happen.

Thanks.
Paolo.

Paolo,

let me prefix what follows with a statement that the MPU-60x0 is an excellent component and concept....

The knowledge of the internal structure is already present in the MotionApps code and documentation, although it is well obscured presumably for good commercial reasons. I think that Invensense believe that the MotionApps firmware makes the design easier but only if you can it run on your host and at a high resource overhead (the very thing the MPU-60x0 is intended to reduce).

Everything you need for set up is part of the configuration sent to the MPU-60x0 over I2C; Sensor selection, data to be returned, calibration and fusion algorithm selections. Once configured, the MPU-60x0 autonomously returns the motion information you require. This is only a SUBTLE change from the given architecture; removing the MotionApps firmware from the host device and presumes that the application does not need to constantly change sensors, calibration algorithms and motion information required in any arbitrary way on-the-fly. Even then, a few preset configurations can be held in ROM ready for upload to the MPU as required.

Maybe Invensense would like to provide a few canned configs so that I can truely break the celophane on this great component, get it off the evaluation board and into some real designs. At the moment, I have it running using RAW SENSOR DATA in my own application code that fuses 6 axis data (no compass) in a control loop running at 1kHz using floating point filters and actuator control. For what it's worth here is the approx benchmark:- Processor: 40MIPS. DSP sample time: 1ms. Program: 8k bytes. RAM: 200 bytes. By running the I2C at 400kHz there is plenty of time to grab all the sensor data including compass every sample time. At the moment, I am using about 80% of the processing capacity and by using the full capability of the MPU-60x0 instead I know I could reduce this to about 5%, clearing the way for some new smarts on the same processor.

Maybe a good software engineer can port the MotionApps code to a PC and provide a menu selection interface to capture the configurations to be uploaded to the MPU-60x0? The only real complication is the 3rd party magnetometer setups but there are a few already catered for.

Comments anyone?

I'll shut up now!

Dave.

totally agree with your way of thinking regarding the DMP config dump and trivial reads.

If Invensense provided as you say canned configs or a configuration GUI for the DMP then it would allow us to use the DMP engine without the overblown Motion Appz and at the same time maintain the Invensense secrecy regarding their DMP.

I was totally put off the motion appz from the start given its bulkiness. Its use has a built in contradiction: In order to save host resources by using the DMP we have to use the motion appz which needlesly hogs precious microcontroller resources.

For now I am contenting myself with using the raw 9DOF readings and writing my own sensor fusion algorithm which will have the added advantage of enabling me to correct for centrifugal effects by adding a velocity signal.

The Invensense DMP/software does not cater for this as far as I know.

In fact I saw a demo video they made where they put an imu unit in a turntable to illustrate the error introduced by the centrifugal acceleration

Ok, so your discussion ends up exactly with my same conclusions. No 9DOM sensor fusion implementation currently available in Invensense programs and documentation. So basically, it's currently impossible to implement/try 9DOM DMP sensor fusion with the MPU605, no matters in which microcontroller you wanna use this.

For 6DOM DMP, thanks to Noah work we have something to try.. but, as Dave, I'm also wondering about the true advantage in using the DMP over a on microcontroller sensor fusion. Probably such advantage will be obvious when complete docs are available.

Question is, when this is gonna happen?

For those in need of a 9DOM sensor fusion, you may have a look at my FreeIMU library, which does exactly that.

How about IMU-3000? Is it possible to convert your code to work with that (Atmel Inertial Two)?

Or maybe would it be possible to use 6-dof motion apps with arduino and just filter the drift with magnetometer (HMC5883L).