Trajectory Planner using Ruckig Lib

Beef wrote:

@rodw

Yes, I mostly agree - however if we would like to be able to package the trajectory planner with LinuxCNC at some point its much easier to build it with CMake. I discovered this myself while attempting to get the trajectory planner to compile alongside the rest of the project, I spent more time trying to get it to properly compile/link and fighting the preprocessor macros than actually making progress on the code itself. However, it can be done as a separate project using HALCompile as you said.

 

I don't think there is any requirement to use halcompile to build the TP module. There are plenty of components written without it so you should be ablr to use Cmake to build you module.

The way I see it, this recent change to allow replacement modules is perfect for your project as  it compartmentalises the code you need to write from the core code.

Hey beef, have you seen the opencn project? its kinda similar, in the sense they use matlab instead of ruckrig. they changed a lot but maybe it has something useful

gitlab.com/mecatronyx/opencnc/opencn

This is interesting, I want to follow the progress so I hope you keep us updated.

I wish I could contribute but I don't have the skills nor the time for it. Time available might change in a couple of months, but what can a newcomer on this topic really do?

When it comes to development methods my view is that you do it the way you find most efficient. Full freedom. Develop and demonstrate that it works. Then, when and if it should be integrated into the linuxcnc source tree, that is the time to start discussions on cmake etc.

cakeslob wrote:

Hey beef, have you seen the opencn project? its kinda similar, in the sense they use matlab instead of ruckrig. they changed a lot but maybe it has something useful

gitlab.com/mecatronyx/opencnc/opencn

Opencn use C code generated by matlab and they say you need to have a commercial licence to matlab to use it. They were a university  so it was free to them on an educational license.  I did look at the licences once and could not see that was an impediment for an open source project.

Hi,

For using scurve jogging in lcnc, i coded the ruckig scurve library into the motdot.so library that is used for jogging.
It seems to work now.

github.com/grotius-cnc/linuxcnc/blob/mai...tmod_src/simple_tp.c

A picture of the jog output in axis:
github.com/grotius-cnc/linuxcnc/blob/mai...ts/motmod/screen.jpg

I need to add the "jerk_max" value into the lcnc .ini file and read this value into the motdot.so lib when lcnc starts up.
Any suggestions?

Treat it in the same way as max_acc and max_vel.
jerk_max is per joint or per axis? questions questions

Edit: jerkmax is settable by G-code in 3d-printing so that can be a way. But what is the interaction with G64 setting, if any?

If you guys get this to work you will be heroes! I have long been dealing with my machine shuddering in small fast moves from the way transitions are handled, I'm sure others with heavy fast machines can relate. I have hoped some of the projects out there would be integrated into linuxcnc at some point. I am fully rooting for you all and hope you have success! I think where it is developed is completely unimportant so long as it is available in the future! I can relate to working off forum for development where distractions are limited and chat is in realtime, I think there is no way around that. Any who have issue with this have likely not tried using the currently available linuxcnc communications platform for development. you need a platform that has instant file sharing and robust functionality beyond what the limited irq offers. This does not mean the forum thread should not be a source of update and communication as that is important. but to any who are frowning upon external development, I would say that is unrealistic with the current offering of formal linuxcnc community communication platforms. Further more the politics the project may be faced with could be stifling. I speak from experience on all of these fronts as a team member of a linuxcnc project. I hope you guys succeed and I would stress to do whatever you feel is most helpful to accomplish that end! Our team uses matrix and I personally use element io as the front end of it and we have found this to be extremely useful in sharing files, gif video, full videos, images etc that make solving problems and working together in realtime very productive! it also does not mean it has to be a closed group, we open the invitation for any and all interested to join!

Hi,

Just a little update today.

github.com/grotius-cnc/linuxcnc/ is a repository with a cmake project.
It builds linuxcnc without the original make file.
Currently only tested to startup a axis gui after build.

In the above repository ruckig is implemented for jogging a scurve motion profile.

Also a max_jerk value is added in the axis_mm.ini file:

# Joints sections

---

[JOINT_0]
MAX_JERK = 200

This value can be changed in runtime by setting a new value for this ini pin.

The picture shows the x axis jogging output in hal :                                                                                                                            

picture

Now waiting for beef's update.

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.