Trajectory Planner using Ruckig Lib

Yes that is correct. Three ta knot's can create a plane.

Note, the tool orientation vector and the current TA knot already define a plane:
 

On this plane we could record the tcp-ta intersection along the plane.

This crossed my mind as well but will only work for small changes in orientation angles. If we have a simple move like this:
G1 X0 A0
G1 x100 A180

there is no single plane that records the intersection path of the tcp-ta vector. As the vector rotates from pointing straight up to pointing straight down the resulting curve would disappear in infinity.

This 2020 publication proposes the use of 3d clothoid fillets for space corner smoothing in tool paths:
www.sciencedirect.com/science/article/abs/pii/S0736584519306222

So it seems that 2D fillets are still the norm in tool path segment blending, which gives me the impression that even modern controllers can't blend non-planar segment corners including anything that involves a helix (which is often used for tool entry moves). I have no idea really but this might explain why 3D CAM toolpaths are often made up of short straight segments as two straight segments will always form a planar corner.
All this makes me think that using the current (planar) clothoid library would require a segmentation of the recorded tool orientation path and then calculate the plane and fillet for every segment corner. I wouldn't know how to do the segmentation of the recorded orientation path much less if this is computationally feasable. Also it seems kind of silly to have to segment an entire helix when it is really just the beginning and the end that need fillets.

I had a look at your proposed method of fitting helixes:
forum.linuxcnc.org/38-general-linuxcnc-q...lib?start=420#303355
This would probably be ok for many cases, however I'm somewhat skeptical about the predictability of the path deviation as it seems to deform the helix not only locally at the beginning and the end but also quite noticeably in the middle. If this was done to our helical path of the tool orientation the deviation of the orientation angle might well be beyond acceptable.

So for the moment I have run out of ideas, unfortunately.

Hi Arciera,

After investing more time into the 3d clothoids. I wasn't able to get it work like it would be. So now the
green line is a bspline 3-degree. This works ok.
Let we use this bspline for the toolpath fillets.

You see there is a differance in clothoids and or bspline. The clothoids are bigger curves.
 

So tomorrow i can integrate the b-spline into the trajectory planner, it needs interpolation function etc.
 

github.com/krcwrhvgyxzqelljes/hal-core

So it seems that 2D fillets are still the norm in tool path segment blending, which gives me the impression that even modern controllers can't blend non-planar segment corners including anything that involves a helix (which is often used for tool entry moves).
I really have no idea. We now can do 95% of blending using clothoids for normal gcode.
For helix and non-planar stuff like tooldir blending, we can use b-spline blending. I think this is logical as long
as the Italian mathmeticians have not provided us the 3d clothoid algo. hihi.


as two straight segments will always form a planar corner.
Yes this makes it easyer to create a plane from 3 input points and perform fillet operations on that plane.

Also it seems kind of silly to have to segment an entire helix when it is really just the beginning and the end that need fillets.
Yes i agree. Just let it be an arc with a z value.

Note, the tool orientation vector and the current TA knot already define a plane:
Yes.

This crossed my mind as well but will only work for small changes in orientation angles. If we have a simple move like this:
G1 X0 A0
G1 x100 A180
To blend this spiral move, we use the b-spline at the X0 and the previous attached curve's end.

Ok i think i have a lot to do tommorrow, i think without wasting a lot off time in investegating as now we know what to do.

as two straight segments will always form a planar corner.
Yes this makes it easyer to create a plane from 3 input points and perform fillet operations on that plane.

Edit:
As long as they are not colinear.

Hi,

The algoritme for tooldir blending works finally.

The algoritme does :
1. It trims the recorded tooldir path for each gcode line on both ends.

• Problem here was with opencascade build in classes, this trimming was not giving expected results.
• I switched to making a curve trim algo myself.

2. It extends the trimmed tooldir path 0.001mm in 3d, on both sides to get a spline waypoint.
3. It draws a 3-degree bspline given 4 points in space.

Tooldir blending 0mm, blending turned off.
 

Tooldir blend 1mm
 

Tooldir blend 5mm
 

Tooldir blend and tooldir record in blue. Where blue is the original recorded tooldir path without tooldir blending.
 

Looks very nice!
When you say 'tooldir blend 5mm' does that mean the blended curve has a maximum deviation of 5mm from the recorded path?

@Hi Arciera,

Yes the deviation is within 5mm. It's less then 5mm.
The blend value is used as trim value seen from intersection point of curves.
Each curve has a trim value on both ends.

Now i have a little video, that shows also the tooldir symetric axis are updated in blue.


Now also a hard part comes. For each gcode line i need a correspondenting gcode tooldir path.
So i have to split the b-splines at the blue tooldir lines. Then i need to regroup a few curves together.

Hi,

Now finally we regrouped the fillets with the recorded tooldir path.
Now each gcode line has it's own tooldir curve. So now interpolation for the tooldir curve is easyer to do from 0-1.

Now i must make a algo to interpolate over the tooldir curve. This tooldir curve is a set of waypoints.
First calculate total lenght, then try to interpolate over the lenght to get ta point.

Ok,

Now it follows the tooldir path.