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
Hey,
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.
here's it:
http://code.google.com/p/arducopter/issues/detail?id=375&q=y6
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
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?
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...
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.
ugh.. lol.
I'm buying a skywalker.
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.
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!!
diusgruntled x-member hacker..
the way YAW is now working in 2.6 is FAR better than anything before, it just needs a tweak in terms of getting it a little more 'sensitive' so you dont have to stick all the way right/left to get some movement, I've added abour 90% negative expo and is perfect, the BOUNCE that was in previous code is now mostly gone.
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.