Trajectory Planner using Ruckig Lib

I'm sorry if you feel insulted, it wasn't intended as such, just your patronizing "hints" about IDE usage demanded a reply. I removed my comments, no need to bother moderation.

Hi Rmu,

About your previous question, i repaired the history of the linuxcnc repository clone a little bit.
This history has been overwrited last week by a push -force.

For info, the scurve jogging is done here:
~/linuxcnc/src/emc/motion/simple_tp.c

Compiled with ~/linuxcnc/cmake/components/motmod/CMakeLists.txt

This is a really interesting development.
I am eagerly waiting for the next phase on how to tackle multiaxis jerk limitation.
As RMU has suggested before, the jerk constraint can be sub divided in the tangential and normal planes.
One way to constrain tangential jerk is to parametrize the path as a single axis (maybe using the distance travelled along the path as the governing variable, and plan a single axis jerk limited path. The waypoints will be the distance travelled by each segment in that path. Then use direction cosines to find the individual axis positions. The max velocity, accel and jerk constraint for each segment of can be computed by taking the direction cosines into account.
The issue would then be to ensure that circles are broken into small line segments and this could be done for each.
A transition fillet would also needed to be added between 2 subsequent gcode segments.

I am looking forward to see if there is an easy method to take care of normal jerk too.

Let me know if there is anything I can do to help in this endevour.

Regards,
-automata

Hi Automata,

One way to constrain tangential jerk is to parametrize the path as a single axis (maybe using the distance travelled along the path as the governing variable, and plan a single axis jerk limited path. The waypoints will be the distance travelled by each segment in that path. Then use direction cosines to find the individual axis positions. The max velocity, accel and jerk constraint for each segment of can be computed by taking the direction cosines into account.

Yes, we calculate the path progress using a single ruckig-dof. (axis).
The xyz Interpolation is done by math.

The issue would then be to ensure that circles are broken into small line segments and this could be done for each.

During the servo cycle update, there is no need for small line segments.
Only a new target point is needed each servo cycle.

A transition fillet would also needed to be added between 2 subsequent gcode segments.

This is the hard part. A great library for this should be the use of cavaliercontours. This is a fast lib for solving
extreme difficult paths. Let's say a look ahead of 10 gcode segments could be fillet this way.

I would preferr to start coding something simple.




 

The issue would then be to ensure that circles are broken into small line segments and this could be done for each.

During the servo cycle update, there is no need for small line segments.
Only a new target point is needed each servo cycle.

On the circle how would we apply the max vel, max acc and max jerk limit for each individual joint/ axes making up the curve. So breaking up a circle into smaller lines will allow the use of the same direction cosines approach as used in the line.

 A transition fillet would also needed to be added between 2 subsequent gcode segments.

 

This is the hard part. A great library for this should be the use of cavaliercontours. This is a fast lib for solving extreme difficult paths. Let's say a look ahead of 10 gcode segments could be fillet this way.

A parabolic fillet may be a good option? If we can find a library that can generate parabolic fillets and we can take them into the ruckig planner? 

-automata

A small update from my side:

I was able to get the simple_tp functionality working in teleop/world mode in LinuxCNC, although I am chasing down an Ferror flag getting set somewhere when translating between the joint space and world space.

The actual machine I have (XYYZ) properly completes his homing cycle while using max_jerk, and I imagine it's a small error or a failure to add one item in my code resulting in the following error. I will be tracking this down next.

Does anyone have a suggestion for which simulation .INI files I could use for further testing - one for a trivkins 4 or 5 joint 3 axis machine, and one for a machine that includes a rotary axis? There are many of these configurations included in LCNC, but I figure someone here may have a configuration they prefer to the built-in ones.

So we are consolidating the repository now that we've gotten a bit more progress, to make it a little bit easier for everyone to follow as we continue forwards, since we have nearly finished our first goal of simple_tp implementation. Of course, there is much documentation that needs to be done as well to make it easier for others to understand and contribute, so once I've finished ironing out a couple of additional bugs, that will be my primary effort.

The main repository will now be github.com/grotius-cnc/linuxcnc


@tommylight, you will see the relevant posts are labeled <removed> by myself and rmu, so I believe this demonstrates agreement

So this thread is now jerk limited?

Um...

Anyhow, nice to see this going and with what I feel is a more sensible approach of "bit by bit" and not what had often been an "if its not on all moves all the time it wont work". I'd be happy with just G1 and G0 exact stop moves for a start. They are the ones that rattle my poor machines to death. CV moves already have a quasi built in jerk limitation so they are less critical.

@Automata,

On the circle how would we apply the max vel, max acc and max jerk limit for each individual joint/ axes making up the curve. So breaking up a circle into smaller lines will allow the use of the same direction cosines approach as used in the line.

This is right. There are more then one way's to design a planner.
If you want you may provide a tiny code example or written example how it should work.

A parabolic fillet may be a good option? If we can find a library that can generate parabolic fillets and we can take them into the ruckig planner? 

The ruckig planner can plan a motion from a to b. It can plan a motion interrupt like "pause, stop, resume".
To check and test if ruckig, or your involved code is working correctly, there is a tiny test project wich prints the scurve in opengl :
github.com/grotius-cnc/linuxcnc/tree/mas...ojects/qt_ruckig_gui
picture_ruckig_test_app

We can problalby find a library to make fillets. I looks like cavaliercontours is for applying offsets only.
 

@Project update for coming day's :

Coming day's i am going to work on a "simple_scurve" trajectory planner that will perform
a scurve motion profile for every gcode segment (line or arc). It will also stop every gcode segment.

So very simple, no look ahead, no fillets, etc.

This above program is then tested for stability, errors when doing :

• start
• stop
• pause
• restart at line
• 10.000+ gcode lines.

This program then is a startup to the more heavy stuff, like look ahead, doing fillets, etc.

I can not talk for theRealBeaf, but i think
Beef is going on with coding the jogging, homing, testing on the real machine, shoot a motion movie for xyz, etc.

There is a possibility to contact me by wattsapp : github.com/grotius-cnc/contact