Trajectory Planner using Ruckig Lib

This post is just for info.
Today i made a code that calculates arc speeds from 3 given values, 3 constants.

1. linear max velocity. (machine maxvel), this is used to limit arc speeds to vm.
2. optimal arc speed (the perfect arc speed for your machine at the radius given by 3.)
3. the arc radius at optimal arc speed

It then calculates the angular speed in rad/sec, called Omega.

ω = linear speed  / radius  [rad/sec]

This omega is then a constant and is used to calculate other arc's and circle speeds at different radius.
Let's consider a example with arcs of radius 10 mm and 1000 mm, both with an angular speed of 20 rad/s,
the 20 rad/s is a constant and calculated from inputs 2,3.

1. For the arc with a radius of 10 mm: vsmall arc=20 rad/s*10 mm=200 mm/s
2. For the arc with a radius of 1000 mm: vlarge arc=20 rad/s*1000 mm=20000 mm/s​
   
   So the speed differs when radius changes, this is good.
   
   Tested the code :
   
   Input:
   double radius4 = 0.01;       // Radius in mm, blending G64P0.01 in LinuxCNC
   double linearSpeed4 = am->calculateLinearArcSpeed(radius4);
   
   double radius5 = 0.1;       // Radius in mm, blending G64P0.1 in LinuxCNC
   double linearSpeed5 = am->calculateLinearArcSpeed(radius5);
   
   Output:
   Linear Speed on the Arc with Radius :0.01 v:2.8 mm/min
   Linear Speed on the Arc with Radius :0.1 v:28 mm/min
   
   github.com/grotius-cnc/angular_motion
   
   

So far the waypoints that constructed the green arc, are outside the yelllow arc. The yellow arc is the exact path to follow.
So next thing is try to get exact path waypoints. With ruckig, this was a no go.

Uh..... no.
I'm no porgramming expert, but I have worked in CAD/CAM as a professional, and also have a mill I use LincuxCNC on. So I realy appreciate your work here.

The point here is that when you go from straight corners with full stop with blending you alter the actual path.... we all get that. You will have corner rounding.
But.... the same happens here! When we go from simple corner rouunding to jerk limited corners the transition between the curves will "distort", and the path will obviously also look different. Just as above.

The corners will in fact end up with what is called a G2 curve. Look it up.

In your screenshot your green curve is in fact a G2 curve, where the transitions between the straitght parts and the curve have a transition, or a derivative which is the matematical description.
And.... this is a BETTER curve. If you look at it it is better resembling the sharp corner we came from. The closest part to the corner is closer to the corner with the green curce that it is for the yellow curve.

So, to me it looks like the Rucking Lib is doing it's job and modifying the curve to the desired G2 curve. This is what this lib. is doing! And you expected it to stay like the yellow corve, which is what it looks like without jerk limitation. You can't expect the curve to stay the same when you change the accelerations on the different axis indipendently. How much you allow them to change is one thing. But this is set by your allowed max accel values, and not much else.

Remember, your car will drive in a different path if you limit how fast you turn the steering wheel when turning. And you might end up having to have a sharper turn radius at the maximum if you have a low rate of turning the wheels, like your green curve. So you will have to factor this in when you set up the system. Because this might alter the requred max accelereations. But the jerks will be limited, which is the goal.

So I'd say you are absolutely going it the correct direction here!
Keep going with what you have here.

Hi,

I have looked into the trajectory planner again. The code is quite well done so far. A nice starting point to go
on with coding.

There are several trajectory planners made so far.
The " scurve_skynet " i think is the nicest to go on with.

The plan is to integrate a linear & scurve motion planner into the trajectory planner.

This is my latest linear motion library, " linear_motion " wich is now loaded into the trajectory planner at
this  line.

For calculating arc speeds, the idea is to use the "angular_motion " library. The angular motion is loaded into
the the trajectory planner at this line.

I hope within a few day's i can present a new scurve_motion libary.

To update my latest post : I hope within a few day's i can present a new scurve_motion libary.

I have been coding for a while now, coding a new scurve library in c.

The first part is working is now.

This includes the jog part for Linuxcnc.

When user press the jog button, the joint or
axis starts to move, when jog button is released, the jog will slow down and stop.

In the lcnc source i also solved a jogging bug in axis.

This scurve library uses only "jerk-max" to specify the s-curvature part.
In relation to the Ruckig library, this library uses a linear acceleration stage between the convex and concave curve
parts when needed.

In this video we show the scurve velocity when jog button is pressed or released.


I hope you like it so far.

I just want to let you know that this work is really appreciated

Hi Routerman,

Thanks for your kind words !

The jogging of a scurve is quite complex, you can find out in the source code.
It took a lot of time and disipline, but for now i am satisfied.

At this moment the jog library is working more or less ok.
Todo is jog step, like jog 1mm, or jog 10mm etc. This you can select in the axis gui.

In linuxcnc this is just jogging to "pos_cmd" and stop there with end velocity zero.

Video shows jogging forward & reverse, and how multipe button presses are being processed as jog interupts.


The scurve-jog project on github includes a c & c++ inplementation. The c part is for linuxcnc.
You can play with the scurve-jog-plot to show the jog curve in a qt realtime plot

Now i will test the jog source code in linuxcnc, and see what the scope displays.
Next update here will be about the linuxcnc scurve jog test.