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 42 58 13 7Motors 1 through 4 spin clockwise, and 5 through 8 spin counterclockwise.
I've tried to ask this a couple times and don't seem to get a straight answer. Is there anything Hex+ people can do to get up and running on APM2.0? ie. Is there documentation that matches the current code? I can see in the code comments that the motor changes were taken out... but, information seems to be disseminated in various forums and it's hard to get a solid status on things. The 'update' in this thread indicates hexes and octos need to wait until the next version. What exactly does this mean? Is there a motor configuration we can go with now to get in the air?
Dave: Hexas work now. It's just that we may change the motor order for APM 2, so you might have to switch some cables around. Documentation is waiting for that.
We solved/understand the problem.
We inspect the code and realised that, as a failsafe, if battery monitor is enabled and a low battery event occurs the copter enters in RTL mode, if the mode is equal to or greater than AUTO (events.pde, lines 55,56). In our case we set our low battery threshold at 10.2 V and preferred to fly at lower voltages without being unaware of this failsafe. And the copter entered to RTL.
In most cases this failsafe is logical. But for landing there is something different: If user gives an immediate landing command, returning to home can consume much power. I will add this as an issue.
As a suggestion a warning message can be added in battery monitor section of GCS.
That's great, thanks.
Tomas, agree wholeheartedly. Have posted often about how much of a struggle some of this stuff is without good and current documentation. Even when documentation is updated, I find that it is often based on theory rather than what you might expect to observe. For instance, from the current Loiter Wiki entry "Parameter: NAV_LAT_P and NAV_LON_P are the proportional response and the default is 2.2." This means absolutely nothing to me - what I would like to see is "If your copter is blown downwind, attempts to get back to the target, but fails and is blown downwind again, then increase parameter x..." or "If your copter flies in large circles ("pudding bowling") then decrease parameter y...".
My question to you though is this - the implication I derived from your comment was that there is not a bug, but that the documentation is inadequate and therefore I have misdiagnosed a bug because I am not in full possession of the relevant facts - is that implication correct? If yes, what do I need to know/do to prevent reoccurrence of the problem? Or were you commenting on the confusion between the wiki and the post by Jason? Regards, Bill
Got it. Thank you.
I'm still having twitches with 2.3, even with rate D at 0.
To check there is nothing wrong with HW I reloaded v49 and it flies good.
Is someone using MT2814 with turnigy plush 25A ESC's??? Just to compare??
Also changed TX and RX.
I saw Jason mention creating a tuning video on one of the dev. lists a few days ago. Maybe this will be the answer to many of these tuning type issues- a process that is guaranteed to work with our structure.
Did you try lowering your Stab_D term? on my setup(using the same ESCs but KDA motors) I found that after tuning down Rate_P(with the default Rate_D set to zero) to eliminate oscilations I had to lower the Stab_D term a bit to get rid of the twitches.
I will try, thx
Twitches for me too are still apparent, very annoying for video or FPV. My quad is well tuned and flies very nicely except for these darn twiches that won't go away, Stab_D is on zero. Turnigy ESC's and KDA motors.
Note: these are not occilations, but twitches. I'll do a video when I'm home again.
I never tried 0.49, only started from v2.2B2 and as far as I can remember they've always been there.
IN DOOR SIMPLE TEST CODE 2.3 PID FACTORY, APM 1.4, RCTIMER 2830 13, 10X4,5. 20A POWER SUPPLY,13.25VOLT, 270WA MAX. XBEE 900, SONAR LV EZ4, NO BATTERY WEIGHT 1,250Kg, RADIO FUTABA T9CAP...VERY STABLE WITH NO CHANGE IN PID