Trajectory Planner using Ruckig Lib

Hi Lcvette,

I runned the program 3-4 times.

The planner stopped with path blending on at line 544 & 1075.
It seemed to be a bug, when one of the blend output lenghts was zero, it stopped. That's now solved.



I know the scurve planner can do a better job, but i have to invest time in optimalisation
the speeds in the future. So far i solved another bug thanks to your file.

grate progress here.

adaptive tends to have a lot of feed changes and micro lifting going on, very common code type to be ran now days too. where feed reposition moves are much highter than cutting feeds and into the m/min like 5 or 10m/min repositions , while cutting might only be 1or 2 m/min

slotting operation would be a good test too makes a lot of machine issues in the current tp due to all direction changes with in a small area.

see attached exsample i just threw together , see what you get from results 

@Robh,

Thanks for your sample. I will test it soon. Exotic examples are welcome to test. And are good practice to test
the planner.

@All,

I just made a c++ interface for the clothoid's. To easely use in c++.
It can build the clodhoid curve, it can interpolate the point on the curve given a progress or current displacment.
I had to figur out that, but it all was quite easy to solve.
So now technically it's ready to use in the trajectory planner. As we can calculate & interpolate the clothoid's.

The performance :

When you create a clothoid given startpoint, endpoint, angle_begin, angle_end it calculates curve params:
- Build duration: 0.006814000 milliseconds

Then this is a result of evaluate the curve using a input of retrieving 20 waypoints.
- Evaluate duration: 0.027010000 milliseconds

Then in the trajectory planner during runtime we need to interpolate the xyz position every cycle.
- Interpolate duration: 0.000772000 milliseconds

Showing interpolation results:


I think this is understandable code to use:
interface.h
interface.cpp


Now the question remains. How to use the curve on the traject. How should we fit the curve between the gcode segments.

Possible solutions :
- Should we give it a max path deviation as input? This could sample the curve up to max deviation value.

Any suggestions?






 

Great,  you could see it struggle a bit around those line segments,  this is a common issue with adaptive tool paths I've been dealing with,  I've since changed repositioning strategy to "stay down least" which forces a straight line move with z lifted up to the programed Clearance plane, but that is alot of wasted travel in z axis where direct xy repositioning would be faster. Was the bug you found also in the current lcnc standard TP?

Thanks Grotius

robh wrote:

grate progress here.

adaptive tends to have a lot of feed changes and micro lifting going on, very common code type to be ran now days too. where feed reposition moves are much highter than cutting feeds and into the m/min like 5 or 10m/min repositions , while cutting might only be 1or 2 m/min

slotting operation would be a good test too makes a lot of machine issues in the current tp due to all direction changes with in a small area.

see attached exsample i just threw together , see what you get from results 

 

I don't typically see issues with adaptive slotting as they tend to use tangent arcs to straight lines.  It seems to be curve created by the cam software that are made up of straight line segments that trip up the tp.

@Lcvette,

you could see it struggle a bit around those line segments
It was certainly struggling. Not worth a presentation. But without doing this we will not
get to the top of the mountain..

What is the defenition of "adaptive" that u used. It has nothing to do with adaptive feed i think?

The bug was only related to my planner. Nothing to do with original planner.

Here is a biclothoid overlay with a circle. I think there is only g1 continuity. I think problem to solve.
How to get the biclothoid drawn with g2 continuity as there are no other inputs to do that.
You only have entry angle and leaving angle. What do we miss here?

 

Grotius wrote:

Now the question remains. How to use the curve on the traject. How should we fit the curve between the gcode segments.

Possible solutions :
- Should we give it a max path deviation as input? This could sample the curve up to max deviation value.
 

could we utilize G64 P# Q# to specify the deviation similar to the coherent trajectory planner? This would work nicely with most post professors.  In fusion there is a lcnc post which uses the operation parameters for tolerance and smoothing to create a G64 P(smoothing) Q(Tolerance) to each operation. 

Adaptive clearing is a high speed type of roughing tool path that uses constant engagement with the work piece.   I don't tend to have issues with the cutting so much as the repositioning moves between cuts as it uses the short line segments and this cannot be altered through settings,  at least none that I have found.   Because roughing is one of the longest most time consuming operations on most parts this really hurts efficiency when you must slow things down to keep machine shake in check. 

@Robh,

I tested your file. It's interesting to see the pocket mill path consists of tiny line segments forming a curve.
Machine is constantly shifting speeds as it thinks, hey the next line is not tangent, so i have to stop.

When i enable the fillets, machine uses little end velocity, little improvement then in the scope.

In the planner there is info about the next segment angle. Like next segment is 1 degree of
course from current one.
In previous planner code i used this to maintain speed. In this planner currently only
full tangent may have a certain velocity end to next segment.

In the end, i think developping this to a biclothoid path overlay may be a magical solution.
I believe in the g2 continuity. But at the moment i have to figur out how to get this with done the current biclothoid library.

In the end of the video, you see a tiny bug i have to solve. It's a exeption that has to be made in the fillet algo.
The transfer from g0 to g1 that is done colinear, here is the problem the algo can not make a plane from 3 points.
So i have to tell the algo to skip when this occurs. Thanks to your file i found this.

@Lcvette,

G64 P# Q# to specify the deviation similar to the coherent trajectory planner?
Thats ok for me.

I was searching where they pass the G64 values to the planner for an hour.
So far i could not find it. Maybe someone knows how it's passed or knows the name in the code.