hi all,
I meet some issue about yaw overshoot in stabilize mode
do I need to add the ATC_RAT_YAW_D or change any other parameter?
log file for reference
https://drive.google.com/file/d/15imWI8TnND0kVyaYYc4VOTNO1jisxheg/view?usp=sharing
I’m not positive with trad heli, but in multirotor we would increase this:
ATC_ACCEL_Y_MAX, 27000
A higher value allows yaw to accelerate/rotate quicker and also decelerate/slow down quicker to better track your stick movements.
@jinchengde the delay you are experiencing in the rate trace is mostly due to the ATC_RAT_YAW_FLTT. You could raise that to at least 20 and maybe higher. This was hard coded in previous versions and it wasn’t until recently when I was looking at the command model stuff that I realized that this filter was creating the delay. I believe the concern a long time ago was noise from your transmitter Joystick signals.
As far as the overshoots, I would need to see some data with the PID logging turned on. I typically use a LOG_BITMASK of 131071
@bnsgeyer
I set ATC_RAT_YAW_FLTT to 20 and it looks better to track
I increase the ATC_RAT_YAW_P, and it looks better
@jinchengde Sorry that I didn’t get to looking at your log right away. So here is what I found. It looks like you are using H_COL_YAW as the collective to yaw mixing. Based on the amount of I term (shown below) that you are holding, I don’t think you have the COL_YAW parameter set correctly.
If you want to use the collective to yaw mixing feature, I think you would have to set the tailrotor mechanically so that it holds the tail steady while the aircraft is rotor turning with zero thrust on the ground. Oh by the way, you need to have the aircraft on a somewhat slippery surface so you can tell if the tail is mechanically adjusted to offset the torque of the rotor at zero rotor thrust (flat pitch). Then you can use the H_COL_YAW param to remove the yaw accelerations due to collective inputs.
Its up to you on how you want to go about it. But you need to get rid of the bias on the I term shown above.
@bnsgeyer , this feature works, but it is a linear response and it can cause undesirable pedal input when lifting up into hover, especially with large and heavy aircraft. I found using the normal yaw PID is just as effective as using the software mixing and doesn’t tend to load up on anti-torque pedal as pitch is increased to lift up into hover. I think it was put in the code because many FBL units have it for doing pitch pumps and so on. But UAV helicopters can have a wide variation in takeoff weight and a mix for MTOW vs minimum requires a different amount of mix to work properly. So what looked like a good idea on paper ends up being handled more elegantly by the normal yaw controller.
It was designed incorrectly. It assumes the rotor has no torque with zero thrust(H_MID_COL). So if you set your tailrotor servo neutral position to be flat tail blade pitch and you calibrate the H_COL_YAW so that the I term is zero in a hover, then the tail rotor compensation will not be correct for collective pitch settings above and below the hover collective pitch. Then there is the question of how linear is main rotor torque with collective pitch but it is probably a good approximation.
It is not linear. Watch the engine torque meter on any turbine powered helicopter as you lift up into hover. Speed is constant, so torque is directly related to power. The power requirement, and hence torque, is an exponential curve from zero to maximum thrust. What the exponent is I do not know, and it probably varies depending on many factors such as blade efficiency vs angle of attack. An airfoil operating at high angle of attack is considerably less power efficient than when operating at ideal angle of attack, and so on.
Yep. Totally agree. Probably want to find the relationship of collective to torque to make it more accurate throughout the collective range. But my main point was that nothing in this feature accounts for the bias needed for torque at flat pitch. And there is no documentation on how to set the tail blade pitch at the tail servo trim position.
I don’t know that that actually makes a lot of difference? I found some people set a lot of D-term, a moderate amount of P-term, and and set the integrator quite low and turn the VFF off. Otherwise it builds up on the ground during runup (integrator) or causes tail jerk in hover (VFF).
After I went away from using that collective to yaw mixing long ago that’s the way I went to setting the yaw controller, sort of based on the way Ferruccio was doing it, using the D-term primarily and set enough P so you got full pedal control with the radio. I don’t remember what I got for I-term in those machines, but it’s just about nothing and really haven’t had a problem with it since going to Ferruccio’s tail setting method. That yaw controller is so quick that even if the tail rotor is set to feather pitch at trim and it tries to yaw, the controller will catch it faster than any human can. And it is the same in hover if you suddenly pull full pitch for some odd reason.
I really haven’t seen a valid use for the COL_YAW mixing ever since. Nor any real reason to use much integrator or feed forward on the tail.
I actually got that COL_YAW mixing commented in my code because I found it doesn’t work right after we got a 180 degree tail swing on the Mosquito one day.
Great info. Thanks for sharing. So then how do you set the tail up mechanically for the trim servo setting. Flat pitch or hover pitch?
I just the trim eyeballing the tail rotor blades so they are flat pitch. That seems to work the best for pistons because if the tail rotor is blowing air sometimes have a hard time getting them to run up when the engine is cold because the tail rotor is drawing too much power. After it is run up and at full speed, then I bump and center the pedal (yaw control) to apply a little counter torque as I lift up into hover and then let the yaw controller take it.
That bump and center moves the ghost a little when it’s on the ground, but that’s where the integrator causes issues because the integrator keeps applying more because it didn’t move. That’s where Ferruccio said get rid of that - don’t need it on the tail on a heli - the old tail gyros never had it, they’re just a P control and didn’t even know what compass heading they were holding. I had never thought of it that way before, but it worked.
thanks @bnsgeyer
I set the rc4_trim from 750 to 730 and the PID.I could around zero, that have effect but not too much
on another way, I increase the ATC_RAT_YAW_P from 0.2 to 0.4 and ATC_RAT_YAW_D from 0.02 to 0.07 and have more effective.
@ChrisOlson
the method you said turn off the vff for the yaw. do you mean set the ATC_RAT_YAW_VFF to 0?
That is correct. I found that if the P gain is high enough so you have full travel of the tail linkages, the VFF does nothing, and in fact, can cause it to constantly “hunt” on yaw. I think the feed forward is fine if you can’t use enough P gain without getting oscillations, but that doesn’t seem to be a problem on tail servos.
