Hi I'm trying to figure out how to use the MPU-6000, I'm reading your source code and I don't see anything about using the DMP
I've also looked at the ArduPilotMega 2.0 repo, found the code for the MPU-6000, but it also does not do anything with the DMP
I understand there's a supposed to be a bit of code that loads a block of instructions into memory banks inside the MPU-60x0, and then the FIFO outputs quaternion data. I do not see any of these elements in "ArduIMU328_V3" or "AP_InertialSensor_MPU6000.cpp"
Can I please see the code to use the DMP?
....that is a man with a plan....
MPU-9150 9-DoF DMP Board:
MPU-9150 MotionFit Wireless SDK $199.00
MPU-6050 9-DoF DMP Compatible Compass:
MPU-6050 6-DoF DMP Sensor Fusion Arduino Sketch:
Reasonable sounding explanation for the way Invensense has been handling this:
[quote="sectionsbest"]The only way we would be able to support a compass independent 9-axis quaternion would be if the user took the responsibility of generating calibrated compass data and feed it into the library.
Every user has his own preference for choosing his compass and calibrating a compass is very specific to the individual compass vendor design and since InvenSense doesn’t make the compass it is not possible to support all the other compass nuances.
In order to deliver a higher performance, we see such a library would have to be designed to take the 6-axis quaternion coming out of the DMP and do the compass data integration on the MCU. Typically compass is sampled
at a much lower data rate than gyro and accel, and we don’t expect this to burden the MCU much at all. This is one of the proposals being considered for implementation and should be available in the future. Unfortunately we don’t have a fixed timeline we can commit to as it is in planning phase as we speak.[/quote]
The above data was the product of my research on the state of this issue. I've been waiting patiently for this issue to resolve itself, and thanks to the efforts of Jeff Rowberg, my needs for this chip have been essentially met. I empathize with the frustrations of those in this thread, and in the developers corner for InvenSense's handling of this issue.
Some people may be interested in abandoning ship and going iNemo, I'm probably going to just rock Jeff Rowberg's code on the ArduIMU V3 for now until the MPU9150 gets more traction up-hill on Mt. "Shotmyselfinthefootandpissedoffallofmycustomers".
LOL! The MPU9150 is $80! What a ripoff.
ST has a little board, the "iNemo M1" that they announced awhile back. Should be in volume production in Q2. Invensense is trying to catch up with ST now. I'm sure they'll push out a buggy, overpriced system so they don't look like losers in their field.
Some wizard out there should make an autopilot based around it.
Looks like I'm not out of the woods yet. Code linked about is for I2C MPU6050 but the ArduIMU V3 is SPI MPU6000.
Does anyone know where the latest and greatest code for this board is on the forum? Is it on the ArduPilot Google Code page or is there something a little bit more 6dof DMP buried in a forum post somewhere?
Last I heard, the V3 was almost working with the ArduIMU V2 test application?
There simply isn't any code that uses the DMP.
There is ArduIMU v3 software that treats the MPU6000 as a pair of dumb sensors, the same as on the ArduIMU v2.
AFAIK, that works but there's little to no processing power left in the AVR to do anything else.
There was code, (http://code.google.com/p/ardupilot-mega/source/browse/libraries/MPU...), but the entire project has been not only abandoned, but forcefully deleted, likely at Invensense's request.
You can still find it at https://code.google.com/p/gentlenav/source/browse/branches/MatrixPi... , but you need to update the code to reflect changes in orientation and ports between 2.0 and 3.0 boards.
Is there an official response as to why this code has not only not been released, but not even spoken about by the development team? I purchased one of the ArduIMU specifically because of the promise of less CPU use using sensor fusion, yet there has been exactly zero support.
We have yet to see if it will live up to it's marketing. Previous comments from the devs make it sound like it's all smoke and mirrors and that the actual "DMP" may just be some crappy code running on on the Atmega processor.
Jake: I'm not sure which comments you're referring to, but the code is here, so you can judge for yourself.
Thanks for the link Chris. I'm looking stuff over.
The comments I'm referring to are every question that has ever been asked about the DMP. All the answers have been extremely vague or outright evasive.
If this DMP lives up to the hype then the Invensense marketing has been piss poor. I've been looking things over in their "dev corner" for almost an hour and not one basic question has been answered yet.
Questions like... What processor/core does it use? How much memory does it have? What clock speed does it run at? How much processing power does it have?
This info should be right at the top of the datasheet and I still have no clue.
Even basic questions like what inputs and outputs does it take are buried in the documentation somewhere and I haven't found the answers yet.
These are basic, easy to answer questions. When the answers are vague or evasive it leads a reasonable person to believe they are misrepresenting things.
Poking around the code it looks like Invensense's interface library is doing most of the work.
It appears that they're just forcing you to use their interface library which is actually doing all or most of the work of the imaginary DMP.
So their "DMP" is actually just a library for accessing the sensors that does a little processing on the data (on YOUR processor)?
Hopefully someone else who's spent more time on this can comment, but it looks to me like Invensense is BUSTED!