Trajectory Planner using Ruckig Lib

Hi Grotius,
Kudos on the terrific progress on jerk limited multiaxis look-ahead planner.
Is there anything we can help with in porting the development to Linuxcnc?
My feeling is that we may want to break up the planner into 2 parts, i.e., RT and non-RT parts.
The geometry / path modification i.e. clothoid fillets, spline conversions etc, can take place in non-rt whereas the actual trajectory planning can be kept inside RT.
My feeling is that the heavy computational burden is in the path modification rather than the look ahead planner. The heavy computational parts can be handled in the non-rt section where loop time deadlines are not a critical consideration.
For this we will have to introduce a layer in milltask that will keep a queue for the readahead from the Gcode file and optimize the path.
I am guessing there will be 2 types of path modification constraints:
1. Add clothoid fillets between 2 moves that are long enough to qualify for clothoid filleting
2. collecting multiple small line segments and fitting a spline on them. This may be something a little more complicated than Douglas-Peucker algorithm applied to small line segments with the G64 Qxx settings.
Then we may need to add these two new entities into AddLine and AddArc commands that send the motion blocks to the RT queue inside the RT trajectory planner tpmod_scurve

Time/trajectory lookahead with jerk limitation could be carried out by tpmod_scurve RT component.

One more interesting feature we may want to account for in this new planner development is kinematic planning. Taking into account the speed and acceleration limitations of the joints involved in the move. This can be done by breaking the moves into small enough segments and checking the max velocity and acceleration at the end points of each of the small segments.

-automata

@Grotius,

how is everything going?  got quiet in here all of a sudden,  hope everything is alright with you!  drop a line and let us know!

Best Regards,

Chris

Hi Grotius,
i have a few spare ethercat stepper drives by leadshine (6amps) and a couple 230v operates servo drive and motors (750 watts) by Veichi that I could send to you for your machine trials.

This way you will be able to isolate the effects of pulse and direction jitter over ethercat on your machine.

Let me know our DM and we can set something up.
- automata

Hi,

I was on holiday, and am back now. Everything is ok.

The responce to the questions of Automata and Arciera, i will do in another post.

Kudos on the terrific progress on jerk limited multiaxis look-ahead planner.
I am aware, after testing the planner on a real machine, it looks certainly promising.
From idea to realism has been a succes so far.

I was on a exhibition yesterday for cnc-machines. All the cnc-machines where using windows.
Non off them was using linux for controller or gui. And the manufacturers didn't know about
scurve motion profile and or path optimalisation using clothoids.

@Automata,
Is there anything we can help with in porting the development to Linuxcnc?
My feeling is that we may want to break up the planner into 2 parts, i.e., RT and non-RT parts.
In hal-core the test used the same planners source code in the rt and in non-rt section. This was ideal for
validating the code in the non-rt section using graphics.
Where in the rt part the graphics are commented out and not loading.
The rt and non-rt sections use shared memory to exchange runtime data like update position etc.

The heavy computational parts can be handled in the non-rt section where loop time deadlines are not a critical consideration.
The planner does all the computation when gcode input loads, this loading is done twice. One time in the non-rt environment, like the gui.
And one time in the rt environment. Then in the rt environment things like loading graphics are commented out.

For porting the planner to linuxcnc the workflow may be different because of the current lcnc workflow like related functions tpAddLine etc.

Last week i made a few libraries to add to hal-core.

The idea is then that the motion controller in the kernel starts a http_server, and a websocket_server.
The gui's, pendants, smart-phones, etc can start a client and connect to the server. A simple website can be a client.
Then the gui's can be coded in python, c, rust, c++, html, java, etc. Cross platform solution.
However, displaying the gcode in a website for example, would still involve using extra code.

There are now 3 libraries tested to create networks :  codeberg.org/skynet/network.git
1.http_server & http_client class. (can send a webpage to client showing the servers status)
2.tcp_server & tcp_client class. (can be used for custom data without the need of any http headers in the package's)
3.websocket_server & websocket_client class. (fastest, used for io, commands, position feedback to gui's etc.)

I have also considered to create a ethercat bus virtual client, but so far it's not essential and causes more difficulties as
a smart phone, pendant, has no ethercat bus running, normally.

And then for the motion controller itself, i like to review the scurve library once again.
I like to add a test environment in google's colab or amazon's sagemaker studio to run automated test's and find out
exceptions over million's of run's.
 

Grotius wrote:

 And the manufacturers didn't know about
scurve motion profile and or path optimalisation using clothoids.
 
 

Almost always the guys at the exhibitions are sales guys without too much technical knowledge from the "back end" stuff. Hardly ever there are actual engineers that work on the products, maker fairs etc. excluded.

Last week i made a few libraries to add to hal-core.

The idea is then that the motion controller in the kernel starts a http_server, and a websocket_server.
The gui's, pendants, smart-phones, etc can start a client and connect to the server. A simple website can be a client.
Then the gui's can be coded in python, c, rust, c++, html, java, etc. Cross platform solution.
However, displaying the gcode in a website for example, would still involve using extra code.

There are now 3 libraries tested to create networks :  codeberg.org/skynet/network.git
1.http_server & http_client class. (can send a webpage to client showing the servers status)
2.tcp_server & tcp_client class. (can be used for custom data without the need of any http headers in the package's)
3.websocket_server & websocket_client class. (fastest, used for io, commands, position feedback to gui's etc.)

I have also considered to create a ethercat bus virtual client, but so far it's not essential and causes more difficulties as
a smart phone, pendant, has no ethercat bus running, normally.
 

I really like this idea, I might be stupid to ask but do you really need 2 servers? Could you just open a websocket server that reads all states, parameters etc. and then stores all that data into example json. Then you could just connect to the server and the client could ask for the json data and you use from the stream what you want to use.
So you always get all the data and then decide on the client side what you actually read/use from the json msg.

For the ethercat "client", I dont think its worth it. For speed and determinism, yeah its cool but who needs that in UI? I would say that if you beat your eye's refresh rate, its fast enough. At the end you just want to see a "fluid" change in position or any other fast rolling number, you dont care if at that millisecond the position is correct or not. If a led, stating an input status in a display changes 100ms after the input actaully triggered, who cares. You just want to know the real state of the machine example when it stops. You have and can make debug logs to debug, you dont need realtime screen refreshrate to do it.

Just my 2cents, keep up the good work.

Hi Rda,

The websocket server & client are now updated to exchange json data. This works fine.

For information a few pictures of the exhibition yesterday. So all these machines have a windows gui running.

Esab refused me to take a picture of their 5 axis cutting machine.
The swift-cut (now esab company) uses mach4 i guess, everyone knows how this looks like.

The kutavar is the next generation with my compliments to the software.
Kutavar is a english brand, located left to London on the map. The software they use is external made.
The software brand they use also delivers or advises the servo's for the Kutavar machine.
The kutavar uses software where you can do cad, cam and cnc in one program.
In England is easy'er to get hands on a Hypertherm high defenition as system integrator.

 
 

Then there are several tube cutters using laser, chinese brand, start price 75000 euro.
 
 
 

Tube cutter > 100.000 euro.