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.
but if I search Arducopter.pde after _new_alt I cant find it.
Please can you paste the part of the program were _new_alt is written?
Just search for set_new_alt call in Arducopter.pde.
You see an example of a call line this:
The parameter doesn't have be called "_new_alt" when it's passed in.variable name is used locally in the routine to referenced the passed in value. You seem new to programming. So be careful, it can be dangerous. I always make sure to remove the propellers, before I test any changes, for safety.
I get some strange wobbling in air in stable mode. The quad is simple to fly and i dont have to fight it to keep it quite still, but it has some oscillations every 1-3 seconds, like its trying to correct something. When it does this it wobbles but it still corrects itself and keeps pretty still. You can hear the motors "does something" when this happens.
Has anyone seen anyting like this before? This is my 3rd test of firmware 2.3, apm1 and 3dr frame with stock motors and 10x4.5 props. Apm is not covered with anything, just stock 3dr mounting.. PID settings are stock except i sat roll p from the standard 0.0140 to 0.0120.
Here is a video of the flight, when you see the copter oscillate and at the same time hear the motors run up, im not doing that with the tx..its doing it by itself im just flying it slowly around, almost just floating it around with small stick inputs.
Also notice when i drive it up a couple meters the motors run fine without the twitching..
im flying a 1.8kg, 880kv jdrones motors, 12x4.5" props Hexa and have been struggling with stability in v2.3. my main problem seems to be with STAB_D, for now i have set it to zero and am concentrating on the RATE terms.
this is by no means perfect but is at least flyable on my setup:
stab_p:5; stab_i:0; stab_d:0
rate_p:0.1; rate_i:0.02; rate_d:0.002
im still working on it and am myself very new to tuning these terms (didnt realise how lucky i was that the default settings worked so well for me before). im starting to get a clearer idea of how flight is affected by each parameter, after a lot of failed tests and the feeling that any minor change just made things worse i realise its really the RATE terms you have to get right.
We flied with 2.3 firmware using jdrones default quad arducopter to try auto landing.
In one of our trials we adjusted our three modes as 1-Stabilize, 2-Loiter and 3-Land. When we switched from stabilize to loiter and then immediately after loiter to land, the copter switched to RTL instead of land.
In a second trial our modes was 1-Stabilize, 2-Stabilize and 3-Land. In this case we switched to land after a manual take off and stabilizing the copter. But again the copter switched to RTL.
Is this normal?
Re the sudden yawing..you can imagine that would happen because it tries to aim for the way point no matter how close it is so if it's suddenly blown downwind you will see exactly the behaviour you're see.
Re flying through the way points instead of stopping at them..as you've noticed, we always stop..you could argue, why bother having way points all in a row?
You might try increasing the size of the way point diameter. Once it gets within that diameter it'll figure that it's been successful and move onto the next point. My guess is that if you make it 6 meters it'll never slow down because in the code, it doesn't start to slow down until it's within 6m of the target.
By the way, we've got this 2.3.1 release coming out with a few bug fixes. After that we will be focusing a bit on "3.x" which we hope will make it easier for people to make changes in the code. While that's happening I suspect we will still push out minor bug fix releases but large changes in functionality might be a bit slower.
As always, thanks again for your testing and detailed reports. As you know, Issues list is a great place to put your enhancement requests.
Thanks for the detailed bug report, including logs! I wish everyone did this. I'll have a look at it in the next day or two and stick my comments in that issue. As you probably know you can star the issue to receive updates on it.
Exact same issue here. It wobbles fast more than the AC2.1 (2.1 was the most stable I've seen to date).
Do the basic checks:
a. make sure the frame is stiff, motor mounts not loose, ESC programmed the same, props not slipping.
b. IIRC, the 3DR params are for a 3S mid-size battery. If you're 4S and/or heavier, you'll need to decrease the rate_<???>_P and I values (slowly). Stable PID values are for control inputs, Rate PIDs are for hover in some ways. Since I have a custom frame (a mix of AL and Basswood), I set Rate P to where is just wobbles, but settles on position with light stick inputs, then increase Rate I to dampen the wobbles. I tune this way on my MK hexa and it always comes out stable with different payload weights. I almost removed the wobble doing it this way....
That doesn't sound normal to me. If you switch to land straight from stabilise or loiter it should land at it's current position instead of trying to return home. I've checked this by looking at the do_land command in particular this line which should cause it to land at it's current position:
// hold at our current location
Could you check your log files and ensure the MOD:LAND line appears intead of MOD:RTL? Maybe stick your logs here or create an issue on the issues list.
Same here, flipped twice on me (no broken parts). By chance did you have the AC connected to MissionPlanner(MP) and just pulled the USB? My flipping started when I realized MP was still connected when I pulled the USB. After the flips I reconnected to MP, rewrote PID values, did a proper disconnect and cycled power--no flips yet.
There is only one direction the sound occurs at.
Check out the mechanical, bearings, prop crack, etc..