ACRO bug (fixed in 2.9.1b): while doing flips in ACRO mode, if you switch to Stabilize while inverted your throttle will go to minimum.  To regain throttle control you need to switch back to ACRO then back to Stabilize again (i.e. switch to stabilize twice).  You never lose control of roll/pitch/yaw.

Loiter/AltHold/Auto/RTL bug: if you switch into these modes with throttle at zero motors will go to minimum until you raise the throttle.

Auto mode altitude bug (fixed in 2.9.1b): setting a waypoint altitude greater than 320m over home altitude may wrap around and instead be interpreted as a low altitude.

ArduCopter 2.9 is now in the mission planner and the downloads area!

The major improvement is we use inertial navigation to improve altitude hold.  This increased reliance on the accelerometers means you must do some additional set-up before flying:

1. Perform the new accelerometer calibration in the mission planner (video).  The auto-trim metho has also changed (video).

2. Add vibration dampening foam between your frame and the APM.  Some suggested materials: DuBrogelhk foam.

 3. If upgrading from 2.8.1, modify the throttle and altitude PID values:

  • Increase your Throttle Rate P, reduce I to zero, increase D
  • Increase Altitude Hold P, reduce I to zero
  • Tune Throttle Accel P and I terms but try to keep P about 1/2 the size of I


Here is the list of major changes (a more detailed list can be found in the release notes):  

  • Alt hold using inertial navigation (Leonard, Randy, Jonathan)
    • AUTO_VELZ_MIN, AUTO_VELZ_MAX parameters control the max climb/descent rate for the autopilot (cm/s)
    • PILOT_VELZ_MAX controls max climb/descent rate for the pilot (in cm/s)
  • Landing improvements (Leonard/Randy).  Copter will descend to 10m or until an object is sensed with the sonar.  Then slows to 50cm/s descent (speed can be adjusted with LAND_SPEED parameter). (video).
  • Surface tracking with sonar (Randy/Leonard).  Copter will attempt to maintain current distance from objects in front of sonar regardless of altitude.  Only used in alt-hold and loiter, not used for missions.  Sonar can be enabled/disabled with CH7 switch. (video)
  • Failsafe improvements (Randy/Craig/John Arne Birkeland) including bug fixes, additional check for PPM encoder failure and implementation of battery failsafe.  Set-up instructions are here.
  • Mediatek gps driver accuracy improvements and use of SBAS [Craig].  Instructions on upgrading your mediatek to firmware 1.9 are here.
  • Traditional Heli improvements (Rob) including (a) bringing heli code back into the fold, (b) enabled rate controller (previously only used angle controllers). (c) fix to rotor speed controllers - now operates by switching off channel 8.  (d) allow wider collective pitch range in acro and alt hold modes vs stabilize mode  (e) bug fix to allow collective pitch to use the entire range of servos
  • Acro trainer (Leonard). Copter will return to be generally upright if you release the sticks in acro mode.
    • ACRO_TRAINER : set to 1 to enable the auto-bring-upright feature
    • ACRO_BAL_ROLL, ACRO_BAL_PITCH : controls rate at which roll returns to level
  • Camera control improvements (Randy/Sandro Benigno):  (a) AP_Relay enabled for APM2  (b) Trigger camera with CH7 or DO_DIGICAM_CONTROL command  (c) Allow pilot override of yaw during missions and fixed CONDITIONAL_YAW command.
  • PPM sum support for transmitters with as few as 5 channels (Randy/Tridge/John Arne Birkeland).
  • Performance and memory useage improvements (Tridge).


As per usual PIDs are optimised for the 3DR/jDrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.

Special thanks to our testing team lead Marco and the dedicated bunch on the 2.8.1 release thread who put their copters at risk while testing the pre-release version.  Some of their videos are here: 1 2 3 4 5 6 7 8

Please feel free to report issues you find in the discussion below and/or add them to the issues list.


Views: 298480

Reply to This

Replies to This Discussion

ํYes, tx/rx only.

Thanks for bearing with an Arduino newb guys. I have no idea exactly where Arduino was pulling libs from, but I cleaned up stuff to the way it was a few days ago (as per Chris' setup instructions) and all is fine.

Oh my. Does this imply that mag declination will always be correct then, no matter if you drive across country?

I finally upgraded from 2.8.1 to 2.9.1.  Stabilize worked good.  RTL did not work well.  The quad rose a little bouncy when I first switched to RTL (with 2.8.1 it rose smoothly).  The the big problem came, as it approached the launch position it yawed to the right more than 90 degrees.  I tried again with the same results except this time the yaw was to the left.  It was late so I only had two attempts with RTL and I haven't looked at the logs yet.  FYI, when I upgrade, I always do a erase and reset.

For another datapoint, I often have the the comport error problem.  Often times it is after I've been connected in the flight data, planner or configuration screens.  If I go directly to the terminal, I get the error.  If I click disconnect and go to the terminal I get the error.  What I normally do is to close MP, restart it and go directly to terminal.  It has been this way for me for many version of MP.

Thanks a lot Randy. Appreciate your time.


My COMPASS_OFS_X, Y and Z values were quite large. Infact the Y was 342.44 which is fairly large. Does this increase with magnetic interference by wires motors etc? I reset them to 0.

Compass Learn is set to 1.

The declination was 0. I am assuming this is ok...

The trim values were 0. will reset everything and try again and update you.



Hi Pablo,

I have a very similar setup (hardware) and a homebuilt frame as well. Mine yaws too, but was able to resolve that as follows:

- move the APM away from the power distribution board.

- move ESC's away from the APM.

- and most importantly: use compass calibration based on log files. The log file I used was a very short log file in which I made sure that I was taking off, hover, then rotate the copter clockwise in a slow movement and again in fast movement. Then do the same counter clockwise. Then load that log to calibrate the compass.


Hope it helps for you too!


PS: this was in 2.8.1 and I suspect I need to do the same in 2.9.x. Just waiting for the weather to warm up.

Yesterday I had a really weird thing happen with 2.9.1rc2... actually 2 weird/bad things. I already dug into my logs and brewed some conclusions, but I wanted verify with the experts before continuing.

First, I was loitering in a hover and it randomly pitched hard to the right and back. I attempted to correct giving full forward and left stick with no apparent affect. It happened so quick I panicked, and forgot to switch to stab and punch the throttle for the save. Fortunately I was only a few feet up when it happened so it didn't go too far before crashing in the grass. Upon reviewing my dataflash logs, it's clear at the moment of departure the nav control was reacting correctly to GPS location, but for whatever reason the GPS location went the opposite of where the quad actually traveled. Is it possible for a bug in APM to cause a misinterpretation of GPS data? The departure happens @3:30 in the video... I attached the dataflash log and KMZ for visual aid (flight 1). Unfortunately I didn't have ATT on, but I think just GPS and NTUN tell the story well.

Second, I had a problem with the motors cutting off briefly when switching to loiter during an aggressive descent in alt hold... don't ask why, we were quad racing that's why. My strategy, just like I pulled off on top of the hill @7:00, was to come in fast in alt hold, then switch to loiter over the LZ, and drop straight down. Obviously that landing at the finish line was lower and more rushed than the one on the hill; I had to make up time after "over climbing" on the way to the hill. I held "throttle off" during the switch from alt to loiter, assuming there would be that usual burp in throttle, but not quite a "motors off roll" like what happened. If the motors didn't cut off for that split second it probably would've landed safe. I have my pilot max CR set to 300 and auto max CR to default (+-125). I also increased my waypoint max speed to 6m/s. These settings have worked flawless with auto and slow/tame loiter use. My theory is loiter tries to correct alt and xy position at the same time. I came in hot on all 3 axis, and loiter responded strongest to the direction of highest velocity. So instead of toning down the pitch to stop and leaving some reserve power to control the fast descent like I wanted it to do, it lurched over to stop the xy movement first, and ran out of altitude before it could right itself and correct the descent rate. This is seen in the video @7:30, and I also attached a log (flight 8) in case someone else can come to a different conclusion. Note how the altitude drops right past WPalt when the motors shut off; again sorry for no ATT or motor data.

The second problem is probably something I can fly around... mainly avoid "hooking up to loiter" so low, or at least not without slowing the descent and velocity first. I hope 2.9.2 INAV will fix this behavior. The first problem though, I sure do hope that is just more of my bad luck, because that incident really hurt my confidence in using GPS guidance at all with APM. Shame, because except for this incident it was about as close to perfection as I could ask.


Guys I did the new calibration and I see my Yaw 330 degree is this normal or it should be 0?


I value is 0 except the yaw

Awesome, just did the same :)

Header is 100% on my desk now.

Reading this info so many times in wiki, but now i did it. Perfect!

Hi Randy,


This is what I did.. As I told you that my COMPASS_OFS_Y was way too much, I reset COMPASS_OFS_X, Y and Z values to 0. Enabled the COMPASS_USE and the yaw drift i spoke about was gone. However, the COMPASS_OFS_X, Y and Z values rebuild and Y built upto -107 whcih started the yaw a little again. I am afraid that with time as the OFS will build more, the auto yaw behavior will come back

I also did auto Trim and my HUD became offset. The horizon moved up (as if the quad was going nose down) I reset using action- preflight calibration, but that reset my AHRS_TRIM_X, Y, Z to 0

Is this a bug?


I am attaching my logs. Please suggest.


My question is this then, on a 450 or 550 size frame, how does DJI get away with it on such a small area?

Posted screen shots of my GPS setups and using foil to block the mag interference, but with the latest FW, while sitting still on the bench, my Artificial Horizon is jumpy.

Now on my FW450 frame, the APM 2.5 is on the dead center, bottom tray (Just like the NAZA which never had an issue)...Is there just not enough room on a 450 frame? I've never seen a UT video of a FULLY stuffed FW450 frame with telemetry,the power unit, etc that is flying perfect.

My loiter is drifting like crazy, which is evident of noise entering the APM. However, the same exact frame, I ripped the NAZA out of flew silky smooth.

If people want to get in and start commenting, and saying how great their setups are flying.. then I have one thing to say..

You know the rules!!! "HOST THEN POST".. cause I'm not seeing many of these phantom great flyer setups configs on here.


Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service