Trajectory Planner using Ruckig Lib

Hi,

A little project update.

At this stage linuxcnc can home & jog using the ruckig scurve library.
In the ini file's the user may specify max_jerk values for joint's and axis.
Also the max_jerk values can be changed in runtime by hal commands.

To try out scurve jogging on your real machine : github.com/grotius-cnc/linuxcnc
The ~/linuxcnc/config/axis/axis_mm.ini config is the one you could try out as offline example.

And here are the promised videos with jogging an XYYZ machine:

Trapezoidal planner, 7k mm/s^2 max_acceleration on X and Y and their respective joints


S-Curve planner, 8k mm/s^2 max_acceleration on X and Y and their respective joints, but 22k mm/s^3 max_jerk.


There's about 150kg of moving mass in the Y axis, which is why even on the massive table under it, the trapezoidal manages to shake it quite vigorously.

@Beef,

Wowie, what a difference in vibration, shock's, between trapezium & scurve jogging.
It's hard to imagine it's so different. I can almost not believe this. Is this real?

Good job.

@Tommy,

Holy moly. With sound on it's even better. 

The github source github.com/grotius-cnc/linuxcnc has now a new ruckig trajectory planner component
called tpmod_scurve . When the cmake build script is done, it starts up linuxcnc with this new trajectory planner running.
All the includes for ruckig are already there. So anyone can now show his coding skills in this file.

The new trajectory planner is loaded in the ini file in section [TRAJ] by : TPMOD=tpmod_scurve

In the  axis_mm.ini file the blend is turned off. "ARC_BLEND_ENABLE=0"
There are more parameters that can be set in the ini file, this for info.
So you don't have to worry about blending for now.

I have checked the video of Rob Ellenberg tonight for second time about the current trajectory planner.
So i hope with a some magic we can hopely get it going.

Grotius wrote:

Holy moly. With sound on it's even better. 

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 .

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 , 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