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

Reply to This

Replies to This Discussion

Thank you jean louis, hoping the weather will be good for you!

ArduCopter V2.4 - Angle problem at high speed:

Wonder if someone can confirm this behavior: move the quad with an angle of 45° and mantain nick in that position do a great accelerated, with close to full throttle(90<->95 %).
A few seconds later I no longer takes the corner and a backward stroke, may be seen in the video.
When my X8 "throw back" is not me, it's all him, at that moment I keep a constant angle of nicks.

Does anyone have similar problems with 2.4/2.3? Thanks...


Yes James, is possible...

im still trying to get to the bottom of it, and with "real life" things to deal with for a week or two not making any progress this weekend.

thus far i have set stab_d to zero and this seems to have improved things a lot, but i still have a lot to test to clear up exactly whats happening.

My guess is that for Marco's situation it's engine saturation.  The copter is being given nearly full power and it's also leaning over so this will make the "angle boost" kick in (this is a feature which adds more throttle if the copter is leaning over to compensate for the loss of lift and helps it maintain a steady altitude).  I guess this could cause one of the engines to reach it's maximum and stop the copter from being able to maintain it's attitude which leads to the temporary levelling out..

I could easily be wrong however, it could be I term build-up or something so I think Marco's going to try and turn on the "motors" logging so we can dig into it more.  It's an interesting behaviour!  :-)

Johann, I do not think they have run tests on that configuration, so watch out!
I have dealt only tests on X-Quad and X8, and those I can guarantee that I have not encountered major anomalies.

Hello Marco,

May be that you have a bit too much integral in Stabilize ?


STAB_I and RATE_I are "0" on my X8 (at the moment).

Damn, Mea Culpa, Mea maxima culpa ;-)

After a good night sleep, and a little bit of tinckering, I restarted this morning with my problematic setup of 2.4

I reloaded 2.4 through arduino 1  relax and then did the setup with MP.

I did the hand test and to be honest it wasn't responding correctly to the tx inputs. It didn't feel right.

I thinked about it because the quad seemed to go in the direction in which it was held.

And then it strucked me. I didn't configure the modes ....... So it was in acro all the time.

I was so fixated on stab that I thought the modes shouldnt be configured. Thinking that the default would be stab.

So I redid the setup including the modes and eureka. It flies.

And the first impression is that the twitches are gone.


Further test will be for later because I have some family obligations I have to attende ;-(


Thx guys for the help and very sorry for the inconvinience

For this reason there's new motors test in 2.4... :P

Marco, What can the motor test prove when not setting the modes?


© 2015   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service