Version 2.5 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
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 in 25% steps.
While some testers have reported very good flights with the default PIDs, some have reported that this release is a little "sharper" due to the DCM improvements and have found they needed to:
reduce stabilize P by 10% (i.e. 4.5 -> 4.2)
reduce stabilize D by 30% (i.e. 0.15 -> 0.10)
increase rate D from 0 to 0.001
Tuning loiter can be tricky. Refer to the discussions which will appear below for more community feedback on what parameters work best.
Please post your feedback in this discussion. For enhancement requests and bug report, please add them to the arducopter issues list. When possible please include logs (tlog and/or dataflash) and tell us whether you're using APM1 or APM2 and what version of the software you're using (presumably 2.5 but tell us anyway!).
Thanks for this release go to the developers (both in the core team but also those who have provided bug fixes through the issues list) and also the community members who participated in the previous release thread and provided some great detailed information in the form of issue reports and logs which allowed us to nail some bugs!
Similar to my preferences which I like. I also use lower Stab D currently ( I think 0.05 off the top of my head).
BTW, does anyone know what STAB_D_S does or is?
The STAB_D_S seems to be recently invented and it introduces gain scheduling (or the possibility of?) for the Stab D term.
As I figured by reading the code (though I am a rookie with programming) this down-scales the Stab D-term when we move the stick away from neutral. So if STAB_D_S is 0,5 then at full stick the effective Stab D term is reduced by 50%.
Check around line 1533 in ArduCopter.pde (to which I traced this parameter)
// These values can be used to scale the PID gains
// This allows for a simple gain scheduling implementation
roll_scale_d = g.stabilize_d_schedule * (float)abs(g.rc_1.control_in);
roll_scale_d = (1 - (roll_scale_d / 4500.0));
roll_scale_d = constrain(roll_scale_d, 0, 1) * g.stabilize_d;
pitch_scale_d = g.stabilize_d_schedule * (float)abs(g.rc_2.control_in);
pitch_scale_d = (1 - (pitch_scale_d / 4500.0));
pitch_scale_d = constrain(pitch_scale_d, 0, 1) * g.stabilize_d;
Maybe one of the developers care to confirm (or correct) this and the idea behind it?
Well done... yes that is exactly the effect of STAB_D_S. It is gain scheduling as you said above. The idea is the more stick you are applying, the less it should be dampened. This allows for a slightly higher STAB_D value while not feeling too sluggish.
Any changes which data can display in minimOSD... ?!?
I'm having only two significant problems with 2.5 and I'm hoping I'm not the only one. If these have been addressed, please point me to the solutions or appropriate discussion. I'm running on a standard 3DR quad frame, 880kv, 12x4.5, APM2 (with AC 2.5).
Magnetometer: Whether on the bench or in the air, the compass direction is affected by motor speed. Motors off provides a solid direction, but varying motor speed causes the compass direction to drift one way, and then back to normal when motor speed is decreased. This, of course, causes significant yawing issues when in flight and motor speeds are varying with height, etc.
Alt-Hold: I've seen this mentioned in the comments but haven't been able to implement a solution. The TRIM_THROTTLE term is low by default causing the quad to drop out of the sky. On the other hand, setting it too high causes altitude gain. I've gotten it to the point where a value works, and from what I understand this value is dynamic and automatically adjusted while in stabilize mode in an approximate hover. The real problem is that this value no longer works either toward the end of a battery pack, or when the pack is swapped out. This makes it very tricky to get things to the point of having a decent hover. I had perfect results with the default parameters in 2.4, so this change is somewhat troubling.
Other than those two things, I'm having perfect results with 2.5 using default parameters except for STAB_P ~3.2 and RATE_P 1.1.
Hi Eric, try with the latest beta: http://code.google.com/p/arducopter/downloads/detail?name=ArduCopte...
The "alt-hold" problem i think is fixed, but not the issue with the compass.
I figured the alt-hold problem was being worked on, but I haven't gotten around to grabbing a beta version yet. I'll take a look and see how it goes.
Is the compass problem a known issue and being dealt with in a future version?
It's a know issue but at the moment not fixed.
Occurs only on some configurations, many do not realize this error.
The problem is being studied, but if you want to do a report on the "issues list"...
Silly question about Magnetometer calibration.
Should the HUD show due North when the aircraft is aligned to magnetic north with a mechanical compass?
Or should the HUD show due North when the aircraft is pointed at TRUE north?
I'm afraid I'm getting a little tangled up with my setup. The declination where I am is about -11°. When I aligned my aircraft using a mechanical compass, it was not pointing at 0° North, or even -11°. It was about 8°. So, I changed the declination setting to -3° so that when the aircraft is pointing at magnetic north, the HUD shows 0° north.
But I don't know if this is right? I'm really not sure how I should set this up for Loiter precision.
My declination is -17.4°, APM2's compass, my phone's compass and a handheld traditional compass all point the same direction, therefore I presume the HUD must show magnetic north...
Hmmmm.... now what does that tell us? It would seem to indicate the HUD indication is exclusive of the declination adjustment. They all line up at Magnetic north, and the only thing that the declination setting is doing is telling the Loiter algorithm exactly where true north is, so it knows which way to fly when told to fly true north.
But if that is the case, why does my HUD compass move when I adjust declination?!
Can you try changing your declination to 0, and see if the HUD compass moves?
Robert (and other guys interested in how north reference is managed);
I have filed an enhancement issue (584) about the north reference indication in Mission Planner.
As food for thoughts I attach this short video, showing how it´s done in Airbus A340: