Thanks to help from Sami Finnila and Wesley Chuen we've found an issue with the default MPU6000 accelerometer scaling in some of the recent APM2 boards shipped in the last month or so. You can find the original discussion from Sami here.
Internally we use "DCM" to merge the gyro and accelerometer values together to calculate attitude. With the recent boards we are finding the accelerometer values are 2x as big as they should be which leads to an inaccurate attitude estimate. It's apparently possible to fly with this misconfiguration but it at least makes "the leans" more common (you can recognise "the leans" by your copter requiring more and more manual roll or pitch to keep it level as you fly).
This patched version is being called 2.5.5-Beta and is in the downloads area. After a short testing period (maybe 24h ~ 48h), if all goes well it will be available in the mission planner.
We're still working on the next official release 2.6 so we haven't included any improvements to flight dynamics in this patch except Adam's "Retro" loiter. This uses the ground speed directly from the GPS instead of calculating it using lat/lon position. You can enable this by setting the "RETRO_LOITER" parameter to "1". BTW, it's "retro" because this is the method used in the popular 2.0.49 version of Arducopter.
Feel free to post comments / issues regarding this patch release in the discussion below.
If you have recieved an APM2 in the last month, please try the test shown above:
Next just roll and pitch your board a bit and attach your tlogs below. These logs can be found in your AP Mission Planner's log directory. On a windows machine you will likely find a recently updated file here: C:\Program Files (x86)\APM Planner\logs\YYYY-MM-DD HH-MM-SS.tlog
Thanks for your help.
Yes, we have the DMP running privately. It works very well, although not all that much better than a well-tuned DCM. The main advantage is that frees up processing power to do other stuff, like self-learning algorithms. Not a game-changer, but a nice thing to have. We're in production discussions with Invensense about releasing the necessary code open source and I hope we'll be the first to be able to do so. I hope to have more news in a few weeks.
I think one should not expect much from a 15$ 6 in 1 chip as compared to costly (accurate) AD sensors. probably you can see some comments from timecop on this chip
Sorry, this is a bit of a jump in thread, the original question I was answering:
Permalink Reply by Andke
ouch - why do we do business with that company then ? - are they really that good
Who else makes the very sensors in a combined single chip solution? Exactly, they (Invensense) OWN the market on a combined sensor. This is why the APM 2.0 costs $199 and the older APM1.0 costs $250. The sensors and required support hardware drive the cost.
APM1.0 uses analog sensors and a separate A/D conversion chip thus driving up the cost and introducing several more points of error. A single chip solution that talks to the main processor via a single connection is far easier. They also own the proprietary code to run that chip in the very DPM mode they created.
I'm just trying to give you some background on the why it's used, and why it's a problem. Also, just a heads up it would not be way off to see some "export" laws thrown into the mix as to what can and cannot be opened to the public as source code. The US is very strict on code and software like this.
ST makes an excellent Accel/Mag chip and a good gyro. It's a 2 chip solution to get 9DOF either way you go. Personally I would have gone with ST. Invensense is a shitty company to deal with.
And as far as source code, the export issue was settled back in the late 90's. See Bernstein v. United States. Source code is 100% constitutionally protected free speech. It's a shame the government was able to scare so many people into thinking they had to obey their bogus export control laws. Nobody has ever been prosecuted for that sort of thing BTW. Bernstein sued the government and won before they even tried to enforce anything.
He sued the gov. again when they rewrote the laws (still unconstitutional), but the judge threw out this case because he had no real standing since the gov. wasn't enforcing them or giving him any trouble.
So it would be no problem to release the DMP code. The real issue is that 3DR probably didn't write any significant portion of it, so the code is still copyright by Invensense and covered by their disclosure agreement.
3DR should just rewrite the code instead of trying to deal with Invensense. The code was given to them as example code so they really wouldn't have to change more than a tiny bit to call it their own. I've never heard of any case where example code was the subject of a copyright lawsuit.
In fact, it would be laughable to try and tell a judge that you're suing because your "example code" is the basis for a derivative work. They'd laugh you right out of court.
So 3DR, release the code! If you want, I can give you the number of a copyright lawyer. Drop my name and I'm sure he'll give you some free advice (if he's not drunk).
Regarding my compass problem:
I've got another APM2 - replaced the GPS/SD/magnetometer board, - and it works as expected.
So the failure is somewhere on my GPS/SD/mag board - but I verified all power & interface connections, without finding the error - the fact that SD *and* magnetometer fails on it - hints that it should be something they have in common.
Thanks to all who tried to help.