Trajectory Planner using Ruckig Lib

Hi Arciera,

The G64 P.. value stands for max path deviation.

Current implementation uses the P value as a trim value for corners and then
create fillet. This results in a deviation less then should be.

It's done this way for now, to keep it simple and get things to work. Adding loops to the code to get as close
to the real path deviation is possible for sure. This code change is on the todo list.


say 25%, 50% and 75% of the total length of the trimmed segments and compare those to the 3d coordinates
Path deviation check at progress t=0.5 of the fillet segment to original path is ok to find closest value of P..
If that is what you mean?

I don't think this is practical as the operator would have to keep this in mind for every possible machining operation.
Yes, and on the other hand, i showed an exceptional case. Normally a travel height would be like 1 up to 50mm and
a G64 P0.01 for the fillets. This will not be a problem at all.

Here we tested a velocity profile based on current curvature along the path.
The red line is a interpolated velocity offset along the path based on the shape's curvature input.
This is interesting.

*Note that the line has zero curvature and speed is constant.
*Note in the lower left of the picture the red line has sharp transition corners, this has a reason i figured out.
The maxvm for the path is set at 250. The clothoid at curvature=0, may have a higher speed and it lowered down.
This results in a sharp speed transition edge.

 

Regarding spline roughing.
I'm not sure if you envisioned using the filleting algorithm to optionally create feed optimized roughing paths but if you did this we could then abandon the max-deviation value and use a minmal-curvature value instead. The algorithm would then increase the trim-back until either
a) minimal-curvature value is reached
b) one of the original path segments gets too short.

Hi Arciera,

optionally create feed optimized roughing paths
You mean, check until a minmal given feed is valid over the path? This feed input creates the fillet size's?
This is holy grail? Haha.

It's done this way for now, to keep it simple and get things to work. Adding loops to the code to get as close
to the real path deviation is possible for sure. This code change is on the todo list.

I get it, but keep in mind that details like this will make all the difference between success and failure for a project like this. I just make suggestions and since you are doing all the hard work it is of course up to you how to proceed.

Current implementation uses the P value as a trim value for corners and then
create fillet. This results in a deviation less then should be.

See my post about dependency of deviation on the angle between two line segments

Path deviation check at progress t=0.5 of the fillet segment to original path is ok to find closest value of P..
If that is what you mean?

Yes

Yes, and on the other hand, i showed an exceptional case. Normally a travel height would be like 1 up to 50mm and
a G64 P0.01 for the fillets. This will not be a problem at all.

In my opinion it is usually much better to handle the exceptional cases from the beginning. Once these things go out into the wild there are going to be enough cases left that nobody ever thought about.

Here we tested a velocity profile based on current curvature along the path.
The red line is a interpolated velocity offset along the path based on the shape's curvature input.
This is interesting.

Indeed, very good idea to plot the velocity on top of the tool path! Thanks for sharing.

You mean, check until a minmal given feed is valid over the path? This feed input creates the fillet size's?
This is holy grail? Haha.

Yes, but really this would only produce a time _optimized_ tool path as the max-curvature would need to be exceeded in some corner segments that are not long enough.

Hi Arciera,

A time optimal algo we can add on the todo list. It's really interesting to code this, and see the results.
I have no idea how difficult it is to code this.


For now i plotted the trajectory path lenghts vs the velocity profile on the xz plane.
Then for fitting the scurve on the trajectory (look ahead), we could do a forward sweep in white.
Then a backward sweep in green.
Then get the create a final blue curve that is below the green & white curve.

The blue curve is the overall path velocity profile. I think this should be correct.