RKCL main concepts

RKCL aims at processing an online control loop to manage the actuation of a robot’s joints in order to fulfil a given task. The control strategy is said kinematic as the resulting output sent to the robot is either a position or a velocity command, but torque control is not supported (yet). It is however possible to integrate force/torque feedback data to adapt the command.

Software architecture

Below is depicted the architecture of the library:

RKCL relies on core classes which are the foundation of the kinematic control library. In particular, the rkcl-core package contains the fundamental data and processor classes required to implement a kinematic control loop. The rkcl-core package also includes the rkcl-utils library which provides a set of basic utility classes such as a data logger or the CooperativeTaskAdapter used to define dual-arm operations in the cooperative task space.

Some complex operations inherent to the kinematic control of robotic systems are performed using existing programs. To do so, specific packages have been created to wrap these libraries in order to make them usable with RKCL components. Notably, the following external open-source libraries have been wrapped to provide the main features to the controller:

  • Forward kinematics adapted from the RBDyn library1 which provides a set of class and function to model the dynamics of rigid body systems. The implementation is based on Roy Featherstone Rigid Body Dynamics Algorithms book and other state of the art publications.
  • Online trajectory generation based on Reflexxes2.
  • Collision avoidance evaluating distance with sch-core3, an efficient implementation of GJK algorithm for proximity queries between convex shapes. Collision objects are represented with sphere or superellipsoid geometric shapes. The former requires less computational efforts to perform proximity queries but the later gives better approximations of arbitrary objects.

To facilitate the creation of applications, we have also developed the AppUtility class provided by the rkcl-app-utility package. It allows to manage efficiently the different processors in the control loop and offers a quick and easy way to configure new applications.

An interface for the robotics simulator V-REP4 is available in the rkcl-driver-package. Thus, the user can validate an application on simulation before launching it on a real platform.

All what we have seen so far is generic and can be used with any kind of robots.

Now, to execute the control process on a given robot, we need to implement robot-specific packages. Referring to the previous figure, we show as an example the packages dedicated to the control of the dual-arm platform BAZAR from LIRMM. We notice that 3 main elements are required to control a real robot with RKCL:

  • A description of the robot. In this case, it is provided by the rkcl-bazar-robot package. RKCL supports both YAML and URDF description format to define the kinematic properties of a robot.

  • Drivers to communicate with the hardware components. In this case, the dual-arm platform is composed of several distinct components: two Kuka arms driven by the FRI driver wrapped in the rkcl-driver-kuka-fri package, a Neobotix MPO700 mobile base (package rkcl-driver-neobotix-mpo700) and ATI force/torque sensors at the tip of each arm (package rkcl-ati-force-sensor-driver). All driver classes in RKCL inherit from a base class which define the common process to perform (e.g. read/send).

  • Dedicated applications to run a scenario in real or simulated environments. These applications strongly relies on the AppUtility class which is in charge of handling the call to the different processes. All C++ application files are generally similar as almost all the application is parametrized using YAML configuration files.

To summarize, RKCL comes with a set of core components which allows the execution of a reactive kinematic control loop. Some of the processes have been developed from scratch and other are based on existing libraries. The integration of new robots in RKCL requires the development of specific packages.

Data representation in RKCL

In RKCL, the core object is a robot. It gathers the essential data needed to execute the control loop. It is made of the tree data structure shown in the figure below:

The robot component is initialized with the description file providing the model of the robot. Then, it is possible to classify the joints extracted from the kinematic model into several JointGroup. This categorization allows assigning a priority to each JointGroup. Without going into the technical details, it means that the JointGroup having the highest priority will be used first to try solving the set of tasks. If this is not sufficient, the next JointGroup is involved to compensate for the remaining error on the tasks, and so on. The classification is arbitrary and is left free to the user. For instance, considering a dual manipulator robot, the two arms might be treated as a unique JointGroup if they are identical but could also be split into two groups if they have different properties (e.g. control time step) or if it is desired to favor the use of one arm over the other.

A ControlPoint object is added to the robot each time a task is defined. It holds the information related to the current state of control :

  • State: the current state of the control point obtained through feedback data (joint positions, force/torque sensor, …)
  • Goal: the final state for the control point to fulfil the current task (usually defined by the pose)
  • Target: the next time step objective for the control point.
  • Command: the task space command for the control point computed from the State and Target elements. Different behavior can be obtained depending on the control mode that is selected for each task variable.

A ControlPoint also carries the limits of the control point in the Cartesian space and the Jacobian matrices for every JointGroup.

A ControlPoint is a specific case of an ObservationPoint. The latter is used to get state information about a frame of the environment without controlling it (no Goal/Target/Command fields). For instance, an ObservationPoint can be defined to track the evolution of the pose of a particular frame or to input data measures from a sensory device.

Synchronization issues

The generic kinematic control approach implemented in RKCL, allowing to deal with multiple robots in a unique control loop, leads to synchronization issues. Indeed, different types of machines with varying control time steps may constitute the whole robotic platform. Also, it is often not possible to use a common synchronization signal between the robots, which means that they usually operate at different times. There is no general way of solving this problem as communication aspects depend on robot manufacturers.

Instead, in keeping with the focus of making RKCL a generic and easy-to-use solution for kinematic control of various robots, we accepted the fact that robots may be unsynchronized and decided to deal with this in such a way that it does not noticeably affect the performances of the system.

In this regard, we propose to separate the execution of communication drivers from the controller by adopting a parallelization strategy. The ecosystem is composed of a unique kinematic control loop that executes the different processors sequentially and several drivers in charge of exchanging data between the hardware components and the controller. Each thread runs independently and at varying frequency: the drivers are triggered by the reception of new data coming from sensors, meaning that the time rate is fixed by the associated component. The case of BAZAR robot, equipped with two arms, a mobile base, and two force sensors at the arms’ wrist is illustrated here:

  1. https://github.com/jrl-umi3218/RBDyn ↩

  2. http://www.reflexxes.ws/ ↩

  3. https://github.com/jrl-umi3218/sch-core ↩

  4. http://www.coppeliarobotics.com/ ↩