Ruckig generates trajectories on-the-fly, allowing robots and machines to react instantaneously to sensor input. Ruckig calculates a trajectory to a target waypoint (with position, velocity, and acceleration) starting from any initial state limited by velocity, acceleration, and jerk constraints. Besides the target state, Ruckig allows to define intermediate positions for waypoint following. For state-to-state motions, Ruckig guarantees a time-optimal solution. With intermediate waypoints, Ruckig calculates the path and its time parametrization jointly, resulting in significantly faster trajectories compared to traditional methods.

More information can be found at ruckig.com and in the corresponding paper Jerk-limited Real-time Trajectory Generation with Arbitrary Target States, accepted for the Robotics: Science and Systems (RSS), 2021 conference.

Installation

Ruckig has no dependencies (except for testing). To build Ruckig using CMake, just run

mkdir -p build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make

To install Ruckig in a system-wide directory, you can either use (sudo) make install or install it as debian package using cpack by running

cpack
sudo dpkg -i ruckig*.deb

An example of using Ruckig in your CMake project is given by examples/CMakeLists.txt. However, you can also include Ruckig as a directory within your project and call add_subdirectory(ruckig) in your parent CMakeLists.txt.

Ruckig is also available as a Python module, in particular for development or debugging purposes. The Ruckig Community Version can be installed from PyPI via

pip install ruckig

When using CMake, the Python module can be built using the BUILD_PYTHON_MODULE flag. If you’re only interested in the Python module (and not in the C++ library), you can build and install Ruckig via pip install ..

Tutorial

Furthermore, we will explain the basics to get started with online generated trajectories within your application. There is also a collection of examples that guide you through the most important features of Ruckig. A time-optimal trajectory for a single degree of freedom is shown in the figure below. We also added plots of the resulting trajectories for all examples. Let’s get started!

Waypoint-based Trajectory Generation

Ruckig provides three main interface classes: the Ruckig, the InputParameter, and the OutputParameter class.

First, you’ll need to create a Ruckig instance with the number of DoFs as a template parameter, and the control cycle (e.g. in seconds) in the constructor.

Ruckig<6> ruckig {0.001}; // Number DoFs; control cycle in [s]

The input type has 3 blocks of data: the current state, the target state and the corresponding kinematic limits.

InputParameter<6> input; // Number DoFs
input.current_position = {0.2, ...};
input.current_velocity = {0.1, ...};
input.current_acceleration = {0.1, ...};
input.target_position = {0.5, ...};
input.target_velocity = {-0.1, ...};
input.target_acceleration = {0.2, ...};
input.max_velocity = {0.4, ...};
input.max_acceleration = {1.0, ...};
input.max_jerk = {4.0, ...};

OutputParameter<6> output; // Number DoFs

If you only want to have a acceleration-constrained trajectory, you can also omit the max_jerk as well as the current and target_acceleration value. Given all input and output resources, we can iterate over the trajectory at each discrete time step. For most applications, this loop must run within a real-time thread and controls the actual hardware.

while (ruckig.update(input, output) == Result::Working) {
  // Make use of the new state here!
  // e.g. robot->setJointPositions(output.new_position);

  output.pass_to_input(input); // Don't forget this!
}

Within the control loop, you need to update the current state of the input parameter according to the calculated trajectory. Therefore, the pass_to_input method copies the new kinematic state of the output to the current kinematic state of the input parameter. If (in the next step) the current state is not the expected, pre-calculated trajectory, Ruckig will calculate a new trajectory based on the novel input. When the trajectory has reached the target state, the update function will return Result::Finished.

File truncated at 100 lines see the full file

Changelog for package ruckig

Forthcoming

• [ci] don't check python for c++11
• [ci] move gcc-5 to ubuntu 20.04
• bump version
• add example for per section minimum duration
• Budan's theorem
• use valid profile iterator in step1
• add jerk-minimizing profiles in step2
• fix c++11 patch
• fix c++11 patch
• fix patch c++11
• c++11 fix inplace patching
• improve support for c++11
• update pybind11 in ci
• fix optional in tests with c++11 patch
• update ci checkout version
• fix msvc warning in online calculator
• fix msvc compiler warnings
• expose calculators
• bump version
• performance improvement in step2 vel
• Contributors: pantor

0.8.4 (2022-09-13)

• robustify step2 vel uddu
• fix readme tracking example
• add tracking interface to readme
• fix brake duration reset
• fix brake when current acceleration is on limit
• improve tracking example
• fix pyproject.toml
• clean tracking example
• clean examples
• add pyproject file
• add DOFs to traj serialization
• nlohmann/json based serialization for trajectory
• point out Eigen 3.4 or later
• add custom vector types to readme
• disable vector types example with online client
• include deque
• add examples for custom vector types
• dont support custom data types with online client
• add tests and fixes for custom vector type
• use template specalization without using
• custom vector type as template template parameter
• clean error_at_max_duration, add StandardVector
• clean licenses
• update header dependencies
• clean comparison benchmarks
• extend phase synchronization to velocity control
• move src to src/ruckig
• clean gitignore
• remove -Werror
• Contributors: pantor

0.7.1 (2022-07-10)

• bump to 0.7.1

• fix python 3.10 deployment

• Merge branch 'master' of github.com:pantor/ruckig

• bump to 0.7.0

• allow user to force new computation for the same input (#132)

  * allow user to force computation again Otherwise sending the same target with non-zero min_duration multiple times in a control loop will not trigger a new trajectory.

  * rename to reset Co-authored-by: pantor <<lars.berscheid@online.de>>

• profile precision as constant

• clean notebooks

• fix c++11 std::clamp

• use steady_clock, minor code cleaning of roots.hpp

• fix numeric for time sync with discrete durations

• fix independent min duration with brake trajectory

• clean header includes

• improve stability of velocity control

• msvc warnings

• fix msvc warnings

• static cast for std::div

File truncated at 100 lines see the full file