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?
Replies
Hey if You have a DMP code which can run on ArduIMU v3 Hardware please share it..?
I want it very badly cause, DCM is not giving proper output without GPS.
Please share the code..
I think i have found something:
#define CONFIG_APM_HARDWARE APM_HARDWARE_APM2
Now this line is enabled in code.
Try now
Gábor
Hi everybody.
I really don't mean to be rude but:
We have all bought the hardware and should really just start using it. How about we stop whining about Invensense and start getting a working library going for the ArduIMU3.
There is partly working source out there (from the dark side of the reposetory) that need a bit of tinkering to work with the ArduIMU V3 hardware.
I have sort of gotten this to work, still without the compass fusion.
Any suggestions on how we proceed?
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.
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".
Here's some bad news from an unacceptably rude response from Invensense:
i.e. they were providing false advertising to everyone including the developers here at DIY Drones and absolutely every customer. Despite telling them exactly how my chip was acquired and why DMP code is necessary, here's their solution:
Quite unacceptable for a corporation of any size, especially when they made gains through illegal means (fraud by way of false advertising). If someone here happens to be friends with (married to, or actually ) a lawyer, maybe they could give some insight on options?
I think we can expect DIY Drones to never release DMP based code (unless Invensense suddenly remembers how to use DMP, or a lawsuit helps them remember). Since DMP based quaternions is not an option, can we please have quaternion output option? I'm using this thing in a snake type robot, and while euler representation should never blow up in an airplane (unless you do 3D, in which case you would be manually driving anyway), it happens every 10 seconds on my project (6-DoF end effector... and every other point too). Hell, according to the literature on DCM, they have a quaternion based DCM correction too, which is apparently more computationally efficient. I just can't make sense of it since I'm no math/CS person, just hardware and control.
DMP, where art thou? :/
Any updates on the DMP code?
results are good for roll and pitch, but i am facing problem with yaw... heading angle from magnetometer is not linear over full rotation(if i rotate imu for 90deg i get heading as 70deg or 105deg). thus yaw is not correct. i don't know i am missing something or it is compass fault.
I am now using the ArduIMU V3 for projects with the preliminary firmware previously discussed here.
See:
http://dzlsevilgeniuslair.blogspot.com/
And:
http://diydrones.com/profiles/blogs/rctp-a-directed-airflow-control...
-
1
-
2
of 2 Next