Trajectory Planner using Ruckig Lib

Took me an extra couple of days than I hoped fighting joint vs coordinated mode and some other issues since I've got an XYYZ machine on a mesa card, so unfortunately I only have Z to show at the moment, but it runs!

I will have some more videos available soon as we continue to resolve some of the outlying issues, but you can see the results of some various jerk values that (as Grotius said) initialized through .ini but are HAL pins so can be changed on the fly.

HALscope outputs are attached (also in the same Testing_TEMP on github ... i'll remove this down the road)

github.com/TheRealBeef/LinuxCNC-CMake/bl...Testing_TEMP/low.mp4
github.com/TheRealBeef/LinuxCNC-CMake/bl...Testing_TEMP/med.mp4
github.com/TheRealBeef/LinuxCNC-CMake/bl...esting_TEMP/high.mp4

Hopefully we have more to show soon, and of course once I sort out teleop (or am brave enough to home this thing) I will come back with a better video demonstrating the trapezoidal vs s-curve and some more documentation.

I've heard back from Ruckig as well. Here's a summary of the key points

- Packaging the community version of Ruckig is fine
- They don't sell individual/hobby licenses for Ruckig Pro (although it may not be needed anyway)
- They're willing to help with some technical questions

One bit that's worth more digging into as we move into the actual trajectory planner instead of just the simple_tp for jogging is figuring out how to keep lookahead functionality working without delving into the Ruckig Pro version. I've copied the email directly here as I have to do some thinking and it may be interesting for the rest of you

From me:

However, to my understanding the only way to keep the lookahead functionality that LinuxCNC's trapezoidal trajectory planner has will require the use of intermediate waypoints, which is in the Ruckig Pro version.

And their reply:

Yeah, this seems to be correct. However, the intermediate waypoints might work a bit different than what you might expect in the CNC world. Basically Ruckig Pro will calculate a time-optimized trajectory going through all waypoints exactly.

If you apply Ruckig to control each axes directly, it might deviate from a straight-line path between waypoints, and in general the time-optimization works best for fewer waypoints. More info in our docs here. There is a cloud server built into the community version to try out the intermediate waypoints (of course with lot’s of latency), but it’s good to make sure that the intermediate waypoints work as expected.

You can also apply Ruckig to time-parametrize the path in a single DoF, so that you stay exactly on the path. This way you can add kinematic limitations easily, but it would still require intermediate waypoints for the lookahead. Which approach do you have in mind?

We'll look into the various solutions moving forwards, just wanted to provide an update.

I'm sorry if you feel insulted, it wasn't intended as such, just your patronizing "hints" about IDE usage demanded a reply. I removed my comments, no need to bother moderation.

Hi Rmu,

About your previous question, i repaired the history of the linuxcnc repository clone a little bit.
This history has been overwrited last week by a push -force.

For info, the scurve jogging is done here:
~/linuxcnc/src/emc/motion/simple_tp.c

Compiled with ~/linuxcnc/cmake/components/motmod/CMakeLists.txt

This is a really interesting development.
I am eagerly waiting for the next phase on how to tackle multiaxis jerk limitation.
As RMU has suggested before, the jerk constraint can be sub divided in the tangential and normal planes.
One way to constrain tangential jerk is to parametrize the path as a single axis (maybe using the distance travelled along the path as the governing variable, and plan a single axis jerk limited path. The waypoints will be the distance travelled by each segment in that path. Then use direction cosines to find the individual axis positions. The max velocity, accel and jerk constraint for each segment of can be computed by taking the direction cosines into account.
The issue would then be to ensure that circles are broken into small line segments and this could be done for each.
A transition fillet would also needed to be added between 2 subsequent gcode segments.

I am looking forward to see if there is an easy method to take care of normal jerk too.

Let me know if there is anything I can do to help in this endevour.

Regards,
-automata

Hi Automata,

One way to constrain tangential jerk is to parametrize the path as a single axis (maybe using the distance travelled along the path as the governing variable, and plan a single axis jerk limited path. The waypoints will be the distance travelled by each segment in that path. Then use direction cosines to find the individual axis positions. The max velocity, accel and jerk constraint for each segment of can be computed by taking the direction cosines into account.

Yes, we calculate the path progress using a single ruckig-dof. (axis).
The xyz Interpolation is done by math.

The issue would then be to ensure that circles are broken into small line segments and this could be done for each.

During the servo cycle update, there is no need for small line segments.
Only a new target point is needed each servo cycle.

A transition fillet would also needed to be added between 2 subsequent gcode segments.

This is the hard part. A great library for this should be the use of cavaliercontours. This is a fast lib for solving
extreme difficult paths. Let's say a look ahead of 10 gcode segments could be fillet this way.

I would preferr to start coding something simple.