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?
Tags:
Permalink Reply by Jake Stew on May 27, 2012 at 12:37am You're pretty limited legally. In most states you're only going to be able to recover your purchase price. If you legitimately had serious damages, like if you ordered 10k of them and had other contracts and investment involved it might be worth a go.
I agree with you that Invensense is committing fraud. However, you have 0% chance of having it stick in court. They will just talk some techno-gibberish and make a bullshit argument. The standard for getting punitive damages is pretty high, and you'll never come close.
The more I hear about the DMP the more I think it's complete bullshit. I believed Chris when he said it exists and they've done *something* with it. But I'm beginning to think perhaps his idea about it and mine are probably different and I'll be disappointed when the details are known.
Nobody has provided ANY information about this smoke-and-mirrors DMP...
What processor architecture does it use? How many MIPS does it do? Etc, etc, etc, etc. I never really believed it existed in the first place, and everyone else should have known better than to believe Invensense's bullshit.
Invensense has sold many chips based on a feature that doesn't exist, that's "theft by deception" in many states. Perhaps ST, which does have an open source DMP solution (iNemo) that works with it's 9DOF platform could sue the shit out of them. They are the ones that have actual damages that would justify a major lawsuit.
If you really want to do something about this I would file a small claims suit against Invensense. You pay your $25 filing fee and list any damages you can think of... lost time, production delays, emotional distress, or whatever you feel is reasonable. Try to file for the max (often $2000). Then Invensense will either not show up and have to pay you the $2k or they will have to pay $$$ to send a lawyer out to defend against it. Either way you will make them take notice of you and force them to make you whole again. Likely you can end up with a couple hundred bucks and a priceless amount of satisfaction.
Permalink Reply by Gerry Lichter on May 29, 2012 at 11:10pm MPU-9150 9-DoF DMP Board:
MPU-9150 MotionFit Wireless SDK $199.00
MPU-6050 9-DoF DMP Compatible Compass:
AK8975
MPU-6050 6-DoF DMP Sensor Fusion Arduino Sketch:
https://github.com/jrowberg/i2cdevlib/blob/master/Arduino/MPU6050/E...
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".
Permalink Reply by Jake Stew on June 1, 2012 at 12:54am 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.
http://www.eetimes.com/electronics-news/4235992/ST-adds-MCU-to-iner...
Some wizard out there should make an autopilot based around it.
Permalink Reply by Gerry Lichter on June 2, 2012 at 10:25pm 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?
Permalink Reply by Richard on June 3, 2012 at 3:55am 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.
Permalink Reply by basroil on June 20, 2012 at 2:47am 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.
Permalink Reply by basroil on August 13, 2012 at 12:13am 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.
Permalink Reply by Gerry Lichter on August 13, 2012 at 3:10am
Permalink Reply by Jake Stew on August 13, 2012 at 9:37am 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.
Permalink Reply by Jake Stew on August 13, 2012 at 10:44am 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.
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.24 members
1277 members
183 members
246 members
179 members
© 2013 Created by Chris Anderson.
Powered by
