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?
I have a new theory about problem 2). I believe this is to a large degree, being caused by imbalanced motor torque forces. A tricopter has 2 motors turning one direction, and a 3rd motor turning opposite. This is in contrast to a TradHeli, where all the rotor torque is in a single direction.
Helicopters have an issue where, when you jam the throttle up (collective pitch), there's a strong yaw created. We have already fixed this for the most part by using a feed-forward, where basically a little bit of opposite yaw is added according to how much collective pitch is being used. So the rudder servo actually moves at the same time as the collective pitch servos. It's pretty slick and works well.
I think Tris could benefit from something similar. However, they have another problem. The yaw reaction is constantly changing just due to the Tri trying to stabilize itself. Particullarly in the CCW/CCW/CW configuration, if you enter a roll command, the yaw reaction completely changes. So in addition to the problems of lag with the yaw servo, you have a problem where it can never settle down even if you're not trying to yaw it.
So what I would like to do, is may yaw compensation feedforward similar to the helis. Basically sum all 3 motors, or sum 2 and 4 and then subtract Motor 1, depending on the configuration. Multiply that by a parameter, which feeds forward into the yaw controller.
What do you guys think, is this an extra step that will be too confusing?
Since no one dare to answer, this will be an over-enthusiastic reply. (Did I mention I was one of your biggest fan ? :-)
First of all, thank you so much for the yaw fix in your git-clone. I tried the "alternate-yaw" method in 2.6, which I found quite precise but delayed and slow as hell. I'm currently flying your code with the gain scheduling, and so far so awesome. I can see the tail servo moving to prevent the overshoot, and it is really efficient doing exactly that. I quickly dialed in the rate P and stab P, which give me a slow and steady rotation with a low stick deflection, and about 1.5 turn/sec at full stick. I can confirm that all the issues listed on the first post are gone. I feel really happy the way it is (but pushing boundaries, 2 turns/s will seems attractive to me ;).
On my tricopter (700kv motors, 11x48props, all turning in the same direction) the throttle does not induce any noticeable yaw, even while punched hard at takeoff. I have however noticed a trend to drift slightly and steadily, then to correct smoothly the heading every 10 sec or so when the rudder stick remain centered for a long time. Will try to disable the compass and/or record Tlog for my next flight.
At last, the yaw isn't perfectly axial (the tail tend to drop slightly and the roll may bounce very slightly) but with good PIDs, that's only happening at high yawing speed.
To conclude, your latest fix made a world of difference, even if there is some room for improvement. I'm strongly in favor of pushing your code through the MP repo, for the tricopters at least. If you have something to try, feel free to contact me. Thank you very much for your awesome code.
Will try to upload logs and/or video ASAP.
Jazztech, thanks for your comments! Glad to see somebody has tried this!
About the slow steady yaw error with centered stick, I'd really love to see some logs on that. I really need the flash logs with PID logging enabled, and the set Ch6 Tuning to Stab_Yaw_P or any yaw term, which will make the PID log the yaw stuff.
I suspect what you are seeing there is actually compass calibration problems, but I'll need more data.
As for the "not perfectly axial" comment, is this a yaw problem? Or are you saying that your Tri bobbles in pitch and roll when spinning fast? That could be a bigger problem with the stability of the roll/pitch, especially at high turn rates. One thing that might be possible is if the Yaw servo is moving faster than the motors can respond to the required thrust changes. For example, if you stab the yaw, the motor moves over a lot, decreasing thrust on the tail. The motor needs to speed up to make more thrust to compensate, but it can only respond once the tail has started dropping.
Really the only way to solve that problem is some feed-forward. Not sure if there is any or not, I'd have to look.
Sorry for the delay, Its family time, out of tricopter's reach ;)
I agree on the compass calibration problem, since the heading displayed by the mission planner is steadily shifting when the tri is on the ground. Tried to manually enter declination, used tlog and auto calibration without much success for now. The platform being compact, isolating the magnetometer from power sources is proving difficult (all power wires are shielded or twisted). Had to set AHRS_Yaw back to 1. The axial problem seems to be cg-related. When using multiples batteries, the cg is shifted forward and the yaw become quite ugly. Can be solved or at least minimized by placing the batteries closer to the tail. The tri also bobbles in pitch and roll when spinning fast, but that's not much an issue to me. Will send dataflash logs with PID logging enabled next week when I will be back home (if it stop raining).
Thank you so much for your awesome piece of code.
Do you really have your Stab_Yaw_I and Rate_Yaw_I as Zero? I'm surprised it flies well at all like that, and it's entirely possible that is the cause of your yaw wandering. Try setting Rate_Yaw_I to 0.010 to 0.040 as a starting point, see if that helps. I am surprised you don't have the same problem with the yaw drifting to one side and not stopping, as Glenn has.
I think with this code, it will be really important to have Rate_Yaw_I set properly. I might guess that the only reason this worked for you is a happy chance where your mechanical linkage is offset just the right amount to allow it to work.
That Rate_Yaw_I is very important, as it is what allows the whole thing to find center and come to stop, which is what allows it to then lock onto a heading.
Yes, I disabled both stab and rate yaw I. In an attempt to make the damn thing works with the main trunk firmware, I adjusted the mechanical linkage so that when the servo is centered and throttle is applied, the tail motor has the right offset to stop the rotation induced by the prop torque, as instructed in a post about tricopter's yaw problem. Even with this adjustment, the tri drift a bit when no yaw order is given for a long period of time, as described above. I blamed the magnetometer calibration for that, but I don't had the time to try it with mag disabled (it has been raining like mad the last few days here in Paris, and I had some preparative to do before family trip, but I will investigate the case and send dataflash logs and tlogs as soon as I can when returning home). Will try to add some rate_yaw I too. Thanks for the input !
Oh, very interesting stuff. I love it when my theories prove to be true!
Definitely throw some Rate_Yaw_I in there. You may find the slight wandering is because it's zero. That was the revelation to me that started this whole thing for me. I had horrible yaw control, assumed it was the Mag the whole time. Then I looked carefully at my logs and realized that it KNEW that it was off-target but just wasn't trying very hard to stop it!
Hi Robert, thanks for putting this time in on this. I didn't see this discussion until now. Your suggestion of replacing my yaw servo with a faster one (0.08sec) seems to have solved my yaw oscillation issue (or reduced it to a level where it's barely noticeable at least) and also it didn't seem that it would incorrectly yaw the wrong way with a small amount of stick input either, but I have only had one quick flight since making the change, so it could still be there.
I'm keen to try your new code with the gain scheduling. Is this the branch I should be checking out?
Right, so I've just had a few flights with this. I've compiled the source from Robert's WIP2 branch.
First up I was running my new hextronik d-mg16 servo, and it seemed to hold yaw pretty much correctly, however I gave it some full throttle punches, and it spun around the yaw axis making me think that the torque from the tail motor stalled the servo out.
Then I replaced the d-mg16 with my old bms-385dmax, and full throttle punches now don't cause the yaw to spin, however the original issues of the yaw oscillating, and the yaw moving the wrong way in response to light stick input one direction returned.
I then added #define ALTERNATIVE_YAW_MODE ENABLED to my apm_config.h and recompiled, and that has given me more precise yaw control, although at full stick the yaw response is still a little slow, do I need to do anything else to enable the gain scheduling?
Glenn, just got back from ~5 days of being outside of comm-range. ;)
When you use the code in my branch, are you sure that you are using the Yaw Control branch? The master branch in my clone is basically trunk, (though it's usually somewhat behind the latest). But you need to change to Yaw Control branch and work with that.
I think you're using the wrong branch, because ALTERNATIVE_YAW_MODE probably shouldn't even compile in my branch.
Ah yes that makes sense. I was just using the master branch in your clone. I'll have to figure out how to get the yaw control branch now and will report back after giving it a go.