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.
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
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
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
- grandixximo
- Topic Author
- Offline
- Expert Boarder
- Posts: 110
- Thank you received: 0
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
- grandixximo
- Topic Author
- Offline
- Expert Boarder
- Posts: 110
- Thank you received: 0