Trajectory Planner using Ruckig Lib

Hm, seems to me that the recorded (blue) path deviates quite significantly from the displayed smoothed tool direction path.

like here:

 

@Hi Arciera,

Yes, i have to track down this. The pre- & post- recorded toolpath doesn't match in some cases.
 

@Hi Arciera,

I tracked down the issue. One important issue, that was responsible for wrong cone preview angles.
The other issue i will show you in video.

The important issue was a function that calculated the abc angles from a given tcp & ta point in space.
The function was using atan... for 3 planes. However, it did not output what we want to see.

Now i changed the function to use a quaternion with config : gp_Extrinsic_XYZ. new function. This seems to work properly.

Now in next video i recorded tooldir axis lines, to show you what is the difference between

1. recorded tooldir path
2. blended or optimized tooldir path.

In the video the vertical axis lines can contain 2 different colors. One color is for recorded tooldir path. Other color
is for blended tooldir path. The axis lines can be off different lenght between path's. However they are valid as they
are on the same plane.

Yes I see, the smoothed tooldir line does not necessarily retain the constant distance from the tcp path which is fine since we are really only interested in the direction of the tool vector.
I'd say this looks quite promising!
So, does the smoothing process ingest a gcode file, process it according to 'smoothing' parameters and then output another gcode file? If so could this output file be run with the current Gcode Interpreter/ trajectory planner?

@Hi Arciera,

We can do so. We could write a tooldir blended gcode file out. This then can be runned in the current interpreter of linuxcnc.
But i heard, when a,b,c are involved it falls back to no look ahead mode.

So maybe with a trick it can use look ahead for xyz, and then just output the interpolated a,b,c values?

But i heard, when a,b,c are involved it falls back to no look ahead mode.

Yes that is true, it does not make much sense for multiaxis. Would only be of interest for XYZ axes.
Getting advanced look ahead/ velocity blending for multiaxis working is pretty much a prerequisite for multiaxis operation.
 

I'm just thinking that a XYZ jerk limit smoothing 'postprocess' app would enable people to test the algorithm.

I'm just thinking that a XYZ jerk limit smoothing 'postprocess' app would enable people to test the algorithm.
Let's put this is on the list. We could output a gcode file with a certain mm resolution. This is the easyest way.
I will not split a g2 in multiple G2's with different a,b,c values.

Ok i just tested when there is only a,b,c move with no xyz. This now works.
When there are xyz values it will interpolate the abc over it. But with tiny xyz values and huge abc values, there i have not
yet a solution for in the code.




 

Hi,

For fun i made some video's of the 5 axis tooldir blending.
I typed some gcode lines for xyz and added some abc values in radians to it.
Some of these blending really blow's my mind. It can just filter out complete rotations on a & b axis....