I have a Trex 600 with a Pixhawk 4 mini and it has a weird tail wag in any mode for example pos hold.
When I input a left or right movement of the tail the problem is increasing.
Any tuning doesn’t seem to make it better, what am I doing wrong?
I would really like to start with the autotuning, but this requires a steady flight first.
Movie of problem:
Log file:
Isnt the noise too high in your y axis?
Do you use a yaw torque tube or belt? If torque tube, move the inner bearing to a position that doesnt coincide with a vibraition mode. Dont put it in 1/2; 1/3 or 1/4 distance, this simple measure can break the noise down.
@Ojwhaaa_Ojwhaaa
In reviewing your log, it appears that you may have your yaw Rate P or Rate D gains too high. However it also could be that you have the angle P too high.
I’m not really sure how to interpret this graph, but I think again the RATE.Y is the cause of the problem? I also think it could be due to the tail and governor interacting, because before I enabled the governour I didn.t have this problem. Another weird thing is that it is drifting when switching from POS HOLD to ALT HOLD But how to troubleshoot this, I really don’t have a clue where to start from here, please help 
Log:
Movie:
I think it could be due to the tail and governor interacting, the problem started when I enabled the governor function, before that it was alright, thanks for the reply
@Ojwhaaa_Ojwhaaa set H_RSC_MODE to 3 (throttle curve) and conduct a flight with some hovering and heading changes to see if you get the weird yaw behavior. Then post the log. I want to see that the yaw behavior is normal with pilot inputs and also see if the tail is tuned properly (without feedback instability).
Once we know the tail is tuned correctly and there is no weird yaw behavior with pilot inputs, then we can turn on the governor and go from there.
With H_RSC_MODE set to 3 I have no problems whatsoever, the tail is perfect still even with fast yaw movements. So the problem is indeed the governour interacting with the tail somehow. I still don’t know exectly where to look for in the graph, but to me this looks better with less intense spikes.
What I also still don’t understand is why in ALT HOLD mode the helicopter is drifting to the left and when I switch to POS HOLD it stays perfectly still in one place.
I below the last log with H_RSC_MODE set to 3:
https://1drv.ms/u/s!AiJnqSX-_IInonYusPz3Bpf8si0L?e=wxHCm2
It appears that you still have some feedback oscillations going on with the governor turned off. You can see in your graph how the signals oscillate after the large inputs are made. It’s not terrible but could be better. I will take a closer look tonight.
In althold, the flight mode is designed to hold altitude only (vertical axis) and behaves exactly the same as stabilize flight mode in the pitch and roll axes.
In poshold, it is like althold in the vertical axis but in pitch and roll, it holds position when the stick is centered. When you make pitch and roll inputs it behaves like stabilize.
You can read about the different flight mode behaviors in the wiki.
@Pedro_Claro Thanks for commenting. I don’t think it is an electromagnetic interference issue(EMI). If it was, I would expect it to be more regular and repetitious. I believe @Ojwhaaa_Ojwhaaa commented that he was making inputs and the erratic behavior followed his input. I believe these look jagged because the RCIN data is only 10 hz data.
@Ojwhaaa_Ojwhaaa The tail tuning could be better but I don’t think that is the root cause. If you would like, I recommend zeroing the ATC_RAT_YAW_VFF gain. In the data you can see that it overdrives the response. This will help with the inputs not being so abrupt. Then you can lower the ATC_RAT_YAW_P gain to 0.21 (this is a 25% reduction from your current). Hopefully this will remove the oscillatory behavior without degrading the tail response.
After you flight test that to ensure it is responding nicely, then turn on the governor and I would recommend lowering the droop compensation (H_RSC_GOV_DROOP). It is currently at 40. Lower it by increments of 5. I wouldn’t go much lower than 20 but that is just a guess on my part. @Pedro_Claro has more experience with governors than I and might be able to make a recommendation. Looking at the most recent log without the governor, the RPM held fairly constant but that was mostly steady hover.
Hope this is useful. Regards,
Bill
Hi Bill,
sorry for insisting, I didn’t understand your answer and I’m intrigued I really enjoy following these problem analysis, they help me in the future to face my own problems more efficiently, I hope you don’t feel confronted
I measured the pulse times and they have a rise time of 200ms when the pwm starts from 1500 to 1800 and a fall time of 200ms from 1500 and 1100, total of ~400ms. Making this fast movement with the joystick on the remote is very difficult. I agree it shouldn’t be an EMI problem, but couldn’t then be a problem with the yaw potentiometer on the remote?
Cheers Pedro
No not at all. I appreciate others weighing in on these issues. I am not the expert on all of this stuff.
Yes I agree that it seems odd that these sharp inputs would be made by the user. Hopefully my latest recommendations will provide more insight to what caused the residual oscillations after these inputs. One thing in noticed in his setup is that the PWM from the yaw channel of the TX is reversed from what is expected. That’s why they reversed the channel 4 RC input on the controller. I don’t think it has any impact on this issue.
Regards,
Bill
Hi Bill, Pedro,
Thanks for putting in all the effort to help me solve this problem!
I followed the recommendations:
ATC_RAT_YAW_VFF = 0,0
ATC_RAT_YAW_P = 0,21
H_RSC_GOV_DROOP = 35
H_RSC_MODE = 3
Then I flew without problems when giving sharp rudder inputs where this is the log, he felt a little sluggish and not really tight rudder, but flew OK:
Then I enabled the governour function again and flew, with the same problems like before, but it seems a little milder, with this log:
H_RSC_MODE = 4
And here is the movie with governor enabled:
I’m thinking in abandoning the governor usage and using a throttle curve instead, because I really want to start with the autotuning, is autotuning also working fine without the use of a governor?
Hopefully someone knows how to solve this, because if Bill can’t nobody can
After watching your video I think I had already experienced this tail-twitching effect, that is related to DROOP very high. Try the following below, they where the values working well on mine:
H_RSC_GOV_DROOP = 5
H_RSC_GOV_RANGE=100
H_RSC_GOV_TCGAIN=100
For the new governor in 4.2 they are different settings.
Cheers,
Pedro
Continue lowering the H_RSC_GOV_DROOP by increments of 5 until the behavior goes away. It appears from what @Pedro_Claro wrote that you may have to go pretty low. Less than what I had said in my previous post. But @Pedro_Claro is correct that your settings for the governor in 4.1 may not apply to 4.2 as the governor completely changed in 4.2. If you want to use autotune in 4.2 then you can do it without the governor. Since your notch filter is set to follow the RPM then you should not have issues with vibrations if your throttle curve is not perfect. You just want the throttle curve to maintain a relatively constant rotor speed. (+/- 100 RPM) for the tuning.
