Trajectory Planner using Ruckig Lib
15 Aug 2024 10:16 #307788
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
i Lcvette,
Yes, will check the mm to inches.
To test the scurve motion planner in linuxcnc i added a new repository , based on lcnc stable version 2.9.3.
Inside the repository we have the cmake framework to build one the current motion planner "tpmod" and
two a motion planner called "tpmod_scurve".
Conclusion: very compact code enviroment to test scurve motion planner.
Now to make the new motion planner work in linuxcnc, we have to add some logic because the new planner works a little
different then the current motion planner.
Main differences :
1. New motion planner loads gcode itself. Old motion planner, recieves gcode in chunks over the servo cycle.
2. New motion planner calculates "look ahead" before gcode execution, Old motion planner does this at runtime.
Possible difficulties:
1. New motion planner loads gcode itself, this can take a few seconds for big files. This could result in creating a multi-threading process.
2. The clothoid & spline fillets are not shown by lcnc gremlin on forehand. Validation and debugging is more difficult.
Next week i will add the code to make this work.
Yes, will check the mm to inches.
To test the scurve motion planner in linuxcnc i added a new repository , based on lcnc stable version 2.9.3.
Inside the repository we have the cmake framework to build one the current motion planner "tpmod" and
two a motion planner called "tpmod_scurve".
Conclusion: very compact code enviroment to test scurve motion planner.
Now to make the new motion planner work in linuxcnc, we have to add some logic because the new planner works a little
different then the current motion planner.
Main differences :
1. New motion planner loads gcode itself. Old motion planner, recieves gcode in chunks over the servo cycle.
2. New motion planner calculates "look ahead" before gcode execution, Old motion planner does this at runtime.
Possible difficulties:
1. New motion planner loads gcode itself, this can take a few seconds for big files. This could result in creating a multi-threading process.
2. The clothoid & spline fillets are not shown by lcnc gremlin on forehand. Validation and debugging is more difficult.
Next week i will add the code to make this work.
The following user(s) said Thank You: Todd Zuercher, akb1212, tivoi, pommen, Lcvette, Aciera, Darium
Please Log in or Create an account to join the conversation.
15 Aug 2024 12:12 #307801
by Aciera
Replied by Aciera on topic Trajectory Planner using Ruckig Lib
[qoute] To test the scurve motion planner in linuxcnc i added a new repository , based on lcnc stable version 2.9.3.
Inside the repository we have the cmake framework to build one the current motion planner "tpmod" and
two a motion planner called "tpmod_scurve".[/quote]
So having cloned your repository, is there a way for me to compile 'tpmod_scurve'?
Inside the repository we have the cmake framework to build one the current motion planner "tpmod" and
two a motion planner called "tpmod_scurve".[/quote]
So having cloned your repository, is there a way for me to compile 'tpmod_scurve'?
Please Log in or Create an account to join the conversation.
15 Aug 2024 19:26 #307832
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
Hi Arciera,
cd ~/linuxcnc-2.9.3/cmake/build
remove all items in this build dir.
cmake ..
make -j6
make install
This will compile tpmod & tpmod_scurve and install them in the ~/rtlib.
For now the tpmod_scurve is a duplicate of tpmod, as the code for the scurve has to
be integrated next week. But nevertheless you can test the build and test if it loads in lcnc.
cd ~/linuxcnc-2.9.3/cmake/build
remove all items in this build dir.
cmake ..
make -j6
make install
This will compile tpmod & tpmod_scurve and install them in the ~/rtlib.
For now the tpmod_scurve is a duplicate of tpmod, as the code for the scurve has to
be integrated next week. But nevertheless you can test the build and test if it loads in lcnc.
Please Log in or Create an account to join the conversation.
16 Aug 2024 06:46 #307885
by Aciera
Replied by Aciera on topic Trajectory Planner using Ruckig Lib
While the build seems to be working:
and the 'tpmod.so' and 'tpmod_scurve.so' are present in the '/rtlib' folder, starting a config with this in the [TRAJ] section of the ini file
caused the startup process of Linuxcnc to fail and hang:
Note the 'libnml/buffer/shmem.cc 320:' warnings are probably unrelated.
user@user-iMac:~/git/Scurve/cmake/build$ ls
CMakeCache.txt CMakeFiles cmake_install.cmake components install_manifest.txt Makefile
user@user-iMac:~/git/Scurve/cmake/build$ rm -r *
user@user-iMac:~/git/Scurve/cmake/build$ ls
user@user-iMac:~/git/Scurve/cmake/build$ cmake ..
-- The CXX compiler identification is GNU 11.4.0
-- The C compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Python3: /usr/bin/python3.10 (found version "3.10.12") found components: Interpreter
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/git/Scurve/cmake/build
user@user-iMac:~/git/Scurve/cmake/build$ make -j6
[ 10%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/emc/tp/tc.c.o
[ 10%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/emc/tp/tcq.c.o
[ 15%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/emc/tp/tpmod.c.o
[ 25%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/emc/tp/tc.c.o
[ 25%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/emc/tp/tpmod.c.o
[ 30%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/emc/tp/tcq.c.o
[ 35%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/emc/tp/tp.c.o
[ 40%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/emc/tp/tp.c.o
[ 45%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/emc/tp/spherical_arc.c.o
[ 50%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/emc/tp/spherical_arc.c.o
[ 55%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/emc/tp/blendmath.c.o
[ 60%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/emc/nml_intf/emcpose.c.o
[ 65%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/emc/tp/blendmath.c.o
[ 70%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/libnml/posemath/_posemath.c.o
[ 75%] Building C object components/tpmod_scurve/CMakeFiles/tpmod_scurve.dir/home/user/git/Scurve/src/libnml/posemath/sincos.c.o
[ 80%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/emc/nml_intf/emcpose.c.o
[ 85%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/libnml/posemath/_posemath.c.o
[ 90%] Building C object components/tpmod/CMakeFiles/tpmod.dir/home/user/git/Scurve/src/libnml/posemath/sincos.c.o
[ 95%] Linking C shared library tpmod_scurve.so
[ 95%] Built target tpmod_scurve
[100%] Linking C shared library tpmod.so
[100%] Built target tpmod
user@user-iMac:~/git/Scurve/cmake/build$ make install
Consolidate compiler generated dependencies of target tpmod
[ 50%] Built target tpmod
Consolidate compiler generated dependencies of target tpmod_scurve
[100%] Built target tpmod_scurve
Install the project...
-- Install configuration: ""
-- Installing: /home/user/git/Scurve/cmake/build/components/tpmod/../../../../rtlib/tpmod.so
-- Set runtime path of "/home/user/git/Scurve/cmake/build/components/tpmod/../../../../rtlib/tpmod.so" to ""
-- Installing: /home/user/git/Scurve/cmake/build/components/tpmod_scurve/../../../../rtlib/tpmod_scurve.so
-- Set runtime path of "/home/user/git/Scurve/cmake/build/components/tpmod_scurve/../../../../rtlib/tpmod_scurve.so" to ""
user@user-iMac:~/git/Scurve/cmake/build$and the 'tpmod.so' and 'tpmod_scurve.so' are present in the '/rtlib' folder, starting a config with this in the [TRAJ] section of the ini file
TPMOD=tpmod_scurvecaused the startup process of Linuxcnc to fail and hang:
LINUXCNC - 2.9.3
Machine configuration directory is '/home/user/git/Scurve/configs/sim/axis'
Machine configuration file is 'axis_mm.ini'
Starting LinuxCNC...
libnml/buffer/shmem.cc 320: Shared memory buffers toolCmd and toolCmd may conflict. (key=1004(0x3EC))
libnml/buffer/shmem.cc 320: Shared memory buffers toolSts and toolSts may conflict. (key=1005(0x3ED))
libnml/buffer/shmem.cc 320: Shared memory buffers emcError and emcError may conflict. (key=1003(0x3EB))
linuxcnc TPMOD=tpmod_scurve HOMEMOD=homemod EMCMOT=motmod
Note: Using POSIX non-realtime
Waiting for component 'tpmod_scurve' to become ready.
While waiting for 'tpmod_scurve', component 'tpmod' loaded.
Did you specify the correct name via 'loadusr -Wn'?........Note the 'libnml/buffer/shmem.cc 320:' warnings are probably unrelated.
Please Log in or Create an account to join the conversation.
16 Aug 2024 07:05 #307887
by Aciera
Replied by Aciera on topic Trajectory Planner using Ruckig Lib
Ok disregard the above.
There is a component name mismatch as 'tpmod_scurve' currently builds from the 'tpmod.c' file.
I copied 'tpmod.c' and changed the component name in the code, then changed the Cmakefile for tpmod_scurve to point it to the modified file and now it loads.
There is a component name mismatch as 'tpmod_scurve' currently builds from the 'tpmod.c' file.
I copied 'tpmod.c' and changed the component name in the code, then changed the Cmakefile for tpmod_scurve to point it to the modified file and now it loads.
Starting LinuxCNC...
libnml/buffer/shmem.cc 320: Shared memory buffers toolCmd and toolCmd may conflict. (key=1004(0x3EC))
libnml/buffer/shmem.cc 320: Shared memory buffers toolSts and toolSts may conflict. (key=1005(0x3ED))
libnml/buffer/shmem.cc 320: Shared memory buffers emcError and emcError may conflict. (key=1003(0x3EB))
linuxcnc TPMOD=tpmod_scurve HOMEMOD=homemod EMCMOT=motmod
Note: Using POSIX non-realtime
Found file(lib): /home/user/git/Scurve/lib/hallib/core_sim.hal
Found file(lib): /home/user/git/Scurve/lib/hallib/sim_spindle_encoder.hal
Found file(lib): /home/user/git/Scurve/lib/hallib/axis_manualtoolchange.hal
Found file(lib): /home/user/git/Scurve/lib/hallib/simulated_home.hal
Found file(REL): ./cooling.hal
note: MAXV max: 53.340 units/sec 3200.400 units/min
note: LJOG max: 53.340 units/sec 3200.400 units/min
note: LJOG default: 30.480 units/sec 1828.800 units/min
note: jog_order='XYZ'
note: jog_invert=set()
Shutting down and cleaning up LinuxCNC...
task: 16752 cycles, min=0.000006, max=0.004275, avg=0.001076, 0 latency excursions (> 10x expected cycle time of 0.001000s)
Note: Using POSIX non-realtime
Please Log in or Create an account to join the conversation.
24 Aug 2024 13:49 #308533
by Lcvette
thanks again for such awesome work Grotius!!
Replied by Lcvette on topic Trajectory Planner using Ruckig Lib
awesome!! just let me know if you need anything from me, im willing to test things is need be on my end! we are using VTK for the QtPyVCP gui backplotter so if you need any testing with that as well or way to figure how to draw updated plots we could have a look at that. although i assume you are trying to solve how to feed the planners modifie gcode out instead of the file gcode.i Lcvette,
Yes, will check the mm to inches.
To test the scurve motion planner in linuxcnc i added a new repository, based on lcnc stable version 2.9.3.
Inside the repository we have the cmake framework to build one the current motion planner "tpmod" and
two a motion planner called "tpmod_scurve".
Conclusion: very compact code enviroment to test scurve motion planner.
Now to make the new motion planner work in linuxcnc, we have to add some logic because the new planner works a little
different then the current motion planner.
Main differences :
1. New motion planner loads gcode itself. Old motion planner, recieves gcode in chunks over the servo cycle.
2. New motion planner calculates "look ahead" before gcode execution, Old motion planner does this at runtime.
Possible difficulties:
1. New motion planner loads gcode itself, this can take a few seconds for big files. This could result in creating a multi-threading process.
2. The clothoid & spline fillets are not shown by lcnc gremlin on forehand. Validation and debugging is more difficult.
Next week i will add the code to make this work.
thanks again for such awesome work Grotius!!
Please Log in or Create an account to join the conversation.
29 Aug 2024 06:49 #308920
by automata
Replied by automata on topic 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
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
The following user(s) said Thank You: akb1212, tommylight, tivoi, rodw, Lcvette, Grotius, Darium, Unlogic
Please Log in or Create an account to join the conversation.
30 Aug 2024 19:12 #309039
by Lcvette
Replied by Lcvette on topic Trajectory Planner using Ruckig Lib
@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
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
Please Log in or Create an account to join the conversation.
04 Sep 2024 03:37 #309325
by automata
Replied by automata on topic Trajectory Planner using Ruckig Lib
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
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
Please Log in or Create an account to join the conversation.
02 Oct 2024 10:04 #311163
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
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.
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.
Please Log in or Create an account to join the conversation.
Time to create page: 0.143 seconds