Trajectory Planner using Ruckig Lib
25 May 2024 20:08 - 25 May 2024 20:52 #301440
by Grotius
Replied by Grotius on topic 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.
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.
Last edit: 25 May 2024 20:52 by Grotius.
Please Log in or Create an account to join the conversation.
26 May 2024 10:44 #301470
by robh
Replied by robh on topic Trajectory Planner using Ruckig Lib
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
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
Please Log in or Create an account to join the conversation.
26 May 2024 11:41 #301471
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
@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?
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?
Please Log in or Create an account to join the conversation.
26 May 2024 19:41 #301514
by Lcvette
Replied by Lcvette on topic Trajectory Planner using Ruckig Lib
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
Thanks Grotius
Please Log in or Create an account to join the conversation.
26 May 2024 19:47 #301515
by Lcvette
Replied by Lcvette on topic Trajectory Planner using Ruckig Lib
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.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
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
26 May 2024 20:03 #301517
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
@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?
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?
Please Log in or Create an account to join the conversation.
26 May 2024 20:13 #301519
by Lcvette
Replied by Lcvette on topic Trajectory Planner using Ruckig Lib
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.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.
The following user(s) said Thank You: akb1212
Please Log in or Create an account to join the conversation.
26 May 2024 20:42 #301522
by Lcvette
Replied by Lcvette on topic Trajectory Planner using Ruckig Lib
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.
Please Log in or Create an account to join the conversation.
26 May 2024 20:44 #301523
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
@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.
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.
Please Log in or Create an account to join the conversation.
26 May 2024 20:58 #301524
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
@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.
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.
Please Log in or Create an account to join the conversation.
Time to create page: 0.222 seconds