curve smoothing

I have a curve-smoothing algorithm now that seems to work the way I like. The attached patch has the algorithm and replaces the standard linear interpolation with a cubic-spline interpolation (with some heuristics for the control points). you cannot switch between linear and bezier, this is just a proof-of-concept, not ready for checkin.

I am curious how folks will feel if you can only use 11-point (or less) curves with smoothing?

Adding more fields to the curve structure has a large impact on memory usage. the alternative of not pre-calculating the control-points has a potential performance impact.

On the Devo8/10/12 we have lots of RAM so I could pre-calculate the control-points without issue.
On the Devo7e, I'm in a bind because I don't want to increase memory allocation.

So my options are:
1) not support curve-smoothing on the 7e
2) do something special for the 7e (support fewer mixers or curve-points)
3) be consistent and limit all models to 9-point curves when using smoothing
4) increase the memory usage on the devo7e (probably limiting other capabilities in the future)
5) do-not pre-caclulate and hope we have enough spare cycles to not impact the system

I really don't like option (2) or (5) but I'm not sure what the best solution is here. I'm leaning towards (1) since I don't really want the devo7e to prevent me from developing features for the other radios, but I know a lot of folks use it, and this is one of the most-requested features.


Assuming you build from source, from the 'src' dir, run:
patch -p2 < path_to_bezier_patch_file

It looks like this:



I may do some tweaking to the endpoints as they are not quite as straight as I'd like, but I think it is just a matter of tuning.

I just checked in the code. You can play with it and see what you think. In the end I optimized it sufficiently that I think (5) will be ok. I also implemented (4) as a backup but it is currently disabled.

Code need some tuning, straight line is not straight.

I have specifically tailored the spline so that there will never be any overshoot. Since I define the control points, I can prevent that. That doesn't mean that there isn't more tuning to do (or even a better algorithm), but I've tried a lot of things, and this is the 1st time I was remotely happy with the outcome.

I guess I should have clarified that it is a cubic bezier spline (which has control points in the 1st place, and not some sort of cubic-fit.

I found some problem with 13 point curve, it's deposed to the left and on the right there is artifact (jump from -100% to 0%):

I think that doing sin or cos calculations on the stm32 will be very complicated for arbitrary values. We do not have floating point, and I don't like math enough to figure out how to do it quickly in fixed-point.

I figured out why vlad was seeing curvature in what should be a straight line. I made the simplifying assumption that f(t) is ~= f(x) which is a terrible assumption. Unfortunately it also means that the whole thing may be bunk, since calculating t from x may require a solver that i don't want to implement.

I replaced the bezier cubic spline with a hermite cubic spline.
It has several benefits:
1) it can be directly calculated as f(x) which makes it much better suited to our needs (straight-line performance is now good)
2) there are monotone rules for calculating the tangents to guarantee no overshoot. These are better formalized than the home-brew rules I developed for the bezier curve

This was the function that was originally recommended to me in the bitbucket ticket, but I completely missed that it works fine with local maxima.

Anyhow, let me know how it works. I still haven't looked into why the 13-pointcurve isn't functioning right. It is definitely a bug, but I don't think it is directly related to the curve properties.

I've resolved the offset issue vlad reported with 13-point curves as well now.

I basically follow the 'monotone cubic interpolation' method here:
en.wikipedia.org/wiki/Monotone_cubic_interpolation

The only significant change I made was to not calculate Beta but instead use m_k/delta_k+1 to enforce the monotonic behavior, since that is what I had available. this may not work perfectly, but so far it seems to be working as expected.

I found other artifact, spike on curve:

If point 6 value will be lower, spike on curve can overshoot 100%. It has place only with first ans last segment of curve.

vlad_vy wrote: I found other artifact, spike on curve:

If point 6 value will be lower, spike on curve can overshoot 100%. It has place only with first ans last segment of curve.

Thanks vlad. Calculating these splines in only 32bits without any overflow requires very careful management of multipliers. I had the order of operations slightly wrong and that was allowing the values to overflow. I've applied a fix that corrects this. Let me know if you see more issues.

I've found one more artifact.

7 point curve, throttle (ch3), -100, -25, 25, 55, 75, 90, 100. If throttle (Ch3) = 100%, at channel monitor Ch3 = 0% (and at right panel of emulator). Any decrease and Ch3 value restored. If curve smooth = Off, all works as expected.

Smoothed curve


Curve without smoothing