- Posts: 4819
- Thank you received: 2177
Trajectory Planner using Ruckig Lib
- Aciera
- Offline
- Administrator
-
Less
More
2 years 3 months ago #306018
by Aciera
I don't see another way than to limit the speed to the highest curvature value but since this will only apply to fillets I don't think the segments are going to be very long in the first place. Not really sure about this but creating a path deviation of a couple of mm is likely already the limit of what you would want even in a roughing cycle.
Replied by Aciera on topic Trajectory Planner using Ruckig Lib
Then there might be a problem when one segment is very long and has high curvature value at one spot.
This then will reduce the overall segment speed. How to deal with this?
I don't see another way than to limit the speed to the highest curvature value but since this will only apply to fillets I don't think the segments are going to be very long in the first place. Not really sure about this but creating a path deviation of a couple of mm is likely already the limit of what you would want even in a roughing cycle.
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
- Grotius
- Offline
- Platinum Member
-
Less
More
- Posts: 2419
- Thank you received: 2349
2 years 3 months ago - 2 years 3 months ago #306019
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
Hi Arciera,
I don't see another way than to limit the speed to the highest curvature
When only dealing with lines and arc's this should be fine.
Once we have spline's and clothoid's the curvature varies along the path.
Say for each segment we create a scurve velocity profile using 5 waypoints.
Then using a B-spline to represent the upper bound of an S-curve profile can be a practical approach.
Then running realtime we are able to follow the upper bound (spline) with the scurve algo along the path.
Then when we for example should apply a spline roughing algo like seen in the science papers,
this then results in perfect velocity changes along the path. A sort of dynamic feed flow. I dont know how to call it.
This upper bound (spline) then also smoothes the transition's between lines and arc's with clothoid fillet in between.
In fact we could create one upper bound (spline) along the entire gcode path. I could test this with a large file.
// Notes:
// curvature = k;
// k = 1 / radius ( this is for arc, or circle, for spline or clothoid use library functions ).
// linear_acc = r * angular_acc
// angular_acc = linear_acc / r
// velocity = sqrt( angular_acc / k )
I don't see another way than to limit the speed to the highest curvature
When only dealing with lines and arc's this should be fine.
Once we have spline's and clothoid's the curvature varies along the path.
Say for each segment we create a scurve velocity profile using 5 waypoints.
Then using a B-spline to represent the upper bound of an S-curve profile can be a practical approach.
Then running realtime we are able to follow the upper bound (spline) with the scurve algo along the path.
Then when we for example should apply a spline roughing algo like seen in the science papers,
this then results in perfect velocity changes along the path. A sort of dynamic feed flow. I dont know how to call it.
This upper bound (spline) then also smoothes the transition's between lines and arc's with clothoid fillet in between.
In fact we could create one upper bound (spline) along the entire gcode path. I could test this with a large file.
// Notes:
// curvature = k;
// k = 1 / radius ( this is for arc, or circle, for spline or clothoid use library functions ).
// linear_acc = r * angular_acc
// angular_acc = linear_acc / r
// velocity = sqrt( angular_acc / k )
Last edit: 2 years 3 months ago by Grotius.
The following user(s) said Thank You: akb1212, Lcvette, Aciera
Please Log in or Create an account to join the conversation.
- Grotius
- Offline
- Platinum Member
-
Less
More
- Posts: 2419
- Thank you received: 2349
2 years 3 months ago #306092
by Grotius
Replied by Grotius on topic Trajectory Planner using Ruckig Lib
Hi,
For every gcode segment, we calculated the velmax "vm" for the segment given the curvature extrema of
that segment. The curvature extrema is retrieved by c++ functions that iterate over a spline, clothoid curvature.
For arc & line, the curvature is constant and easyer to retrieve.
If you look at the results, i think they aren't shocking or out of scope. My first impression is ok for the vm values.
From here we can do the look ahead function.
For every gcode segment, we calculated the velmax "vm" for the segment given the curvature extrema of
that segment. The curvature extrema is retrieved by c++ functions that iterate over a spline, clothoid curvature.
For arc & line, the curvature is constant and easyer to retrieve.
If you look at the results, i think they aren't shocking or out of scope. My first impression is ok for the vm values.
Warning: Spoiler!
Code:
get vm, g_id:1 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.61821 kmax:0.276379 vm:25.1632
get vm, g_id:1 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.61821 kmax:0.276379 vm:25.1632
get vm, g_id:1 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.61821 kmax:0.276379 vm:25.1632
get vm, g_id:1 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:1.45241 kmax:0.688511 vm:15.9428
get vm, g_id:0 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.47639 kmax:0.287654 vm:24.6651
get vm, g_id:0 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.47639 kmax:0.287654 vm:24.6651
get vm, g_id:0 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.47639 kmax:0.287654 vm:24.6651
get vm, g_id:1 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:14.4729 kmax:0.0690948 vm:50.3264
get vm, g_id:1 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:14.4729 kmax:0.0690948 vm:50.3264
get vm, g_id:1 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:14.4729 kmax:0.0690948 vm:50.3264
get vm, g_id:1 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.47639 kmax:0.287654 vm:24.6651
get vm, g_id:0 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.47639 kmax:0.287654 vm:24.6651
get vm, g_id:0 radius:0 kmax:0 vm:250
get vm, g_id:9 radius:3.47639 kmax:0.287654 vm:24.6651
get vm, g_id:0 radius:0 kmax:0 vm:250
items G64 P.. Q.. before:22 after:33 diff:-11
From here we can do the look ahead function.
The following user(s) said Thank You: akb1212, Lcvette, Aciera, Darium, Unlogic
Please Log in or Create an account to join the conversation.
- Aciera
- Offline
- Administrator
-
Less
More
- Posts: 4819
- Thank you received: 2177
2 years 3 months ago #306094
by Aciera
Replied by Aciera on topic Trajectory Planner using Ruckig Lib
The following user(s) said Thank You: Lcvette, Grotius
Please Log in or Create an account to join the conversation.
- Lcvette
- Offline
- Platinum Member
-
Less
More
- Posts: 1682
- Thank you received: 784
2 years 3 months ago #306095
by Lcvette
The first is me thinking that the Z start/end threashholds should NOT be violated as i could see that being problematic and arbitrarily gouging into parts when repositioning and increasing the cut loads beyond he commanded settings.
The second is that it is really not any different than the way i currently plan the tool paths when roughing and setting smoothing tolerance and stock to leave in the XY cut plane. That said, i do notice that in cam the z heights do not violate the set bottom height of the selected geometry regardless of the smoothing and or tolerance settings. if linuxcnc currently does have not seen evidence of it. of course i typically set the smoothing values in LCNC fairly low, typically not more than 1-3 thousandths so would be difficult to see that when using a stock to leave with enough cushion for it not to show up on the finished part after finish passes are complete.
interesting situation, i am curious to hear more on it from Grotius.
As always, Thank you for the awesome work and effort on this amazing project!
Chris
Replied by Lcvette on topic Trajectory Planner using Ruckig Lib
are the two drawn squares of the same code with different trajectory plan methods applied? if so, then I am wrestling with two thought trains.Looks like there is a bit of a problem there:
I don't quite understand why the fillets go above the G0 and below the G1 moves.
The first is me thinking that the Z start/end threashholds should NOT be violated as i could see that being problematic and arbitrarily gouging into parts when repositioning and increasing the cut loads beyond he commanded settings.
The second is that it is really not any different than the way i currently plan the tool paths when roughing and setting smoothing tolerance and stock to leave in the XY cut plane. That said, i do notice that in cam the z heights do not violate the set bottom height of the selected geometry regardless of the smoothing and or tolerance settings. if linuxcnc currently does have not seen evidence of it. of course i typically set the smoothing values in LCNC fairly low, typically not more than 1-3 thousandths so would be difficult to see that when using a stock to leave with enough cushion for it not to show up on the finished part after finish passes are complete.
interesting situation, i am curious to hear more on it from Grotius.
As always, Thank you for the awesome work and effort on this amazing project!
Chris
The following user(s) said Thank You: akb1212, Grotius
Please Log in or Create an account to join the conversation.
- Lcvette
- Offline
- Platinum Member
-
Less
More
- Posts: 1682
- Thank you received: 784
2 years 3 months ago #306096
by Lcvette
Replied by Lcvette on topic Trajectory Planner using Ruckig Lib
unless the minimum radius setting would not allow for the transition to move from the previous line plane to the new line target plane maybe?Looks like there is a bit of a problem there:
I don't quite understand why the fillets go above the G0 and below the G1 moves.
The following user(s) said Thank You: akb1212, Grotius, Aciera
Please Log in or Create an account to join the conversation.
Time to create page: 0.177 seconds