Trajectory Planner using Ruckig Lib

I did not know those even existed


back when machines had no memory things were different. my Maho had all sorts of interesting canned cycles for complex motion that you would not have the memory to hold in a program.

Regarding the formula for Theta(1,0):

I still don't fully understand the first formula, the short one at the top.
I think its calculating the "angle start" parameter for the z component.
 

This calculates the tangent angle (in the XZ plane) in the starting point (s0) of the clothoid on the first trajectory segment after rotating and translating the space corner so that the normal vector of the corner coincides with the z-axis (as shown in Fig 6 ).
If the corner is planar then the expression inside the bracket is zero and Theta(1,0) is zero (ie the tangent is horizontal).

I haven't yet been able to make up my mind if this method can also work for arc-helix corners.

[edit]
Well, I've given it a fair bit of thought and I cannot see a reason why it shouldn't work with helical segments.

Hi Arciera,

Well, I've given it a fair bit of thought and I cannot see a reason why it shouldn't work with helical segments.
Indeed, this works with anything.

Maybe, maybe we are lucky. In this thread it is possible they will give us 3d clothoid code from Italy university first hand.
He is not looking dayly here, but we have time.

It's also possible to request other 3d clothoid code from China.

Today i did review the gcode parser source code as i was not satisfied with it. I had problems changing from G40 to G41 after
one line of gcode during the program run. So the tool was not reacting to the given offset side.

So now that is solved. The parser can now read more gcode's at one line. Also it can read the spline
with multi xyz inputs at the same line. It will create xyz point sets.
 

valid input for spline :
g1 x0 y0 z0
g5 x1 x10 y5 x15 z20

will create spline points :
x0 y0 z0
x1
x10 y5
x15 z20

parser_to_shapes , wich is improved to work better now.
 

Maybe, maybe we are lucky. In this thread it is possible they will give us 3d clothoid code from Italy university first hand.

Phew, one can sure tell that the paper linked in that thread comes from mathematicians. I could _probably_ workout the other paper written by engineers but this one I don't even need to try. I guess we'll see if they come up with anything useful.

Also it can read the spline with multi xyz inputs at the same line. It will create xyz point sets.

So if I understand you correctly you are planning on approximating the 3d clothoid fillets with the G5 spline gcode?

You extended the G5 2d cubic spline to 3d?

Hi Arciera,

So if I understand you correctly you are planning on approximating the 3d clothoid fillets with the G5 spline gcode?
For what i have seen, is that a spline is a shorter, cq sharper curve between 2 points than a clothoid.
I have been thinking if we could change spline characteristics to approx a clothoid, but i don't know for now.
And we can use the spline  to solve the 3d clothoid fillets. like a helix to line fillet, or helix to arc fillet etc. All the fillets that
are out of plane we can use the spline for now. If we have the 3d clodhoid algo available, we just change the algoritme to use a 3d clothoid.

You extended the G5 2d cubic spline to 3d?
I used a 3d spline 3-degree. It's a standard spline curve available in opencascade library.
For motion a 5-degree or a quintic spline is maybe better, but we have to find out when we are going to do the look ahead.
Then calculating speeds become's essential.

Left to do is create the interpolation function for a helix.
Then i will do the path blending function.

At this moment, we have played along with tooldir blending, we could see if the result was valid in our graphics output.
This all is done in c++. This c++ code is runned from userland. Now the nice thing is, the kernel module uses
excact the same c++ functions. There is no code duplication or translation to c needed. Therefore the kernel
also opens the gcode file, read's it, parses it, loads data into memory etc. (In lcnc the gcode data is streamed from userland to kernel, in hal-core, kernel loads gcode itself.)
In userland, we only need the graphics, the rest of the memory is released, in the kernel we don't need the graphics,
there the graphics memory is released, so the program turns out to be memory efficient at runtime.