Trajectory Planner using Ruckig Lib

I understand that you are currently developing a global software solution. Right now, I am trying to work with OMPL. As I understand it, this should work as follows: first, OMPL calculates the points, then either all at once or one by one, they are sent to Ruckig and only then to HAL. Is this how it should fundamentally work? I am currently trying to implement linear movement in this way. I understand perfectly well that this can be done using only Ruckig. But in the future, I plan to create more complex movements.

@TheRoslyak,

I get your point. But if you start using lcnc as it is with a c++ hook on top,
you will be able to use scurve planner in future.  This then enables you to perform a G2 continues path movements.

And for now you just use the existing tp planner. With one day of hard work, you can get something to run.
Then just keep your c++ code base closed to the public.

I would certainly not advise to you to create your own planner, as this is a difficult and time consuming task.
But if you have no time limits, you can do it. If you think you have to do it, just do it.

@All.
I got the file with half a milion gcode loaded. It's quite responsive.. haha.
Had to use a old trick in opencascade.
Filtered out 86% of stuff. Then made path G2 continue attaching tri-clothoids inbetween.
 

Yes, you said well that if I work on it for a day, I'll manage to get it done. That's how it turned out. I managed to use OMPL to build a linear trajectory, split it into segments, and then send these segments to Ruckig and then to HAL. Then I wrote to GPT asking to make an example with circular interpolation. It replied that OMPL cannot handle circular interpolation on its own; it needs to be calculated using sine and cosine, for example, and split into segments. So I end up first calculating with a simple equation, then OMPL, then Ruckig. And I wonder why this planner is needed at all if I still have to calculate the circle myself.

Maybe I don't quite understand what a trajectory planner is. To me, it should have tools for constructing circles and splines, etc. What is the point of it if I can indeed calculate the circle myself and use Ruckig?

@Andrew,

Here is the scurve doing 100 segments:

Hmm, it looks like this is coming to zero velocity and acceleration at the end of each segment instead of getting up to the highest velocity the segment can get to, and the next segment starting from that velocity.

I think I've fixed all the bugs that I know about so far. Here are 100 randomly generated segments. Some places look like sharp edges, but it's just scale. When zoomed in they are all smooth s-curves.

I'm pretty sure this can also be used for velocity mode and jogging too. The more expensive functions take about 5200ns, and the ones that would be needed for jogging take about 1200ns. I was thinking though. Isn't using s-curves for jogging kind of pointless? You're not cutting anything while jogging, and if you are, you're cutting straight lines, so there is no benefit, just added complications.

 

@Andrew,

Nice work!

With scurve jogging you can jog faster because you can use higher acc profile. But its problably also
more dangerous jogging at such high speeds.

For a servo driven machine with a lot off mass, scurve jogging will be a used more often as it reduces
machine shocks, cq inertia.

But indeed if you jog normal speeds, trapezium jogging is fine, and in practical sence, it feels
more direct.

Hmm, it looks like this is coming to zero velocity and acceleration at the end of each segment instead of getting up to the highest velocity the segment can get to, and the next segment starting from that velocity.
Ahh ok.

I modified the example to do 100 x 1 inch segments without stopping in between.
It works ok.