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

Reply to This

Replies to This Discussion

Forgot to mention I was flying stabilize.  Params listed below



I had a similar flip in stabilize mode after about 30 seconds of flight or so.  Not sure why.  Logs show that it was uncommanded.  See my post below

Thank you.

the motor are smoother and with less vibrations.

Really a big diference!

The 2.4 zip file in the downloads section now includes the patch that fixes a momentary code freeze at GPS lock, which may account for some of these glitches. The dev team has tested and is not seeing any remaining issues, but as always we welcome more brave beta testers checking it out before we release.  

Dave, when you takeoff are you sure to have the fix with the gps?
I've same flip Saturday with my X8, two somersaults (is heavy lol).
Very nice demo video, I like it! :-)

ArduCopter V2.4 - Loiter and low passes - Heavy X8 Coax:

My daily video, with the latest fix of GIT, Loiter mode and low passes at medium speed in Stabilize with my X8.


By the way - turn the volume up at 2:30. At 2:34 Robert, an enthusiastic audience member just can't contain his excitement. :)

Here's pitch vs gps lock graph of the flip.

As you can see I decided to take off 'just' after gps lock was aquired and had a rather unexpected pitch reaction. 

Only happened once in 7 batteries though, doing nothing different. The flip happened on my first fly after a FW upload. Took off at least twice more (did it twice on purpose) without GPS lock just to try it (low, slow flying), no probs.  A cold restart (batt lead out and in) was all it took to fix. It seems, as previoulys mentioned, it's only after the first upload that this can cause a prob, but that's my amateurish speculation ;))


Great to see the beast in the air again :)

That's a great performance for such a big bird! Very smooth, lovely loiter.

Have you tried low passes on the quad yet? I'm curious, will give it a go tomorrow.


     Sorry to hear about your crash, glad it wasn't really serious.  This is the same bug as reported by PACEFE yesterday in which the first GPS lock was freezing the APM for 1/3rd of a second.  This bug has been fixed in trunk and the latest code also put in the downloads area (as of 3 or 4 hours ago).

     You can see the telltale signs of the issue in your log file at lines 8932 and 8935 as two GPS messages both with the same time value.  Normally the time value increases by 250ms with each GPS update.  Also note that there's no ATT message between the GPS messages...this is essentially telling us..oops, it hasn't tried to do any attitude control!  Amazing that a quad can flip if it loses control for just 1/3rd of a second.

     Anyway, this particular bug is fixed now so you shouldn't see it again although actually there's still a delay of 70ms after the first GPS lock as the home location is stored to the eeprom.  If you look closely you may still see a small twitch when this happens but it's short enough that it won't cause a crash.

Thanks for the detailed analysis and explanation!  That's what I get for not reading all 80+ pages of comments :).

The fix seems to fly fine and no more flipping.  Can't wait to try it in a larger than area than my backyard for some real tests.

Hey again everyone.

Quick quesiton, I loaded 2.4 to my big octo yesterday, and the tune function did not work correctly, kept tuning between 0 and 1, not at 4.0 up and down as it should and does with 2.3, I reloaded 2.3 and then noticed the same GPS glitch, when it detects home, get an odd twitch in the air, not cool. I see this is now sorted with 2.4, but again, I use tune 1 for normal flying to tune stabilize for different styles, smooth camera moves, more rigid stab for stills etc.

Has this been sorted in the final 2,4 in MP ? Anyone else having trouble with tune ? ( I did try upload new firware twice, still had the tune issue)

Reply to Discussion


© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service