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
-
Permalink Reply by Fatih Gokce on -
Hi Marco,
Did you make/publish your MTK vs U-Blox comparative test? We are hardly waiting for it!
-
Permalink Reply by John Hanson on -
So far stable mode is best ever - hovers in place without even autotrim.
The only strange thing I have had so far is that simple mode seems to start off fine, one can yaw and steer as expected. This works ok for a minute or two and then it gets very hard to control, almost like some pid term got out of whack. Return to normal mode and control is perfect - I have not had enough time to test this bug more, but It seems repeatable.
Looking forward to Boulder!! Hopefully our winds will be tame next weekend.
-
Permalink Reply by Duran - SteadiDrone on -
ANYONE know why on a big octo we have 4 motors spinning hotter than other 4 ??
-
Permalink Reply by theo van niekerk on -
Im wondering if it could have somehting to do with.....Coriolis effect (http://en.wikipedia.org/wiki/Coriolis_effect) I find that that my ccw set run hotter then my cw set on my octo.......
-
Permalink Reply by Greg on
-
Duran this falls in one of those "it depends" questions. For example it could be related to the type of motor design you have. Some motors channel more air into the coils due to the shape of the vanes around the top of the motor when looking at CW versus CCW rotation. One thing to do is characterize the electrical load on the motors. e.g measure the current & voltage drop on two motors with different operating temperatures. Also look a overall platform balance maybe you have some motors running harder to counter a weight distribution issue.
-
DeveloperPermalink Reply by R_Lefebvre on -
Duran, is it all the motors turning in a certain direction? If so, look at the little blower fans on them. Some motors have "directional" vanes, meaning they are angled, and will pump much more air in one direction than another.
In fact, on my little heli motor, I found that the fan is reversible! I can unscrew the end cap, take the directional fan out, flip it over and put it back together. Have a look.
-
Permalink Reply by Aerhead on
-
John
I have seen the same control issue with my AMP2/quad with yaw control in simple mode. No idea if it is caused by a code bug or magnetic interference generated by my set-up. Two or three minuets into a flight my quad will occasionally be out of control because your stick movements right or left will be switch to control forward or back movement.
-
Permalink Reply by John Hanson on
-
Pretty sure it is a code issue- my apm2 quad hardware has not changed and simple mode worked fine on last version.
I also noticed that when I add the weight of my camera assembly (386 gm) altitude hold mode causes it to rise rapidly. Without the weight hold is ok (both baro and sonar) but with weight it rises even if just baro hold. I kind of remember this is a throttle_trim issue - I lowered it from 593 to 400, no luck. AH P from .5 to 1.2, no luck.. Should I change something else?
-
Permalink Reply by Fatih Gokce on
-
We observe same issues for simple mode and alt hold. Alt hold issue seems related with an improvement in 2.6 Delta (from Randy's post regarding 2.6 Delta):
"2. throttle scaling. it was possible to max out the engines which could lead to instability so the max throttle has been reduced to 85%. The downside is that the hover position of your stick will be slightly higher. Worst case a heavy or slightly underpowered quad may require so much throttle that when you switch to alt-hold, your throttle is above the 'deadzone' and the quad may start to climb. in this case you will find that you will need to lower your stick after switching into alt-hold and similar raise your throttle stick when coming out of alt hold."
I think this improvement should be revised. Being have to play with throttle stick is a little bit annoying. We could not have a chance to try, but I expect a similar raising behavior when switched to loiter mode.
-
Permalink Reply by Gustav Kuhn on -
Any features I can switch off to make 2.6 fit on a 1280 APM1 board?
-
Permalink Reply by Duran - SteadiDrone on
-
yes, stabilize mode ;) (i have no idea)
-
DeveloperPermalink Reply by R_Lefebvre on -
Some notes about yaw control for anybody testing 2.6beta (or gamma or delta... whatever it's called now).
What do you guys think of the new yaw control? I am not sure if you saw it on the dev list or not, but I revamped the Stab_yaw controller. I don't know if it's perfected yet, but it should be much more "predictable". Basically what used to happen is that when the yaw stick was centered, the yaw controller tried to hold the current heading. That's cool. But what wasn't cool was that there were a few reasons behind the scenes that it was not in fact holding the correct yaw heading, particularly for TradHelis. There was a steady state error, but the pilot actually wasn't aware of it. You might think the AC was holding 0° due north. It would look like that to you, but behind the scenes, it was actually trying to hold (just as an example) 5° to the right, there was a constant error.
The problem is with the way it handled yaw commands. Basically, once you touched the sticks, once yaw input was anything other than zero, it would "accept" whatever the current heading is, and then try to yaw at a rate determined by Yaw_Stab_P (not what you'd think!). It was always updating the Nav_Yaw setpoint to what it currently is, and then there was a rate that was sort of added in.
So if you had a 5° steady state error, as soon as you touched the stick, moved it just a bit, it would accept that error as the new target, and so it would offen yaw to face 5°! So you could touch the yaw stick just a bit, trying to push it left, but instead it would move right 5 degrees! This was driving me nuts.
So what I've done is change it so that Nav_Yaw never accepts an error. And the stick input does not go to a rate determined by Yaw_Stab_P. Now what happens is that Nav_Yaw setpoint is always held, even if there's an error, but the Nav_Yaw target moves at a fixed rate determined by stick input. So if you have a 5° steady state error, and you command exactly 90° movement, it moves exactly 90°. It does not accept the error, and then move.
It is very important that you will all need to go and really crank up Stab_Yaw_P. This no longer controls the rotational speed of the aircraft. The rotation speed is hard coded to the stick angle now, and should be about 90°/sec at full stick. You need to crank up Stab_Yaw_P as that allows the AC to keep up with the incoming yaw commands. Basically it should make it sharper. I used to fly with Stab_Yaw at 2.5, and I've gone as high as 7 now with no instability.
It's important to do this as it increases the "sharpness" with which the AC will follow the yaw commands. If Stab_Yaw_P is low, it will be "loose" feeling, and you may even see a bounce-back after you let go of the stick.
On my helicopter, I ended up with really really great yaw control, check it out:
But one very important point to note in all this:
When the stick is all the way down, it accepts whatever the current yaw is. So you can walk around, set it down, arm it, and it will not try to move unexpectedly. BUT! Once you arm it, and then soon as to raise the stick even a little bit, that yaw controller is active. If you are still on the ground, armed and motors running, and you touch the yaw control, it will move the target. It will try to move, but it can't because the thing is on the ground. As soon as you lift off, however, it will yaw to the target.
It's an unfortunate side-effect, but I'm not sure what to do about it at this point.
Also, at present, the maximum yaw rate might be lower than people would like. The rate is hard-coded to be linearly variable with the yaw stick input. In the future, this will probably be a parameter, but just please bear with us we work through this. I tried to set the default to some happy middle ground, which is what you see in my video. Marco has already hacked the code to double the rate, and still wants more! ;)
Now, what's really awesome about all this, is the yaw control with my heli was so completely terrible before, that I had been assuming that it was the compass that was wrong, because the heli was always doing these really weird things. Just seemingly had a mind of it's own and it was all I could do to control it. Now it's rock solid, and I have learned that the compass is actually darn near perfect.
I should also say that be using some of the "best practices", I've managed to get a completely negligible effect from electro-magnetic interference. So it is possible.
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
-
ArduRover User Group
184 members
-
Moderators
24 members
-
Documentation Editors
51 members
-
ArduCopter User Group
1288 members
-
Australia
78 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
