Trajectory Planner using Ruckig Lib

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 agree with Rod, i do not like how this is heading, one member trying to get other members away from here at any cost and pointing them to work on a closed project, using private messaging, etc etc, that smells like plenty of other projects that after getting to a usable point, just locks the other developers out and moves on to profit from the work they have done.

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.

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