LinuxCNC S-Curve Accelerations

It should be noted that, the time to execute the acceleration/deceleration part of the motion segment will not change. Hence the overall trapezoidal trajectory planner need not be changed. Only the playout part of the acceleration and deceleration sections need to incorporate the jerk limitation parts.

To implement in linuxcnc, we could find the point where the acceleration/ deceleration is computed and break that segment it into 3 parts. If an acceleration/deceleration segment is represented by a second order polynomial, we can break that polynomial into 3 parts. Two of third order polynimials and one second order polynomial. The formula to compute the 3 polynomials from the original second order polynomial should be straight forward given the boundary conditions.

It sounds interesting.
The question is: Have you estimate the effort to do this implementation? How many hours of coding/testing?
Available time is the constraint.

Hi,

It should take about 2 man months for implementation and another few for testing and bug removal.

Just found this interesting site that has a standalone trajectory generator.
www.atwillys.de/content/cc/trajectory-generator-in-c/

The code here is a good starting point for testing the logic for a new trajectory planner. The good thing is it will make the trajectory planner simulator easier to integrate into linuxcnc. We need to integrate Robs new look ahead planner into this code.

What has always thrown me off is the cubic joint interpolators used in the linuxcnc planner. These should not have much effect if the rate of calculation of the new point from the planner is equal to the rate of application of the point. I am going to try out this theory with a few concrete examples to see if the joint cubic interpolators could be removed.

-automata

automata wrote:

Hi,

It should be noted that, the time to execute the acceleration/deceleration part of the motion segment will not change. Hence the overall trapezoidal trajectory planner need not be changed. Only the playout part of the acceleration and deceleration sections need to incorporate the jerk limitation parts.


-automata

I am not a motion control expert by any means..
I don't understand how what you are describing is possible.

As I understand it:
linuxcnc plans with no jerk limiting so in other words maximum acceleration.
If you add jerk limiting after planning then the acceleration profile must take longer, undoing all the planning.

The only way around that, that I see is to have linuxcnc initially plan with less then maximum acceleration.
This would give you head room to add jerk limiting on the ends and add more acceleration in the middle so the acceleration
profile ends up taking the same time.

So then I would imagine the percentage setting might represent how much over the INI acceleration setting jerk limiting would go to
maintain this acceleration time length.
ie 10% Jerk setting would add as much jerk limiting as you can while using 110% INI acceleration setting.

Is this roughly what you intend to try?
Chris M

Chris M: Yes that is exactly how jerk percentage works. You violate the Max acceleration constraint on the overall path. However, the ratio of the max_a in trapezoidal plan to max_a in jerkpercent plan is related by the formula
max_a_jerk_percent = max_a_trapezoidal*100/(1-jerk_percent*0.005). So you can also limit the max_a_trapezoidal taking into consideration the jerk percentage.

If jerk percentage is kept at 100%, which means the zero jerk time in the figure (support.motioneng.com/Software-MPI_04_00...n_ty_jerkpercent.gif) is 0, the max_a_jp = 2*max_a_trapezoidal.

One more point to note is that with jerk control enabled, machines are able to sustain much higher accelerations.

Then again, the jerk percent can also be set to 0, to retain same behaviour as the current planner.

-automata

That sounds very interesting.
IIRC the developers that did the cubic planner was not so interested in jerk limiting because he felt the acceleration curve would be slower (because of ramping time) on most machines that were low powered.
But I also remember the guy working on jerk limiting saying that he could increase acceleration with jerk limiting above what was possible without.
Of course the way you are planning on doing it, one could try either situation.
I'm rooting for you!

Chris M

It would be really awesome to have a Jerk control, i'm available to do any testing you may need on real actual machines, i have machines with steppers and with brush less motors, 3 and 5 axis, other than robot kinematics i can test almost anything else

I was thinking that using s curve in our jogging planner would probably be a good project too.
rapid acceleration is really the name of the game when jogging slowly.
It would surely be easier to to do then the full motion controller.

Chris M

Did anyone have a further look into this?

What I don't understand is what to do if accel/decel in a segment is short enough to never reach full acceleration, in this case execution of the segment takes longer than planned for.

When I wrote a trapezoidal acceleration algorithm for an Arduino, I truncated the acceleration profile when required so that it could ramp down and finish where it should. eg. in short segments it never got to full speed (so it was triangular rather than trapezoidal). You would need to do the same thing with an S curve.