LinuxCNC S-Curve Accelerations

That's a great find automata! Thanks!

They do use the same iterative method to find roots that I do - Newton's method. However through further mathematical rigor they seem to have managed to "box it in" so that it guarantees a solution (they make sure to constrain each run to a section with one and only one solution, which ensures convergence).

Overall the algorithm is actually pretty close to mine, but having it formally analysed and described is super valuable - for squashing those last bugs but even more for maintainability! And also for peace of mind regarding robustness. This is great! *woohoo!*

In addition, they extend the algorithm to multiple synchronized axes which could be interesting for jerk-limited jogging of homed machines not using trivial kinematics!

One (hopefully minor) snag is that their algorithm seem not to solve the type of trajectory that you'd get if you start a move and then return to the starting point - say turning a jog wheel one click forward and then immediately back again, before the move has finished.

Anyway, I'll definitely look very very close at this once I've solved the homing/integration issues detected by TheRoslyak.

Hi,

I did a 6-DoFs implementation of the library into a hal component. And it seems to work.
github.com/grotius-cnc/hal_trajectory/blob/main/README.md


 

Interesting. you could probably use it in pncconfs axis test to see it actually work.
Pncconf uses simple_tp.comp for axis tests.

Hi,

Thanks for the tip!.
I just finished and tested a standard implementation of the trajectory component. I feel like a type goat now.

It uses a  trajectory.hal file for input parameters for DoFs axis 0 up to 5.
Then with halcmd i do a : $ setp trajectory_request 1
Then it perform's the traject until it's finished.
User can set all destiny position's before doing the actual trajectory request with
$ setp target_position_0 10.0
$ setp target_position_1 5.0
etc.

Has anyone a better idea how to pass the arguments?

The github is updated.

If you have amd64, you could grab the compiled files from the repository and copy them to the /linuxcnc/rtlib
trajectory.so (linuxcnc component c style)
libtrajectory_6DoFs.so (c to cplusplus style wrapper, compiled as shared library)
libtrajectory_6DoFs.so.1
libtrajectory_6DoFs.so.1.0
libtrajectory_6DoFs.so.1.0.0
libruckig.so (trajectory s-curve c++ library)
If this will not work without header files, then copy the ruckig include headers into the /linuxcnc/include dir.

i'm wondering, any chance that Ruckig OTG can make it into the linuxcnc trajectory planner? in 3-axis trivkins for a start? as i understand currently blending is done with circular arcs and should be reworked?

circular blending and jerk limiting are two similar but different concepts.

circular blending modifies the requested profile to adjust slowdowns/stops at corners. - ie The planner can modify the profile (within defined parameters) to get closer to the requested feedrate, usually on corners. This uses look ahead.
(That's very simple explanation - look for youtube videos in makinekit for better explanation)

jerk limiting allows higher utilization of the speed/power of the motors by having the trajectory planner not ask for impossible moves, suck as instant acceleration.
In general, without jerk limiting you must lower the max acceleration because the TP asks it to change instantly. It would be the same idea if we didn;t have an acceration setting in the TP - we would have to lower the max speed or the machine would tear it's self apart pretty quickly.

of course one could complement the other.

IIRC the guys here are testing jerk limiting on jogging profile which is a different process then profile planning.
Jogging only plans one joint.

This of course is a great idea in it's self and could lead to changes in the trajectory planner for multi axes.

but it's a pretty big jump. There has actually been a couple jerk limiting TP in development for linuxcnc - none of them make it far enough to include.
once you add such things as spindle sync and feed override etc it gets much harder it seems.

The only reason linuxcnc got the circular blending TP is because Tormach paid for it and they helped us get the code to work for us.
I hear they have circular blending with angular axes too now - we don't have that.

There are some smart motivated people here - I'm routing for them!

(I hope I didn't miss-represent anything/anybody here -not a TP expert)

Chris

As i speak for my situation. My interest is most of time the hal related stuff like components.

I hope in the future linuxcnc will be reduced back to a more modular form, for example a component style
gcode reader, motion planner, etc. I simply miss the linuxcnc building block style at the moment. In other words, a ini file
is not needed. Hal files can do it all.

Today i started coding a multi axis motion planner in component style that can read the gcode, can perform the motion etc.
I hope this will bring some luck.

actually they are modular.
The motion component is a hal module - you load it in the HAL file.
The interpreter is modular - there is a sim (axis/canterp) that uses a canonical interpreter rather then gcode interpreter.
the interpreter is set in the INI file, it just defaults to gcode.

Chris

circular blending and jerk limiting are two similar but different concepts.
circular blending modifies the requested profile to adjust slowdowns/stops at corners. - ie The planner can modify the profile (within defined parameters) to get closer to the requested feedrate, usually on corners. This uses look ahead.

i understand the basics like replacing trajectory corners with arcs allows to keep a positive velocity with limited acceleration along the way. contrary to traveling thru a sharp corner which needs either a complete stop at it or an infinite acceleration.
but straight line -> arc transitions introduce a discontinuity into the acceleration, i.e. an infinite jerk.

so now there's a fast algorithm available which can construct an optimal trajectory between two states (pos,vel,acc) keeping the velocity, the acceleration and the jerk limited. which is kinda a big deal, as i understand.

so we need to transform a gcode-defined trajectory into something that can be fed to that Ruckig thing and it will happily interpolate it at the servo-thread frequency? is this solvable with the current state of the art? or i just don't have a clue how it's all done?

The laws of physics determine the arc radius that can be achieved for a given maximum acceleration. If you set a G64 limit then you are saying the machine must slow down to achieve that radius.
The lookahead allows the trajectory planner to check out the next segment so the velocity reduction matches what it has to do next. eg if you are travelling at 3 m/min and you have to slow to 2 m/min to negotiate the corner to meet the G64 limits. But if the next segment requires a velocity of 1 min/min, then the TP will slow motion so there is no jerk as it enters the next segment.

The gcode is read into a buffer which in turn is processed by the TP (motion) and tokenised into motion. So its not being applied at the gcode level but at the planning level.

As a first step. I'd like to see it applied to XY motion as that is used by plasma cutters where acceleration and velocity is king (but only  on the X & Y axes). There is no spindle so there is no real complications to deal with.