LinuxCNC S-Curve Accelerations

I have a little bit of understanding of the frequency domain. Not through audio but through control theory, e.g. frequency analysis of PID and state space controllers. I'm far from an expert though: I guess I could do a frequency and phase analysis of a system with the help of my old textbooks if I *really* wanted to.

I don't know enough to see how to apply it to this problem though. Feeding in the target position as a stepwise time-domain curve and applying a low pass filter in the frequency domain would remove the infinite acceleration in the curve, I guess. How would further derivatives of position map to the frequency domain? How would you adapt the filter to ensure certain limits on not only acceleration, but jerk etc?

Maybe take the resulting time-domain position curve, take its derivate numerically to get acceleration, and then do another low-pass filtering to limit jerk? Then you'd have to integrate it back twice to get acceleration and position, and also ensure you ended up on the correct coordinate at the end of it all somehow.

It's intriguing - you should look into it!

Any update on this project,
I will make this question and please don't feel sad,
there is any person we can pay to make LinuxCNC to have jerk controlled trajectory planer, I think this feature is the only one that is missing in this great project.

I'm not sure about other's work, but the status of my work on a jerk-limited jog planner is that I got stuck and had to rethink it. I ditched my idea for a recursive algorithm and have rewritten it now to be in a better shape, I think. I have taken a break from it to clear my head a bit; the math is quite horrible. (I'm doing some work on EtherCAT drivers now instead and that is frankly much more straight forward!) I have not given up though and will look into it again - unless someone else beats me to it!

I have very limited energy to spend on this during a typical month, unfortunately. I do it for fun and for me, accepting payment would only add stress.

A tip for anyone who wants to tackle this problem is to look into using software that maniplulates symbolic math, like Sage Math . It seems it could save a lot of manual labour trying to manipulate the equations without introducing errors.

E.g. used for getting some equations for acceleration-limited motion (or equivalently, equations for speed in jerk-limited motion):
The equations for jerk-limited motion are far worse. So far I have only managed to produce gibberish when it comes to the trickier corner cases for jerk-limited motion (getting the initial conditions right is difficult) - but as I said, I haven't given up.

grijalvap wrote:

[Is there] any person we can pay to make LinuxCNC to have jerk controlled trajectory planer, I think this feature is the only one that is missing in this great project.

By the way, if you want to hire someone, hire a mathematician and have them answer the following:

Given initial acceleration a0, velocity v0, and position s0; j0 and j2 constrained to +/-J_CONST; j4 = j2 (I think) and j6 = -j4; and acceleration limited to some limit A_LIMIT; and this set of equations for motion:

s1 = 1/6*j0*t0^3 + 1/2*a0*t0^2 + v0*t0 + s0
v1 = 1/2*j0*t0^2 + a0*t0 + v0
a1 = j0*t0 + a0

s2 = 1/2*a1*t1^2 + v1*t1 + s1
v2 = a1*t1 + v1
a2 = a1

s3 = 1/6*j2*t2^3 + 1/2*a2*t2^2 + v2*t2 + s2
v3 = 1/2*j2*t2^2 + a2*t2 + v2
a3 = j2*t2 + a2

s4 = v3*t3 + s3
v4 = v3
a4 = 0

s5 = 1/6*j4*t4^3 + 1/2*a4*t4^2 + v4*t4 + s4
v5 = 1/2*j4*t4^2 + a4*t4 + v4
a5 = j4*t4 + a4

s6 = 1/2*a5*t5^2 + v5*t5 + s5
v6 = a5*t5 + v5
a6 = a5

s7 = s_target == 1/6*j6*t6^3 + 1/2*a6*t6^2 + v6*t6 + s6
v7 = 1/2*j6*t6^2 + a6*t6 + v6
a7 = j6*t6 + a6

What would be the maximum velocity reached, and what would the signs of j0 and j2 be, to reach a specific value of s7 with v7 = a7 = 0?

Answer that and I'm pretty sure the problem is solved (the jog planner, that is). Note that the problem might not be well-formed: it might be under- or over-constrained and part of the job would be to figure out what's missing to make it well-formed.

arvidb wrote:

A tip for anyone who wants to tackle this problem is to look into using software that maniplulates symbolic math, like Sage Math . It seems it could save a lot of manual labour trying to manipulate the equations without introducing errors.

Manually dissecting an "S" curve into phases of constant jerk, constant acceleration, constant speed etc... has a lot of cases, I'm not sure such an approach will yield something reasonably bug free.

Bezier curves / Bernstein polynomials have some very useful properties for this kind of stuff. Executing segments that were planned for constant acceleration with limited jerk and at max 2 times the acceleration is implemented in my branch, mentioned elsewhere, for "normal" moves (non-jog, non-synced). modulo bugs. I think this should work in principle, and be an improvement over current situation.

The really tricky thing would be an optimizing planner that generates segments with blends from g-code.

Indeed, I would think thorough testing (including regression testing to ensure one fix doesn't mess something else up) is essential, regardless of algorithm. Once you get into those corner cases with initial acceleration and/or velocity not zero (and velocity maybe greater than your current target, or the new target not even reachable without changing direction), things get tricky!

This is just one reason I'm preferential to Rust:

$ cargo test
Compiling smooth1d v0.1.0 (/home/arvidb/tmp/linuxcnc/smooth1d)
Finished test [unoptimized + debuginfo] target(s) in 0.39s
Running target/debug/deps/smooth1d-4677e64f2fc95240

running 30 tests
test path::tests::alim_continued_move_neg ... ok
test path::tests::alim_continued_move_pos ... ok
test path::tests::alim_inc_vel_novmax_pos ... ok
test path::tests::alim_dec_vel_pos ... ok
test path::tests::alim_move_all_limits_pos ... ok
test path::tests::alim_move_no_vmax_neg ... ok
test path::tests::alim_null_move ... ok
test path::tests::alim_move_all_limits_neg ... ok
test path::tests::alim_inc_vel_pos ... ok
test path::tests::alim_move_no_vmax_pos ... ok
test path::tests::alim_shortened_move_neg ... ok
test path::tests::alim_shortened_move_pos ... ok
test path::tests::alim_reversed_move_neg ... ok
test path::tests::alim_reversed_move_pos ... ok
test path::tests::alim_stop_neg ... ok
test path::tests::alim_stop_pos ... ok
test path::tests::alim_stop_interrupted ... ok
test path::tests::jlim_continued_move ... ok
test path::tests::jlim_move_all_limits_pos ... ok
test path::tests::jlim_move_no_amax_neg ... ok
test path::tests::jlim_move_no_vmax_neg ... FAILED
test path::tests::jlim_move_no_vmax_nor_amax_neg ... FAILED
test path::tests::jlim_move_no_vmax_nor_amax_pos ... FAILED
test path::tests::jlim_move_no_vmax_pos ... FAILED
test path::tests::jlim_move_all_limits_neg ... ok
test path::tests::jlim_move_no_amax_pos ... ok
test path::tests::jlim_stop_at_amax ... ok
test path::tests::jlim_stop_at_vmax ... ok
test path::tests::jlim_stop_not_at_limits ... ok
test path::tests::jlim_stop_switch_v ... ok

I published my code in case anyone wants to take a peek:
github.com/arvidbrodin/smooth1d

If nothing else the gnuplot script is quite a nice tool for visualizing the trajectories, if I may say so myself.

I see this code in the internet, I tested it un Octave and it seems to work but I really don't know if this can be adapted to our purpose

grijalvap: Drawing a random s-shaped curve is not that difficult. You also need to:

* Have it end after moving a specified distance
* Respect acceleration and velocity limits (limited first and second derivatives of the curve)
* Handle non-zero initial values (non-zero velocity and acceleration) at the start of the move
* Handle initial velocity greater than the velocity limit (since it's possible to set jogging speed during jogging)

It might be possible to base such an algorithm on an exponential function like in the code you found - I encourage you to try!

On a more general note, I don't think the lack of jerk-limited motion in LinuxCNC is because of a lack of skilled and engaged programmers, but because it's a surprisingly difficult problem to solve.

forum.linuxcnc.org/38-general-linuxcnc-q...oth-velocity-profile

Look at pictures in first post.

The problem with the code is that it exceeds acceleration limits in some situations and I don't understand why. Nobody except skunkworks bothered to even test it.