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

Reply to This

Replies to This Discussion

Hi all,

just got back from field with broken tricopter ;o(

loaded v2.6 (slightly modified for LEDs, others untouched) and tried only basics (STAB, LOITER, RTL, AUTO, RTL ...)

When switched from RTL to stab copter seemed to not respond and gone away. I switched back to RTL but didn't help and copter fall down in the field. Luckily I found it ;o) (only broken arms and props). From logs I can see the roll (yellow curve) got crazy right before the copter fall down (around 7250).

Can somebody explain whats going on from log? (log attached)


For X8 coaxial quads using APM1, how do the channels out put the signal for yaw? The props on each arm in normal flight counter rotate at the same speed. However for Yaw to work the speed for the two props would have to be different correct? Can someone explain how this is configured for the 8X quad and what the props are doing for yaw?

When I dug bit in log file I found mag heading - went too high. Can somebody explain me what mag heading is (what units it is)?

I have not been able to find anything no how Copter LEDS works in terms of wiring.

I am new to APM/ArduCopter, I have APM2, I can read code (mostly debug, not so much write unless in VB6 :P).

I plan to take a look at the code to see what outputs you use, but even then I am not sure I will be able to figure it all out. I am also fairly new to RC stuff, so that gives me more things to lookup at times.


I think that a Wiki or at least MSPaint would be great. Even a quick one that can be added to later.


Yes the wiki on CopterLEDs could be more complete. Now it references a blog. I would also like to hook them to my APM2 but need to study where the connections are on APM2.

F11: Good point. I can give you wiki access to make those changes. Please just PM me with an email address linked to a google account. 

I've made it work with the APM2. Start here:


and then a check the code for 2.6 found that some of the analog ports are assigned to COPTER_LED

#define COPTER_LED_1 AN4   // Motor or Aux LED
#define COPTER_LED_2 AN5   // Motor LED or Beeper
#define COPTER_LED_3 AN6  // Motor or GPS LED
#define COPTER_LED_4 AN7  // Motor LED
#define COPTER_LED_5 AN8 // Motor LED
#define COPTER_LED_6 AN9  // Motor LED
#define COPTER_LED_7 AN10  // Motor LED
#define COPTER_LED_8 AN11  // Motor LED


My own experience was that AN4, AN6 and AN7 were functional for the LEDs and that AN5 didn't work, but it's probably because I didn't enable something that needed enabling.

Interestingly, AN10 and AN11 are also assigned to camera gimbal functionality (which I use) so I've stayed away from testing the LEDs on those ports.


I've got three strands of LEDs (R, G and W as Nav lights) and they work as advertised (slow flash when disarmed, solid when armed). Haven't tried the battery warning yet, since I've got Frsky telemetry telling me that on the transmitter.



I take it those velcro straps are to mount the batteries and on is on the top and the other along the back ?  The one on the top particularly would be a concern  to interfere with the gps and probably even the gyros. Try a different mounting for the batteries where they are under the frame just to see if that is the problem

I'm running a tricopter (2.6 with Robert Lefebvre's yaw control branch) and am finding that my yaw servo will jam hard over to the right when disarmed, and today this led to the servo burning out. I only have one more of these servos on hand, so I'm quite keen to modify the code so that this will not happen again.

I see in another thread from late 2011 (here) about the same problem, It was mentioned that modifying radio.pde, and in the function void output_min() changing a line  APM_RC.OutputCh(CH_7, g.rc_3.radio_min); to  APM_RC.OutputCh(CH_7, g.rc_3.radio_min + 300);


However it seems in 2.6 the function void output_min() only contains the following:


void output_min()

Is there something I can place in this function to limit the travel of my yaw servo, and if so, what should the line of code be? If I added APM_RC.OutputCh(CH_7, g.rc_3.radio_min + 300); within the function, is this still the correct syntax to have the desired effect?


Glenn, I had a look at your issue.  No, you can't just add that function in output_min();  It has to go in the motors class now.  But, it's a pretty easy fix I think, and here it is:

So grab that, and give it a shot.

If you want, you can also try:

_rc_yaw->radio_min + 300



The second option there will actually make the yaw servo move just as if it was in flight. That is what we do on Helicopters, I actually sort of like it.  I'm not positive it will work the same way on Tri, but there's a good chance it will (I don't have a tri to test).  Give it a shot, disconnect your servo rod.

Let me know which you like better, and I'll push it to trunk.

Thanks for your legwork, it actually made it really easy to find the problem.

Excellent, thanks so much for this.

I've just loaded that in, and it works like a charm. It really feels like this thing has ninja precision and control now! Hopefully my servos will begin to live longer lives too.

For those of us who don't have the means to build this, any idea if and when the fixes will be released in the mainline code?


Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service