Background Information

Numerical Stability

The current test suite validates over 5.000.000.000 random trajectories as well as many additional edge cases. The numerical exactness is tested for the final position and final velocity to be within 1e-8, for the final acceleration to be within 1e-10, and for the velocity, acceleration and jerk limit to be within of a numerical error of 1e-12. These are absolute values - we suggest to scale your input so that these correspond to your required precision of the system. For example, for most real-world systems we suggest to use input values in [m] (instead of e.g. [mm]), as 1e-8m is sufficient precise for practical trajectory generation. Furthermore, all kinematic limits should be below 1e9. The maximal supported trajectory duration is 7e3. Note that Ruckig will also output values outside of this range, there is however no guarantee for correctness.

The Ruckig Pro version has additional tools to increase the numerical range and improve reliability. For example, theposition_scale and time_scale parameter of the Calculator class change the internal representation of the input parameters.

Ruckig<1> ruckig;  // Works also for Trackig<1>;
 
ruckig.calculator.position_scale = 1e2;  // Scales all positions in the input parameters
ruckig.calculator.time_scale = 1e3;  // Scale all times in the input parameters

This way, you can easily achieve the requirements above even for very high jerk limits or very long trajectories. Note that the scale parameters don't effect the resulting trajectory - they are for internal calculation only.

Intermediate Waypoints

In comparison to the Community Version, Ruckig Pro allows to generate more complex trajectories defined by intermediate waypoints. Therefore, Ruckig takes a list of positions as input and calculates a trajectory reaching them successively before moving to the target state. As this is a much harder problem than solving state-to-state motions (as the Community Version does), Ruckig Pro is not able to guarantee for a time-optimal trajectory. In fact, trajectory planning with intermediate waypoints is a non-convex problem and therefore NP-hard. However, Ruckig calculates much faster trajectories than other approaches for a wide range of trajectory types, primarily due to the joint calculation of the path and its time parametrization. On top, Ruckig is real-time capable and considers jerk-constraints.

In this regard, following information help to obtain robust and ideal optimization results:

1. Ruckig guarantees to output trajectories faster than a trajectory stopping at each intermediate waypoint (with zero velocity and acceleration).
2. Ruckig prefers as few waypoints as possible, both improving the (relative) trajectory duration as well as the computational performance. Note that the complexity of the calculation increases with the number of waypoints, in contrast to many other (time-parametrization) approaches that scale with the trajectory duration or path length. While Ruckig is tested with 50+ waypoints, we strongly recommend to limit the number of waypoints to a lower number.
3. Ruckig includes public hyperparameters for tuning the waypoint calculation, in particular Ruckig.calculator.waypoints_calculator.number_global_steps = 96 and Ruckig.calculator.waypoints_calculator.number_local_steps = 16 with their respective default values. For a higher number of waypoints, we recommend to reduce the number of global steps and increase the number of local steps, e.g. to global_steps=16 and local_steps=256. Additionally, there is the Ruckig.calculator.waypoints_calculator.number_smoothing_steps = 0 parameter for smoothing the trajectory. It is turned off by default, and a higher number (e.g. in the range 0 - 64) will improve the smoothing.
4. Ruckig prefers waypoints that are far away from each other (relative to the given velocity limit) and not positioned in a straight line. When using waypoints from a motion planning algorithm (such as RRT), we strongly recommend to pre-process your list by a waypoint filter (such as the integrated Ruckig::filter_intermediate_positions method) first. Fortunately, a straight line of dozens of waypoints is not a typical use-case seeking for near time-optimal trajectories. For a single DoF, Ruckig automatically filters waypoints without loss of generality.

Benchmark

We find that Ruckig is more than twice as fast as Reflexxes Type IV for state-to-state motions and well-suited for control cycles as low as 250 microseconds. The Ruckig Community Version is in general a more powerful and open-source alternative to the Reflexxes Type IV library. In fact, Ruckig is the first Type V trajectory generator for arbitrary target states and even supports directional velocity and acceleration limits, while also being faster on top.

For trajectories with intermediate waypoints, we compare Ruckig to Toppra, a state-of-the-art library for robotic motion planning. Ruckig is able to improve the trajectory duration on average by around 10%, as the path planning and time parametrization are calculated jointly. Moreover, Ruckig is real-time capable and supports jerk-constraints.

Requirements

Ruckig is written in C++17. It is continuously tested on ubuntu-latest, macos-latest, and windows-latest against following versions

• Doctest v2.4 (only for testing)
• nanobind v2.7.0 (only for Python wrapper)

A C++11 and C++03 version of Ruckig is also available - please contact us if you're interested.

C++03 Version

Ruckig Pro is available for C++11 and C++03. While the C++11 version depends (as the standard Ruckig version) only on the C++ standard library, the C++03 requires polyfills of the boost library. We test internally against boost library v1.58, but older (e.g. boost library v1.42) and more recent versions should work too.