APM 2 gyro (scaling?) issue || RESOLVED
UPDATE 2: This thread is now obsolete! If you're having similar issues to what's been described below, please, report it in this thread.
UPDATE 1: It's now confirmed that there's been a bug found and that it affects some or most of the later production batches of APM2 boards. The bug doesn't affect earlier hardware versions -- only some of the APM2 boards. The problem is that some of the earlier MPU6000/6050 chips don't seem to conform to spec and they had different accelerometer readout scale in the 4g sensitivity range than the now-spec-conforming chips. What this bug does is it basically causes your accelerometer reading to be twice as big as it should which on the other hand causes the tilt angles calculated from the accelerometer readings to be erroneous causing the "creeping" of the attitude estimate. This problem if described in detail below.
THE EASY WAY TO CHECK IF YOU'RE AFFECTED: Just connect to your APM2 with Mission planner and in "Flight data" -view click "Status" and check out your ax, ay and az readings. While keeping your board level your az-reading should be about -1000: if so you're not affected! If the reading it is closer to -2000, however, you're affected by the bug..
If you're affected there's a quick and dirty patch below in the comments that you can use until the official update comes around.
-Sami
------------------------------------------------------------------------------------------------------------------------------------------------
Hi,
I finally got my APM 2 a week ago and even flew my quad a couple of times more or less succesfully. However, last evening I finished installing my roll-tilt camera mount to the copter and noticed that after a short roll it takes 2-3 seconds for the copter to converge to the actual position. I then started looking into this matter more thoroughly and after shaking my copter around for quite a while I came to the conclusion that it appears the scaling factors of raw gyro output are too small: i.e. the attitude change given by the gyros is too small for any given movement and after the movement it takes 2-3 seconds for the APM2 to converge on the accelerometer reading. Here's a screencap demonstrating the issue:
What you see in the screen cap above happens every time and even after very slow movements. The problem exists on both the roll and pitch axis on my APM2 and makes the autopilot absolutely useless for stabilizing my camera mount as the error can easily be 10-20 degrees plus whatever lag the servos themselves induce.
Is this normal behaviour for APM2? If not what can I do about it?
Oh, and I'm on Win7, and ArduCopter quad 2.5.4. Log file demonstrating the issue further is attached.
Tags: ahrs, apm2, gyro, imu, problem, quadcopter
- Attachments:
-
-
2012-05-05 13-30-16.tlog, 438 KB
-
Replies to This Discussion
-
Permalink Reply by Sami Finnila on -
RESOLVED: Found a bug with the accelerometer scaling! The MPU6050 is set to 4g scale which means 8192 LSB/g but in AP_InertialSensor_MPU6000.cpp the scaling factor is 4096 as if the sensor value was being scaled for 8g sensitivity. I changed this scaling value to 8192 and the issue went away. So I'm pretty sure it's a bug in 2.5.4 and seems like the same bug exists in the 2.6 beta in the Git repository too.
-
DeveloperPermalink Reply by Pat Hickey on -
Hi Sami,
Thanks for your bug report and analysis! I wasn't able to reproduce your issue with my early (sept 2011) APM2 board I used for development, but it is present with my newer production (march 2012) APM2 board. As best I can tell, the sample MPU6000 parts used to assemble the early APM2 boards the developers have didn't conform to the spec'd 8192 lsb/g in 4g mode. I suspect all of the production APM2 boards do conform to spec, but it looks like I'm one of the few developers who happened to have a production APM2 around.
I'll work on a patch to autodetect the scale factor and select the right one, and we'll get it into the next release. Until then you can continue to fly your patched code, and others may do the same.
Thanks for the report, and thank you to others who helped narrow this down as well: Wesley, Roberto, Justin, and Tridge.
Best
Pat
-
Permalink Reply by Matt Gaige on -
Thanks, I have been asking about this for the last 4 weeks and no one has commented on it. Good research. I will try this out.
-
Permalink Reply by Sami Finnila on
-
NP. Just remember that if you make the change it might require you to change your stabilization PIDs a little. I'd imagine that this change will improve the overall performance of the AP but I haven't test flown the updated code yet.
-
DeveloperPermalink Reply by R_Lefebvre on -
I'll do that right now.
They're looking into it.
-
Permalink Reply by Sami Finnila on
-
Thanks. While you're at it I might have some commits I'd like to make to the camera stabilization: I implemented a PD loop to better hold the camera stabilized. After some tuning my 4$ analog servos hold the camera within (+-) 2 to 5 degrees of the set angle so it's a huge improvement to anyone who might want to shoot some video off of their multicopters with APM.
Oh. And I attached the fixed AP_InertialSensor_MPU6000.cpp. It's just one value that needs changing but atleast I'll save you from searching the correct line where to make the change:
- Attachments:
-
DeveloperPermalink Reply by R_Lefebvre on -
Sami, does this MPU6000 file totally fix the issue for you? Wesley did the same thing, but finds that his pitch and roll movements are not perfect still. It still continues to "move" after he stops moving the board.
-
Permalink Reply by Sami Finnila on
-
For me, yes, it's absolutely rock solid. Absolutely no converging one way or the other once I stop moving the board. Just to be sure I've attached the whole project folder. Included is also a crude PD loop for the camera stabilization.
I'll go and test fly the patched version now... Will report back how it went in about an hour.. -->
EDIT: Stabilization works great but one of my props is badly off balance and is causing some rolling shutter effect. It flies well, though!
- Attachments:
-
-
Ardupilotmega_2_5_4_patched.zip, 1.2 MB
-
-
DeveloperPermalink Reply by R_Lefebvre on -
Oh, about your Camera program questions.
I believe the Camera code is being worked on by Amilcar Lucas, and I understand he has a fairly substantial re-write of the whole thing underway currently. So I'm not sure if what you are working on would be used. You're probably best off trying to get in contact with him.
However, in the meantime, maybe it could be incorporated in the main code. Randy or Chris could probably best answer that.
-
ModeratorPermalink Reply by Dean Wynton on -
Tested my apm2 and the problem was there, have downloaded your patch and uploaded via arduino relax. Using the mission planner tuning view it is certainly much more responsive, cant wait to fly and see the difference. Well done!
-
Permalink Reply by Matt Gaige on
-
The file worked well for me. Very quick and no creep
-
Permalink Reply by Andrew Fernie on -
It does seem to be H/W revision dependent. I have one of the first production run APM2 and it needs the 4096 value. Converges very slowly with the 8192 patch. An auto-detect would be great.
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
-
Telemetry over cellular …
249 members
-
Andropilot Users Group
183 members
-
ArduPlane User Group
693 members
-
Moderators
24 members
-
Documentation Editors
51 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
