LinuxCNC S-Curve Accelerations

just for reference: forum.linuxcnc.org/38-general-linuxcnc-q...oth-velocity-profile

I agree code could be organized better. Unfortunately, my approach leads to acceleration constraint violations (that should not be there and which I don't fully understand) and leads to some really strange behaviour.

You said it well in that thread:

rmu wrote: Explicit constructions of an S-Curve with constant derivative of jerk followed by constant jerk, constant acceleration, constant velocity phases and at the end the other way back seems to be very messy and have a ton of cases and corners, especially if you want to continue a given velocity/acceleration/jerk.

It's an interesting challenge though. If there was just more energy available each day.

github.com/synthetos/TinyG/wiki/Jerk-Con...led-Motion-Explained

I'm curios about this project they have jerk controlled motion.
can we learn about it and implement in Linuxcnc?

Speaking of "cases and corners" in a jerk-limited jog planner, here's an interesting one:

t = 0.0 s: User presses right -> machine accelerates axis in positive direction (v_max reached at t = 0.30 s).
t = 0.35 s (first vertical line): User presses left instead -> machine accelerates axis in other direction to bring vel towards negative.
t = 0.58 s (second vertical line): User releases button -> machine stops axis.

At t = 0.58 s, vel is still > 0, but acc is maximally negative. There's not enough time to jerk acc to zero before vel has swung negative. So to stop the axis without violating the jerk limit, its velocity must swing negative before returning to zero; although the button was released while velocity was positive, you can see the position actually retarding a bit before the axis stops:


Fun stuff! O__o

I used a recursive algorithm and data structure to generate the plot above:

The "level" in the node diagram then corresponds to a certain polynomial degree: s3 is linear with respect to position, s1 & s5 are quadratic, and s0, s2, s4 & s6 are cubic in the example above.

The number of segments grows as a power of 2: 2^N-1 where N is the degree of the polynomial. So acceleration-limited motion is 2^2-1 = 3 segments, jerk-limited is 2^3-1 = 7 segments, snap -limited is 2^4-1 = 15 segments, and so on.

Just for kicks, here's a pop-limited (6th-degree, 63-segment) move generated by the exact same code, just fed with a longer limit vector (jerk = 5 m/s³, snap = 100 m/s⁴, crackle = 4000 m/s⁵, pop = 320000 m/s⁶):




Now this only works because the move starts with no initial motion, and the length of the move is carefully selected, as is the ratio between the limits, so don't get your hopes up too high for a generic pop-limited jog planner!

Now that I think about it though, auto-selection of any limits above acceleration (like jerk) might not be a bad idea? Not many users will want to dig into the maths and physics to learn how to choose sane limits... They/we just want nice motion, right?

They/we just want nice motion, right?

RIGHT!

Aciera wrote: RIGHT!

LOL :lol:

So how many chickens do we have to sacrifice to get it?

I'm happy to say sacrificing chickens is not an effective solution here.

I have a dozen or so tests that I run on my current code, and at the moment five still fails. And when those are fixed, I'm sure I can think of more "corner cases" that I need to test. So the code really doesn't work yet - also it's full of debug printouts, old misleading comments, and not least "panic!()"'s and "unimplemented!()"'s. I want to concentrate on development rather than publishing it and get a lot of questions about things I will change later anyway.

I do think the data structure and the idea of using a recursive algorithm were worth sharing though (in case I never do finish it, or as documentation if I do).

Then when I'm satisfied the code works I have to integrate it into LinuxCNC (now it just spits out a lot of numbers that I feed into gnuplot), which includes convincing you guys that Rust should be allowed into the codebase. Coding-wise I have a pretty good idea on what integration entails though; my code has pretty much the same interface as simple_tp and Rust interfaces nicely with C.

You could say I'm "90 % there", which IME usually means half the work remains.

Hi, I'm not sure how to solve your problem, but I can say that this problem *feels* like it wants an FFT in it...

I used to play a lot with audio and when first starting out I was tempted to think in the time domain and write interpolators and crazy stuff like that, which usually then spew harmonics, etc. However, they feel like the right solution intuitively. The real answer is to think in frequency space and then this stuff just drops out.

I suspect that this problem will lend itself similarly? Consider reading a little on audio resampling in frequency space and then see if this provides some insight into this problem?