Trajectory Planner using Ruckig Lib

@Grotius - just for clarity, were you successful in running with ve On using the file I posted for the test?

I just ran 5 more tests in the sim.  This time on my dev laptop not in a VM. I also made sure I did a "make clean" in the source dir for good measure.  Using the test file I posted I get consistent fails** at the same point in the file.  It runs fine with ve off.   However if I run the file attached then the program completes.  Note that both files are doing the same geometry and came from sheetcam using a different PPs. 

 

Thanks.

** Interestingly while on the plasma table I got a core dump, on the sim it just stops and wont progress anymore.  I can stop the program and restart and it will stop again at the same spot. This might be due to the plasma table having the mesa card in the mix whereas the sim has no connection to physical h/w. 

Hi Joco,

I did run the gcode file using ve=0.

I think we have to go back using the
tpmod_scurve instead of the tpmod_T800.

This also solves a jog issue, using the T800 with ruckig-dev code.

Okay.  I will do some experiments with jerk values re the sharp corner pauses.  However I think the real answer is to honour g64 “looseness” on corners to smooth things out.  I say this as when i run geom that has this already modelled in the path is followed quickly and smoothly. With no pause issue. Even when the arc or chamfer are small/thight.

i think this smoothing is done by the line-line, line-arc and arc-arc routines.

cheers- J.  

Hi Joco,

Thanks for testing !.

If you make a square 100x100 with fillets 0.01 and you test it. (This is like blending G64 P0.01)
Then check if you got a vel_jump on x&y axis with a certain speed.
There must be a velocity jump, but not at very low speeds.
We can track velocity jumps in the future and train our ai model on it.
They are vertical lines in the graph.

In therory the machine should stand still in sharp corners only one servo cycle.
We can trigger if this is true. And the ve is only one servo cycle zero.

It's ok to use endvelocity when segments are colineair (blended).

We gonna do a few more tests for this. Have a nice day !

Tests performed using skynet. High level observation being that pauses still appearing until move to a fillet model with a radius of 0.254mm.  Then the motion around the corners is fast and smooth.


Testing tpmod_skynet for behaviour with chamfers and fillets that represent different G64 settings.
4 Squares in this Order:
Bottom Left = 0.01mm chamfer
Bottom Right = 0.254mm chamfer
Top Left = 0.01mm fillet
Top Right = 0.254 fillet

Sample file being used:
 

Good that the graph shows the pauses as flat spots in the curve so you can observe from a SIM..
Seems very odd that the threshold for radius is 0.254 = exactly 1/10 inch.
Why is a piece of software written in Germany working in inches?
Why does the threshold exist? Is there a setting?
What happens on a square corner when G64 tolerance ia 0.3mm?
What happens if the cut velocity changes? Is is still 0.254 at double the cut velocity?

Just posing some questions for you guys to think about.

re the 0.254mm, that just happened to be the standard plasmac G64 setting. I think to find the tipping point we will need to dial that back to a change in behaviour is seen.

I will try and find time for that today.

What I found interesting was that the fillet triggered the behaviour not the chamfer,   I think some more iterations on both is needed to find where the transition points are.

Edit:   Some quick checks before getting sucked into meetings for the rest of the day.
1.  Chamfer at 0.5mm is still pasuing.
2. Fillet at 0.1mm pauses.   At 0.15mm it does not pause.  The cutoff must be somewhere in that gap.

edit 2:  Some further observations on the impacts of max_jerk a and feed rate.
Max Jerk seems to impact how quickly the velocity ramps up to asked for velocity.  Set max jerk to 1 and se what I mean when compared to say 1000 versus 10,000.  These impacts are more noticeable when the feed rate asked for his quite high.  The test squares with a feed rate of say 700 or 1200 are pretty smooth no matter which one you look stat.  However when you raise the feedrate to 7000 the first square has a noticeable pause on the corners and the length of time of that "pause" is based on how long it takes to decelerate and re accelerate up to speed.  At least that is what it looks like.

Cheers - James.

by definition, max jerk is how quickly *acceleration* ramps up or down. which, in turn, impacts how quickly velocity will ramp up/down.

and if you expect jerk of individual axes to be limited - motion has to come to a complete stop at each segment/line transition. unless segments are coliner (i.e. all motion is following a single straight line in 3d. or a single circle)

chamfers or arc fillets won't help. if they do - it's a bug

As dm17ry pointed out, isn't a pause expected at hard corners in the current implementation?

G64 / blended moves is not yet implemented?

G61 / exact stop requires coming to a complete stop. Doesn't matter how gracefully the accel / decel are done, coming to stop at the corner is still required.

(I could be completely wrong about what is currently implemented in this tp)

Could see what behaviour is of "pauses" using the standard tp with G61 and compare to S-curve to.

i once again want to point out: arc blending used in the current tp is not suitable for jerk-limited motion. it appears to me that not everybody gets that...

imagine a constant velocity movement along a straight line blended to an arc. without any hard corner. but!
while moving straight - velocity is constant on each axis -> acceleration vector is 0, jerk is 0
at the moment of passing the transition point to the arc acceleration instantly changes to velocity squared divided by arc radius (centripetal acceleration). that means infinite jerk.

i'm wondering if arcs can be replaced with some other curves with controllable curvature at the ends. bezier won't do...

edit: found an introductory video about continuity 
there're also tons of research on blending, e.g. www.jamstjournal.com/article/exportPdf?i...9279c255&language=en