Invensense releases licence to allow use of the MPU-6000 DMP processor

Good news: Invensense has finally released a licence that allows open source projects such as ArduCopter/Plane to use the built-in sensor fusion processor in the MPU-6000 gyro/accel chip used in APM 2.x!

This processor, called the Digital Motion Processor (DMP), has been in the APM 2.x sensors from the beginning, but we weren't using it because Invensense had not specifically allowed their driver to be distributed with open source software. However, after much discussion, they have now written a licence that allows this. 

You can get it on the Invensense Developers Corner here. (You'll have to register first). I'm not a lawyer, so I won't attempt to analyze the language to see if there are any holes in it, but the Invensense developer relations managers and their legal team wrote it with projects like ArduPlane/Copter in mind, and they've assured me that we now have the green light to use the DMP code. (The agreement specifies the MPU-6050, which is the I2C version of the chip, but that includes the MPU-6000, which is the SPI version that we use). 

The Ardu* dev team is hard at work at implementing the DMP code in the ArduCopter/Plane code and we hope to have that ready for the next release. It will probably give you a choice of using the current DCM, running on the main processor, or the DMP running on the MPU-6000, freeing up a good bit of processing power for other functions. 

We have not done a rigorous test of the DMP vs the DCM, so we can't yet say that one is better than the other. But this licence now allows us give people the option of trying it, and if it perorms better than the DCM, or just as well but freeing up computational power, we can switch to it going forward. 

Views: 17073

Wiki Ninja
Comment by Gent Armedo on July 26, 2012 at 11:39pm

Wooohoo! I'm waiting for the next Arduplane code to try. Good times are rolling with DIYDrones!

Comment by OuBen on July 27, 2012 at 12:45am


Comment by jumbo on July 27, 2012 at 2:17am
Good news ,Looking forward,I like apm2^_^
Comment by Paul Bealing on July 27, 2012 at 3:32am

Hello All.

I've not said much before but have been following for a long time. Having the option DMP/DCM is good, but switching to DMP later on at the expense of DCM would take a big part of the project out of open source and make it reliant upon a proprietary and very specialized product. If this is the case, it doesn't seem good; or am I missing something. Paul.

Comment by Crispin on July 27, 2012 at 3:54am

I don't really know enough about anything to comment but have a question though: How would their code be better than something that "we" could do. Would their not be good for 80/20 when quad and planes are actually the 20?

Can "we" tweak the code in the DMP? That would be the best I would guess.

From a layman's PoV, I've been flying my quad since December and have seen a large improvement each time a new version comes out. Would these improvements no be slowed because we're relying on their black box to do the work.

Feel free to point out the errors in my thought process ;)

Comment by Florin on July 27, 2012 at 4:17am

this is simply great news... I cant wait to try the DMP version of arduplane.

Comment by Florin on July 27, 2012 at 4:23am

@ Paul: imagine that mega 2650 not doing all the DCM calculation => all that processing power could be put to use for something else in your ardupilot (it could even work on a 328P with some code trimming)

Comment by Vernon Barry on July 27, 2012 at 4:33am

YES!!!!! This has been one of the sore points since the beginning of APM 2.0. Glad the legal team got it figured out!

3D Robotics
Comment by Chris Anderson on July 27, 2012 at 8:06am

Crispin: That's what we'll be able to properly test now. We'll always give people a choice between our own DCM and the DMP, regardless. 

No, we cannot modify the DMP code. But we can modify how we use its output in our own higher-level control code.

Comment by Harry on July 27, 2012 at 1:24pm

This might be good for me, but probably just another hurdle in figuring out how to implement and make good use.  I'm trying to use the new IMU in Jean-Louis' TrIMUpter code and when I add the IMU code as it is now, it chokes and only arms one motor which does respond to motion.  If I run the tricopter code as it was written for IMU V2, it reads the Rx and outputs to the ESC's but the IMU is all screwed up since it isnt the right version.  It's very frustrating trying to do something nobody else has any interest in.  It almost works. 


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service