lukash
Smooth ramping of ATR and Torque Tilt
This feature has been tested by a handful of riders for the past few months.
Following the example of inputtilt where ramping rates of over 50deg/sec are used, we're doing the same for ATR and Torque Tilt now.
Setpoints are ramped slower when near the current setpoint. This allows for much higher ramping speeds without causing a jerking effect.
Instead of using 5deg/sec and 3deg/sec one can now easily run 20 and 12 or even more without any perceived downsides.
Factored it out into a function now (without changing the logic). Haven't done any test rides with it yet to see if functionality got affected...
The way I did something similar was by having targets already smooth, multiplying target_diff by a "Responsiveness" parameter (let's say 15) to produce deg/s, which gets limited by "Max Speed". Then multiply by dt to get the step.
So just a rate limited P control. I like how simple yet user friendly it is (for example changing Max Speed doesn't affect near-target behavior). It's been working great for me, but tbf I haven't tried the proposed changes, so maybe I'm missing out on something.
Where are we on this? People are asking for this feature and I'm tired of sending them custom Refloat packages...
I'm sorry for the delay, I wanted to test this, but I don't have that much experience with ATR. I'll get to it this weekend.
Very excited to see what you have in mind after reading through Discord, @lukash! I've been toying with this too, might as well share some findings:
- What I mentioned in this comment is equivalent to applying a simple EMA filter to the target and then rate limiting it.
- A higher order filter could work better, basically easing into sharp changes (in a way reducing setpoint acceleration) and not lingering for too long. Recently I learned that cascaded EMA filters produce some of these higher order ones (dividing alpha by the number of stages keeps roughly the same delay). 2nd order looks like a biquad with Q=0.5 (no overshoot).
- Rate limiting before EMA can have a similar smooth quality, but it tends to add more delay, especially in the rate limited regions (compared to limiting last).
- Personally I like defining filters that can be "felt" using half time, here's a desmos demo (slightly related to #17). I'm pre-computing the alphas like this.
When I say "rate limiting after EMA", I'm using the EMA's output as the target of rate limiting and storing only one variable. So technically not the same as the 2 consecutive operations, but it has a smoother "release" when the limiting stops and saves resources.
Here's a plot comparing a few options on some generated noisy data.
- Blue: 1st order -> rate limiting (updating 1 var)
- White: 3rd order -> rate limiting (updating 3 vars)
- Green: rate limiting -> 1st order (updating 2 vars)
I'm probably risking being super annoying considering that you teased about posting plots, that's not my intention 😅
And not sure how useful it is, but I found out that this form is pretty much identical to a 2nd order IIR + rate limiting. Essentially what my previous comment suggested but with additional speed smoothing (2nd order requires 4x less filtering per "speed EMA", 3rd order 6x, not sure what's up with that). I don't have this in code, sorry.
Ultimately added manually as a stopgap solution before the new smoothing is finalized.