Jason is travelling this week, so I'll take the helm for the next software release post. 

UPDATE: the motor remapping thing was confusing everyone, so we took that out and returned to the regular motor mapping. That means that APM 2 users with Hexas and Octos should wait for the next version. APM 1 users should be fine with any frame.  

NOTE: Hexa and Octo users: there have been motor mapping changes that may affect you. Please don't upgrade until we can update the documentation to reflect the changes. This should happen by the end of the day today (Feb 1).

ArduCopter 2.3 is now available in the Mission Planner.  This is the next revision of the ArduCopter 2.2B6 code, which is perhaps the most tested code we've ever released (1288 comments in the thread!)  and certainly in my experience the best code, too. 

The default PIDs are optimized for a 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props, start by turning down Rate Roll P (default is 0.14, so start by turning it down to 0.1. In general tune PIDs in 25% steps).

Now that we've got solid code out there, we can turn to collecting suggested gains for standard frames, and a better guide to how to tune PIDs for your unique setups. 

Here are Jason's note on the latest changes (mostly from 2.2B6)

A dampening term called STAB_D has been refined. A D term for all of the Rate based control loops has been added based on Igor's work. Landing for Baro and Sonar has been refined based on JLN's work. A slightly new approach to Loiter and Navigation is being used to try and linearize the pitch and roll for rate control. It tends to use lower gains, yet has a more assertive response in the air.

STAB_D : This is the gyro accretion dampener. This can remove small wobbles during sharp changes in angle commands. Making this too high can have a negative effect in performance and add a memory effect that can cause temporary loss in control. The in flight tuning is ranged so you are just below that effect.

If you haven't noticed before the control loops are in two stages. The first is a PI stage that converts some sort of position or angle error into a desired rate. These generally do not need to be tuned. They are more of a user preference on how fast you want the copter to perform a motion. 

The second stage is the actual PID loop that needs to be tuned for the copter. This converts the desired rate into a motor command of some sort. I added a D term based on Igor's recommendation to the PI's for each rate controller. These should show up soon in the mission planner for the release. I cannot give you a concrete answer for how to tune the D terms, because they each depend on their function such as alt hold or loiter, etc.

Still, the absolute most important term is always the Rate_P term for each loop. Start tuning here.

The default PIDs are in the what flies great for a stock jDrones/3DR Quad with the purple motors in X mode.

Note the Mission Planner does not yet highlight these D terms on the main tuning page (it will soon), but you can find them and modify them on in the Parameters list.

Autolanding should now work well (see video above) and the Tri servo issue is now resolved. 

The code should now compile with Arduino 1.0 (thank, Randy!), but remember that you need to use the "relaxpatch" version of Arduino in our downloads section

[Update: we've reverted the below. See update at the top of the post]

Important for Octo users:

We've changed some of the motor orders for some more exotic airframes. We'll be updating the docs on the Wiki in a day or two to reflect this. Pat Hickey explains:

As before, the hexa plus APM2 motor setup has changed from the ordering [1, 2, 3, 4, 5, 6] to [ 5, 6, 1, 2, 3, 4 ].

The Octa V layout for APM2 is:
6            4
  2        5
    8    1
      3 7
Motors 1 through 4 spin clockwise, and 5 through 8 spin counterclockwise.
Support for roll/tilt camera control on APM 2 should be coming in the next version. Traditional Heli will also be updating to this latest code as well once we track down a memory issue. 
As always, you can see a complete list of changes in the changelogs.

Views: 62199

Reply to This

Replies to This Discussion


I have similar effects on my X650 frame. Rate D is set to 0 and can't get the quad to hover in one place compared to your video with stock frame. It just wonders of in different directions. And I also notice some pulses/glitches. (everything soldered)

I have MT 2814 710KV motors and used 13, 12 and 10" props all with the same result.

With Rate  D at 0, I don't have wobble at liftoff though.....


In my experience: both (and also the stab parameters, so...very complicated).

If you start from a good stable flight and defaults for Loiter and NAV, if you increase Loter_P quickly you get divergences (the bad circles). If you decrease Loiter_P even to 0, you´ll notice no changes. At that moment, Nav_P is dominating.

But really, I don´t know how it works.


I've experienced something similar yesterday, I was testing PID tuning in the back yard, and after some time the quad had a brownout. In the past when that happened it would drop half a meter or so and then regain itself without any trouble. This time it dropped and the started flopping around wildly.

I was lucky, but it could have ended badly very easily.

So I think that whatever is causing the effect, it should be a high priority bug fix. For now i would not recommend anyone to fly with RATE_***_D set to non-zero. 


I was tring to fly ver2.3 this morning without sucess it webbels strongly and flips as soon as it leaves the ground

The configuration that i am using is APM1+GPS+MAG+SONAR (radio configuration STABILIZED, LOITER, RTL)

They way that i am doing the test ;

I am connecting power when the quad is level and wait for GPS lock then i am transfering the quad by hand to the filed which is about 100m away. I am puting the quad on the ground and arm the motors the radio switch is in stabilized position.

as soon as i arm the motor and start ramping out power for takeoff the quad starts to webble strongly and whaen i has a bit more power trying to stabilize it it flips.

is there someting that i am doing wrong?

do i have to have the mission planer and use the configuration  levelup function to set the IMU?

Acro is very useful to recover the quad if you tuning wrong stab pid during flight.
As Dave said MK has a special section to configure the Acro, personally I would like to be always off with my MK because I never had the need to do the tuning of pid in flight.
I agree with Chris that it could be safely removed, but instead should leave a mode, you could call it "Safe" or "Recovery" which is based on sure pid (valid pid before wrong tuning in fly), so that I can somehow retrieve the quad.
The alternative could be a dual-mode for Stabilize,, with two different sets of PID, one for hard flight and the other for a smooth flight.

Hi Marco,

Thanks for the reply. 

Don't apologies for it doing what it did - without you guys, I would have nothing to play with :) This is all part of the fun.

There was no damage to the quad and after the landing, I did a quick check and flew it away again so there was not problem with the lipo (was freshly charged before all of this) and everything was fine.

A question on your code though:

     if(ground_detector++ > 30) {

   land_complete = true;

The minimum value my sonar returns is about 21cm (in reality, floor->sonar is about 10) when it is standing on the floor. Would your code not cause it to stop while still in flight?

I'll post the problem on the list.



Hello Crispin, I did not write that part of the code and there's another section if you have the sonar enable, this is a section only for the baro.
I'm trying to modify the code it to make sure that the engines are disarmed only
if the throttle stick is in a lower position, like some:

    if(current_loc.alt < 150 ){
        if(abs(climb_rate) < 20) {
            if(ground_detector++ > 30) {
            if(g.rc_3.control_in < 100) {
                land_complete = true;
                ground_detector = 0;
                // init disarm motors
                return true;
                etc. etc.

But if you are forced to move the throttle stick to disarm the motors it is no longer a real autolanding! : P
I'm not a programmer but the code is ok in the simulator, i tried with AeroSim.
could be a valuable security only for check if your sensor are ok, that would work even if the RTL has been hired by the encoder ppm because the tx/rx has a problem in flight, in the case landing and disarm motors, in the other do not disarm motors if the throttle stick is not to lower position, but if planted engine part should be very quick to change flight mode and resume the quad, almost impossible.
This does not solve
the problem... :-)

I think it might be a good solution to put a micro switch under the gear, so that when the quad after touching land just switch off the engines touching the ground, and of course will shut down the engines if the sensors will read a really lower altitude.
I personally do not
use the autoland,
i think it is a useful feature in case of emergency only (rx/tx fail).
I think
I'll modify the code for my use so that LAND is engaged only if there's really failsafe (no variation of the throttle stick for the rx builtin failsafe, and the other case the ppm encoder reads a value for throttle failsafe), so once again the home will remain in loiter until I decide what to get him to do.


"Octo of my dreams" ?? :)

Yes, and I've got a wedding in NZ in August - lock up your 'daughters' ;)

Good point, I'm just at the point where I'm starting to understand how my inputs/external forces are dealt with and how to analyse it with the logs. I will try to produce some useful data rather than just comments and observations.

I find it very strange that exactly the same electronics (i took it off one frame and put it on another) behaved so differently. I expected to have to tune it a bit, but having to use completely different controls loops is just weird. I still think vibration has something to do with it, as it seems to be the only real difference between the frames. However i spent 2 hours eliminating vibs from the dji frame, at half throttle it seemed to me that there was little or no vibration being passed to the APM. The mount I've built allows the APM to 'float' on rubber grommets, that are in turn only connected to the frame by anti vibe gel. Its a great solution. I'm sure the ardu frame works even better now I've put my new mount on it too.

Oh well I think I'll stick with APM on ardu frame, its simply fantastic, and slap the kk on the dji, I'm much more likely to require 'crash resistance' using the kk controller ;)

Problem with mission planner 1.1.31 when trying to set up the modes using CH5 i see that it reports in the configuration screen OK and saves the modes but in the flight data i don't see any change of modes although i am flipping the switch back and forth both in armed and disarmed mode.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service