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.

@Rosalyk,

And I wonder why this planner is needed at all if I still have to calculate the circle myself.
Yes, that's work of the planner. It should at least work with lines & arcs.

 

Well, it turned out that even the most advanced MoveIT can't handle circular interpolation on its own. Need to write the math yourself. Tomorrow, I will try to write the math myself + Ruckig, with the only difference being that I will use complex numbers.
P.S. There was a scientist named Steinmetz who studied alternating current and used complex numbers instead of trigonometry in his manuscripts, which earned him the title of academician.

TheRoslyak wrote:

Well, it turned out that even the most advanced MoveIT can't handle circular interpolation on its own. Need to write the math yourself. Tomorrow, I will try to write the math myself + Ruckig, with the only difference being that I will use complex numbers.
P.S. There was a scientist named Steinmetz who studied alternating current and used complex numbers instead of trigonometry in his manuscripts, which earned him the title of academician.
 

When I was trying out ruckig the problem that I came across was when you give it a set of constraints and a start and end position, it would create the trajectory and satisfy the constraints, but it would overshoot the end point and then move backwards to it. I'm not sure if I was just overlooking something and there are ways to have more control. It seems like its made to get from point A to point B as fast as possible with no restriction that it has to stay on a line segment connecting A and B. There is a paid version with waypoints, but I don't think that really solves the problem. It sounds like you want to generate an exact path and then move along that path while satisfying jerk, acceleration, and velocity constraints.

Yes, I understand what you mean. At first, it seemed to me that examples 4 and 5 in the Ruckig library were free implementations, but it turned out that they are for the pro version. However, I still managed to implement circular interpolation with maximum accuracy. I created an algorithm that calculates the next point on the circle before sending it. And it turned out that this works without any issues!

Right now, as a test, I made a program that creates a circle with a given radius. Overall, I am satisfied with the result. For now, I will continue to move forward. In general, I have a working solution that does not relate to LinuxCNC and is free from many of its drawbacks.