Trajectory Planner using Ruckig Lib

@ You all.
The spike's on the velocity curve for joint[n] outputs are solved. Added endvel must be zero.

@Andrew2085,
Thanks for your input. I have read the pdf document. It's interesting document. They actually did a test at
mercedes benz on a machine.

I don't think the FIR s-curve generation will really work for this after messing with it for a while.
If you can give me a working python example, i maybe can convert it to c, c++ and test it just like i did with the
grbl's corner algo.

I think for path blending arcs have to be avoided because there is a curvature discontinuity where they meet a line or different radius arc.
In my current solution, it uses endvelocity when arc's are tangent to each other, or lines to arc's have to be tangent, or lines
have to be colinear. Coincentric arc's with same radius are also accepted.
All other things will use ve=0.

I think the best way to blend a path is using clothoid curves
This can be true, i believe you. But what is accepted by the community? A arc blend or a clothoid blend.
If a product has corner with a arc blend, it looks quite nice. If its a non arc shape, i think they are not happy.

But i am open to integrate a algo into the source, we can just test different solutions.



 

Hi,

I did a cavaliercontour offset test, to get blended path result.
The test include's 2 lines at 90 degree.

1. Offset path both sides, inside & outside offset.
2. Offset the 2 offsetted path's back to original path, inverse offset. This creates a fillet for one inverse offset.
3. The two inverse offset path's on top of the original path with the most segments is the winner of the game !

 
 
 


Then the question is, how to integrate this into the trajectory planner, should we insert a gcode arc between these 2
lines? Or should we interpolate this at runtime and leave the gcode as is?
 

Hi Tommy,

For the planner this arc is a motion to be fullfilled.

The arc has it's own scurve motion from arc start to vm to arc end.
Then the toolpath must follow the arc. This is done by creating a arc segment, like creating a g1,g2,g0 etc.
Then the segment is interpolated how far the scurve motion is.

We can leave the original gcode as is. No problem for that.

In extreme conditions, like G64P25 this should result in big fillets. This can cause the cavaliercontour to skip gcode content,
because they are simply teared away by the cavalier algo.

So i have to come up with a solution....
In the mean time i am listening music trough just cloned youtube-dl. Modified the makefile, it uses python zero there.






 

Well, you could add a gcode filter that modified the gcode to insert an arc when the file is opened
Plasma configs Qtplasmac and more notably Monokrom both use filters. Monokrom arguably has  a more sophisticated filter that replaces holes with some "high def" hole cutting features. It does this by replacing any circles in the gcode with its own code with several segments to alter velocity

@Hi Rod,
Yes we can add gcode. We leave the gcode structure intact as is. But add extra info to it.

Will add a Head & Tail to each gcode segment. This are half segments that are tangent to each other.
The Head will get info about it's next gcode segment. Some may be filtered out by the cavalier algo.
This then will solve missing gcode lines when users decide to use G64P100

The cavalier algo is made fertig for 3d operations.
Testing 2 lines in a 3d position :

    cavline l0;
    l0.p0={0,0,0};
    l0.p1={50,50,50};
    l0.bulge=0;

    cavline l1;
    l1.p0={50,50,50};
    l1.p1={100,0,0};
    l1.bulge=0;

Then we create a plane from the given line points. We translate & rotate the line content to topview xy zero.
Then we do the cavaliercontour algo.
Then we translate & rotate the results back to original plane. This far better then any other fillet algo.

 

Looks awesome Grotius

I'm also following this closely

I have a 22 ton 5axis machine I would love to see this working on

It has rapids of 40m per min so very fast and heavy. Would be a good torture test of your scurve code

It's not enough for an arc to be tangent to a line or to another arc. They have to be curvature continuous. When a line meets an arc on its tangent, the curvature goes from zero to 1/r immediately, where r is the radius of the arc. The radial acceleration goes from zero on the line, to v^2/r instantly where they meet. That means infinite jerk or at least very high jerk in real life. The same is true for arcs with differing radii that are tangent.

The only way to limit jerk is either to slow down to zero velocity where they meet, or join them with a type of curve with a curvature that smoothly varies between the two.

The problem is basically this: en.wikipedia.org/wiki/Track_transition_curve

@Becksvill,

Looks awesome Grotius
I'm also following this closely
I have a 22 ton 5axis machine I would love to see this working on
It has rapids of 40m per min so very fast and heavy. Would be a good torture test of your scurve code
Good idea to test this out soon!  If you press stop in lcnc using 40m/min. I mean using the trapezium planner,
what will happen to your machine? Is the building shaking or is the machine walking to outside?
I ask this because a stop is very dangerous. I would to see happen a mavel to zero pause instead, Then realease the servo
drives. Or use the servo brakes is this is possible.

@Andrew,
I agree that tangents also don't satisfy the perfect solution.
If you make a proposal in the code language you like, we can test it. 

As today i am ready create fillets in 3 contours, fillets are made from polyline to polyline. The polyline may be a line or arc.




 

I did a little playing around here colab.research.google.com/drive/1UHn0M74...8Aln1z77?usp=sharing with what I read in this paper www.researchgate.net/publication/2926698..._Numerical_Algorithm. Basically you give the algorithm a starting position, radius, angle, angular direction, and ending angle and it generates a matching clothoid curve. You don't know the ending position until the computation is finished so it will have to be translated after. I'm not sure if this would cause problems that couldn't be dealt with.

There could be other curves that are easier to work with, but I think it might be important that they have closed-form solutions to solving the jerk at a given point and velocity on the curve for efficient trajectory planning. The clothoid is easy in this sense, but harder in actually fitting it to the path geometry. B-splines have C2 curvature continuity so jerk could be limited, but I haven't looked into them further yet.

The s-curve generator is coming along well, it seems very fast.