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!
Stilll no upload?
I was just looking for info about the pitch twitch:
I didn't think I saw pitch-in spikes, but I haven't completely dissected the logs. Today I captured video and tlogs with the intent of combing through it to find the event and post them for help, but I've not had time to edit the video down.
I think I've been having this problem since 2.5.4 and believe it can (rarely) be drastic enough to cause a crash.
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
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?
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
I agree 100%.
I'm trying to adjust loiter and yaw PID's and it's very hard to get good results in windy conditions.
I like that idea, it would make finding what your looking for a lot easier.
I implemented a couple of months ago the stability patch for Y6 that is missing since long but I still don't see it implemented in 2.6 epsilon. Anyone can test it and include it to the public release, please? My Y6 will be ready soon and I would love to have the stability patch on it.
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.
I haven't forgotten about this fix. I've had a lot of time constraints in the past month but it's going to clear up in a couple of weeks. This won't make it into 2.6 unfortunately but I'm confident it'll be in 2.7 (or maybe a patch release of 2.6 if we need to do one).
ArduCopter 2.6 Epsilon is now available in the downloads area for beta testers. Hoping that this is the final version that will be pushed out to the Mission planner.
A couple of things to be on the look-out for:
a) Please try Simple Mode. The copter should not spin.
b) Empty dataflash for some APM1 users. We have one report of this (from Dean) so I'm interested to see if anyone else has seen this. It's possible that it could be a dataflash hardware problem exposed because of the new method we're using to erase the dataflash.
thanks for your help!
Changes from 2.6-Delta:
- throttle range improvement (higher min and max) [Jason]
- improved standard Loiter PIDs [Alan, Heino, Jason, Angel]
- restored standard yaw control [Robert/Randy]
Improvements over 2.5.5 include:
- Stability improvements especially during level hover [Jason]
- MavLink 1.0 support (use with ArdupilotMegaPlanner10.exe) [Tridge, Craig]
- dataflash erase speed up ('+' messages removed but it only takes 6 seconds now) [Tridge]
- Copter LEDs [Robert Lefebvre]
- RTL loiter stage target set to home to improve final landing position [Jason]
- flip & acro improvements [Jason]
- circle mode target improvement for ground station [Jason]
Bug fixes include:
- UBLOX driver fixes (lock should now be more reliable) [Tridge]
- enable mavlink messages during dataflash erase which resolves issue in which new APMs fresh from the factory appeared unresponsive [Tridge]
- proper printing of lat/lon values in dataflash logs [Randy]
- removed duplicate GPS reads [Jason]
- resolve flooding of telemetry link with low-battery warnings [Tridge]
- RTL bug would land if rtl_approach_alt was more than 1 [Jason]
- WP Radius could not be set larger than 1.3m [Jason/Randy]
Cheers, will give it a go. I did have the problem with logs not being created on APM1 after I moved from 2.5.4 to 2.6 delta. I hadn't cleared my 2.5.4 logs when the logging wasn't working, and as soon as I did, the 2.6 delta logs started to work.