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: 298240

Reply to This

Replies to This Discussion


     I think your self-diagnosis is right on the money that it's a mechanical issue.  As you see the copter's Roll does not match the Roll-In so basically it's not doing what the controller wants it to do.  If it was sensor or controller fault or bug then you'd see the two sticking together but the desired roll (i.e. Roll) would flip over as well.

     The Roll looks a little over tuned so I think you should reduce your Roll Rate P a bit.  The Pitch P looks a little weird in that it seems unable to reach the desired pitch ever.  I think the cause is that your Rate Roll/Pitch I terms are very small.  0.0001 vs the default of 0.1 for quads, hexa, octas.  Maybe you should try increasing this quite a bit..

thanks.. my main suspect is a bad performance simonk-ed redbrick 20a esc.. i don't know why i'm still using this escs, this is my 3rd crash because of esc problem..

1st crash, 2.8.1, stock esc fw, esc overheated..

2nd crash, 2.8.1, simonk-ed, put esc under the prop wash, and extra heatsink

in conclusion, red brick esc is not recommended for multirotor..

i've ordered hk F-30a and i'm to lazy to do flashing, i'm going to stay with stock firmware... is anyone know what configuration is best for apm, such as timing,  pwm freq, start-up ?

for the PIDS, i'll tune more PIDS after my new f30a escs arrived..

as for the pitch, i suppose it was a CG problem.. with extra tilting mechanism and servo weight..

I flashed the PPM with the latest firmware and turned down logging, switching off MOTORS, RAW and ITERM. I reset the compass offsets to 0 and re-tested. Land works perfectly now, both when requested as well as forced due to low battery. Unfortunately I changed a few things so not sure which one or combination of changes fixed the problem, but I suspect the logging because there were no glitches at all while flying in stablise or alt-hold modes.

The compass offsets are still pretty bad so I need to move the APM further away from the PDB or put shielding between the PDB and the APM - any suggestions for shielding or is the only answer to move the APM up an inch or two? The vibration is low, so I don't really want to move the APM if it can be avoided.

I'll try some more flights today to confirm that land is perfect (it was fine yesterday too when the battery failsafe forced auto-land, just requested land was bad). By the way, the 'lurches' yesterday were while the copter was well off the ground - maybe 2m high and quite violent - standing (close) behind the copter when it suddenly pitches up and heads towards you is a bit scary :-).

I won't have my laptop with me at the airfield so cannot try with logging turned back up, but hopefully tomorrow evening that will be the next test.

Thanks again for all your help and hopefully I can figure out the root cause of the glitches over the next couple of days.


     Excellent news!

Thanks for the reply. So the baro drift correction is only in the airplane code and not the multi-rotor code. It would be a nice feature to add some sort of drift correction to the multi-rotor code. Maybe a temperature correction would solve the drift problem. Has anyone attempted to do a temperature correction to stabilize the altitude sensor?



The temperature correction of the read out baro pressure is done several times a second already :).

The easiest way to test this is hover in stabilize, then rotate  (max stick) left, then rotate (max stick) right, if it rotates one way much faster than the other then you know the APM is compensating for some misalignment.


Again, thanks so much for your help. Good to know in case it happens again.

Thanks Randy.  I enabled the MOTORS log and took a series of short flights.  Hopefully this will help with the assessment.  I can't quite figure out yet, (although i'm getting better at reading the logs), how to determine if the APM is sending the left rudder signal to the motors in an expected normal manner and if it's the motors not responding correctly or if it's the APM not sending the correct signals to the ecs/motors.  Essentially, i'm trying to figure out from these logs if the prob is the APM or the esc/motor(s) so I can hopefully rule out the APM being the problem.  

I'm also having a look at the compass offsets but hadn't done anything to them yet when taking these test flights.  I'll look at that today...




General question:  Have we seen many damaged APM boards due to high G-Force landings/crashes?  I'm curious if any of the components (accel/gyros) can be damaged by excessive g-forces if the physical integrity of the board isn't damaged (as in my case).  Since those aren't logged by default, i don't have any insight into how hard the crash was.  Do they have a published rating?


I have been away from arducopter for a year and just picked up a couple apm 2.5 kits. Put one on a dji flamewheel hexa frame, and the other on a flame wheel quad.

All i can say is WOW !!!!! Amazing work and congratulations to the development teams . The multirotors flew great with stock pids and perfectly followed a 7 WP course . Simply awesome!!!



Thanks Peter.  If you're interested, take a look at the vids and log i posted to Randy's response.  I put a pic of my setup as well.  Basically, at this point I can't even hold a stable flight.  You may notice i'm having to put forward elevator and right aileron just to keep it from coming back at me. That may actually be as much of the problem as the rudder issue.  I've calibrated the accelerometers and will do it again now to see if i can at least get stable hover so i can isolate the yaw issue.  Thanks for the comments...

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service