ArduCopter 2.5 released!
Version 2.5 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
Enhancements:
- The first ArduCopter code release optimized for the APM 2. Leans and drift should be much reduced or even eliminated for most users. This was accomplished through a number of core improvements to the DCM implementation by Tridge like this one and this one.
- Loiter and waypoint following should be improved due to a D term bug fix, some tuning and the improved DCM performance mentioned above.
- On start-up, the yaw heading is updated with first successful mag read (so you should no longer see the slow rotation from north to your actual heading).
- Increased output rate to ESCs to 490hz. This update rate is also user selectable using the new RC_SPEED parameter.
- hexa copter stability patch bug fix (should resolve slight flattening when pitching forward and accelerating very rapidly).
- improved baro filtering
- fix to dataflash logging of Mag heading
- addition of H1 swash plate type and bug fix for proactive yaw compensation for collective pitch changes for TradHelis.
Tuning:
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!
Replies to This Discussion
-
ModeratorPermalink Reply by Graham Dyer on -
Randy, have been having a few flights since I first reported this problem, originally changed that value to 450 and reported yesterday that it had increased to 498, today I was hovering in the garden and flicked the ALT_HOLD switch, suddenly my copter shot UPWARDS and collided with the edge of a tree. Luckily no damage but after expecting a drop to suddenly have a rapid climb is unnerving. I tried it in a more open space and the quad shot up to around 8m before I brought it down manually. Just checked and the value is now 533!
-
Permalink Reply by Jan Schermer on -
I don't understand the value of this parameter - ALT_HOLD should take the actual throttle as a starting point, not some "saved" value (that might be wildly different). I don't see any point in having THROTTLE_THRIM at all.
-
Permalink Reply by James Friend on -
I am very new to all this, so sorry if my comment doesn't make sense, but when flying in stabilise, as the battery becomes depleted, one requires more and more throttle to maintain hover. If this parameter (THROTTLE_TRIM) is being updated during flight (while battery is being depleted) could changing to a fully charged battery and then changing to ALT_HOLD not lead to the problems described?
James
-
Permalink Reply by u4eake on -
No, the battery slowly depleting is handled by the I-term of your PID. The I slowly accumulates any errors that arise, such as a battery voltage slowly dropping.
Jan, originally alt_hold would take the trhottle position when you engaged it. Problem was that you only could engage alt_hold when already hoovering steady. If you engage alt_hold while climbing, copter would keep climbing, if you engaged while descending, copter would keep descending.
That's why we implemented throttle_trim. But it seems it now also has it's problems.
-
Permalink Reply by James Friend on
-
Hi all
Just tested ALT_HOLD for the first time (at 450) and get the same result - rockets upward.
James
-
ModeratorPermalink Reply by Graham Dyer on -
James, what's your value after reconnecting, has it changed? I posted an issue here as this is going to catch out a lot of people if it persists.
-
Permalink Reply by James Friend on
-
Just to be sure I am looking at the correct number - as I said, new to this :-)
This is the TRIM_THROTTLE value?
If so, mine is now 683
-
ModeratorPermalink Reply by Graham Dyer on -
yeah, something's not right there, star the issue if you see the same problem, hopefully a fix can be found soon.
-
-
Permalink Reply by Dave C on -
Yup, mines 652, i thought this was because my quad is heavy, and my motors are weak. But i could be wrong..
-
-
Permalink Reply by James Friend on
-
You may have to bring your Rate Roll/Pitch P down to 0.09 or 0.1 for those motors and props.
-
Permalink Reply by Paul Boreham on
-
Hi Umer,
I have the same rig and use a 4S Lipo. I'd suggest the following as a starting point:
Drop Stabilise Roll P to 3.5
Drop Rate Roll P to 0.1
Set Throttle Trim to 450
Regards,
Paul
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Moderators
24 members
-
ArduRover User Group
184 members
-
Japan ArduCopter Group
51 members
-
Taiwan ROC ArduPilot Gro…
8 members
-
Documentation Editors
51 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
