Trajectory Planner using Ruckig Lib

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.