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!
there are some differences in our setups, but theyre not too dissimilar so perhaps this can help, im still flying 2.5 and with the current weather im not likely to fly 2.6 at least til the weekend. i post my setup more than anything for the difference in D values and the very low STAB P you have now - i have spent some time trying STAB P = 3.7 and while it worked with no STAB D, once i dialled the D back in it just felt far too loose - especially in wind. this is what im flying now and i find it excellent:
Flat Hexa - 2.5Kg AUW - 12x3.8SF - 3S - 650mm - APM1 - AC2.5.5
RATE: P 0.95 - I 0.02 - D 0.01
STAB: P 4.2 - I 0.0 - D 0.05
So around 30 pages or so ago, I was having some issues with what seemed to be my copter having some sort of ghost-like Expo. I was inputting pitch/roll but it was taking alot of input to get it to make the movement. After a few different setups nothing worked. Here is what I was doing yesterday afternoon. Around :58 you can see how the copter goes from nothing to a major roll.
So then last night I got cocky completely and was pushing the copter and thought I was a few feet higher.. Mind you the location is the pits for flying given the power lines.
Then this morning I went out and got stupid brave and was pushing it as hard as I ever did. I was coming back toward me and the wind started to gust and I froze I think. The damage? Rusty's CM-2 landing gear were busted in three peices, Canon A540 point and shoot camera was totaled. The FPV gear is all fine as it was sheltered. One boom was bent.
I went out again this evening and the original flight characteristics were back, leading me to believe that the CM-2 gear was really the source of the problem I was having with the controls.
I'm buying a skywalker.
Hope everyone is having a good evening (or morning respectively) guys! I am having issues with MP 1.1.92? My MP software started crashing when I would try to run video overlay into the Hud, and then started freezing completely. I removed the video capture and erased then reinstalled MP 1.1.92 (Nice that it is now in windows start programs now!) I tried bth versions of mavlink and I have no atrificial horizon now. Can anyone look at this video and see if there is something worng in my settings. I am at a loss now how to get my horizon back... Anyone had similar experience or have a workaround? BTW running Win 7 if it makes any difference...
Oops forgot screen capture...
Stilll no upload?
Glenn, we're probably going to back out the yaw change that I made. The delay you are seeing is easily understood, and it's fundamental to the way it now operates. I liked the feel, and Duran liked it, both of us have similar goals: Aerial Photography. The yaw is now very predictable, but also slow. It's not going to make everybody happy.
So, I have plans for a new control algorithm that will combine the best features of the old, and the new. I talked with Randy about it last night and he likes the idea. But it probably won't make 2.6 at this point.
Unfortunately all my helis are broken at the moment so I can't test my own code. If anybody wants to try some alpha changes, drop me a PM and I'll send you some patches to plug in. But you have to be prepared to patch in the changes, compile, and then fly something that... may not work at all. ;) It's totally up to you.
Now, in terms of that oscillation, it has nothing to do with your mechanical setup (or not likely, anyway). The problem is what's called "transport lag". Basically, the servo has to *move* before the yaw torque can change, and that takes time. How fast is your servo? Yours seems to be really severe. You need to have a REALLY fast servo for yaw control, mine is 0.06 sec/60°. So I have a change that I already did to the TradHeli that will help the Tri the same way. It's just a little bit of help that doesn't fully solve it.
Although, your oscillation is so bad, I really wonder if your Yaw_Stab_P is just way too high. Did it get worse when you turned it up?
Thanks for taking the time to look into this Robert, My primary goal too with this platform is aerial photography while I travel Canada & North America over the next 6 months (along with very light weight and portability).
My servo is a Turnigy 380MAX Micro Servo (Metal Gear) 4.1kg / .16sec / 17.4g. I've also tried a BMS-385DMAX Digital Servo (Metal Gear) 4.2kg / .15sec / 16.5g but it also behaves the same. I have just reverted to 2.5.4 and reduced the yaw_stab_p to 5, and it seems like the yaw oscillation is drastically reduced, but is still there slightly.
I'm running a multiwii board on my other tri which is set up the same, and there is no yaw oscillation at all, which makes me think that it's not the servo which is the issue, but the code driving it.
I am keen to test new code if it will help ensure that problems affecting tricopters get caught. I do really appreciate the effort you guys are putting in anyway.
Well, right off the bat, I'll say that, whatever software you are running, a faster servo will help, for the same reason it does for helis. The 380MAX isn't even digital? Right off, you really need a digital servo. This would be an awesome servo if you can get it in stock:
This is what I'm putting on the swashplate of my 450:
The only thing is I'm not sure if it's strong enough? The servo you're using produces high torque, at the expense of speed. I'm not sure how much torque you need though? This is what I'm using on the tail of my 450, it's reasonable strong and fast:
I'll post a patch to you later if you want to try? It's something I've done for my heli that might help a bit. It's probably not surprising that the multi-wii board doesn't have a problem because it doesn't have a compass does it? It probably doesn't waggle, but then it also probably doesn't hold a heading well either? You might not notice because the rate response is decent, but the actual positioning is not accurate.
See the problem is this: If you have a rate error, the copter has rotated, but then it stops when the rate controller gets back under control. At this point, the multi-wii would just leave well enough alone. The problem is that the copter is not on the yaw target anymore. It might be off by a few degrees. Well, arducopter would tell it to go back to the target heading. So it moves back, but then overshoots (partially because of your slow servo). So then it tells it to move back... it just bounces back and forth between headings.
So what I did was create a yaw angle target deadband. Basically, if the yaw is within 2° either side of the target, it just just leaves well enough alone. It doesn't tell the rate controller to move back, it just lets it be, with a target rate of zero. The pilot will never notice a 2° error anyway. And this prevents this waggling back and forth problem.
Quads, hexas and octos don't have this problem. Or it's smaller. Because they don't have to wait for a servo to move. The torque production is almost instantaneous. Soon as the yaw controller tells the motor to speed up to correct the yaw, it takes effect immediately.
obviously in a greater or lesser extent depending on the platform, but all our craft have some latency in yaw response - be it from esc update speed, motor acceleration time, or a tail servo movement in a tri. then theres the inertia to take into account, AC is flying on platforms of wildly varying weights - from the tiny versions jose julio is flying recently to 4Kg+ octos.
i cant see any problem with changing to a faster servo, quite the contrary - any latency that can be taken out of the system is going to help - but surely this could be tuned out with RATE_YAW values? (though perhaps a dead band is a good idea anyway)
i see youve been trying all kinds of values for RATE_YAW_P, have you tried maybe adding a bit more RATE_YAW_D or higher/lower RATE_YAW_I?
That corona 919MG looks interesting, could be worth a try for the price. I just went with the bms-385max and turnigy 380max as those were what were recommended for the kit I bought.
That does make sense about the cause of the yaw oscillation.
I will try that yaw dead band patch if you want to post it. I have just moved to 2.6 Epsilon, and the yaw oscillation has pretty much disappeared, or at least been reduced by an order of magnitude (along with the pitch spikes I was also having). I am running a lower value for stab yaw p of 5 and rate yaw p of .15. I haven't tried adding rate yaw D or I, but will give them a go and see what happens.
Glenn, just the move to a digital servo vs. an analog will make a HUGE difference. The problem could simply be that your analog servo never centers, at all, really. Every time it moves either direction, it will stop on that side of the setpoint.
I just wanted to say I read this forum religiously and I find every ones contribution helpful. I just wanted to make a suggestion in general. When 2.6 is officially released, can we make a 2.6 discussion with mode specific threads in it? For example, a thread dedicated to loiter/loiter tuning or Acro/acro mode tuning. I hope my suggestion doesn't find anyone in bad taste. Just looking for a more organized way of finding help. Thanks everyone for a great community and thanks to the developers for such an awesome project