tp: integrate Ruckig S-curve trajectory planner for planner_type 1

[grandixximo]

Replace the discriminant-based S-curve solver with Ruckig for per-segment trajectory planning (planner_type 1 only, trapezoidal planner_type 0 unchanged).

• Add ruckig/ library and C wrapper (ruckig_wrapper.h/cc/c)
• Rewrite sp_scurve.c: Ruckig-based findSCurveVSpeed, findSCurveMaxStartSpeed, calcSCurveSpeedWithT, calcDecelerateTimes; keep legacy functions for simple_tp.c
• Rewrite tpCalculateSCurveAccel with per-segment Ruckig planners supporting position and velocity control modes, parameter change detection, and replanning
• Add Ruckig state fields to TC_STRUCT; remove unused initialvel, accel_phase, elapsed_time fields; add factor, targetvel, vt, blend_maxjerk, lastacc
• Add tcCleanupRuckig for per-segment planner lifecycle management
• Update tpComputeOptimalVelocity: use findSCurveMaxStartSpeed for reverse velocity optimization, add prev_max_end_vel jerk-feasibility constraint
• Update blend velocity to use local maxjerk instead of global emcmotStatus->jerk
• Cache findVPeak result in findSCurveVPeak (blendmath.h)
• Remove unused tc_finalvel, tc_maxaccel from emcmot_status_t

[smoe]

This is very nice, thank you! I would now go and prepare a separate Debian package for https://github.com/pantor/ruckig (so other parts of Debian can benefit from "ruckig" (informal for ruckelig, German for "jerky"), too. Would ruckig as an external dependency have any consequence that I fail to anticipate?

[grandixximo]

What we added in the codebase is a fork https://github.com/mika4128/ruckig.git Where we made it C++ 11 compatible. And cleaned up building errors

…

On February 13, 2026 6:47:33 PM GMT+08:00, "Steffen Möller" ***@***.***> wrote: smoe left a comment (LinuxCNC/linuxcnc#3802) This is very nice, thank you! I would now go and prepare a separate Debian package for https://github.com/pantor/ruckig (so other parts of Debian can benefit from "ruckig" (informal for ruckelig, German for "jerky"), too. Would ruckig as an external dependency have any consequence that I fail to anticipate? -- Reply to this email directly or view it on GitHub: #3802 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[smoe]

Hm. What do you think should be shipping with Debian? The original or your(?) fork? Please direct me. When it comes to LinuxCNC, I thought we would already have transitioned to C++ 20 that ruckig is prepared for. @andypugh? @rene-dev?

[rene-dev]

Yes, master is c++20

[grandixximo]

We (me and Mika AKA YangYang) wanted to still support debian 10 for a few more years internally, we can keep the fork up to date.
The C++ 11 choice was for supporting older systems in our codebase, which we still use, but the linuxcnc-master codebase has already moved on to C++ 20, so up to you guys, both can work, our (me and yy) fork can stay for our needs, and master can eventually get dependency from https://github.com/pantor/ruckig package in debian. We are willing to keep the fork up to date for linuxcnc needs.
I think you should look at https://github.com/pantor/ruckig for the official debian package.