Version 2.6 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!


Updates to MavLink 1.0 means you will need to use "ArdupilotMegaPlanner10.exe" to connect.  If you've updated your mission planner recently you should find this executable in the directory where the mission planner is installed.


The above video is done using a prototype 3dr ublox GPS which seems to have better accuracy than the standard mediatek.


Improvements over 2.5.5 include:
     - MavLink 1.0 support (use with ArdupilotMegaPlanner10.exe) [Tridge, Craig]

     - Stability improvements especially during level hover [Jason]

     - throttle range improvement (higher min and max) [Jason]

     - improved standard Loiter PIDs [Alan, Heino, Jason, Angel]

     - dataflash erase speed up ('+' messages removed but it only takes 6 seconds now) [Tridge]

     - Copter LEDs [Robert Lefebvre]

     - RTL loiter stage target set to home to improve final landing position [Jason]

     - flip & acro improvements [Jason]

     - circle mode target improvement for ground station [Jason]

     - Auto Approach [Adam Rivera / Marco]


Bug fixes include:

     - UBLOX driver fixes (lock should now be more reliable) [Tridge]

     - enable mavlink messages during dataflash erase which resolves issue in which new APMs fresh from the factory appeared unresponsive [Tridge]

     - proper printing of lat/lon values in dataflash logs [Randy]

     - removed duplicate GPS reads [Jason]

     - resolve flooding of telemetry link with low-battery warnings [Tridge]

     - RTL bug would land if rtl_approach_alt was more than 1 [Jason]

     - WP Radius could not be set larger than 1.3m [Jason/Randy]


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.

This time we spent some time optimising the loiter PIDs.  Tuning loiter can be tricky so please refer to the discussions which will appear below for more community feedback on what parameters work best.
All feedback welcome below.  Enhancement requests and bug reports can be put into the arducopter issues list.  When possible please include logs (tlog and/or dataflash) and tell us whether you're using APM1 or APM2 and what version of the software you're using (presumably 2.6 but tell us anyway!).


Happy flying!

Views: 64384

Reply to This

Replies to This Discussion

Also, I believe Auto Approach is new in this release as well (courtesy of Marco and myself).


     Oops!  sorry about that.  Added above!

yeah! soldering and testing boards for customers right now! this will be a lucky one!
pushing 2.6 on this one for tests! happy!!!

Will try to give it a flight test this weekend and report here as usual.


It sounds like a wonderful set of enhancements!  Great Job.  I do have a question...

I'm using an APM 1.4 with the 3DR Xbee kit.  Other than upgrading the planner host software (run the ...10.exe) and uploading the new APM 2.6 code, is there anything else I need to do to get to MAVlink 1.0 support working?   

So far really like the fact that we dont need to wait 45 sec + on initial firmware installation. Formatting the memory card is way faster (or not done) but result if perfect. Board comes alive (red/blue happy flash) right after the waiting period (timer).

This will reduce a lot of calls where people try to connect right after the initial firmware installation and not getting a heartbeat.  Thanks guys! 

Oh and Randy you should tell people what will happen if they are still using mavlink 0.9 (regular MP executable)  is it bad? will they have to redo the setup? 

If it is there should be a check in MP when trying to push 2.6 to say please use other executable... 

Let us know! 


I must have missed this one.. how do I use mavlink 1.0?  I am apparently using 0.9

one more thing... what happened to the ARMED/DISARMED message in the Mission planner? 

Gone? I can arm and disarm (A LED solid for Armed as usual, blinking for not) but MP is not telling me where it used to do it... right in the horizon display... strange.... 

use "ArdupilotMegaPlanner10.exe" instead of the "default" one. It is in your MP directory.

Thanks, Dany. The Mission Planner will alert you if you need to upgrade to the version that supports MAVLink 1.0. An icon for the 1.0 version is automatically installed if you use the new Installation utility

  - throttle range improvement (higher min and max) [Jason]

is that meant support for ultrapwm (min throtle 200us) ?

i just remove xaircraft stock esc, and replace turnigy 18a plush.

my quad is x650 XA frame., stock motor,18a esc, 3s

anyone have same setup, use 2.5.5 version, crash many time when change loiter in strong wind,

- glad to hear 2.6 release.

Reposting here (closing the separate original thread) as Chris A. suggested:

Fly-Away Scare.

Preface: Needless to say, correlation is not causation. The event described here occurred on my first flight with 2.6, but may be found to not be a software problem at all, like many quad issues.

The Event:

I installed 2.6 this evening and took it out to do a bit of close-in, low altitude test flying to see if my tuning was still good, just before it got dark here. Before today, I had been flying 2.5.5 without issues (besides a yet-to-tune loiter). This first flight with 2.6 went fine too, until...

...a few minutes into the flight, while I was in Stabilize mode I think, the quad suddenly started accelerating vertically, climbing away. I zeroed the throttle, and jumped into Land mode, but got no reaction. I was flying next to a tree, and the quad lodged itself high in the tree crown, preventing a total fly-away. It hung there, props spinning at high throttle like a weedwhacker, for a very-long feeling time (maybe a minute), until it came loose, tumbled down and smacked in the ground.

I flipped through my modes and wiggled the controls while the quad was in the tree, getting apparently no reaction, but I did not have the presence of mind to try to disarm it. (Note to self: remember to disarm.)

A couple of broken legs, a set of chipped props, a few popped screws and a broken cheap camera mount seem to be the only hardware crash damage - not a problem, thanks to the 3DR frame engineering. As a positive side effect, it was good to experience that my heart does not actually stop in this type of situation :-)

In my flights over the last few weeks since building the quad, I have not experienced any unpredictable behavior, scares or radio problems. The props were balanced and the battery had plenty of power.


3dr-b frame, 880kv motors, 11*4.7 APCs, APM2, 3dr radio, sonar, optical flow (not tested yet), 4s1p LiFe 4200mAh battery, DX8 TX, AR6210 RX with satellite, DSMX.

I am attaching the log. It gets interesting just after 90% / 600s in the .tlog, and at line 13930 in the .log



Graphing the log myself, I see that the rc inputs go flat a couple of seconds before the unexpected climb starts. This might indicate an RC connection failure, followed by what looks like a behavior similar to the rtl-failsafe for Auto mode ("Climb!").

I wasn't in auto mode, though, and I don't have that failsafe mode enabled.

While the quad was in the tree, I power-cycled the TX, and that does not show in the RC inputs, also indicating that the RC connection may have been lost. I'll have to compare these frozen rc input values to my RX failsafe settings.


Hi Knut, 

I looked over the logs for a while and can readily pinpoint the radio loss. The set point of the throttle was just high enough at the loss to cause the climb.

Signal loss would be one explanation. Do any channels change on your radio for failsafe? that could rule that out.

A signal wire could have a short causing the PPM encoder to stop reading and outputting a constant set of last good values.

Can you look over things and see if you can reproduce it?


Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service