Trajectory Planner using Ruckig Lib

Hi,

For coleair lines and curves with curvature=0 (clothoid, spline that is in fact a line), i fused them to one piece of type line.
This seems to work better.



 

Hi,

I fixed some issue's in the gcode parser, it now loads the lcevette lift_test.ngc file ok.

In gcode we used:G64 P0.05 Q0.05

It filters out tiny lines according Q value.
It add's fillets according the P value. It first try's to add clothoid fillets, then it add's spline fillets.

There is a lot happening performing the algo. Fillets can be made between 2 helixes for example.
Every scenario had to be code.
Overall this is quite a complex task.

Colors to verify:
red=3d velocity profile.
white=linelight_green=arc
purple=clothoid fillet
cyan=spline fillet
yellow=trimmed helix
dark_green=helix
 
 
 

When G64 P0.0 Q0.0 output:
 
 

Looks _very_ good!
Is this all happening in user-space so far (including the velocity planning)? If so does this output a GCODE file?

This file has ~12500 lines of gcode.Used G64 P0.5 Q0.5
red=3d velocity profile
white=line
purple=clothoid fillet
cyan=spline fillet

 

It's now almost time to test the results on a realtime kernel.
Let's work on to that.

For a letter test:
Original input G64 P0 Q0.5
 
Input G64 P5 Q0.5
The spikes from the velocity profile are gone !

Hi Arciera,


Is this all happening in user-space so far (including the velocity planning)? If so does this output a GCODE file?
Yes, this is all done on a non realtime kernel at the moment. Including the velocity planning indeed.

Currently i have no logic to output a optimized gcode file, but it is certainly possible.
How relevant is this option at the moment?
We could also add a scurve path simulator to the user side.

Then the kernel motion code, can be centralized in a c++ class, then both the user side and kernel side can use
this code to run the program. This is just an idea.

How relevant is this option at the moment?

Not relevant, I was just wondering if I could run the output on a simulator.