Path planner example c++

[grotius-cnc]

Hi,

Attached a path planner example.

• Waypoints with velocity end.
• Master machine velocity control.
• Feed override 0 to 100%.
• Controlled machine stop.

libruckig.tar.gz

https://user-images.githubusercontent.com/44880102/146646643-6e19af94-0258-42db-a5a3-bbf363dca7da.mp4

Improvements for ruckig:

• In a realtime 1ms kernel powered thread bringing back the current velocity to 0.001 will crash at longer paths.
• End velocity accuracy not optimal when crossing waypoints.
• When end velocity can not be reached, ruckig end velocity value is 0 instead of value at end of path.

[pantor]

Hi @grotius-cnc,

it would be great if could you elaborate on your suggested improvements.

• It seems to me that point 2 (end velocity accuracy) is outside of the scope of the community version, as you need to specify the target velocity yourself.
• Point 3 seems like a very significant bug that never occurred to me (or others that I've heard of), so it would be great to have some more details and an example for this. Ruckig checks for the correct end velocity after calculating the trajectories, so I'm pretty sure that there is some misunderstanding here.
• Point 1 seems also like a bug of Ruckig, however make sure to stay within the numeric limits that are stated in the Readme. How long are "longer paths" exactly? What is so important about the velocity of 0.001?

[grotius-cnc]

Hi Pantor,

Point 1. In a machine application, user can command a controlled machine stop. When i simulate this, i let ruckig go down to a velocity almost zero. So far i know it will not except a zero value for maxvel. Then when this near zero velocity is reached, i stop ruckig. The crash seems to happen at longer paths, let's say 1000mm or longer.

Point 2. The target velocity's are important. When gcode lines have end velocity with a waypoint, it had troubles crossing the waypoints with endvelocity. It was like bouncing forward and backwards to find the waypoint.

Point 3. All ruckig problem's started when i made a implementation using waypoints with end velocity. When using ruckig starting with vel:0 and ending with vel:0. i never had any problem. It has perfeclty been running four hours on a realtime kernel program.

All my code is inside the halcore project archive. If i see some code coming time, usefull to you i will post it here. In general i have had a look to your source code, but i did'nt investegate it further. Maybe in the future. ruckig_interface.txt

it would be great if could you elaborate on your suggested improvements.

I have something more precious to share with you. Something that beat's the ruckig output values.

It's a new scurve algoritme i have written the past 2-3 weeks.

It has a lineair_transition stage between the concave & convex period. An sich this is normal, but.. It uses a gain value 1-100% as scurve power indicator. It behaves like a octopussy. It can transform like magic.

It saves machine cycle time during acc and dcc periods.

https://github.com/grotius-cnc/scurve-pro

A video showing the performance.

    gain: 100%   traject time sec: 4        //! This is the full scurve algo without lineair transition stage.
    gain: 50 %   traject time sec: 3.5      //! 12.5 % faster
    gain: 1  %   traject time sec: 3        //! 25   % faster.    

    Normal scurve, like ruckig's scientific paper:  [concave period]+[convex period]
    Improved scurve:  [concave period]+[lineair transition period]+[convex period]
    Improved scurve with power control : [concave period*gain]+[lineair transition period]+[convex period*gain]

https://user-images.githubusercontent.com/44880102/148067684-3e63a697-efc1-45e7-94e2-d2f4879d0f6e.mp4

As where ruckig can reach max acceleration status only once at crossing the inflection point. For users, the inflection point is the point between concave and convex period, where for a scurve algo the acceleration is 2*max acc, only at that point or timestamp.

A scurve algo with lineair transition period between the concave & convex period is 2*max acc during this whole lineair transition period. This results in reduced trajectory time, as the video is showing. Overall the max acc value is respected with this algo.

[pantor]

Thanks @grotius-cnc. Feel free to reopen with concrete, reproducible examples for your stated issues.