I’ve been having this issue for about a year now, and as of yet, haven’t found a solution.
To start with, here is a video displaying the wagging yaw issue:
youtube.com/watch?v=7amHcd-Ws3A
This yaw wagging only occurs with a top mounted yaw mechanism. I’m sure it’s got everything to do with the mass of the yaw mechanism initially moving the tail in the opposite direction of where the controller wants it to go. Simply mounting the mechanism upside down ‘solves’ this issue since the mass of the mechanism helps move the tail in the direction the controller wants it to move.
I’ve tested this with Arducopter 2.9.1b and 3.1.2 firmware.
I’ve also swapped servos in order to reduce internal servo gear slop as much as possible.
When I used the KK2 board on this tricopter, it did not have this wagging issue.
The only downside to using a bottom mounted yaw mechanism is the much increased chance of prop strikes, especially when landing hard, or in rough terrain or braking for a landing. So I really hope this issue can be fixed or that someone can lead me in the right direction.
Want logs? Just tell me what you want logged and I’ll let the tricopter wag for you.
Thanks for the tip on mounting the yaw under the boom.
I am also having yaw wagging with AC3.1 and would be happy to log any data needed.
All I need is to know is what to log, and what flight-profile to use during logging.
Mine moves very similar to the video in the previous post, in Stab, Alt.Hold and Loiter.
I’ve wrestled with this issue over two different tricopters running APMs and found a thing or two. Nothing definitive though.
I’ve noted that the more flexible the tail boom is, the greater the wobble. On my first APM tri, I stiffened the tail boom with thin sheets of G10 fiberglass, and the wobble went away. I then added much larger props, and it returned.
I’ve also found there’s a definite limit as to how much you can do with PID tuning. The wobble really shows up when graphing Yaw versus NavYaw. The oscillations show up as sinusoidal waves in the Yaw, going above and below the NavYaw. This looks to me like overshoot, so increasing Yaw P or I shouldn’t help much. I did get some improvement by increasing Yaw D, which cuts down the overshoot. But you have to be cautious about too much D.
An alternative you might consider to mounting the tail prop upside down is just mount it lower. If you could get the CG of the motor/prop system lower, in line with the centerline of the tail boom, then it would be pivoting around the boom and shouldn’t induce lateral motion. I would guess this would require some sort of mechanism built under the boom.
It is odd that none of this happens with a KK2 board.
It could be the control algorithm of the KK2 board that makes a difference. I’d have to see how they do it.
I think part of the problem, and we have the same issue on helicopters, is that the Nav_Yaw is almost too rigid. You’ll always have some small angle error, because the yaw rate can never stop instantly. But the controller wants it to.
Most simple systems, if you yaw, and then you tell it to stop, it will stop, and it doesn’t really care where it stopped. If you wanted it to stop at 15° North, and it stops at 17°N, it’s fine with that. It will just sit there. This is how standard heli gyros work, and it’s probably how the more simple flight controllers work. But our controller says “Nope, you need to be at 15°, get back there!”. So it sends it the other way, then tries to stop at 15°. But again, because of the servo lag, etc, it stops at 13°. So again, the controller sends it back…
The only thing you can do is sharpen up the PID, so that it stops super fast, to reduce the overshoot. But eventually you run up to the stability limits of the PID.
I found that FeedForward helped helicopters. But it’s still not perfect.
What happens if you guys set Yaw I to zero? Does the wagging stop? It might get slopier in other ways, but does the wagging stop? If yes, then I suspect FeedForward will help.
Multirotors don’t suffer the same effect in yaw, because they use motor torque to create yaw, and the motor torque response is virtually instantaneous. Much faster than a servo. They don’t have as much bulk yaw authority or power, but they are more responsive. So when yaw, and then trying to stop, you’ll usually get one bounce-back, but then it stops precisely.
I did some testing a few hours ago and linked yaw stabilize P to a transmitter pot. I found that the wobbling seemed to stop when I brought the P value down to the 1 - 2 range (default is 4.5). I believe the directional lock won’t be as solid now, but I’ll test it more when I get the next chance and when it’s less windy.
Rob: Helicopters don’t have to shift masses around in order to change the yaw direction, so in that respect they are quite different to tricopters. The mass of the each motor and prop is significant compared to the rest of the tricopter frame which is a simply a lightweight Y made of sticks. If I were to put the tricopter on the ground, and connect the yaw servo to a servo tester and just move it in one direction, the tricopter will shift in the opposite direction, and shake on it’s landing gear. That’s an unwanted side effect that the firmware is going to notice and react to in flight.
Perhaps lowering yaw stabilize P is the key and the main factor that causes the effect you describe in your 3rd paragraph, but I’m not sure, since the documentation is too brief on this. If it is, then that’s nice to know, and perhaps it can be optimized, specially for tricopers, so that yaw stabilize P is dynamically decreased towards 0 or some fraction of it’s normal value if the yaw deviation is within a certain tolerance. I hope you can follow me on that. So what it should effectively do for example is: if the tricopter yawed 10 degrees too far, then use normal yaw stabilize P to correct it as it is currently done, but if the tricopter yawed only 1 degree too far, lower the weight of yaw stabilize P to say a 1/4 of it’s set value so that the tricopter is very slowly and gently moved to the wanted yaw direction.
I don’t know how difficult that behavior would be to code.
I think MultiWii uses a similar idea in it’s horizon mode. It’s a mode that’s like stabilize, but when the sticks are moved to extremes, then the stabilizing/leveling effect is dropped and it becomes acro. Or so I’ve heard.
So you got results tuning Stabilize Yaw P and not the Rate P? I’ve never tried that and not sure why it would work, but I’ll look into it. My tricopter is complicated by having somewhat larger props, 16". When the servo starts moving the motor/prop system, there’s not only a lot of mass it’s pushing against, but a whole lot of angular momentum.
Yes, but it was somewhat windy, so I’ll need to perform more tests to be sure. The rotational momentum of the yaw propeller cannot induce yaw oscillations: it’ll theoretically only produce slight pitch oscillations (due to it’s precession effect) in the most extreme case of using very large and heavy propellers on a very light and short armed tricopter.
I had a chance to fly my tricopter today, and did so in FPV. FPV makes tuning so much easier because you get to see every movement clearly.
Anyway, I can confirm that it flies great now. Having done an autotune (amazing feature!) and lowering the yaw stabilize P to around 2 has made it a fantastic flying machine. It’s so stable and locked in now, and also quite aerobatic too, performing rolls and flips etc. Pure zen. Many thanks to the arducopter developers for making this possible.
Thanks for that update. Mine’s currently at 3.5, with minor wobble, so I’ll try dialing it down to around the 2 area also.
If you do it like I did (flying FPV with yaw stabilize P on a dial), then you can tune it just right for your frame. The mass and CG of the yaw mechanism, length of the arms, and general mass of the frame will all be factors influencing which value is right for your tricopter.
Wow, what a difference. I brought Stabilize Yaw P all the way down to 1.00 from 3.5 and it was flying really nice. No sign of a yaw wobble visually or in the logs. There was a bit of tossing around as it was windy, but I’m pretty happy with the way it’s flying. I set my final Stabilize Yaw P at 1.30.
Excellent catch on your part. Yaw wobbles have been driving a lot of people who have APM tricopters crazy. It may be just that the default APM values for Stabilize Yaw P are just too high for some tricopter designs. That would probably be a good thing to add somewhere in the Wiki.
Interesting observations guys.
In the past, I’ve also played around with the Stab Yaw P, and was running it at 2.0… It also just felt better to me.
But there’s a problem you should be aware of. The Stabilize R/P/Y PIDs run in “earth frame”, while the Rate PIDS run in “body frame”. So, let’s just say as a point of discussion, you have Stab R and P at 4.0, and Stab Yaw of 2. It’s great in a hover. But if you have it rolled over 45°, the body-frame yaw Stab is no longer 2.0. It’s actually between 2.0 and 4.0. I hope you can see this in your head… I’m not sure how to explain it better in words.
So what happens is, you have things tuned well in a hover, but then if you roll it over (or pitch it up), you can get a yaw oscillation. What needs to happen, and I think Leonard talked about this, was converted the Stab R/P/Y terms to body-frame before using them.
Now just think… I have this exact same issue on helis in roll and pitch as well. And I’m still trying to figure out the ultimate solution.
[quote]Perhaps lowering yaw stabilize P is the key and the main factor that causes the effect you describe in your 3rd paragraph, but I’m not sure, since the documentation is too brief on this. If it is, then that’s nice to know, and perhaps it can be optimized, specially for tricopers, so that yaw stabilize P is dynamically decreased towards 0 or some fraction of it’s normal value if the yaw deviation is within a certain tolerance. I hope you can follow me on that. So what it should effectively do for example is: if the tricopter yawed 10 degrees too far, then use normal yaw stabilize P to correct it as it is currently done, but if the tricopter yawed only 1 degree too far, lower the weight of yaw stabilize P to say a 1/4 of it’s set value so that the tricopter is very slowly and gently moved to the wanted yaw direction.
I don’t know how difficult that behavior would be to code.[/quote]
Again, this is really interesting. About 1-2 years ago, I actually experimented with a “deadband” on yaw, where, if the error was <5°, the stabilize controller would not push the rate controller. So as long as it stopped in that window, rate wouldn’t be poked back and forth. It seemed to work, but got lost somewhere in the shuffle.
I think I’m following you…The more a tricopter rolls or pitches, the more the Stabilize Yaw P value moves towards either the Roll or Pitch P values? And a possible suggested fix (with new code) is to create a nonlinear Stabilize Yaw P that is coupled to the roll/pitch values?
If I’m understanding you right, that would certainly be a good fix. But I wonder if it’s really necessary for most usage? For me the wobble is annoying only when hovering or moving slowly forward, and doing video or other imaging. This apparent Stabilize Yaw P fix would take care of that, wouldn’t it? For more, um…enthusiastic attitudes, then not so much. But I wouldn’t be doing video with a tricopter for that, I’d use something else.
My only concern here, and Rob you might know this, is there any downside lurking out there to lowering the Stabilize Yaw P to a very low value? Is there some flight situation that will get worse due to the Low P value? Of course if there is, I will likely find it.
Actually, the easiest way to visualize the EF-BF rotation issue is this. Imagine you roll the aircraft 90°. Now the Stab Pitch P actually controls the Body-Frame Yaw, and the Stab Yaw P actually controls the BF-pitch. The fix is to rotate the BF Stab numbers to the EF before calculating the error compensation from the outer stab loop. I think Leonard said he wanted to do this, or something like it.
What I was suggesting with dead-band is something else entirely. This would help the straight-hovering problem where the yaw bounces back and forth endlessly because the servo always lags the command response. The proper solution would be an adaptive flight control that actually understands how the system behaves, it would understand servo lag, and compensate for it. But that’s probably a long way off.
I flew with Stab P at 2 (in all axes) quite a bit, and didn’t have a problem, but that was on a heli which is more aerodynamically stable.
Rob, thanks for your replies. Do the Arducopter developers have a ticket system where these ideas for improvement can been noted so that they don’t get lost?
Yes:
github.com/diydrones/ardupilot/ … ate=closed
That doesn’t mean it’ll get worked on, unfortunately. None of the devs have a tricopter, AFAIK. I think Leonard was interested in one at some point.
I actually spent most of the weekend working on trying to tune up my little 450 heli. About 18 batteries… It definitely seems to do better with StabYawP=2 rather than 6. I’m not quite sure why yet.
The same is true of Stab Pitch and Roll P. The whole thing led to potentially a concept of a different controls strategy for helis. But again, I think the dynamics of a tricopter are very similar, so might end up being the same.
All - thank you for the updates. I finally have my Pixhawk tricopter up and flying. Flies well with my former APM settings - Loiter is really solid. I’ll see if I can tune down the Yaw as I still see some shake.
The yaw wag really only caused issues when using my Mobius camera. Not bad but some shake back and forth. With the Pixhawk build I also added the yaw axis to my gimbal. It’s fixed now - no wag in the video. Only minus is the extra weight of the 3rd motor which cuts down some on flight time.
Very soon - I’ll try autotune on this new frame then play with the yaw and see what happens