Trajectory Planner using Ruckig Lib

Hi Tommy,

Yes, it's tpmod_T800 & motmod_T800 now.
Next time.

@Grotius - I have been working through the code and the advice given in this post .  I have been adding in more printf statements and logging it all out to log file against a simple test file (still 24k lines).   I THINK I get what is going on.  Can I just test a couple of key aspects using my words.  You can confirm or correct (hopefully minor) where I am not quite right.


My understanding:

1. on program Run state the overall controlling module EMCMOT initiates the the tpRunCycle cycle and starts the gcode interpretor
2. the segments get loaded by the gcode interpreter "started" in #1 into the tp_vector *vector_ptr - which is the global buffer used by the module
3. as the vector gets loaded up tpRunCycle can start to consume off it and process for the ruckig lib, look ahead processing and providing feedback to the UI on what gcode line is being processed
4. tpRunCycle  continues until vector fully processed

Some basics:

• everthing gets broken down into "segments".  A segment can be a line or a curve.  And we know the key data about each of these start, end, radius, length etc
• ruckig does not worry about 3d space, only how long the distance is between a start and end point. We get a 0 to 1 value of proggress throught that segment. Essentially a percenatge complete.  Therefore the xyz postion in space of the intermediate point through that segment can be derived from the known geomtry of the segment and the percentage through that path expressed as a decimal from 0 to 1. (e.g. 0.012543)  i.e. how far along the line we are or how car through the arc we are
• ruckig is also providing acceleration and velocity information which is used to proivide the smoothing we desire.  However if we need to control or influence those parameters further we need to do something more.  I presume this is where using the precalculated trajectory plans come in to play?

Hopefully I have built a better understanding of what is happening.

Thanks - J.

Grotius wrote:

Added also pause & motion reverse to the cyberdyne component.
Ok now we can make the trajectory planner using velocity end moves. This can be very interesting. 

 

Have been reading through the cyberdyne.c file and all making sense.  From the looks of it to gain access to the velocity end moves we just need to move away from the ruckig standard run model and use the_function() to ge the processing every 0.001s  (1ms).  A little more work but the added control would seem to be worth it.   We really do not want to have things go to velocity 0 on a corner when the machines in question can handle some level of g-force on those hard corners.

It does rasie a question or two, but maybe you have a cunning plan already.
- Do we have set the target velocity based on how large a shift the direction is beyond a certain point?
- How is that target velocity modified in relation to the requested feedrate? a percentage?
- How do we represent the above relationship? Is it a simple constant that can be dynamically extrapolated as we build the way points(presumably via lookahead) or do we need to allow for some range of direction-shift/velocity that is held for the machine in the ini file?
- OR something totally different as you already have it worked out? 

Great work by the way.  Cheers - J.

Hi Joco,

on program Run state the overall controlling module EMCTASK (?) initiates the the tpRunCycle cycle and starts the gcode interpretor

If you have qt opened, you can search for "tpRunCycle" in all projects.
Then you can see that control.c is doing this function. This file is part of the trajectory planner.so library.

 

the segments get loaded by the gcode interpreter "started" in #1 into the tp_vector *vector_ptr - which is the global buffer used by the module

this is just a pointer, not initialized yet : struct tp_vector *vector_ptr;

The actual segment is of type :
struct tp_segment line_or_arc;

Adding the segment is done in c++, in the file tp_vector.cpp, by :  ptr->pvec.push_back(b);

Indeed the gcode interpreter gives us the data, interpreter calls tp_addline or tp_addcircle functions. We have no
influence on that process. It throws all the gcode lines at once. Sometimes 10 lines, sometimes 100 lines, etc.

as the vector gets loaded up tpRunCycle can start to consume off it and process for the ruckig lib, look ahead processing and providing feedback to the UI on what gcode line is being processed
Yes, but the exact workflow of the trajectory planner is quite difficult to understand. It runs the tpRunCycle but also positions
are asked and given back. A lot is going on.
therefore there is a tpmod_template project,
to get a better understanding of that workflow.

tpRunCycle  continues until vector fully processed
Yes, it stops when you press stop at the gui button. You can delay the stop if you want to.

We really do not want to have things go to velocity 0 on a corner when the machines in question can handle some level of g-force on those hard corners.
Yes indeed.

Do we have set the target velocity based on how large a shift the direction is beyond a certain point?
This is basicly a path rule. You can create a lot off path rules for this velocity end, based on corners, gforce, etc.

How is that target velocity modified in relation to the requested feedrate? a percentage?
This is not fixed yet. Could be hal input, could be a percentage indeed. For now i just test it with a hal input value.

How do we represent the above relationship? Is it a simple constant that can be dynamically extrapolated as we build the way points(presumably via lookahead) or do we need to allow for some range of direction-shift/velocity that is held for the machine in the ini file?
Yes every machine is different. So it takes different values. I think just finding out the perfect values.

 

Skynet presents : tpmod_T800
Scurve, using velocity ends, look ahead.



This is fun.

Thanks Grotius will continue tracing things through and building out how things work. I was being pretty high level in my description so there will be specifis like ptrs not initalised etc. But hopefully trapping correctly where data is being stored.

Re the ve and vo stuff. I was starting to think about what sort of info we would want a machine config to hold. That could be fed in via hal pins or ini values. That is really points of detail that are easy to solve. I think the more interesting question is what data we need to be able to inform the algorithm how much g-force a machine can handle and so what level of vo/ve should be getting used.

addition:  Awesome to see the velocity path on that new video.  The new vo/ve is working really well.

Cheers - J.

Grotius wrote:

Skynet presents : tpmod_T800
Scurve, using velocity ends, look ahead.
This is fun.

 

Don't forget to book it in else I can't run up a test on real h/w. 
Unless there is some more to do before that h/w test is viable.

Yes push it please Grotius. We all want to see it on real hardware.  
MAybe you will have to place an embargo on JoCo until you get it on your table