Trajectory Planner using Ruckig Lib

What is the line in red and how do you choose the start velocity for a segment in the forward and backward sweep?

Hi Arciera,

The red is the vm based on curvature.
Forward sweep starts at zero vel. Backwards sweep start at zero vel.
Then the algo has to look if the velocity may be increased or not.
 

I see.
Very handy to have these graphs. Like hal-scope for the preview.

Grotius wrote:

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.
 

Grotius,

In fusion there is a setting for lift height which is a very small movement just to lift the tool gently above the previously cut surface while repositioning to the next engagement point, this lift height could certainly be set very near the same value used for the G64 P value in cam.  in this example the lift height is set at 0.005" which would mean if a P value is set at 0.004" (default smoothing value used in fusion for adaptive roughing cycles) it would not be able to remain between the Z start/end positions correct? or am i wrong here?  I have attached the settings in cam along with the code as it would be posted, perhaps you could plug it in to see the results with the new planner?

Thanks, let me know if you need anything else!

Chris

 

 

 


 

@Lcevette,

In previous post somewhere:
the travelheight has to be at least the G64 P..

in this example the lift height is set at 0.005" which would mean if a P value is set at 0.004"
Then you could use : lift height 0.005 and P0.005. Then it will not go down the z.

Thanks for the gcode file. It loads, but i have some spline problems i see. Haha. I see a lot of spagetti.
So i have to look what's going on and fix it. When it's fixed i will let you know about the file fillets and how they behave.

I had solved a weird thing in the gcode parser.
To convert a string to a double value, some times this failed on other linux pc. It had to do with value using . or , as decimal seperator
as input for the std::stod function.
It's solved by adding : std::locale::global(std::locale("C"));

Thanks, let me know if you need anything else!
A bit off luck... Haha.

Today i coded some more for the look ahead.
I think based on previous post, where the red line of the graph is the velocity profile based on curvature of segments.
This then can be used to retrieve the vo,vm,ve for the trajectory planner.

Arciera mentioned earlyer, the clothoid fillets are quite small, so let we use a vo,vm,ve for each segment.




 

Hi,

I am now at the point that we have done :

- Calculate the velmax of each segment given the max curvature of that segment.
- Path Vel Optimizer: perform a forward scurve motion over the path, update vo's, ve's if valid.
- Path Vel Optimizer: perform a reverse scurve motion over the path, update vo's, ve's if valid.
- Plot 2d, 3d velocity profile.

2D velocity profile, the green verticals to z zero, indicates a segment transition.
You see i at the begin of the green curve, i added multiple colinear lines, to test the transition.
 

3D velocity profile,
 

My conclusion so far, if user gives no G64 P.. value. Then P=0. Then no fillet segments are created.
This must be avoided as fillets are ideal to get endvelocity's in line-line corners etc.
So solution is to set a very low P value if P=0 is given.
Then we set P=0.0001, this is valid and creates the fillets, and end velocity's without adding a bunch of extra sourve code.

Then i have seen when max_jerk is set at very low value, the scurve can't keep up and finishes with endvelocity > 0. This
is not ok. So when the Optimizer algo is performed, and the final velocity at the end of the path > 0, then
we must increase the jerk value until a valid output, wich is endvel=0. I have no other solution found for this so far.