LinuxCNC S-Curve Accelerations

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?

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.