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.
How can I find out what FrSky works with my JR9503? I recently got some orangerx which seem to be about 10x cheaper than spectrum but haven't tested the reliability much yet. Does using the FrSky require changing out the module on the back of the receiver?
Loiter behaviour - no/very low wind.
Has anybody else observed this behaviour? When there is no wind, the Nav_P parameter needs to be quite low e.g. 1 to 1.2, otherwise you get pudding bowling. In very light winds, Nav_P can be more like 2 and then the copter is fine loitering in stronger winds. In very low winds, you need to increase Nav_P otherwise it gently drifts off. In other words, it seems very sensitive between no and very low winds.
The good news is that later on, the wind got up - in 8-10mph winds, I had a 7-8 minute loiter, 400m track in a 6x6m box, which I thought was pretty good (anybody care to specify what it should be capable of?). Stock 3DR, APM1, 850kv motors, 10x4.5 props, Nav P 1.9, Nav I 0.01 Nav D 0.004.
I'm sorry Bill, but if you have a good gps fix the box 6x6 is too high, not good result... 2x2 or 1x1 is nice, all the rest is sxxt! :-)
The loiter must operate in a much more narrow range.
Even in wind? The wiki indicates that wind will increase the size of the box.
I noticed the same sort of behavior but I played with the Nav_I term as well because as I understand it, it allows the copter to ramp up against error over time...which basically means that you can have the Nav_P term lower to avoid the pudding bowling effect but at the same time allow it to correct for errors when there are consitent external forces...now that's the theory as I understand it anyway. In practice I had to keep both the P and I term low to get it to loiter in either conditions...and still with that I got about a 2X2 meter box(but only sometimes)...but always when entering loiter it seems to want to select it's own loiter location rather than stop where it is(assuming it wasn't moving to start with).
Dare i say it?
Has anyone played with NAV_D yet? :)
And also does anyone have any bright ideas as to how i can set up a virtual gps - i'd like to be able to tune loiter in my lounge :D
I wonder if you can transmit the signal using something similar to the Xbee kit with the gps connected to the transmitter outdoors?
dave, i remember years ago seeing "Local Positioning Systems" for tracking stuff inside warehouses, seems it still exists: http://en.wikipedia.org/wiki/Local_positioning_system
i dont know if it uses exactly the same protocol as gps, but to have this working at a range of a few meters you should get an absolutely spot-on lock!
Hi everyone,I am a novice but I follow this discussion with interest from version 2.0.XX,
congratulations for the work.
I try every version from 2.0.48 to 2.3 on my hexa with apm1 ,
with this version i have a stab P Pitch and roll = 3 Stab I 0 Stab D 0,12
Rate P 0,129 I=0 D=0 but i have a strange action
when releasing the stick of pitch after a long forward progress, "the nose" of hexa goes up.
how is the correct procedure for a good setup of 2.3?
i am suffering from the same problem, i started to notice it in v2.2 but believe its worse now - was looking for advice here (http://diydrones.com/forum/topics/arducopter-configurations-and-set...)
im hoping it is something that can be resolved with tuning, and now have my hexa bolted to a test jig trying to reproduce the problem. so far i have not seen the problem on the jig which makes me think that it might be related to vibration - having the hexa clamped by four arms changes the flexibility of the frame so i might have to find an alternative mounting method to more closely reproduce flight conditions.
apart from the nose up twitch after forward flight i find the inability to maintain the hexa in a nose down position is far more worrying - as i hover against the wind i need to apply more and more forward stick to maintain the same angle, i wonder if you have noticed this too?
considering that it might be due to vibration i have two or three motors with some play in the bearings, so i will be looking very closely at that and checking everything is perfectly aligned.
any chance that for tri's something like that can be implemented in near future version?:
#define TRI_YAW_SERVO_DIR REGULAR
and in Arducopter.pde;
static void fifty_hz_loop()
#if FRAME_CONFIG == TRI _FRAME
#if TRI_YAW_SERVO_DIR == REGULAR
#elseif TRI_YAW_SERVO_DIR == REVERSE
APM_RC.OutputCh(CH_TRI_YAW, ( (-1 * (g.rc_4.radio_out - g.rc_4.radio_trim) ) + g.rc_4.radio_trim ) );
Not the best, but a lot better as now!
There's an issue for this already in the issues list. I was unsure if the problem was still there or if you could resolve it by changing a parameter in the configuration screen of the AP MissionPlanner. I think the parameter is RC7_REV. You should try making it -1. If that doesn't work could you comment in the issue linked above? I think we can fix this issue.