Trajectory Planner using Ruckig Lib

Source and Documentation
Repository: github.com/grotius-cnc/linuxcnc
Documentation: github.com/grotius-cnc/linuxcnc/wiki

Once these three components are ready, we will combine these into a new repository with some documentation that is easier for others to add to. However, if you are interested in contributing you are welcome to provide feedback or reach out even now.

Introduction
Over the years, many people have attempted to implement an S-Curve or limited jerk trajectory planner into LinuxCNC. The only fully successful implementation that I'm aware of was built by Micges (1). Unfortunately, this attempt predates the look-ahead functionality of the current trapezoidal trajectory planner built by Rob Ellenberg (2). While the current trapezoidal trajectory planner was perfect at the time, as technology has progressed so has the need for an s-curve planner in LinuxCNC, even for small hobbyist router machines.

I believe that the reason that so many other attempts have failed is that they were primarily the projects of individuals. Just understanding the existing code for the LinuxCNC trajectory planner is already a monumental task - and building a replacement one is yet even more daunting. RMU was able to develop a Smooth Planner that works very well by hacking onto the existing TP, but it is not yet the complete solution (3). Grotius has also made huge strides, and incorporated Ruckig (4), but even this attempt has more work that needs to be done (5).

That's why Grotius and I have decided to start this new project and leverage his existing codebase and what we can learn from the attempts of others to build a project that's more accessible for contributors with clean and documented code that can achieve our goal. Our draft outline is below - of course, this is subject to changes as we determine potentially better paths.

Endstate
Our endstate is to develop an s-curve trajectory planner that incorporates lookahead and blending capabilities with a bare-minimum of three axes, although we of course hope to implement this for as many axes as can be feasibly achieved. We will incorporate the Ruckig library (licensed under MIT) to help us with this task. We anticipate that this trajectory planner may not implement all the functionalities of the existing trapezoidal trajectory planner (as an example, rigid tapping) - but we will implement as many as are possible to do. Since this is an additional trajectory planner and does not replace the existing one, LinuxCNC will not lose any capabilities as the trapezoidal trajectory planner will still be available.

What we need
We need brainpower. It's unlikely that any of our individual efforts will be as successful as a team effort. Amongst the forum here we have more than enough knowledge and skill to achieve this - we are only lacking a place to document and centralize our efforts towards this goal.
What can you do?
- Share your insights, your knowledge, and your (ideally constructive) criticisms to help us refine our roadmap, stepping stones, and overcome challenges
- If you are capable of tackling some of the issues that we will add to our to-do list, contribute code to the repository
- If you are familiar with some aspect of the trajectory planner code and can explain it so that other people can understand it, contribute to our documentation so that we can make it easier for other developers to contribute in the future

Stepping Stones
Project Home/Wiki
To streamline our efforts, we will establish a new GitHub repository. This will serve as our central hub for tracking our to-do items, addressing issues and squashing bugs, and managing pull requests. We will also build a place (Likely using GitHub wiki) to catalog the collective knowledge and build our documentation.

Build System
To facilitate our project, we do want to make one potentially controversial change to LinuxCNC. We want to convert LinuxCNC to use CMake. There are number of advantages of this building and installation system over the existing Makefile system, not the least of which is that the existing Makefile is very nearly unreadable and difficult to decipher. Adding additional components to LinuxCNC is no small task as a result.

However, we recognize that it will potentially take some years until LinuxCNC (may) transition to this build system, so instead of reorganizing the entire structure of LinuxCNC, we will instead build a script that generates our CMake project from the existing LinuxCNC codebase. This way, we ensure that our branch can remain up-to-date with the ongoing enhancements and fixes of LinuxCNC.

Documentation
For clarity and accessibility of the s-curve trajectory planner codebase, we intend to employ Doxygen to automatically generate documentation for the trajectory planner. The complexity of the trajectory planner code can't really be understated. By using this tool, we will make it easier for other developers to resolve issues and solve items on the to-do list.

While we're leaning towards Doxygen due to our familiarity with the tool, we remain open to feedback - perhaps there is a better method to incorporate our documentation within the existing LinuxCNC documentation or a more efficient approach.

Roadmap
Stage 1
In our initial phase (now) we are establishing a robust foundation. The script is challenging but possible, and the rest is relatively straightforwards - this system may be possible within a couple weeks.

- Set up our GitHub repository
- Build our documentation wiki to consolidate existing knowledge
- Develop our script that generates the CMake project

Stage 2
Next, we will achieve some goals that should be easy given Grotius' existing codebase. Nevertheless, we anticipate to take several more weeks to accomplish this.

- Incorporate the codebase into simple_tp. This trajectory planner is used during manual mode activities like jogging.
- Gain any additional insights and resolve issues from simple_tp that assist with resolving the larger trajectory planner
- Build a small debugging toolkit - either leveraging HALShow/HALScope or an external tool that assists with solving issues that arise in the larger trajectory planner
- Build our relevant tests to ensure that the trajectory planner operates as expected after updates

Stage 3
Finally (pending whatever other issues we uncover). This is by far the hardest and longest step, even with the existing codebase.

- Build the s-curve trajectory planner

To wrap it up
I'm sure some of you are absolutely sick of hearing about S-curve, but I think that this collective effort represents our best chance of achieving it in such a way that the code is usable on a live machine without fear of errors resulting in unexpected behaviors and crashes.

Extra Info
(1) Micges Trajectory Planner - github.com/LinuxCNC/linuxcnc/tree/micges/master/limited_jerk
(2) Rob Ellenberg discusses Trajectory Planner -
(3) RMU's Trajectory Planner - forum.linuxcnc.org/38-general-linuxcnc-q...oth-velocity-profile and Github - github.com/rmu75/linuxcnc/tree/rs_qvp_2.9
(4) Ruckig Lib - github.com/pantor/ruckig
(5) S-Curve Thread, including Grotius' Trajectory Planner  - forum.linuxcnc.org/38-general-linuxcnc-q...-curve-accelerations and Github - github.com/grotius-cnc/linuxcnc/tree/main/cmake

You should not need to touch the linuxcnc core code.
It is possible to create your own custom trajectory planner module in your ini file in 2.9 and 2.10 under the [TRAJ] section
Ref: end of section 2.10 in linuxcnc.org/docs/2.9/html/config/ini-co...tml#sub:ini:sec:traj

• TPMOD =

   alternate_trajectory_planning module [tp_parms=value]
  The 

  TPMOD

   variable is optional. If specified, use a specified (user-built) module instead of the default (tpmod). Module parameters (tp_parms) may be included if supported by the named module. The setting may be overridden from the command line using the -t option ($ linuxcnc -h).

So your new TP module can be a totally seperate project which canuse whatever make tool you want.
Good luck with your project!

The infrastructure shouldn't really be a problem so I wouldn't waste too much time at that.

IMO the scope of the problem isn't really specified clearly enough. Some options:

* jerk limited G0 moves: easy, no path blending needed, accuracy of position not very critical.
* jerk limited tangential speed: should also be relatively easy too (see my hack, "just needs debugging")
* path blending while obeying joint accelertion and speed limits, G64 tolerances and optimize for uniform feedrate (thats already existing) and avoiding infinte jerk at transitions (that would need different path blending to e.g. avoid line -> circle transitions)
* path blending while obeying all of the above plus joint jerk limits plus kinematics.

It would probably be helpful to check and summarise what popular commercial controllers offer in that regard to get an idea what would be feasible in the limit.

Hi Beef. I've added you to my development. Essentially, everything you said is great, but we still need to move away from Linuxcnc and embark on a new development, utilizing Linuxcnc and Machinekit-HAL in the process. I wanted to know which kinematics you are more oriented towards: CNC machines (3 or 5 axes), SCARA and delta robots, or 6-axis robots?

TheRoslyak wrote:

Hi Beef. I've added you to my development. Essentially, everything you said is great, but we still need to move away from Linuxcnc and embark on a new development, utilizing Linuxcnc and Machinekit-HAL in the process. I wanted to know which kinematics you are more oriented towards: CNC machines (3 or 5 axes), SCARA and delta robots, or 6-axis robots?

I think its poor form to talk about moving away from linuxcnc on a linuxcnc forum! The best way forward is to build a custom stand alone tp module for linuxcnc. Then you can move the module wherever you like!

@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.

By using a script to generate the CMake project, we avoid touching the core code and achieve this somewhat tangential goal - as it doesn't alter the existing LinuxCNC functionality or build system but allows a user to build the same result using CMake by generating the project dynamically. It also makes it easier to build an entirely separate target such as TheRoslyak is interested in. If we somehow cannot achieve this goal we can cut it out fairly easily.


@rmu

Thanks for the feedback. If we hit a wall with the CMake script then I think it's an easy goal to cut.

I really like what you said about defining the scope of the problem a bit more clearly - we'll do a bit more digging and determine the answer. I think that the jerk-limited tangential speed is very feasible, but the 3rd choice you've mentioned - including path blending - is something we discussed and would like to achieve. One of the limitations is the calculation complexity as Grotius discovered with his 3d arc generator, but given a larger audience of contributors I think it's achievable.

I think that the 4th option is less feasible unless we begin to use the Ruckig Pro library, but this drifts from the open source into the closed source and I think is out of our reach for now.


@TheRoslyak

I personally am interested in CNC machines. I have an almost 1 ton 3 axis router that I've built in my garage that I would like to limit jerk on since it shakes everything with the trapezoidal trajectory planner. I will also build a 5 axis machine in the not-too-distant future that would benefit from a jerk-limited trajectory planner assuming it's achievable to scale to 5 axes. The other people I've talked to that are interested in contributing are also interested in the CNC machining use-case.

I do agree that LinuxCNC is less-than-ideal for fully IK systems, for 6 axis robots and the like, but I don't know that going the MachineKit route and stripping out HAL and rebuilding everything around it solves the issues entirely.

You likely have heard of it, but can check out what Excessive Overkill and others have done towards that aim and what they intend to do. (github.com/ExcessiveOverkill) They're currently working on an entirely new system of hardware and software to achieve it and I think will have significant progress. They also have a Discord channel dedicated to its development

Beef
I think we need to create our own community for discussions. I'd prefer Telegram, but I believe not everyone has it, although it seems both Europe and America can use it (except maybe China which has restrictions). As I understand, everyone generally uses Whatsapp, so we can create a channel there too. I am now working on the interface for my device. In general, the design can be used for both CNC machines, robots, etc. I'll be basing it on Mazak + Probe Basic Linuxcnc + something from computer games. If there are interesting interface solutions, feel free to suggest them.

I'm disappointed how already you guys (starting with TheRoslyak and perpetuated by Rod and TommyLight expressing their valid concerns) have already derailed the thread with alternative projects and problems not directly related to our stated goal of making an S-Curve trajectory planner that works within LinuxCNC.

Of course this trajectory planner can be ported to other projects that utilize HAL as it will be a HAL Component, but this kind of bickering nonsense is the whole reason that I spent the time to write such a detailed description of our objectives. I would prefer to get feedback and information more aligned with what RMU has provided and with Rod's initial feedback than what the rest of the thread currently is.

To try to help push this back on topic.

I'll offer my lay persons opinion on the tool planner, while I much appreciate the current motion planner in Linuxcnc. It's multi line look ahead is something Linuxcnc was sorely lacking before. I do feel that it's use of circular arc blending was a step in the wrong direction, as far as jerk limiting goes. I think the previous planners parabolic blending was much closer to what is needed for jerk limiting. I think trying to constrain the blending movement at line/move transitions to any predefined geometry (such as an arc or other) may be a mistake,

Maybe part of my problem with this is not fully understanding how the blending tolerance is applied, but here is how I feel it should probably work.

I think the blending tolerance as defining the distance from the end points where blending can begin and end. Then the shape of the blending move simply takes what ever shape the maximum jerk limited acceleration profiles of the involved joints allow. Then the shape of the curve should be able to be calculated from the formulas used to calculate the joints acceleration profile.