LinuxCNC S-Curve Accelerations

rmu: I'm not sure I would expect people to test my code as long as there are known bugs left? Also you say not to "run on something that moves" so I'd say having one person test it is rather encouraging!

Those Bezier curves give interesting shapes to the jerk.

rmu wrote:

Please keep in mind that this branch does NOT change the trajectory, it is only manipulating accelerations.

This means you will have to come to a complete stop at every line-arc (and arc-arc) intersection if the TP is set for exact path following (G64 P0) (see this post ). Any velocity > 0 through the intersections gives infinite jerk. So that's one interesting situation to test.

Edit: And even if set to do blending I'm guessing that the current TP runs at full speed, while following the programmed G code exactly, in the case of e.g. a line -> tangential arc transition (as long as the arc itself does not violate the acceleration limit)? That transition is also an infinite jerk situation where you'd have to come to a complete halt to limit jerk while not modifying the trajectory.

I didn't really mean for end users to test that, target audience is developers. Running on "something that moves" may be a bit dangerous as long as there are excursions of acceleration limits. I just posted the link to this old thread as illustration that the problem is not how to generate S-curves, there is a bunch of possibilities (exponentials, polynomials, "manual" segmentation in segments of constant n-th derivative, etc...) that are more or less straightforward to implement. The hard part is the trajectory planning and how to factor in kinematics. Speed, acceleration and jerk limits should really be applied per joint.

My hack just changes the "execution" of the segments generated by the unchanged TP to smoothly change acceleration (of tangential velocity). At the beginning and the end of a segment, acceleration and jerk is zero. Max acceleration should be limited to double that of the acceleration used by the TP.

As I said, some unexpected excursions of acceleration may occur. I really should go back to the code...

I'm not sure what (else) to do in the exact path mode situation. There is no "exact" in the real world, so something will give, but for me, specifying G64 P0 means to not do any path blending.

Caveat emptor. I'm not an expert. YMMV.

No, for sure no path blending with G64 P0. I'm just saying that in contrast to the current acceleration-limited planner you'd have to come to a complete stop between *every* segment to have limited jerk. And that would be a good extreme-situation test of the jerk-limited planner - to make sure it actually does stop completely between each segment.

When you say segment, are you talking about only straight line segments or do you also consider an arc a segment? I'm not sure how LinuxCNC handles things at the level you're talking about, is it feeding only straight lines to your smooth velocity generator or also higher-level entities like arcs?

If only lines, there will of course be infinite jerk on each transition between non-colinear segments. If both arcs and segments there will be infinite jerk on the start and end of each arc, due to centripetal acceleration.


I guess what I'm trying to say is that, just like you cannot have a practical/usable acceleration-limited trajectory without blending through sharp corners, you cannot have a jerk-limited trajectory without modifying each and every arc - reducing their radius and inserting a transition curve and start and end of each arc. If you're not modifying the trajectory, the only thing you *can* do is limit jerk on straight line (or rather constant radius) moves with zero velocity at both start and end?

The reason I'm so anal about the above point is that

1) It's not exactly intuitive (it took me a long time to realise)
and
2) I don't want people to waste time trying to make the TP do something that's physically impossible. Better to to realise why you cannot have jerk-limited perfect arcs and then spend one's time creating a jerk-limited TP that actually works.

The arc-thing is kinda obvious to me. Say your line is parallel to X axis and you approach an arc, you will then have your x-speed proportional to cos(t) and your x-acceleration proportional to -sin(t) whereas your y-speed is proportional to sin(t) and your y-acceleration to cos(t). At the beginning of the arc (t=0), your Y-acceleration make s a jump, and a jump in acceleration means infinite jerk.

The Trajectory planner outputs "segments" that could be lines, arcs, quadratic and cubic splines and even NURBS, but only arcs and straight lines will be blended.

Those segments are "executed" with the "Trapezoidal Planner" that generates a trapezoidal tangential velocity profile. My "hack" changes this profile to 6th order Bezier curve (see pictures in other thread).

github.com/rmu75/linuxcnc/blob/rs_6otp/src/emc/tp/tp.c#L2436

rmu wrote:

The arc-thing is kinda obvious to me. Say your line is parallel to X axis and you approach an arc, you will then have your x-speed proportional to cos(t) and your x-acceleration proportional to -sin(t) whereas your y-speed is proportional to sin(t) and your y-acceleration to cos(t). At the beginning of the arc (t=0), your Y-acceleration make s a jump, and a jump in acceleration means infinite jerk.

Exactly. Took me a while to realise that you actually have to modify the shape of the trajectory to get around this.

rmu wrote:

The Trajectory planner outputs "segments" that could be lines, arcs, quadratic and cubic splines and even NURBS, but only arcs and straight lines will be blended.

Those segments are "executed" with the "Trapezoidal Planner" that generates a trapezoidal tangential velocity profile. My "hack" changes this profile to 6th order Bezier curve (see pictures in other thread).

github.com/rmu75/linuxcnc/blob/rs_6otp/src/emc/tp/tp.c#L2436

How much of a difference does a jerk-limited tangential velocity do in a typical tool path? It depends on the settings of course, but just trying to get a feel for it. There will be infinite jerk at every segment boundary, and also each time the tangential velocity changes (without jerk limiting). How often does the planner have to change velocity, typically? Also on the order of once per segment?

arvidb wrote:

How much of a difference does a jerk-limited tangential velocity do in a typical tool path? It depends on the settings of course, but just trying to get a feel for it. There will be infinite jerk at every segment boundary, and also each time the tangential velocity changes (without jerk limiting). How often does the planner have to change velocity, typically? Also on the order of once per segment?

I'm not sure. It should decrease the amount of energy you pump into resonances of the whole machine. It should make a world of a difference with jogs of individual axis.

Replacing blends between segments with some kind of (per axis, better per joint) jerk limited path obeying constraints like acceleration and feedrate is where it gets complicated, ideally you would also involve kinematics.

edit: I forgot to mention that the positions are filtered once again before output to the servos (cubic spline IIRC), that also will limit jerk somewhat.

arvidb wrote:

How much of a difference does a jerk-limited tangential velocity do in a typical tool path? It depends on the settings of course, but just trying to get a feel for it. There will be infinite jerk at every segment boundary, and also each time the tangential velocity changes (without jerk limiting). How often does the planner have to change velocity, typically? Also on the order of once per segment?

Each segment has an "enter" and an "exit" velocity. In between, the bezier curves ensure limited jerk and smooth transition of acceleration. Segments that are executing should not be changed any more, this situation is unhandled at the moment. Also things like feed override don't work (yet). Change in tangential velocity happen in a segment and not as a step, so that should be covered.

On my machine (big old heavy wood router with kinda-slow analog servos), doing spirals at feed rate, even fast ones, is not really a problem, whereas single-stepping or doing G0 moves in quick succession like you get from adaptive clearing toolpaths can really shake the machine. The hacky approach should at least deal with jerkiness from G0 moves.

Thank you for the analysis. Maybe tangential-only jerk limiting is more useful than I imagined. Interesting!

Regarding kinematics: I don't even want to think about jerk limiting, say, a robotic arm. Cartesian machines first?

When it comes to feed override and a full jerk limiting TP, I'm thinking that one solution could be to plan the trajectory for pre-set max feed rate and following tolerance, producing also data on max velocity at each point on the path. And then limit velocity further at each point, where applicable depending on current feed rate setting. Yes, it makes the tool path less precise than absolutely necessary, but on the other hand, do we want the tool path shape to change depending on feed override setting? Maybe there has been a lot of discussion about this already so that there is some consensus?

hello,

i'm not deep in this theme but very interested because some of the machines i'm doing are very big gantrys (>10 tons). For them i can't use Linuxcnc at the moment, the jerk is not controlable.

i'm not a studied mathematics, but my native language is C....

How and where is the feed override applied at the moment? In front of the look ahead?

Maybe this could be useful:

infosys.beckhoff.com/english.php?content.../1534284427.html&id=

journals.sagepub.com/doi/full/10.1155/2013/974152