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.
Randy, if i put ELE UP (pitch down) the quad going down in front diagonal sx.
I've X-QUAD, software compiled and upped to APM1 with Arduino 1.0.
Now i'll check again, but this does... I may have something that does not work well here.
Yes, with x-quad all is ok, just my error with compass, i'm sorry.
i think we have a problem with naming conventions.
2.2 b6 plus a last minute change of fundamental mapping should not be released as "final". it wont catch me out as ive read this thread, but for someone installing their first firmware it could cause a major headache.
btw the first firmware mission planner installed for me was 2.1 alpha, again not what i expected at all.
im not complaining about the overall development effort, its great that things move along at this pace, i just think that anything released via mission planner should be "final". In the case of having more than one stable release this should be reflected at the moment of installation, giving the user a choice over the firmware to install.
right now i might (for example) present the user with the options:
2.2 b4 - 26/01/2012 - "stable, some issues with RTL and auto-land .... etc."
2.2 b7 - 01/01/2012 - "based on 2.2 b6, much improved RTL and auto-land, complete re-map of motors for hexa and octo ..."
just to give the end user an idea of what to expect.
I just loaded 2.3 On my tri-copter APM1 with the mission planner and the tail servo works great...
But the tail motor does not come on... ESC says bad PW..
So ran the tail motor with a seperate receiver... all is good...
I measured the PW on chanel 4 and its 0... not sure what do to next..
btw.. I write a lot of software and I think the is fantastic software... and I am sure it will get sorted out..
Marco: Yes, I've tested with all quad configurations, on both APM 1 and 2 and all looks good here.
It's always easy to criticize, but I sorta agree with James on this one. It's a regrettable and understandable oops if it happens in unreleased beta code, but this is something that should never have happened to a release version :(
Sorry, my bad. Jason was travelling and I took over the release process for the week. I'll fire myself.
It's understandable, the amount of stuff Chris and the guys have to deal with, all the little details, I think this is something that just got overlooked, but yes, I agree that final should be final, I flipped my big octo, luckily no damage, but i was, as i said, lucky, others might not be.
No worries Chris, it's bound to happen now and then. Though might be a good idea to get Michael to pull 2.3 from the mission planner. Hexas and Octos are among the most expensive machines people here build, you might save someone a few hundred of dollars.
Just been flying on my quad while I wait for the octo fix, but having some issues, sorry to say, not sure what it might be.
When flying stabmode, it seems fine but everynow and again, say 2 or 3 times out of 10, when I roll lefr/right, it gets 'stuck' on that possistion for a second, then reverts back to level, as if it's got some lag when at 30' angle for example, now I'm not sure if this is code, settings or what, but it's very terrifying when flying and it doesnt come back level, almost crashed..
Any ideas on this, anyone else having this issue ?
(I've re-loaded firmware and re-cal, still does it.)
Writing this post in a hurry. Really have to get started with some pancake production in this kitchen.
Anyhow. Have just spent five batteries testing the 2.3 release. Promising!
I fly a stock 3DR, APM2, 3S3300mAh but with decent props (10x4,5 carbon reinforced).
Some quick notes:
Default parameters are mediocre.
I reverted to setup table presented by Afernan, based on Igor´s tuning procedure. Much better! Even promising. Though I had to to some altering on the parameters from Afernans table, no surprise, we have different frames and configuration.
BUT! Still that damn 5 seconds of oscillation at rev-up. Wasn´t that supposed to be fixed? (yeah, I read another post about it too). I will be back with my basic settings later.
Also tried a some loitering. Altitude works nicely (only using baro, for the moment). Position keeping was first oscillating way TOO much. And reducing loiter P did not seem to help (Loiter I already 0). After a while i figured out what is the problem: Loiter gain is not set by Loiter P, it is set by Nav P. I had some last seconds of flight testing Nav P=0,5 and then I started to see some results. But that was just a start, more tuning remaining.
I regard that as a BUG. Loiter gain is supposed to be set by Loiter P, and not Nav P, right?
Be back later. Now to the pancakes... :)
Sounds like radio lockout to me.. logs?