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
-
DeveloperPermalink Reply by R_Lefebvre on -
Well, I deleted what was left. It was like 40 lines but only 0.5 lines showed up.
And now it won't take this reply either it says:
"
- We're Sorry
- Please write something for your reply."
-
Permalink Reply by Duran - SteadiDrone on -
weird, can you pm me or email info@steadidrone.com :) tx
-
Permalink Reply by Duran - SteadiDrone on
-
lol
-
DeveloperPermalink Reply by R_Lefebvre on -
Ok, I'll try this again:
If you look for line 412 of attitude.pde, you will see this:
_yaw = nav_yaw + (yaw_input / 50);
Change it to this:
_yaw = nav_yaw + (yaw_input / 25);
That number can be as small as you want, but at some point your copter won't be able to keep up. The error will keep building, and if it got bigger than 180 degree, the copter will start going the other way.
Now, I just came up with the solution to that, if you want to try, but this is completely untested!
Immediately after that line, add this new one:
_yaw = constrain (_yaw, ahrs.yaw_sensor - 25, ahrs.yaw_sensor + 25);
This will mean that the yaw target can never get too far ahead of itself. 25 deg should be plenty. My helicopter never got more than 12, IIRC. This will actually limit the yaw speed in a way.
It also solves Dave's problem where the copter turned when he lifted off. In this case, it won't be able to have a target greater than 25° from it's current position. So it might lift off and turn 25°, but that's manageable, I think.
Another thing you can try, is line 260:
int16_t yaw_limit = 1400 + abs(g.rc_4.control_in);
This limits how much control the yaw controller can have, and it's related to the control input. That might be ok when you input a yaw, but this really hurts your ability to stop a yaw! Try changing it to this:
int16_t yaw_limit = 2800 + abs(g.rc_4.control_in);
Or even simply:
int16_t yaw_limit = 4500;
That's how I have it for TradHeli and it's fine for me. Let me know what you think. This should help it "stop on a dime".
-
Permalink Reply by Duran - SteadiDrone on
-
diusgruntled x-member hacker..
-
DeveloperPermalink Reply by R_Lefebvre on -
No, I don't think so, it's done this before.
-
Permalink Reply by Ayush Gupta on -
Hey guys dont know if its the right place to ask but could someone help me with PID parameters for the following:
DJI F450 Flamewheel Frame
10x4.5 Props
880kv jdrones motors
I have been trying to tune it but it is getting worse so please help!!
-
Permalink Reply by Dave C on -
If you are after just stab params you should be ok close to default, with the small frame and extra power i'd reduce rate_p and stab_P by about 20% from default and start from there. Use channel 6 if you have a pot on your tranny to dial rate_p in first then stab_P. This will get it hovering properly, then use rate_I OR stab_I to gain a bit of wind resistance.
Also before you start reduce stab_D to ZERO, add a bit (0.004) rate_d. If you don't have that as a default already.
That should help for now, although it would help to know what version you are flying, if you have 2.6.gamma for instance you may need to crank up your stab-yaw-P...
Oh and keep reading ;)
-
Permalink Reply by Ayush Gupta on
-
Thanks for the tips Dave :)
Currently I am flying 2.5.5 but I think maybe I should wait for 2.6 but dont know when is it going to come out.
Also I agree that the PID for hover and stable flying are good enough right out of box what i needed was either PID setup or tips for tunig my PIDs for Loiter and Navigation as that is a wicked one ;)
-
Permalink Reply by Dave C on
-
Loiter - reduce your loiter_p params from stock, i start at 1.0, adding 0.1 at a time until you get overshooting of the target then add in 0.1 increments of loiter_D, until it moves more abruptly towards the target but does not overshoot. Then a bit of I (0.1 at a time) to hold against wind and imbalances.
Nav, i use stock, then tune other params to improve it.
You won't get it perfect, as there's still some work to do in those areas, but it's being worked on.
And you can get some great results 'as is' with a bit of patient tuning.
-
Permalink Reply by Jonathan M on -
Anyone have recommendation on parameters for a large hexa (3+ kg, 12x3.8 SF props, 4s, 800mm motor to motor, APM2) use 2.6 delta? Overall, it feels so much more solid than my quad ever was, which I somewhat attribute to better build quality on my part, but I haven't begun tuning yet. Currently:
Roll/pitch:rate P =0.09
rate I = 0.01
rate D = 0.002
stab p = 3.5
stab D = 0.08
not sure about the rest of the top of my head. I am really going to for lock-in control with good hover capability. It's going to be a video platform. Testing yesterday had good results, but I still had issues finding the hover point easily. I always seem to be hunting up and down. Is there a tuning value or tx setting that can be changed to make finding the hover point easier? I don't seem to see this problem with other flight controllers out there.
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
-
ArduPlane User Group
671 members
-
ArduCopter User Group
1280 members
-
Taiwan ROC ArduPilot Gro…
8 members
-
Andropilot Users Group
182 members
-
3D Models
15 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
