Soften RCOUT transitions

Hi, I would like to know if it is possible in Arduplane to soften RCOUT transition, when deflecting input sticks. As you can see in this exemple, stairs effect present in RC input (probably due to sampling frequency or my own thumb movment) is reproduced on output. I would have prefered a gentle curve on output instead of stairs jumps to motor output. Of course, in this exemple on throttle, this is only a problem in not assisted throttle mode (FBWA in that case)


It is something called “RC Smoothing” in Betaflight and maybe it also exist in Arduplane but I can’t find it.
Thanks
Alex

ArduPlane has a throttle slew rate parameter: Complete Parameter List — Plane documentation
This limits the rate of change of throttle output.

Hi, thanks for your reply. I know that parameter but it does not act exactly as RC smoothing. Throttle slew rate act on the output responsiveness, not on the output curve itself. Reducing throttle slew rate will negatively impact accelerations and not reduce this stairs effect.

@Alex Exactly how do you want to “Smooth” the output without adding a slew ?
It cannot predict how rc input will change, it only sees the change and responds to it, the rate of the response is governed by the slew rate. If you want more smoothness, you have to increase the RC input update rate by using protocols that can do it.

1 Like

Well in fact there are at least two different ways to smooth the RC signal and that stairs effect (mainly due to TX framerate + frame rate vs PID loop + transmission latency but also jerky stick movements). As for every kind of signal you can interpolate or filter (lowpass). Of course, (due to mathematics it implies) this adds some latency between stick and motor reaction but it comes with an important benefit : it reduce the impact of each stair to FeedForward which is very sensible to setpoint jerk and at the ends smooth motor output without adding delay in motor response like Throttle slew rate do.

  • Interpolation adds more latency because it implies to wait for next TX packet(s) (negligible if you use modern TX like ELRS or CRSF at 150Hz but also because piloting plane is less sensible to TX latency than piloting quadcopter) but can smooth more aggressively depending on interpolation interval.
  • Filtering (PT1 or Biquad) adds less latency but at the cost of no totally smoothing the curve and also is more cpu impacting

I think that Ardupilot would really benefit of this kind of feature

1 Like

Well, now we are talking about smoothing the RC input, and not the motor output.
But the original issue was the throttle channel and motor output steps.

The result from a well setup slew time, will be almost the same as interpolation or filtering. It won’t be a smooth curve, but have the same effect.
(Black is a PT1 filter, red is a slew)

My initial question was about smoothing motor output by smoothing RC input :wink: This could be extended to every channels that said. In fact your diagram shows exactly what I mean when I said that throttle slew rate acts differently. You clearly showed that a Filter accelerate lot more at the beginning than slew (this could be increased by modifying filter frequency) and this is where it is important. This should give better pilot feeling on fast transition. That’s why I think that RC smoothing could be a good benefit in Ardupilot. It acts “sticky” to stick deflection whereas slew is a fixed rate that tends to give the feeling that plane is slow to respond. Even if at the end both come to the same Setpoint at the same time.

It looks like it’s taking almost a full half second for your RC input to change values. I’d suggest that no amount of smoothing would make that refresh rate feel responsive. What RC protocol is that?

Hi, I think it’s a misinterpretation of the graph. I use CRSF protocol (50hz/150hz) that is used to be around 6ms of latency (TX->RX) with a Radiomaster TX16s RC that should not be a bottleneck.