Trajectory Planner using Ruckig Lib

Grotius wrote:

So i could do this for 9 axis. Who thinks this is a thing you should have or not have?

Yes please

@RDA,

Okey. Served to you a 9 axis jog while paused planner.

Now i thought, maybe first resume the xy to the path and as last the z and other axis abcuvw.

The result is stunning, I feel like a type goat to do it for 9 axis.

This is awesome, keep up the good work.

I've been thinking about this kind of stuff lately and have been messing around with path blending ideas, and general trajectory planning and look ahead ideas.

For blending, a cubic curve seems like it would work well. They can be set up to have zero curvature at the ends for joining to lines, or the curvature to match an arc so there's no step in acceleration at a transition. The only problem was I haven't been able to figure out a closed-form expression for the jerk at a given point of the curve at a given velocity. Do you currently have a plan for how you will do blending?

For S-curve planning I found this:  assets-eu.researchsquare.com/files/rs-1637727/v1_covered.pdf . I'm not sure if you might find this useful. I put together a Google colab notebook here to try it out:  colab.research.google.com/drive/1AkdxP2-...0jYZjW-a?usp=sharing . For P2P or exact stop mode it seems very simple and useful. I haven't figured out if there is an easy way to control the starting and ending velocity while maintaining the same area under the curves. If that is possible it could be very useful.

Does the jog while pause use multiple command lists ?
That is what Michael Haberler did many years ago.
It never got included in linuxcnc.
I'd love to see your work in linuxcnc.

@Andrew,

Do you currently have a plan for how you will do blending?
Yeah, after the look ahead is done, i will try to do it with cavaliercontours. If you offset a open contour to 2 sides, then back
to original the path, you get arc blended corners. Then from this, you can filter out the final blended path.
You could offset the x ammount of look ahead lines.

I have seen the docs, it have to dive deeper into that pdf later on in a quite moment. It looks interesting.
My first impression is, it's like a signal filter.

@Mr. Morley,
Does the jog while pause use multiple command lists ?
It only uses a hal pin to emulate a button press. One pin for x+, one pin for x- and so on for each axis.
It's able to move multiple joints together. That's nice.

take a look.

That is what Michael Haberler did many years ago.
It never got included in linuxcnc.
I'd love to see your work in linuxcnc.

This jog while pausing is coded in less then 3 hours for scurve.
So i think in a few hours you can code it into the original tpmod written by
Rob Ellenberg. You only then have to use the trapezium velocity profile, like the simple_tp jogging.

I used one function in the program loop to check when we are in pause, and velocity is zero.
Then i save the tp position.
Then user may jog the joints. When pause resume is pressed, it is locked until all axis are back at saved position.

Hi,

The look ahead seems to work. It's based on this skeleton code.
It was fucking frustrating designing this code. It seems so simple, but it was not.
It took me day's. In the end i first designed a working skeleton code. Then i was sure faults where
not related to this look ahead skeleton code. From there i calculated the velocity end's for the optimizer
by a trapezium velocity profile. As this is the fastest algo.

Then in the component the skeleton code is integrated as a look_ahead_optimizer .
Then with hal pins you can enable the look ahead and define the nr off look ahead lines.
If no values are given, it sets standard 20 look ahead lines, and standard the look ahead is active.

Then for arc's it uses a integrated velocity optimizer, these settings have to be ported to hal pins too in a later moment.
The perfect arc velocity is now set to radius 5 mm with velocity 1400 mm/min. All other arc velocity's are derived from
this setting.

The component now does not use the grbl's corner algo.

There is a tiny bug when the planner uses end velocity from current segment to next segment. The joint[n]
graph's in the scope show's little transition spikes, however the scurve graph output is ok.
I could not find the problem in a short time, so to solve this,
enable this line. The backend runners will filter the transition spikes out.

The video of today.

- Jogging scurve.
- Run sample program.
- Pause, resume.
- Jog while pause.
- Motion reverse.
- Look ahead 20 lines.

Next week i will test it on the production machine.



lcnc scurve source code

Reverse motion might open up the door to replicating the "Traking" feature on Prototrak CNC lathes. It lets you use one of the MPG wheels to move forward or reverse through the program motions.

I don't think the FIR s-curve generation will really work for this after messing with it for a while. I have found some papers on s-curve generation with other analytical methods instead of resorting to an iterative solver. It gives a time-optimal solution given the constraints: max velocity, max acceleration, max jerk, path length, starting velocity, and ending velocity. I think this might be much faster than anything else. So far it's looking very promising and its mostly working. There were some errors in the paper that I'm working through.

I think for path blending arcs have to be avoided because there is a curvature discontinuity where they meet a line or different radius arc. It's not possible to limit jerk at the transition unless you come to zero velocity at the transition point. I think the best way to blend a path is using clothoid curves because their radius changes linearly with the curve length which allows curvature continuity which results in smoothly changing acceleration in a transition. There are also algebraic solutions to calculating radial acceleration and jerk at a given velocity and point on the curve. The solutions to fitting the curve to the path geometry are closed-form. I've done a little work on this that I can share soon.