LinuxCNC S-Curve Accelerations

grandixximo wrote:

@ruediger123
For your exact parameters: 1ms cycle, 50 m/s³ jerk, 5 m/s² acceleration, P0.01 on a 45° corner, the only cornering speed that mathematically fits within the jerk limit on a 1ms grid is zero. 

I don't think it's actually zero, but it's pretty close. 
Centripetal acceleration is v^2/r and centripetal jerk is v^3/r^2.

My back of the envelope math says the maximum velocity at a 45 degree junction with .01mm deviation would be .0056 m/s or .336 m/min to keep centripetal acceleration at 5 m/s^2. That would produce a centripetal jerk of 4568 m/s^3, which is an order of magnitude over the limit. 

To keep the jerk within the limit, the maximum velocity at the junction would be .001243 m/s or .0745 m/min. At that velocity it would take 8ish servo cycles to traverse the radius. 

But, for all intents and purposes, it's basically a full stop. 

Wouldn't it be pretty simple to find the maximum junction velocity to keep both jerk and acceleration within the limits of each axis? We have everything we need to make that calculation. Interestingly, since corner tolerance, max accel, and max jerk are constants, this velocity limit is only dependent on the angle. That would make it pretty easy to use a look up table generated by the tolerance setting. 

onehossshay.wordpress.com/2011/09/24/imp...cornering_algorithm/
 

Jerk-Aware Full-Stop Fallback (The "G64.1" Proposal) - is possible solution but what if ...

Path Tolerance Splining (Point Compression): Instead of treating the corner as a "sharp" mathematical point, use the G64 P tolerance to convert the corner into a tiny, high-order polynomial curve (spline). This gives the "train" a physical radius to turn on, spreading the Jerk over several segments even at high speed?.... it should plan for the re-parameterized spline. By doing this, the "junction" disappears, and the Jerk limit is satisfied over a distance (the spline radius) rather than a single 1ms step. - but comp-power consuption will be high

or look-ahead Acceleration Pre-Smoothing...Use the look-ahead buffer to start the direction change "rotation" slightly before the actual vertex. By "bleeding" the X-axis velocity into the Y-axis earlier, you reduce the magnitude of the step-change at the corner. "Bell-shaped acceleration" or "Jerk-limited FIR filtering." - but not actual timing 

or second much faster thread which will handle just calculation to fine result .. as Taylor Series expansion to "fill in the gaps" between those 1ms updates: P(t) = P_0 + V_0 \Delta t + \frac{1}{2} A_0 \Delta t^2 ... This should ensure that the drive receives a perfectly smooth 4kHz or 8kHz stream, effectively making the Jerk "infinite" at the digital level but "finite" and smooth at the physical level ?

Unless I'm not understanding some fundamental concept, isn't that how it already works?

You can't cheat the actual physics. Any corner 90 degrees or less will require a nearly full stop to achieve the P tolerance. The more acute the angle, the smaller the blend radius you can have to satisfy the P tolerance, and the closer to a full stop the machine has to come.

Put another way, centripetal acceleration, jerk, snap, crackle, etc depend only on velocity and radius. If you want to follow a constant radius at a constant velocity, the acceleration, jerk, etc will be constant. Only their direction changes, not their magnitude.

The only way to reduce jerk in a corner is to reduce the velocity or increase the radius.

An option, which has been discussed earlier, is an "egg" shaped corner radius where the jerk increases to a maximum at the middle. That might be preferable since at the midpoint the jerk force is shared by both axes. You could accomplish roughly the same thing by decelerating before the radius, accelerating toward the midpoint and decelerating again before the exit.

Another option would be to permit higher centripetal jerk than straight line jerk. This would be similar to input shaping used in 3D printers.

I don't see how much can be gained here. Fancy blending algorithms will be too slow to benefit the fast machines they are intended to benefit.

 
I was wrong, on closer inspection the planner can stay within the jerk limit without falling back to a full stop.

It was a bug in the jerk budget split during Bezier blends. Tangential jerk (Ruckig along the path) and centripetal jerk (curvature change through the blend) were budgeted independently, 50% and 100% of the per-joint limit respectively, assuming they're orthogonal. They are in Cartesian space, but not per joint axis, where they add as scalars. For @ruediger123's octagon: 25k + 50k = 75k on a 50k limit, matching the ~47% overshoot in the HALscope trace.

Fix: subtract the tangential share before allocating centripetal. 25k + 25k = 50k, exactly at the limit, no overshoot, no wasted headroom. Corner velocity drops ~20% vs the buggy code, but it's the true physical maximum.

@PCW was right, the TP should always obey constraints. Fix is in the 9d branch.

Edit:
the artifacts at the end of the page.
I'm also looking at what Automata had reported, I think I can improve merging of small segments, I'll put some effort into that


Edit:
I think the previous build maybe have some issue because I merged master without being careful
New build, still working on speed, not ready yet

delete link, this had issues too

I have been experimenting with planner type 1 for a while now with 3-axis milling machine. Generally it seems to work but I'm having problems with g33.1. What is the current state with tp1, should it work when running g33.1? Right now I get error "ruckig_plan_position: invalid limits (v=0.000000, a=3000.000000, j=120000.000000)" at every spindle revolution. In ini file I have nonzero traj(default_linear_velocity, max_linear_velocity), axis' and joints(max_velocity).

EDIT: did more testing. Slowed down spindle speed, looks like the error appears all the time and not only once in revolution. The z-axis velocity seems to be bouncing between 0 to something when the control tries to keep the axis synced, and the tp1 planning breaks every time the speed goes past zero. The other (bigger) problem is when g33.1 is on the bottom and spindle rotation changes, joint2 following error appears.

I solved this temporarily by adding a hal pin to tp which sets true when spindle synchronized motion is on and used that to live change to tp0. With that rigid tapping works just fine although the same z-axis velocity bouncing is present.
 

I know TP2 does not support G33.1 yet, I thought TP1 did but never tested, might have to do some work there, thanks for reporting, will try to patch it up soon

github.com/LinuxCNC/linuxcnc/actions/runs/24246961815?pr=3807

new build has slight speed improvement, still working on it

Found another bug/missing feature in tp1. Hitting feed hold sometimes breaks planning, I guess the remaining length of current segment is too short to calculate using ruckig?
Ruckig planning failed (first attempt),
Back to tp 0
feed_override: 0.330000
max_vel: 132.000000
cpos: 380.077500, tpos:
380.133525, dx: 0.056025
cvel: 33.000000, tvel: 132.000000
cacc: 3000.000000
maxa: 3000.000000, maxj: 120000.000000

hi grandixxmo, any further development on the 9D S-curve branch?
what is the area of testing we need to look at.
If we can setup some direction, we will get multiple volunteers to help check the work that is already done.
-automata

It's been reworked by YangYang, 9D branch will probably be abandoned, in favor of whatever YangYang comes up with, it's loosely based on my work form 9D branch. What we are working on now internally, which I was going to talk in the next meeting, is a pre-processing library, as we are testing Yangyang's TP2 internally before release, we found that the last few jerk spikes were caused by segments that are shorter than a cycle time, there is just no time to do proper calculations on them, the pre-processing will be a toggle in the INI file, the library will be called Liscio, also renaming Ruckig to Scatti cause that's what we talked about with smoe in the mailing-list, and YangYang can't pronounce Ruckig 
Anyway Liscio will create a smooth path with NURBS, still early stages, would love some test gcodes from the community, so we can kink out most issue internally before release.
There is precedence commercially with Fanuc I believe, they are doing similar work, probably others as well.