LinuxCNC S-Curve Accelerations

Hi,

To inform you all.
I designed a new scurve algoritme the past day's. Based on something bare simple.

Here a video of the scurve : video

This scurve has 3 periods for acceleration- and deceleration periods,

1. concave
2. linear acceleration
3. convex

The curve is based on the lineair acceleration formula :

v=vo+a*t

v=velocity, vo=velocity start, a=acceleration, t=time.

The implementation of the above formula makes it behave like a scurve.
Every cycle in the concave and or convex period the "a" is incremented
by a value "a_step". This simple thing makes it behave like a perfect scurve.

Let me know how you think about it..?

Source code : github.com/grotius-cnc/scurve_idea/blob/main/jog.h

Notes :

The source is working but not stable.

Trying to explanation why :

This is born out of a problem
with the scurve inplementation following
the science papers attached to the project where
Andy is pointing to in previous post.

The main problem in some scenario's is calculating the
jerk max. jm value. This value is based on a few inputs
like "velocity start" & "velocity end". It also relates
to acceleration start & acceleration end values.

In some cases, i found that the "velocity end" value can not
always be calculated on forehand.

In short, for full path calculation, that end with
acceleration end is zero, there is no problem.

The problem occurs when using acceleration end values and
recalculate a curve from there.

For example when releasing a jog button, machine will make a
controlled stop. Acceleration gets down. When then pressing the
jog button again, this is really a problem for calculating the
next curve i found out.

So your acceleration at time t is a(0) + a_step * t with a_step constant? AFAIK that is called "constant jerk".

Its relatively straightforward to calculate for one axis. Tricky thing is a) figuring out how kinematics folds into it b) figure out path blending.

going from line segment to circle has a (large) step-change in acceleration perpendicular to velocity vector.

So your acceleration at time t is a(0) + a_step * t with a_step constant? AFAIK that is called "constant jerk".

For linear acc-dcc:
v=vo+a*t   

For scurve acc_dcc
v=vo+(ap+a_step)*t  

Where ap=acceleration previous.
Where a_step=acceleration increment/decrement value for each servo cycle, usually 0.001 sec.

In the concave part for each servo cycle : a=a_previous+a_step.
In the convex part for each servo cycle : a=a_previous-a_step.
Then update "a" each servo cycle : a=a_previous.

The jerk is then : jerk=acceleration_end-acceleration_start / time. This value is "constant" during the acc-dcc periods.

Its relatively straightforward to calculate for one axis.
Indeed straight forward, but get's more complicated if using acceleration end period's to resume movement's etc.

Until now this example is only tested for jogging one axis.
Path blending, kinematics, etc are not included in this test.





 

very cool project here!! How are things coming along @Grotius have you found a successful scenario for s curve? I do have some questions regarding your previous comment on challenges of handling changes such as changing max velocity during a program. does this refer to actually changing the max velocity slider or the feed override? I think that in some situations there would be a good use for even a s-curve that was limited on all of those features. something that could be used for production machines where proven programs are run for hours and days at a time with really not much user input or change. maybe have a setup where if any external influence such as override or max velocity changes etc were activated that it would revert back to trapezoidal. this way a user could fine tune a production program which could greatly benefit from this bang bang machine saver update. is this something you think is possible?

Speaking personally, for simpler machines such as 3 axis mills, is this component near capable to handling that type of situation? i would be more than happy to test if you would like as i am facing some pretty bad jerk issues that i would love to get rid of and it would appear this could certainly help!

thank you for all your hard work!

Lcvette wrote:

Speaking personally, for simpler machines such as 3 axis mills, is this component near capable to handling that type of situation? i would be more than happy to test if you would like as i am facing some pretty bad jerk issues that i would love to get rid of and it would appear this could certainly help!

thank you for all your hard work!

Sorry to crash the party, but there isn't really anything to test.

Generation of jerk limited trajectories is not that hard, there are even complete libraries available github.com/pantor/ruckig. Some types of curves like bezier curves of sufficient degree are inherently jerk limited.

Unfortunately the hard part is coming up with a concept that can be integrated into linuxcnc. The TP stuff isn't very hackable. 

Hi,

How are things coming along @Grotius have you found a successful scenario for s curve?

To update from here. I made a conventional one axis motion controller code in c++ with some help of ai
for the used formula's. It's called SMP "simple motion planner".
The code is on github : github.com/grotius-cnc/motion_tryout

The above project took me quite a while, with up's and down's. Especially the live motion mode was
giving bug's during testing. This is when the motion is live performing during the servo-cycle.

It was a struggle, and i finally found out the problem, made a solution for it, It's now working.

The SMP is capable of planning a motion given a displacement "s" and some velocity values
for cruise speed "vm", initial speed "vo", final speed "ve", etc.

It can already be used for jogging, no problem.

The SMP can plan the curve or motion on forehand.
During the "live motion", user can modify the "cruise speed", controller will respect this value.
User can press stop, and motion will do a controlled stop.

If this SMP code is polished & accepted by the community, the transition or expansion to a-scurve lib is
easyer to do.

For above code i also made a sample for a 9 axis controller with axis synchronisation. All is quite nice.

This SMP library is header only and can be used in a hal component. This can result in a
multi axis motion component.

Perfomance is outstanding.



 

Hi Grotius,
Good progress.
I have suggested something similar earlier in this thread.
forum.linuxcnc.org/38-general-linuxcnc-q...ons?start=240#216601
Every motion can be broken into 3 parts and represented by polynomials.
During execution, we can compute the current value of the polynomial by advancing the time.
For immediate feed override action, we can speed up or slow down the time increment for popping the values from the polynomial.
Polynomials can be one of 3 types: accl, decel, constant vel.
For S curve implementation, each accel or decel polynomial can be broken into 2 or 3 parts which are represented with a higher order polynomial. See the method of jerk-percentage I have alluded to earlier in these threads :
forum.linuxcnc.org/10-advanced-configura...tics?start=90#124855
forum.linuxcnc.org/38-general-linuxcnc-q...file?start=20#183298
please share your thoughts on these 2 extrapolations i.e., feed override and jerk limitation.
-automata

Hi Automata,

For immediate feed override action, we can speed up or slow down the time increment for popping the values from the polynomial.

This would certainly work. But the solution for this made in the SMP is slightly different :

In general for every servo cycle step a new motion is generated on forehand. This is needed to finish exactly where we want to.
For immediate feed overide, a change in "vm" will calculate a new motion.

In simple words, the algoritme looks wich periods are needed to create the motion to respect "vo", "vm", "ve", "s, "a".
There are multiple scenario's possible. More then you can count on one hand.

If the feed overide is changed during live motion execution, you will see the motion is accelerating to the new max vm value.
This is really nice to see it happen.

github.com/grotius-cnc/motion_tryout/blob/main/smp.h line 211 is the function to determine how the motion will look
like.
It calculates the motion periods : t1,t2,t3. including types : acc,dcc,steady.

please share your thoughts on these 2 extrapolations i.e., feed override and jerk limitation.

For the s-curve you need a few things. The t1,t2,t3, the vo, vm, ve, a, s.
With above info the "jerk max" and finally the scurve can be calculated. The jerk max is one of the most
important values to define the power of the scurve.

The difficulty i see in performing the scurve in live mode is when changing the feed override, how to deal with it?
I need to write some functions for this. Functions that can calculate vm changes for scurve.
This is nasty code to write. But i can ask the ai to help a little.