MPU6000 scaling issue
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).
UPDATE (11-May-2012):
Craig and Tridge have completed a patch to automatically detect the scaling of the accelerometer so we can compensate.
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:
- hold your APM2 flat and check the "az" value in the mission planner's Flight Data, Status screen is approximately 1000 (it should be for everyone, regardless of whether you have a new or old board)
- hold your APM2 up-side-down (but still level) and check the "az" value again. If it's not close to 1000 then we want your tlog! :-)
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.
Tags: ArduCopter, ArduPlane, MPU6000, Scaling
Replies to This Discussion
-
DeveloperPermalink Reply by Randy on -
2.5.5 actually supports the optical flow sensor as well. Forgot about that.
There's no immediate plans to make it easier to solder to the APM2 I'm afraid. That will take a change on the APM2 board and there's currently a conflict with how they initially load the bootloader onto the 2560. I'll bring it up with the 3dr guys and we will see.
-
Permalink Reply by Mark Murray on -
Most excellent, thanks! :-)
The soldering was easier than thought, but I planned it properly, and used connectors to make it possible to more easily remove the sensor.
M
-
Permalink Reply by Greg on
-
With this issue in mind what are the plans for new batches of APM2 boards. What will end users receive? The original spec MPU6000 accelerometer scaling or will the new production batches continue to have the 2x factor in accel vaules?
-
Permalink Reply by Vernon Barry on
-
Permalink Reply by Sami Finnila
Neither the earlier nor the later boards have any actual hardware issue but rather a deviation from specified properties of the inertial sensor chip which the current flight software doesn't take into account. The actual issue is more of a software bug so you have nothing to worry about: there's absolutely nothing wrong with the newer boards, AFAIK.
-
Permalink Reply by Andke on -
One, unresolved hardware problem may be the compass reversal error, if related to reset signal.
-
DeveloperPermalink Reply by Randy on -
Jeepers, I guess I forgot all kinds of thing in my post. These other problems should be fixed:
1. compass reversal problem should be fixed <-- not 100% sure it's fixed
2. no need to press reset before arming motors (this affected just some people)
Tridge fixed them and I think they were both caused by interrupts firing during the startup sequence.
For #1, I'm not 100% sure because we couldn't recreate it on the dev team but we strongly suspect it's all the same issue.
-
Permalink Reply by Florin on
-
Randy, I still have the " reset before arming motor" issue, even with arduplane 2.33...
If I fall under the "some people" category should I hope for a fix?
-
DeveloperPermalink Reply by Randy on -
Florin,
Yes, there is hope! ArduPlane 2.33 went out about a month ago and the problem still existed then. The ArduPlane patch (presumably 2.34) will go out very soon...probably this weekend and will include this fix.
-
DeveloperPermalink Reply by Randy on -
My guess (and it's just my guess) is that from now on, it'll be the version with the 2x accel values. It seems like there are two version of the chip "Revision C" and "Revision D". All the latest boards are "Revision D". I suspect that the world is running out of the earlier version so it'll be "Revision D" from now on.
There's a new parameter, IMU_PRODUCT_ID, that you can see if you look at the parameters list through the AP Mission Planner. If it's "20" you've got Revision C. If it's "88" you've got revision D.
-
Permalink Reply by Jake Stew on -
So what is the actual issue? Did the mems sensor change, did they change the register settings, or what? If you set the registers to provide a certain scale then WTF?
If I set the chip to provide a certain scale and it doesn't provide that scale then it's a defect and should be returned. If it's some sort of undocumented chip revision change then that's the sort of crap I expect from invensense, but might be able to be worked around. So what's the deal?
-
Permalink Reply by Vernon Barry on
-
Jake, I think you are way over thinking this. The issue is an assumption in the code. The code assumed a certain scaling based blindly onthe first batches of chips. Somehow in the second revision, that scalling changed. The code is now modified to detect chip version and then apply the proper scaling.
A little bit of common sense here is that "we" are not the only customer of Invensense, so likely another larger volume customer asked for that change. 3DR has become a high(er) volume customer so maybe it's just one of those things somebody missed when getting large batches of parts, especially when Invensense might be running close to capacity thus supply is low and whoever is in the supply chain shipped what they had.
That said, it's NOT DEFECTIVE, and it's not nearly as big a deal as you are making it out to be. We are now aware of the revision and needed to add simple switch to the code to detect version.
I need to add, I don't work for 3DR, Invensense, or anybody, I just read this thread and was able to see through the lines what's going on here. You seem to have it stuck in your head we should be shipping these boards back and that's not the case. The reason is that due to volume, Invensense may have changed production for another customer and the new scaling chip is all that we will get in the future and thus community wide, we would have 2 versions of the board to support code wise. And as I said, this has been done rather quickly.
-
Permalink Reply by Jake Stew on
-
Thanks for the response. I'm just curious what actually happened and how it was dealt with. Some people may really care if the chips meet the specs in the datasheet as promised, if they are defective or don't meet specs, or if it is just an undocumented default change.
From your response I'm assuming that the code doesn't properly set all the necessary registers and that an undocumented default register setting change was made that screwed things up. If that's the case I don't understand why we need to detect the chip version since just setting the defaults instead of assuming them would be a better solution.
It's important to know what's going on. For example, if my emergency flight of life-saving vaccines crashed because of a known defective chip or some undocumented settings change (like changing the actual register setting without notification)... guess who would be legally liable for the damage? It won't ever be 3DR since they're making a DIY experimental dev kit basically. But if invensense promises X and delivers Y and that causes loss of property or life then they're 100% liable.
If I was a corporate customer I might care more, but even as an experimenter I like to know what's going on. I don't really see why things need to be cryptic and it makes me wonder what is going on with 3DR. Do they know the exact cause and don't want to say or do they not really understand what happened?
Social Networking
Top Content
Contests
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.A list of all T3 contests is here.
Groups
-
ArduPlane User Group
677 members
-
ArduCopter User Group
1284 members
-
Moderators
24 members
-
Queensland
4 members
-
Taiwan ROC ArduPilot Gro…
8 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
