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.
Comments
I accept that off-loading the work from the main processor would be a good thing in the broader sense. Not knowing anything about how "sensor fusion" works, I guess the (rhetorical) question is: Are there good ways and bad ways to do it? Could Invesense put a method in that is "just ok" but being a black box, we would never be able to change it.
Crispin, I am assuming DMP does motion integration at a much much faster rate than what can be done off-chip. Hence the DMP solution is likely to be much more accurate.
I'm a fan of using the DMP fusion algorithm and started in quads with the intent of using a CH Robotics' CHR-UM6 with a PIC32. APM 2 came out with even more functionality than what I could install on my real estate and did it in a smaller package, so APM2 was a no-brainer, and cheaper. Implement DMP and I'm back to my original dream of using the "fusion" processor (extended Kalman filter?) to free-up the APM2. I welcome this with open arms and am thrilled that an agreement between open source community and Invensense has been reached. If this means I just register as a developer, so be it... Cheers!
I dont even know what I'm looking for on that site. I agreed to something and then the downloads were nothing but .pdf . I need the code that will replace mpu_read(), read_adc_raw(), HMC5883_read(), HMC5883_calculate(pitch, roll) and not need all kinds of low level tricks.
Jumbo news, it's been a year or more since people got excited about the DMP but couldn't use it.
Well, this is excellent news and will boost the APM2 value and long term usability for sure:) congratulations for your well done negotiations with Invensense.
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.
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.
YES!!!!! This has been one of the sore points since the beginning of APM 2.0. Glad the legal team got it figured out!
@ 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)
-
1
-
2
-
3
of 3 Next