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

Reply to This

Replies to This Discussion

Good catch, Fatih!

I think this serves as another example illustrating the importance of functional documentation (wiki´s), how thoroughly and complete they are written and updated (prioritized).

If a voltage drop can trigger RTL, then this must be explained in all relevant sections (failsafe, RTL, voltage / discharge monitoring wiki´s).

The disturbing fact is: Information that exists in a too much fragmented way (in old forum posts or semi outdated wiki´s) is virtually as useful as no information.

doh!, sorry didnt see it was APM2 :#

Hi Rod,

Maybe "Tail To Me" works similarly as ArduCopters "Simple mode" or  "Super Simple Mode"?

Or is it something else? (really want to know, as I actually have a WM in a box...)

/ Tomas

Hi all, need some good reports about my "motors test" (preview from AC 2.3.1 code), if anyone ranked last GIT want to try please contact me, cool thanks!
It 's simple, intuitive and not dangerous,
is performed with a very low rpm of the engines.
I need test in hexa frame (x and +) , "quad +" and octo (x and +).
I've tested only on with my "X Quad" and "X8 Coax".



Details on "Tail to Me" are pretty hard to find on the web, but it sure seems like either of the above are very close in functionality. Robert hasn't received his Wookong M but should have it soon and we shall find out.

Great find.

So when are the changes to the motor order for a hex going to be released. a couple of pages back someone said it was done but havent seen a update in MP.

Hi Marco,

I would like to test it on my hexa & octo. How can i get this vers. AC 2.3.1 code. I don't have access to GIT.


me too

thanks, marco

Sorry guyz, 2.3.1 is on GIT but only for tester, can't release here now.
My request is for those who are already testing the current version on GIT.
All users can browse the GIT, but for non-experts I recommend to wait the official version, I believe due out soon (this week).

Oh! I'll test anything me :)

I can wait though, having great fun with 2.3 as it is - flight report to follow :)

I've got a quad + though if you want me to 'motor test'

Hi All,

At last I got a few hours to head to the field. Imagine my surprise when the wind was a nice steady 18 mph... gusting to 34 mph, yes that’s nearly 55kph.... To give you an idea the wind was spinning the props quite quickly as I climbed out of the van, see attached windguru data...

What better a day to test out 2.3

Obviously this wasn’t very scientific – I didn’t stand a chance with loiter tuning with the gusts (I almost didn’t stand a chance just flying it) so today’s tests centre around stab and alt hold.

I decided to stick with default settings, a good fair test, slightly reduced stab_p and rate_p for my frame, standard ardu kit.

I have to say this was the most fun I’ve had testing any multi rotor ever!

I’ve never had the guts to fly in this sort of wind but recent playing about with the ardu inspired me. I was sure it could cope and it did! All 6 batteries, heart in my mouth. Imagine the gusts having a similar influence as a friend sliding your trim right from one side to the other, and then any yaw just translates the random effects to a different orientation, scary but brilliant fun.

There were times I had full roll or pitch (40 degree lean) just to hold position, but hold position it did, just sitting there fighting. When the wind subsided to 15mph I could fly about like there was almost no wind, then a gust would blow, the quad would take the lead and lean into the wind, I’d follow with a load of throttle and pitch or roll and back we’d go to nose at the ground position hold again. There were times where even at full pitch it was still getting pushed away (need bigger motors :)) , so I’d let it climb, kill the power a bit then nose down full power at the wind, she would just come scything through the wind ( about 10 foot of the ground with alt_hold set) back home.

All just amazingly stable – despite the ludicrous conditions.

Trying to work out the logs to show the hilarious attitude in relation to the lack of positional movement!

Oh then I came home charged a battery, and crashed straight into a tree in the garden, trying the ‘kill throttle and recover’ move...doh. So part 2 of my day of testing, to cut a long story shorter, I stripped the ardu and slapped everything on the DJI flamewheel frame and despite previous probs got it flying Oh So Lovely. Again DEFAULT params. Although in the vid you will notice a mod for the frame (8 cable ties around the legs) that seems to reduce the ‘torsional twisting’ related vibration in the legs with this frame – wavydavey and Robert take note ;) any way – I’ll let the vid speak for its stability indoors - and now i have a crash proof quad – what with the Tupperware and all - I will of course post this in the config thread. And will be out testing no matter what the wind is doing. If I can get loiter in a 5m box with 35mph gusts I think I may lay an egg. GoPro will be van mounted soon for outdoor vids.

Oh and in case you are wondering, I am blissfully aware of the capability of this platform beyond just  stable flight and throwing it about a bit, I just think it’s so important to get that perfected before trying to tune anything else and it seems that v2.3, with default params, is doing a great job. I can’t wait to try rate_D tuning this frame now, and with a bit less wind for loiter and auto... 


2.3 stock dji frame indoors from Kamakaze UK on Vimeo.


Hi Randy, thanks for feedback on Nav matters.

Yes, I figured so regarding that yawing close to waypoints. I obviously need to understand the waypoint proximity navigation laws in action to try to make the best out of the navigation performance. Very good hint to increase the waypoint radius in order to make it not slow down upon approaching the waypoint, will try that.

I think I will eventually submit a multitude of suggestions on how to improve the mission capability of the ArduCopter, but first I will do some more mission flying to get a more thorough understanding about what it can and cannot do as per today. The mission capability is one of the major "selling points" of AC concept and I look forward to contributing to it´s further evolution. The modularity of 3.x code will encourage that. Trajectory navigation is not trivial and moving ahead with that will rely on community team work, as usual.

Ending this post with a photo on the A340 MCDU (Multifunction Control and Display Unit), used for interacting with the FMS (Flight Managment System) which controls the lateral and vertical navigation of the aircraft. As default, all waypoint are "fly-by" type, implying that when navigating inbound a waypoint, the aircraft will initiate the turn in anticipation of arriving crisply on the outbound track, without any overshoot. Which means it does not actually hit the waypoint. The flight plan is sequenced once we pass abeam the waypoint. If, by any reason there is a waypoint that we must fly over, then we modify that waypoint using the OVFY button (highlighted in the photo). Once that is done, aircraft will fly right over that point before turning to next waypoint, thereby overshooting.

Navigations Display in map mode:

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service