Trajectory Planner using Ruckig Lib

in the python library it's available from settings:

linuxcnc.org/docs/devel/html/config/pyth...xcnc_stat_attributes

Grotius wrote:

@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.

if you are referring to fusion 360, it is done in the customized post processor here:

 
 

if you mean linuxcnc, it is called path_blending i believe:

https://​​​​​​​https://linuxcnc.org/docs/stable/html/gcode/g-code.html#gcode:g64

@Chris,

Yeah, thanks to your hint i could find it.

~/linuxcnc/src/emc/motion/motion.h line 227.

located in the  emcmot_command_t structure.
     double tolerance;    /* tolerance for path deviation in CONTINUOUS mode */

Its quite hidden.

In the planner there is :

//! Status and config from motion.h
static emcmot_status_t *emcmotStatus;
static emcmot_config_t *emcmotConfig;

But we have to add the command channel to it.

//! Status and config from motion.h
static emcmot_status_t *emcmotStatus;
static emcmot_config_t *emcmotConfig;
static emcmot_command_t *emcmotCommand;

then i could do :
    double g64_tol=emcmotCommand->tolerance;

@Lcvette, also thanks for searching.
 

Related to the clothoid example's i feel stupid.
The lib i used is called G1fitting. As the name say's it's fitting G1 continuity.... And indeed
the results are G1 continuity.

To satisfy the G2 continuity needs, i came to a even bigger library.
Its cloned and builds ok in qt now. I hope i can now figur out wich algo to use.

There is a whole list of possible solutions. Even a clothoid spline G2 is on the menu.

The nicest algo would be a point overlay algo. Like just fitting a curve on top of our excisting gcode points.
Using start angles, end angles to construct curves is annoying. Hopely others can read also this website
document a little and together choose the right path.

ebertolazzi.github.io/Clothoids/api-cpp/root.html

A spline sounds interesting and maybe what we would be looking for to create an easy curved motion based on shorter line segments no?

Grotius post=301523 userid=23278

I tested your file. It's interesting to see the pocket mill path consists of tiny line segments forming a curve.

Any modern roughing trajectory (hsm adaptive, solidcam imachining, etc.) looks like this. The imachinig can also change the feed speed in each small segment. But these operations do not require high precision, since they are used for roughing (maximum deviation >0.1mm is acceptable for higher speeds)
 

Similarly, any 3D processing path is a set of lines 0.1mm long or less, only this time they are performed with higher accuracy - drawing fillets on each of them is not always rational - you need to combine and approximate large sections of the path into one smooth NURBS with a programmed maximum deviation - this is called "global path smoothing" - most modern CNCs use this method. And for rounding two large segments (local smoothing) with jerk control, most use 5 degree b-spline
 
 
 

Grotius post=301533 userid=23278

 The nicest algo would be a point overlay algo. Like just fitting a curve on top of our excisting gcode points.

Yes, most modern CNCs do just that. There is no need to exactly follow piecewise linear interpolation in G-code, because it is obtained by approximating arcs or splines with linear segments in CAM. The main task is to again reproduce curves close to the original ones, within the established tolerance.
fanuc:
 
siemens:
 
 

And many other CNCs are similar.
As simpler options, some CNCs use Moving Average, Savitzky–Golay filter, and others... to obtain a smooth path.
CCMA would be an interesting example:
github CCMA
You can also look for ROS path planners, some of them also use spline interpolation of waypoints. Ros/Ros2 used a lot of variations of schedulers, including Ruckig, it's hard to keep track of them all, but one might be interesting.
github.com/smarnakis/trajectory-smoothing-ros
github.com/gkouros/path-smoothing-ros
github.com/ros-navigation/navigation2/issues/3246

From the example closest to linuxcnc, I would advise you to pay attention to how this is done in OpenCN:
  OpenCN - Geometric Operations Feedopt
SmoothCurvStructs smoothes the path by connecting lines with a 5th degree polynomial, so as not to smooth out many microscopic g1 movements, they are combined by the CompressCurv function in B-spline.

OpenCN has documentation describing the architecture of the components, links to scientific publications, and you can also download their code from gitlab for experiments (there is also a link to VM-disk or docker). They use the same interpreter as linuxcnc, but further scheduler code is compiled in matlab, which imposes some licensing complications.

 

Lcvette wrote:

I wanted to throw this out as this is where my issues arise from with machine shake, it occurs during adaptive cutting tool paths on repositioning moves where a series of short line segments are posted.  I have tried using smoothing settings and tolerance settings in fusion but it continues to spit out these short segments.  i use G64 with the P value tied to fusion 360's "smoothing" setting, and it helps slightly but the shake at these repositioning moves is terrible, the doors on the machine rattle and shake something fierce and im sure its awesome for the motion mechanicals.  I am posting the file and was wondering if perhaps you might be inclined to run it in your test TP and show a comparison of the current stock tp and the new scurve.  i have a video here showing the machine shake its pretty ugly..  it was cutting this part, if you have volume you can hear the shudder and if not watch the frames of the doors for the shake.. /o\

 

you use very high precision for roughing toolpath 
P0.001 inch ≈ 0.025mm. Such precision is not needed in this trajectory.
Also, linuxcnc postprocessor sets the value not always optimally. Its settings always include P=Q. In my version, I made a modification to determine roughing operations, as well as the value of stock to leave to set the value of fillets.

In my practice for roughing I use Q=0.05=tolerance but P≈0.1-0.5 (value in mm. you can use 1/2 to 2/3 x stocktoleave). This trajectory initially does not have sharp corners, and given the size of the allowance, there is no need to be afraid that the sharp corners will be cut off - such a value of P will allow the planner to better smooth out the trajectory, which will greatly increase the speed at the connections. You can also increase P on 3D trajectories without sharp corners - in this case, the accuracy will not suffer in any way, but the smoothness of the work will be much higher.

Lcvette post=301538 userid=21571
A spline sounds interesting and maybe what we would be looking for to create an easy curved motion based on shorter line segments no?

The current planner (naive cam) combines lines that do not go beyond the tolerance into a single one. its performance allows it to process high-precision code - 2-4 thousand frames per second - and this is typical work for 3D curve milling. The previous planner (simpleTP), which only did fillets without merging lines, could never work as well.

Here is one demonstration of how path smoothing works - a zigzag path. the final path of the machine that was obtained after the work of the planner is the average line with a deviation of +-Q. You can see how smooth it is compared to the original G-code.
G64 Px Qx (P-Corner error, Q-Linear error)
 

I recorded a couple of videos with the capabilities of the current planner. I also attached the test trajectory from the video.

youtube.com/shorts/R9c6sxMjiHY?feature=share
youtube.com/shorts/FqobL6rUDgg?feature=share

 
   

hmnijp wrote:

Back when i was testing things i tried using different p and q values but it never removed all of the shake and in many cases very little difference.  is your post processor for fusion 360?  if so i will gladly test it and video the result.  I do like the fact that a post processor has a little more finesse in selecting the PQ values based on stock to leave and the machining operation!

Lcvette wrote:

yes, fusion 360, but actually on the work machine I use UCCNC. it has exactly the same planner algorithm as linuxcnc (but the developer also plans to switch to S-curves with nurbs interpolation -  uccnc CV toolpath smoothing ), differing only in the names of the G64 parameters and their number. I wrote a post processor for this CNC with many fixes quite a long time ago.
 

Modern postprocessors have added the initializeSmoothing function, which uses many parameters and the properties-scopes block. Give me a little time to understand it and remember the nuances, and I will try to transfer everything to the linuxcnc post-processor, in its original form it requires some corrections.