I'm opening this up to try and get all the discussion about yaw problems into one place so that it's not scattered. I'm working very hard to fix the yaw control because it seems to be the #1 complaint about the general flight characteristics currently. It seems like everything else related to "just flying around" is doing quite well, except for yaw.
I'd like to start by enumerating the individual problems. Please feel free to let me know if I missed any.
1) Copter "bounces" after entering a yaw command and then stopping.
2) Copter oscillates back and forth when yaw stick is centered. This is predominantly a Tricopter problem, but I'd like to know if any quad/hexa/octos have this problem. Any amount of oscillation is too much. So if you have logs to show it's oscillating 1°, I'd like to see it.
3) Yaw is too slow. Currently, yaw speed is controlled in a round-about way by Stab_Yaw_P. So to yaw faster, you increase Stab_Yaw_P, but if it's too high, it can lead to steady-state oscillation. This is obviously a problem. I think I have also just identified a situation where the yaw rate is also capped, no matter how high you turn Stab P.
4) Copter turns the wrong way if I try to turn it slowly to the left or right. This usually only happens in one direction. For helicopters, it's usually when you try turning to the right slowly, it will go left at first, until you feed it a lot of yaw stick, then it will start turning right, and then may turn right too fast. After releasing the stick, it will often turn left again before stopping. I believe this also really affects Tris, but should not affect quad/hexa/octo unless your frame is bent/motors not straight. But I'd like to hear about it if you have a problem.
5) Copter rotates when I punch up throttle. This is largely a TradHeli problem, and we already have a fix (Coll-Yaw) but I would like to know if it affects others. I would bet that it affects Tris too.
So far, I have already boiled down a lot of these problems and understand them very well. I had made a yaw fix that was in 2.6Delta, but it was pulled before release because come people didn't like the way it felt (it was a little slow and "springy", but it is VERY precise). I am working on something that will make everybody happy. Dave has a copy of that and I'm waiting for him to test it. It includes a somewhat radical change: gain scheduling. This is an attempt to make the copter STOP NOW when you release the stick. Basically, if you are yawing, and then return the stick to center, and it is yawing too fast (overshooting) it doubles the output from the yaw controller. I have no idea if it's going to work and haven't even flown it myself. Hopefully it's not too screwed up and just causes a crash, I don't like trying to code without testing myself, but that's the situation I'm in right now.
I did just check in a small change into trunk that is pretty simple, and targets a number of these problems. Hopefully this should be tested and go out in 2.6.1. Basically, there was a bit of code that constrained the output from the yaw controller excessively (I think) when the stick is in the middle. This prevented the copter from being able to stop yawing, and contributed greatly to the "bounce". I already got rid of this for TradHeli, and it helped a lot. So I've also gotten rid of it for all other Copters and that will get tested soon.
Now, problem number 3) is going to require a new parameter, where you rigidly set the yaw speed relation to full stick. I'd like to set the default to something that most people are happy with and won't even have to worry about that parameter. Can we get a consensus on how many rotations/second most people want? 1 rev/second? 2? 1/2?
Cheers I'll give the new code a go.
How hard would it be to implement a min/max pwm value for the yaw servo travel? I'm still getting my yaw servo being locked hard over to one side and buzzing when disarmed, and would like to stop this from happening. If there's any other way to limit the yaw servo travel I'd be interested to know how.
Yes, there should be a way to do it, I'm surprised there is not in the code already? We have this for helis, and should be just a case of implementing it for Tris. I'd also be curious why the servo moves all the way to one end when disarmed? Is it always the same direction, or does it move as you yaw the airframe while walking around? Did it always do this or it's new?
Yeah this servo problem has only started occurring since I got my APM2. It didn't happen on the APM1. I'm powering my servo with a BEC.
When I run my d-mg16 servo, it locks over to the right when disarmed, and when I ran the bms-385dmax or turnigy 380 max it locked over to the left when disarmed, but with those servos I had to reverse my yaw in radio setup and also on the TX for it to work correctly.
I'm guessing that the reason it didn't happen on APM1 was simply because a code change happend at that time. I think it might be a little mistake in the AP_Motors class that was instituted... about 2 months ago?
This is a little more urgent now. My tail servo just burned out as a result of it being locked hard over to the side, and I only have one more spare, so I'm pretty much grounded until I can figure out how to stop it from doing this.
Ok Glenn, in combination with your other post in the 2.6 thread, I think I know what needs to be done. I'll have a look.
Thanks, I'm looking forward to trying it out and seeing if I can finally get this freaking thing to be reliable!
I am going to have to try this. Thank you.
Just put together a QAV500 quad with APM1 and am seeing problems #1,#4 and #5.
Hi Felix. Sorry this is offtopic but regarding the QAV500 - how did you connect the ESC leads to the APM? Did you just connect them directly to the APM or did you modify the leads at all? cheers.
Hello Simon -
Didn't realize I was still subscribed to this thread :)
I removed the + lead from the ESC servo connectors and plugged them in vertically to the APM1.0.
Power was fed to the APM via the RX connector rather than a PDB. The RX was powered from a dedicated 5V BEC.
The + and - pins on that edge of the APM 1.0 are common buses, respectively.
Hope that helps.
Thanks Felix. That was helpful.