**3.1 Design goals**

The considerations and limitations of the existing frameworks, described in detail in the previous section, motivated the development of the *XBot* framework bearing in mind that the design of a software platform, which lies at the foundations of such complex and diverse robotic systems, is the most crucial phase in the software development process. *XBot* was designed to be both an RT control system and a user friendly, flexible and reusable middleware for RT and non-RT control software modules. *XBot* was developed starting from the following design goals and features:


<sup>4</sup> https://xenomai.org/

• **Flexibility**: *XBot* has to be easily modified or extended to be used in systems and applications other than those for which it was specifically designed.

Finally, the *XBot* software framework was not developed to address the requirements of a specific robotic platform, instead its implementation is flexible, generic and cross-robot. Furthermore it does not directly depend on any existing software or control platform, but it provides to the user the functionality to easily integrate any RT or non-RT framework. To obtain the above features, a user of the *XBot* with a generic robotic platform to control, has to provide a set of configuration files, mainly related to the kinematics and dynamics of the robot, the control plugins to execute, the HAL implementation, the high level communication framework and the kinematic/dynamic engine to use.

### **3.2 Software architecture**

As presented in **Figure 1**, the *XBot* software architecture is composed of different components, described in detail within the following sections. In particular the design choices, from a software engineer point of view, are the results of the design goals described in Section 3.1. To avoid scheduling issues and keep the complexity of the software infrastructure as low as possible only two RT threads and one non-RT thread are currently employed in the framework as presented in **Figure 2**. The RT layer contains the R-HAL (Robotics Hardware Abstraction Layer) to assure cross-robot compatibility and seamless porting of the higher level code from the simulation to the real robot. The communication mechanism employed in this layer is a shared memory one using basic synchronization methods (i.e. mutex and condition variables). On top of the R-HAL, the *Plugin Handler* is designed using a

#### **Figure 1.**

XBot *software architecture: components overview and interaction. From the bottom the* R-HAL *and the plugin handler inside the RT Xenomai layer are presented, with the shared memory communication between them. The non-RT layer and the external software integration component of the* XBot *is represented by the* Communication Handler *which is able to communicate with the robot/simulation through a XDDP mechanism which assures lock-free IPC. Thanks to the* XBotInterface *on the left, all the layers of the framework have an uniform way (through an API) to send commands and receive state from the robot.*

#### **Figure 2.**

XBot *threads structure and communication mechanisms: To keep the complexity of the framework low and assure full control over the software infrastructure, only two RT threads and one non-RT thread are currently employed.*

component-based software design paradigm by featuring a clear component concept (the plugin as a shared library) with well-defined structure and communication interfaces. In order to be able to assure external software integration, the communication with the non-RT layer, represented by a standalone component called Communication Handler, is implemented using a lock-free Inter Process Communication (IPC) mechanism based on XDDP (described in details in the following sections). The same concept is applied to communicate with other RT frameworks (e.g. OROCOS), using a mechanism based on IDDP. The idea of the *NRT Deployer* came from the need to have a behavior similar to the one of the *Plugin Handler* but completely in the non-RT layer. Finally a standard way of communicating with the robot regardless of its specific structure (humanoid, quadruped, manipulator, etc), and also independently of the particular software layer that the user wants to operate within, is provided by mean of the *XBotInterface*.

*3.2.2 Plugin handler*

**Figure 3.**

The main component of the *XBot* architecture is called *PluginHandler* and it is

*COMAN+ robot controlled inside the gazebo simulator (left) and CENTAURO robot in RViZ (right): Both*

The Plugin implementation is compiled as a shared object library (.so). In details a Plugin is a simple class inherited from the abstract class XBotControlPlugin; this means that writing a Plugin is straightforward for the user, as the only need is to

• an *init\_control\_plugin()* function, which is called by the *PluginHandler* after the plugin is loaded/reloaded and is useful to initialize the variables of the Plugin

• a *control\_loop()* function, which is called in the run loop of the *PluginHandler*

After the design and the implementation of the latency-free, hard real-time layer

• a *close()* function, which is called in the *PluginHandler* closing phase

the next significant feature is accompanied by the implementation of flexible

represented in **Figure 1** with the dark pink color. The software design of this component relies on two core requirements for a robotic system (described in 3.1): the RT control and the highly expandable software structure. To achieve this the *PluginHandler* is implemented using a single RT thread running at high frequency (e.g. 1 kHz) and it is responsible for the following actions with the order they appear below: load the set of plugins requested by the user from a configuration file, initialize all the loaded plugins, and start them upon user request, execute the plugins that have been started sequentially, reload and reinitialize a plugin upon user request, close and unload all the loaded plugins. In **Figure 4**, the UML state

*using two different implementations of the* R-HAL *provided in the* XBot *software architecture.*

*XBot: A Cross-Robot Software Framework for Real-Time Control*

*DOI: http://dx.doi.org/10.5772/intechopen.97066*

diagram representing the life-cycle of a plugin is presented.

implement three basic functions:

after the plugin is started

**7**

#### *3.2.1 R-HAL*

The Cross-Robot compatibility feature is achieved through the development of a suitable hardware abstraction layer [18], which enables the user to efficiently port and run the same control modules on different robots, both in simulation and on the real hardware platforms. The main goal of this software component is to provide an independent layer in between the robot hardware and the high-level control, enabling the seamless integration of new actuators, sensors or other hardware components.

Concerning the threads configuration, *XBot* employs a separate thread to execute the low-level robot control loop and permits to realize separate controllers with different frequencies. The synchronization between the *Plugin Handler* thread and the *R-HAL* thread is implemented using condition variables, assuring the safe access of the shared data structures.

*XBot* currently supports EtherCAT (for robots like WALK-MAN, CENTAURO and COMAN+), Ethernet (for COMAN), and KUKA LWR 4/KUKA LBR arm based robots [19–21]. The possibility to simulate the robot and its controllers behaviors prior to testing on the real hardware is essential, especially when dealing with complex robotic systems. To achieve this we provide an *R-HAL* implementation for the well known *Gazebo*<sup>5</sup> simulator environment **Figure 3**. In particular we rely on the *Gazebo* ModelPlugin class to be part of the Gazebo internal loop.

<sup>5</sup> http://gazebosim.org/

*XBot: A Cross-Robot Software Framework for Real-Time Control DOI: http://dx.doi.org/10.5772/intechopen.97066*

**Figure 3.**

*COMAN+ robot controlled inside the gazebo simulator (left) and CENTAURO robot in RViZ (right): Both using two different implementations of the* R-HAL *provided in the* XBot *software architecture.*

#### *3.2.2 Plugin handler*

The main component of the *XBot* architecture is called *PluginHandler* and it is represented in **Figure 1** with the dark pink color. The software design of this component relies on two core requirements for a robotic system (described in 3.1): the RT control and the highly expandable software structure. To achieve this the *PluginHandler* is implemented using a single RT thread running at high frequency (e.g. 1 kHz) and it is responsible for the following actions with the order they appear below: load the set of plugins requested by the user from a configuration file, initialize all the loaded plugins, and start them upon user request, execute the plugins that have been started sequentially, reload and reinitialize a plugin upon user request, close and unload all the loaded plugins. In **Figure 4**, the UML state diagram representing the life-cycle of a plugin is presented.

The Plugin implementation is compiled as a shared object library (.so). In details a Plugin is a simple class inherited from the abstract class XBotControlPlugin; this means that writing a Plugin is straightforward for the user, as the only need is to implement three basic functions:


After the design and the implementation of the latency-free, hard real-time layer the next significant feature is accompanied by the implementation of flexible

frameworks, meaning that the end-users has YARP control board wrappers / analog sensors and ROS joint state / command messages already available. Interoperability for YARP/ROS framework and *XBot* is one of the key feature offered by the Com-

1.a joint space interface, consisting of standard ROS topics that are advertised/ subscribed by the *Communication Handler* itself in order to publish the robot

ROS-powered robots expose to their users an interface that is mainly based on topics. For instance, the robot joint state is usually published to a /joint\_state topic through sensor\_msgs/JointState messages. The same kind of message can be published by the user on a /command topic in order to control the robot.

The *XBot* framework provides also the integration with any external RT software framework (e.g. OROCOS) thanks to the use of the IDDP (Intra Domain Datagram

Inside the Communication Handler component, the *XBot* framework provides

In this section the results of the validation of the overall framework is going to be presented with particular focus on the flexibility in terms of integration with different robots and external software frameworks, and also on the overhead introduced by the *XBot* while assuring predictable response time at high frequency (i.e.

To evaluate the performance of the *XBot* software platform, two sets of experiments were performed: in the experiment **set 1** the WALK-MAN [22, 23] robot was used, a humanoid with 33 Degree-Of-Freedom, 4 custom F/T sensors and 1 VN-100 imu. The WALK-MAN vision system is composed of a CMU Multisense-SL sensor that includes a stereo camera, a 2D rotating laser scanner, and an IMU. The robot control modules were based on GYM [24] (Generic Yarp Module), a component model to easily develop software modules for robotics leveraging the YARP ecosystem: YARP Based Plugins for Gazebo Simulator were used to validate the control

performing Input/Output operation from the non-RT layer to the RT layer. The so called IOPlugins are very similar to the Plugin used in the RT layer, in fact the implementation is compiled as a shared object library (.so). In detail, an IOPlugin is a simple class inheriting from the abstract class XBot::IOPlugin, which gives to the user simple access to the shared memory component and the pipes to communicate

the user with the possibility of running non-RT plugins that are useful for

between the non-RT layer and the RT one. As for the standard Plugin, *XBot*

provides a ready-to-use skeleton (simple script to run) for the user.

Inside *XBot* a similar interface to the ROS middleware is offered, the only difference lies in the message type being used. Broadly speaking, *XBot* uses an extended joint state message that make it possible to perform more flexible control

In the specific ROS case, *XBot* provides two families of interfaces:

2.a set of tools for using a subset of ROS inter-process communication

state (including sensors) and accept commands

*XBot: A Cross-Robot Software Framework for Real-Time Control*

*DOI: http://dx.doi.org/10.5772/intechopen.97066*

capabilities from the RT domain

of the robot than is allowed with standard ROS.

**4. Experimental validation**

1 kHz) control loop.

**9**

**4.1 Experimental setup**

Protocol) pipes for the RT inter-process communication.

munication Handler.

**Figure 4.** *UML state diagram showing a* XBot *plugin life-cycle.*

interfaces, called *XBotInterface*, which permit our framework to integrate with state-of-art, widely spread robot control frameworks.

#### *3.2.3 Communication handler*

The above mentioned software components do not give the possibility to communicate with external modules/hosts outside the robot: for this purpose the software framework of a robotic system should incorporate a set of non-RT threads that permit the communication of the system with remote pilot stations or cloud services. *XBot* provides this with the implementation of the Communication Handler component (represented in **Figure 1** with the yellow color) that is a non-RT thread exploiting an XDDP (Cross Domain Datagram Protocol) handler with the ready-to use *XBot* non-RT API for a set of components called CommunicationInterface(s). The non-RT API uses XDDP Xenomai pipes to achieve asynchronous communication between RT and non-RT threads. A lock-free inter-process communication (IPC) is employed to permit the RT control threads to exchange messages with the non-RT communication threads without any context switch. The execution loop of the Communication Handler thread is responsible for updating the internal robot state using the XDDP pipe with the non-RT robot API, sending the robot state to all the communication frameworks implemented as CommunicationInterface(s), receiving the new reference from the "master" CommunicationInterface (to avoid having multiple external frameworks commanding the robot) and finally for sending the received reference to the robot using the XDDP non-RT robot API.

It is relatively straightforward to add a new CommunicationInterface in the framework: *XBot* provides built-in support for YARP and ROS communication

frameworks, meaning that the end-users has YARP control board wrappers / analog sensors and ROS joint state / command messages already available. Interoperability for YARP/ROS framework and *XBot* is one of the key feature offered by the Communication Handler.

In the specific ROS case, *XBot* provides two families of interfaces:


ROS-powered robots expose to their users an interface that is mainly based on topics. For instance, the robot joint state is usually published to a /joint\_state topic through sensor\_msgs/JointState messages. The same kind of message can be published by the user on a /command topic in order to control the robot.

Inside *XBot* a similar interface to the ROS middleware is offered, the only difference lies in the message type being used. Broadly speaking, *XBot* uses an extended joint state message that make it possible to perform more flexible control of the robot than is allowed with standard ROS.

The *XBot* framework provides also the integration with any external RT software framework (e.g. OROCOS) thanks to the use of the IDDP (Intra Domain Datagram Protocol) pipes for the RT inter-process communication.

Inside the Communication Handler component, the *XBot* framework provides the user with the possibility of running non-RT plugins that are useful for performing Input/Output operation from the non-RT layer to the RT layer. The so called IOPlugins are very similar to the Plugin used in the RT layer, in fact the implementation is compiled as a shared object library (.so). In detail, an IOPlugin is a simple class inheriting from the abstract class XBot::IOPlugin, which gives to the user simple access to the shared memory component and the pipes to communicate between the non-RT layer and the RT one. As for the standard Plugin, *XBot* provides a ready-to-use skeleton (simple script to run) for the user.
