Trajectory Planner using Ruckig Lib

@Joco,

1. “We don’t ask for xyz powition” - which flows on to the dof comment.  Given we are working in 3d space how does that work? It looked like ruckig was sorting all that out based on an a 3d space target and on each time slice it returned a new progression in 3d to that target and a return status of Done or Working.

It's in fact made as simple as possible.

Given a trajectory of just one line segment:
startpos xyz : 0,0,0
endpos xyz : 100,0,0

total calculated lenght xyz : 100

The trajectory planner then starts the ruckig with the following inputs:
curpos=0
tarpos=100
After the planner  is started, it gives for every 0.001 seconds a new position, vel, acc until tarpos is reached, this
is ruckig::finished flag = 1.

Line interpolation 0-1 in 3d space:
if the curpos=50, this is 50/100=0.5 progress of traject lenght.

2. “… the outcome of 0-1% path  progress” - is this reflecting the time slice element? I can recall a constant of 0.001 being aet that was (i thought) something to do with that.
I made the sum off all segments paths a progress between 0 and 1.
So the 3d coordinates of the tp are somewhere between the interpolation of 0 and 1 progress.
This makes the conversion from current tp to 3d coordinates very easy.

On the topic of the pauses - given the difference in morion behaviour between a “square” with a small chamfer or arc replacing the 90deg corner v’s a  pure square with true 90deg corner, there are some choices.
a. The user needs to design geometry to achieve desired behaviour from the planner.
b. The CAM path software drives paths that avoid hard corners. e.g loop or triangle over cutting  on external corners
c. Path following tolerance between geometry elements allows for some blending and thus on the fly addition of new target points within tolerances that soften harsh transitions which would otherwise introduce these pauses.

a. The behaviour of the planner lies in it's applied path rules. There are now a few applied path rules, like,

• stop at g0, looking 10 lines ahead.
• colinear segments within 10 degrees, full trottle ahead, looking that path rule ahead for 10 lines.

b. I think not relevant. Hard corners are normal.
c. This should be implemented as blending. Create blending is not that difficult. It's not handy to do now.
Usage of a ve (velocity end) on 90 degrees corners, could be implemented as a acceptable inertia tollerance
on the machine body and moving parts with max_gforce as input value.

It would be interesting to know what the expectation is on commercial machines with these types of scurve planners already in place. 
Yes, more info is alway's welcome.

@TheRoslyak,
It's quite difficult to get a nice algo going for all circumstances.
You can look at sigmoid or scurve algo's.
If your algo is running, you could show a print of the produced curve, wich is always interesting.

@All,
Currently almost finished the hal integration of the latest ruckig-dev code.
Made a c interface for it.

Soon going to test some waypoints using vo and ve values > 0.
This all is tested in a new hal component called : Cyberdyne

Git is updated.

Hi Grotius, Best regards
Tomorrow I'll upload the entire project and its images. Generally, I'm not very satisfied with the final result. It works, of course, but with some set of parameters, it doesn't work quite as I would like. Perhaps this library already has solutions and other aspects that I'm unaware of. For now, briefly, I'm interested in how this library saves time. Does it find the ideal trajectory in the shortest possible time by some esoteric aspects?

@TheRoslyak,

I'm interested in how this library saves time.
It does not save time. Trapezium has the same trajectory time, normally.

Does it find the ideal trajectory in the shortest possible time by some esoteric aspects?
Yes, it does. It's doing a good job.

@Grotius,

I think you are gonna have to spell things out a bit more for me.  Or point me towards some reading that will achieve the same thing.

"Given a trajectory of just one line segment:
startpos xyz : 0,0,0
endpos xyz : 100,0,0

total calculated lenght xyz : 100

The trajectory planner then starts the ruckig with the following inputs:
curpos=0
tarpos=100"
What I do not understand is how it works when you have a start point of 10,33,55 and an end point of 100,15,25 how is that getting simplified into a single axis?
Or have you dropped things in your example and the inputs are really
curpos=0,0,0
tarpos=100,0,0


"After the planner  is started, it gives for every 0.001 seconds a new position, vel, acc until tarpos is reached, this
is ruckig::finished flag = 1."
I understand the finished/working flag and the call frequency.  the 0.001 seconds make sense.

"I made the sum off all segments paths a progress between 0 and 1.
So the 3d coordinates of the tp are somewhere between the interpolation of 0 and 1 progress.
This makes the conversion from current tp to 3d coordinates very easy."
So are you just dividing the current rolling total of a number of segments by the sum of them all.  i.e effectively a percentage completed?
I presume segment paths are all vectors of x,y,z in this instance?

Thanks - J.
 

What I do not understand is how it works when you have a start point of 10,33,55 and an end point of 100,15,25 how is that getting simplified into a single axis?

Ok, hold on :

1. A function that the interpreter calls, to fill our gcode buffer (std::vector).
Here we get the 3d startpoint & 3d endpoint, and some other data, like speed.
Also we calculate the 3d path lenght between start- & endpoint to store in our buffer. (std::vector).
In fact we know enough now, to go further on. After the function call's of the interpreter stop's, our program
may begin it's path.
interpreter calls this function to give us the gcode

2. The function call to calculate line lenght. to store in our std::vector.
pathlenght for the 3d line

3. In c++ we call this adding the line to our vector, push_back on the queueu.
I don't use any c style vectors in the code, i use c++ to store data. The c++ std::vector is quite easye to handle.
add the line to the vector, cq gcode queue

4. Ruckig looks in the std::vector buffer and just start's with the first element. When the first element scurve is
done, second element is processed.
ruckig update function

5. The gui needs to know what position we are. The gui is using this function to determine the 3d position.
It's given the traject lenght and it's given where we are on the traject between 0-1.
Then the function can calculate wich segment & segment progress along. This exact point is then interpolated 3d
with  this function.
gui update function that gives the tp loctation in 3d


I presume segment paths are all vectors of x,y,z in this instance?
Point 1. For every item, line or arc, i call them segments in this case. The segments is a paper that holds multiple
data, like startpoint, endpoint, radius, speeds, abc, uvw data, etc.
So you can ask the segment, for one of these values.

So the ruckig doesn't know anything about 3d coordinates. It's only aware of colineair points where it has to go to.
These colineair points, are the endpoints of pathlenghts, stacked after each other.

we know:
line a {0,0,0},{100,0,0}
line b {100,0,0},{-100,0,0}
line c {-100,0,0},{1000,0,0}

ruckig knows:
0

---

100

---

300

---

1400

Ruckig gives the 0-1% progress for the item nr a,b or c.
Interpolate that 3d and done.



 

Hi All.

Until now the trajectory planner didn't use velocity ends.

This is because of a ruckig online trajectory calculation problem.
Using ruckig inside the so called control loop, it refuses to finish at a given velocity end value.
It misses the point completely and goes in bouncing mode.
So that's why we coded no velocity end's other than zero 0.
The issue could be on purpose to avoid people to use waypoint's. I don't know. I planned to hack ruckig within
a few hours to solve the problem.

To get it running, i did some research yesterday and today, i managed to get it going using velocity ends.

All build in a seperate linuxcnc hal module, so everyone can play with it.

It uses the latest ruckig-dev source code. That's now added to the repository inside the ~/vendor dir.

The procedure is now little different then we used to do.
The trajectory is calculated in a offline manner, and used in a online manner, this works.
So if a interupt is done, like a velocity max change, we trigger this event, and new trajectory is calculated on the fly.

cyberdyne.c component
The component can be used in auto mode, then it run's a few waypoints, but also manual mode, with hal inputs are possible.

Test video using waypoints and velocity ends :