c2 smooth velocity profile

In theory, my code should not lead to acceleration excursions.

It may be a bug in the math (unlikely) or some interaction / wrong understanding of trajectory planner on my part (very likely).

The tinyG 6th order bezier curves inspired me to the code in the branch

g2 fork claims, that jerk-free acceleration works with feed overwrite and start/stop

Hi rmu,
Excellent work. I want to help carry it forward.
First a few caveats that will simplify the problem:
1. Leave spindle synchronized motion alone. Let that fallback to the trapezoidal planner
2. For each call to tpRunCycle, if the value of the Feed override Velocity has changed, recompute the optimization with new feed value based on current feed (call tpRunOptimization). In this case, include whatever is left of the current executing segment too.
3. For Cycle Pause, do the same as (call tpRunOptimization again).
4. On Estop, do whatever is done currently.

There are only 3 sources of change of velocity for the planner during running.
1. Estop
2. Cycle Pause
3. Feed override

Each TC segment has an initial velocity vi, final velocity: vf and max velocity: vm. It also has a time taken for execution, tf and the starting position and end position. Assume that the start accel and end accel of each segment is 0 (for simplification of the problem) as you have done: (github.com/rmu75/linuxcnc/blob/ed7c30ab5...rc/emc/tp/tp.c#L2443).

Let me know your thoughts on the issue and maybe we can work on it together?
-automata

automata wrote:

Hi rmu,

Let me know your thoughts on the issue and maybe we can work on it together?
-automata

Thank you for your kind words.

I'm in the process of getting my dev environment back together. It shouldn't take too long for "master" to build on ubuntu focal. It seems the rs_6otp branch applies cleanly on top of rene-dev/limuxcmc. I will rebase my branch onto current linuxcnc as soon as the python3/gtk3 fixes are merged to master.

IIRC from my last tests, sometimes strange things like accel limit violations would happen when running 3D_Chips.ngc, and some circumstances start a motion that never stops.

Spindle synchronized motionc is kinda off-topic anyways, because motion is synchronized to whatever the spindle is doing, not the other way round as far as I understand it.

Jogging could be a useful thing to target.

But feed override is not that easy to crack, because it should be applied while the current segment is executing (that segment could be long), so it needs to be recalculated on the fly and ideally, axis should accelerate to overridden feedrate smoothly. I imagine a bunch of cases like current segment too short for acceleration, long enough with current feed but too short with new feed, and so on.

A possiblity could be to use an "internal" feed override that gets updated from "real" feed override, and those updates are smoothed out.Then no recalculation of segments should be needed, but I have to check if this works with the trajectory planner.

E-Stop shouldn't matter. With "real" hardware, drives go into e-stop and decelerate motors as fast as possible.

Hi rmu,
In case of feed override, for the current executing segment, we can initially relax the condition to have jerk limited transition to the new feed rate. Assume that acceleration can be changed instantaneously only when the feed override is changed. We can relax this condition later (not so hard to do once the remaining formulation/algorithm is clear).

On Feedrate change, we take the current executing segment. We already know the current position, velocity and acceleration and how much distance is left to be executed in the current segment.

We make a smaller segment of that size and insert it (not actually insert but use it in the optimization as the current segment) into the Queue for optimization.

Now there are 2 scenarios:
1. Feedrate has increased from the previous value: In this case we need to consider a complete plan to get to the new feedrate by running tpRunOptimization function with the part of the current smaller segment as the first segment.
2. Feedrate has decreased from the previous value: In this case also we need to replan by calling the tpRunOptimization with the current smaller segment as the first segment.

This call to tpRunOptimization can be done in the motCommandHandler function where the tpRunOptimization is generally called when the incomming command is tpAddLine or tpAddCircle etc,. OR it can be called independently at the start of emcmotController function.

The purpose of the tpRunOptimization is as follows:
Iterate through all the segements on the list from front to back and back to front and set the following 3 velocities,
a. segment start vel
b. segment end vel
c. segment max vel.

For jerk limitation, we can add a step to this process itself to compute the polynomials for each segment for executing a trapezoidal profile. So we will get 3 second order polynomials (t-polys or only polys) for each segment which are accel_poly, const_vel_poly and decel_poly. The polys could be zero time i.e., the poly actually does not get executed.

For executing, based on the time tick, we get a new value of the planned position from the current poly and keep advancing the polys in the queue once the segments finish executing.

This part gets us done with Trapezoidal type planner with second order polynomials. The math for this is easy enough to workout and I will have a short white paper on this soon for the benefit of our community.

Now here is the actual jerk limitation (or I would rather say jerk percentage limitation).

Based on the jerk percentage allowed value set from config, we can modify all the accel_poly and decel_poly to be broken into 3 more 3rd order polynomials (s-polys). Given the starting vel, ending vel, and time of execution, we can make 3 new polys that will keep the area under the accel curve (average velocity) same as well as the time of execution the same. For doing this we will have to increase the max acceleration to a maximum value 2 times the maximum acceleration specified. This maximum value is directly related to the percentage of time the first and third polys spend in increasing and decreasing the accel vlaue to the max value. If we specify jerk percentage as 50% max violation is 2xa_max. else the violation is lower.

We iterate through the trapezoidal polys in the segment queue and find any that have an acceleration transition (from max_accel to 0 accel or vice versa) and those polys we break into 3 more 3rd order polys. There are 3 cases we need to handle on this:
1. prev t-poly is 0 accel and curr t-poly is amax accel.
2. curr t-poly is amax accel and next is 0
3. prev t-poly is 0 accel and curr-tpoly is amax and next toply is 0.

In all three cases we can find the 3 new s-polys and use them for execution.

NOTE: The two things we kept constant when converting from 1 t-poly to 3 s-poly has been the area under the accel box and the time it takes for execution of the accel t-poly. This means we cannot really limit the actual jerk but only limit the percentage impact of jerk. And we will be doing this by violating the max acceleration limit for a small percentage of the accel/ decel time. Though not ideal, this will be better than the current scenario of infinite jerk.

Also, if we dont want to do this, set the jerk percentage value to 0, and we have only t-polys which is the current scenario as a fallback.

This ends the basic jerk percentage limited planner.
***********************************
Now we can handle the simplification we made earlier on about accepting an infinite jerk at the point of replan i.e. feedrate change.

The assumption we made about conversion from 1 t-poly to 3 spoly was that the average accel was always at amax at the start and end of a t-poly. We may need to relax that consideration for the conversion of the first t-poly where the initial acceleration can be anywhere from 0 to 2*amax. The guiding formula during conversion from t-poly to s-poly would be
1. keep the average acceleration the same
2. keep the time of execution of the t-poly same.

I will try to write up this approach in a white paper and post as this post has become a little wieldy and long.
But it does cover the gist which is
1. replan on feed change
2. represent the segments as 3x t-polys (2nd order polynomials) which can be further broken into 3x s-polys (3rd order polynomials).
4. on switching from t-poly to s-poly, keep the average acceleration same in the segment.
5. on switching from t-poly to s-poly, keep the execution time same as the t-poly.

We could optimize on this approach a little with the accel/decel t-poly spilling over into nearby const velocity t-polys but that is for further research.

let me know your thoughts on this elaborate method for jerk PERCENTAGE limitation.

Regards,
-automata

This means we cannot really limit the actual jerk but only limit the percentage impact of jerk. And we will be doing this by violating the max acceleration limit for a small percentage of the accel/ decel time. Though not ideal, this will be better than the current scenario of infinite jerk.

I have often wondered if we could use a similar approach to external offsets to respect the machine max acceleration limits. That is in the ini file have a JERK_RATIO setting. Say we have a machine that has max acceleration of 5 m/sec^2 and a JERK_RATIO = 0.2. The maximum trapezoidal acceleration would be reduced to 5 * (1.0 - 0.2) = 4 m/sec^2 and then the jerk limited curve could safely exceed this limit by 5.0 * 0.2 or 1 m/sec^2 without violating anything.

hi everyone

just checking in, I have a high speed machining center running linuxcnc (actually have 2 of them so can use on for testing everything for you guys. they are 6 ton machines so vibrate all over the place at the moment lol.. I am very keen to see a jerk control built into linuxcnc so if you guys want to test anything just let me know.. regards

Andrew

Hello, rum, I recently tried to set the curve acceleration, I saw your post on the forum, and then found your code on Github, after downloading it, I compiled it and ran it, but it had some problems. I use the MID command and it starts off well, but ends up pretty bad with a steep drop in speed. I saw your result picture and it works great, I would like to ask what command mode you were using, how far you moved it, speed settings and such, thank you very much.

The picture below is my result, thanks again.

In case this is addressed to me: I don't remember exact commands, but it was some short G0 or G1 move. The code obviously has some problems.

edit: added a screenshot of rebase on 2.9, g1 move with distance 20, feedrate 1000, metric. 

I updated the code and fixed a few problems. New branch is here: github.com/rmu75/linuxcnc/tree/rs_qvp_2.9

after g0 x0 y0 halscope of g0 x10 y20