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

Reply to This

Replies to This Discussion


Is it by any chance possible that the ESCs are powering the wrong engines? This can happen if you have made a mistake with soldering the power distribution board.

What I mean is: example: when you try to lift off, the APM wants to stabilize itself by bringing more/less power to each of the engines. Say the APM detects that the *front-right* motor should provide more power to stay stable, then the APM sends a signal to one ESC to increase power, should be front-right. If the power of this ESC is sent to the *front-REAR* engine... Then the wrong side is getting more power and this confuses the APM which tries to compensate even more, etcetera. If you were to increase power the quad will lift off but immediately flip-over as the power/signal cables are 'crossed'.

Reason I say this is that I *have had* this problem with an *RTF* ArduCopter Quad from Udrones no less! It took me weeks to figure that one out, as I was new to the scene then. They had soldered the power distribution board incorrectly!

My take-off behavior looked very similar to yours in the video.

Try to move all the signal cables to the next motor and see if this helps. This did the trick for me.

It is hard to tell from your logs because you don't have INAV turned on, but I suspect your Thr_accel_P and I terms are too large for your frame. I would reduce them to 0.5 and 1. I would also drop the INS_MPU6K_FILTER to 20 to minimize the impact of noise on your system.

Did you think that was a subtle way of dumping on the APM platform? If you arn't willing to look for examples you won't find them mate!

Is there somewhere I can read up on how to properly tune these two parameters?  I think I have a pretty good understanding of almost all the others but I do not understand these two.

I do have difficulties to differ all the logs, with just a number start and number end. No time stamp.

Every time you "erase" the accumulating number of logs restarts.

Any good advise to process logs an easy way. I am renaming all the time to have more control with my log archive but a lot of work.

I have enabled more or less all log parameters. Does this steal performance of the system? Where are this logs stored? How big is this memory, what happens when memory is filled up with logs? FIFO?




I have been seeing problems with one of my quads, I have 3 with APM2.5's on them. One I have sonar, OF, telm (the works on) the other I just have wireless telm and gps.  the one with little on it is giving me weird problems, I am not sure if it is 2.9.1 because I just built this one with new esc's and a new frame.

What happened today, it flew well, or pretty well, it is not near as stable/smooth as my other arduquad (which looks like it is sitting still in the air, it is awesome) but it flew pretty well, I tried alt hold and loiter, both did pretty well. After watching Marko's videos,  I got in this habit of testing loiter by yawing fast in both directions to see how well it holds position. First thing I noticed is it didnt stop yawng as soon as I let off the yaw stick, next thing I know it is yawing on its own, I switched to stab mode and it was still yawing on its own.. I am not exactly sure what happened after that but I got it down safely, but with a couple pieces missing :).

I did repairs, and went out to fly again, same thing happened.  after that I took my other quad out and tried it with 2.9.1 and it flew like champ.

If someone can tell fro my logs what, or where my problem could be coming from, please do.  I am suspecting the esc's or at least the 5v's regulator from them.  but I am not sure.  I have gone through the log but I just dont understand enough to know where the problem is from.

thanks for any help,



First I'd like to thank the entire development team for their efforts.  I am fairly new to the Arducopter community only recently completing the build of my first quadcopter (APM 2.5, 3DR 900 Mhz telemetry, 3DR uBlox LEA-6 GPS, XL-EZ0 Sonar, 1100KV motors w/11" props) and have been running 2.8.1 since it was introduced.  Last week when 2.9 was released I followed the recommendations to add vibration dampening of the APM 2.5 controller to get ready for 2.9.  I then loaded the new release and after setting everything up very quickly thought I had an issue with my sonar as I wasn't getting the normal altitude readings I was getting with 2.8.1.  Upon further reading of this thread I now see that this is because of the changes made in 2.9 and the way it handles the sonar reading to adjust the altitude value.  

My question is this...  How do you now validate that the sonar is functioning properly if nothing in the Mission Planner shows the direct impact of the sonar sensor reading?  Would it be a good idea to add support in a future release to show the current distance being read from the sonar somewhere in the Mission Planner HUD (in addition to showing the altitude)?

Thanks again for all your efforts.

"Front-REAR" ?  Yea, that would flip...

But he did say that the CLI Motors command presented the correct sequence and direction.

I had a prop on upside down once.  The hex flew, but reluctantly.  And it made an awful "lawnmower" sound.

Ken...If you use the terminal (CLI) and wait for the prompt, you can enter the word "test" (no quotes). At the next prompt, you can enter the word "sonar" (again, no quotes) and the terminal will stream your sonar distance readings. You can see the height changes in cm. BTW, my build is identical to yours from an electronics point of view - 1100 kv, 900MHz, GPS, sonar, etc. (mine's a hex, but our experiences should be close), I would like to know how your 2.9 testing comes out...Jeff

Jeff... Thanks for the info.  I still think it might be a good idea to have this data available in the Mission Planner "Flight Data" screen somewhere (maybe on the HUD or adding a guage).  When I originally thought I was having an issue with the sonar in 2.9 I ended up reloading my APM with 2.8.1 and restoring my settings.  I will be moving to 2.9.1 shortly and will let you know how my testing goes.  Thanks again for your help.  - Ken 

I noticed something strange with the sonar enabled. I'll try and get a log of it. Basically it holds altitude great and then does a sudden dip like there was a quick power outage. It then recovers and bobs up and down for a couple seconds to get back to where it was.

This happens after a minute or so in altitude hold, either just hovering or flying around. Doesn't do it without sonar.




     I'm pretty sure you'll find that you're getting spikes in your sonar data.  We use a "median" or "mode" filter in the code to try and ignore these but if two in a row arrive then it'll be fed into the contoller.  There's some good advice on the wiki about placement of the sonar and a link to the maxbotix recommendations about adding a cap, resistor and shielded cable to reduce the EMI (electro magnetic interference) from nearby electronics.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service