Trajectory Planner using Ruckig Lib

Grotius wrote:

Holy moly. With sound on it's even better.  image missing /media/kunena/emoticons/w00t.png

This is truly awesome work!.
It seems to me you install ruckig then intall the components to connect linuxcnc via driver/interface to it.
I think omly the tpmod and simple trajectory planner are required on the linuxcnc end
I think that these two components should be seperated from all of the Linuxcnc code and distiilled down to a build a single deb file (or two if you must).

This will gurantee the sucess of the project.
A pull request to Linuxcnc to migrate to CMAKE is going to face very heavy headwinds and could pull this project down to an exrtent it fails to be accepted.
It would be far better to just build driver the modules needed in your Cmake environment and publish the debs in a similar way to how I integrated ethercat external repository with a fork of the linuxcnc ethercat driver I host on package.io
Ref:  forum.linuxcnc.org/ethercat/45336-etherc...-how-to-step-by-step
Then it is easy to include the companion apps in the Linuxcnc environment for those that want to use them.
This is the approach I hve taken when building the 2.9.1 live installer which includes repositories for QTVCP and ethercat
It would be trivial to add a new hook 0540 to the linuxcnc live installer in this folder  github.com/LinuxCNC/linuxcnc-live-build/.../config/hooks/normal to install the new repos.

Once you get this far, you will be in a strong position to send a pull request through to the devs to incorporate your new driver modules. Not everybody will want to install ruckig so it could still become an optional pathway.

All very cool but set your architecture up to suceed!



 

GIVE TO MEEEEEEEEEEEEEEEEEEEEEEEE

My little machine which is bolted to the floor and wall. It is being such a jerk. Needs help


 

hey beef

just out of interest

do you know how much they want for a license of the pro version?
if it was cheap enough i wonder if we could just buy it...

just a thought. i am another user with a big heavy fast cnc mill that rattles to death with fast rapids and i would absolutely love to try a jerk limited TP

@rodw,

I think what you describe is the ideal situation, but we'll have to see if it's so simple. We do need to make some changes to a few more objects than just those generated with simple_tp.c/h just for the jogging planner to incorporate s-curve into jogging (simple_tp is instantiated all over the place ...), which complicates things a bit. The joint jerk is relatively simple, but as you pull on the strings for implementing axis jerk there are chains of functions that go further and further into the rest of the source code like that bomb scene in Hurt Locker image missing /media/kunena/emoticons/dizzy.png.

Grotius redid the axis implementation and avoids some of this by just skipping some of these and injecting the jerk values closer to simple_tp, but there are nuances like the screw map and backlash compensation functions that need to be able to increase max_jerk properly, and there are kinematic transformations that alter max acceleration values based on the transformations that may also be better if they can properly alter maximum jerk values as well.

In short, it's a bit of a problem to solve - but I think that having it as an external add-on (either through .deb or a script) is a fine solution. In any case, I think that this will remain in a bit of an experimental stage for some months even after we are "finished" as there will undoubtedly be edge-cases and bugs that must be squashed, and we can return to the issue once we get there. I don't see it as a high priority just yet, but undoubtedly worth keeping in mind.

On the topic of the build system - of course there will be strong disapproval (or headwinds) as you mention towards changing the LCNC build system - we mention this in our project statement in the first post - but this is really a concern for much further down the road (potentially years) once we've achieved feature parity with the existing build system. It's controversial of course image missing /media/kunena/emoticons/grin.png, but the current build system (particularly the thousands of lines in the makefile) is so full of dark magic that it's near impossible for any mortal to fully understand how all fits together.

@ Becksvill

The ruckig guys didn't disclose to me any pricing unfortunately so I can't answer that, as mentioned further back, but I don't think the license would actually help us given the way we're approaching the problem anyway.

Edit: Updated repository links in the first post to be current

Maybe not so much for the simple trajectory planner but if you find you cannot simply write a single custom trajectory planner module as intended, report it as an issue on the Linuxcnc github.

This is the first attempt to write a new TP module since the modular approach was added. If it can't be done, it has to be considered a bug and the data you require should be exposed to the TP. I'm sure Dewey Garrett will take an interest in the issue.

Perhaps the simple tp also needs to be installed via the ini file to so it also has a clearly defined interface in Linuxcnc.

Hi Rod,

Maybe not so much for the simple trajectory planner but if you find you cannot simply write a single custom trajectory planner module as intended, report it as an issue on the Linuxcnc github.
This is the first attempt to write a new TP module since the modular approach was added. If it can't be done, it has to be considered a bug and the data you require should be exposed to the TP. I'm sure Dewey Garrett will take an interest in the issue.

You could write a new trajectory planner, no problem, this works excellent.

It is that code for jogging and homing are done outside this trajectory planner. And also adding INI values require
extra code to inihal, inijoint, iniaxis and so on. The lcnc command struct's and other data struct's like nml need a max_jerk value.
This is going trough the whole lcnc source code.

If you want to add a new trajectory planner properly, it's a bit like adding external offset's into the lcnc source code.

Perhaps the simple tp also needs to be ""installed"" (started?) via the ini file to so it also has a clearly defined interface in Linuxcnc.
Here indeed we need a ini argument. This is quite easy to do.

A pull request to Linuxcnc to migrate to CMAKE is going to face very heavy headwinds and could pull this project down to an exrtent it fails to be accepted.

There are 2 things. The cmake and the scurve planner. When our lcnc fork is doing things well and users step over one by one,
the dev team will eventually merge it, without me asking them. I have seen this happening before.