Flying in althold, my desired roll/pitch angles are very jagged, which causes the rate D term to go crazy. It seems to be caused by the lack of smoothing of the RC control inputs (but the RCIN logging is too slow to show that). I thought smoothing the input was the purpose of the ATC_INPUT_TC parameter, which I have at the default value of 0.15.
You can see that the desired pitch angle moves in a stepwise fashion, the steps are about 22ms long (~45 Hz). The rate D term consumes these steps and causes the rate controller to struggle:
I suspect this is caused by the RC input not being smoothed, but I don’t remember ever seeing this before, so I must have misconfigured something, but I can’t figure out what.
Hi Rick, that is definitely odd.
It is safe to use ATC_INPUT_TC,0.2 up to 0.25 without causing too much sluggishness. This wont be the cause of those strange graphs though.
I always just use these logging settings:
The batch logging ones can be set to 0 after the copter is tuned and working as planned.
Anything else is surplus to requirements unless you’ve been channelling Leonard Hall and know what to do with all the extra Fast and Sensor rate logging.
Ah, okay, then I misunderstood how that parameter works. All of the ATC_RAT_*_FF gains are set to 0 so I thought it was essentially disabled anyway, and I thought the input to angle target smoothing was handled by the input TC.
As for why I turned that off, I wanted to look at the simulated step responses in the PID review tool, and the methodic configurator said to disable FF to do this. In fact, various tuning guides suggest to set ATC_RATE_FF_ENAB= 0 to evaluate the quality of a tune. This now seems like strange guidance to me, given that it affects the input rather than the rate control loop like I thought.
Which block do the ATC_RAT_*_FF affect, and which one is ATC_RATE_FF_ENAB? I thought they were both the FF block in the rate PID controller, but if that’s true, then why does disabling the FF do anything if all the FF gains are 0?
A question for @Leonardthall ! I am only going off the code and the input shaping is only active when that is enabled. I always found that parameter a little weirdly named but that’s probably based on my own misunderstanding.
Understood - thanks Rick. Apart from some “more jagged than normal” I’ve never seen that stepped appearance from fast logging or any input shaping (what I call input shaping anyway).
This is what does the smoothing. We turn this off to directly test the angle P loop because when we are using the command model (the thing that does the smoothing), we are effectively flying in acro so only small errors are corrected using the Angle P, even in large attitude changes.
