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

*Luca Muratore, Arturo Laurenzi and Nikos G. Tsagarakis*

## **Abstract**

The widespread use of robotics in new application domains outside the industrial workplace settings requires robotic systems which demonstrate functionalities far beyond that of classical industrial robotic machines. The implementation of these capabilities inevitably increases the complexity of the robotic hardware, control a and software components. This chapter introduces the XBot software architecture for robotics, which is capable of Real-Time (RT) performance with minimum jitter at relatively high control frequency while demonstrating enhanced flexibility and abstraction features making it suitable for the control of robotic systems of diverse hardware embodiment and complexity. A key feature of the XBot is its cross-robot compatibility, which makes possible the use of the framework on different robots, without code modifications, based only on a set of configuration files. The design of the framework ensures easy interoperability and built-in integration with other existing software tools for robotics, such as ROS, YARP or OROCOS, thanks to a robot agnostic API called XBotInterface. The framework has been successfully used and validated as a software infrastructure for collaborative robotic arms as KUKA lbr iiwa/lwr 4+ and Franka Emika Panda, other than humanoid robots such as WALK-MAN and COMAN+, and quadruped centaur-like robots as CENTAURO.

**Keywords:** software architecture for robotics, real-time control, cross-robot framework, humanoid robotics, hardware abstraction layer, XBot, ROS

#### **1. Introduction**

Nowadays effective robotic solutions targeting new applications outside the traditional industrial environment, are supposed to operate in partially known spaces with unforeseen uncertainty and increased variability in the application tasks. Hence, to be effective, they have to adapt rapidly and seemly their functionalities in these demands, leading to an increase of the complexity in each layer of the robotic system, from the hardware to the high level control.

To tackle this, several software frameworks for robotics have been developed in the past twenty years, as stated in [1], aiming to provide flexible infrastructures, which not only permit the seamless integration of new functionalities and interfaces in the robotic system, but also ensure standardization, easy tracking and maintenance of the software development, despite the increased complexity. Apart from dealing with the software complexity, these frameworks have to provide hard Real-Time (RT) performance, ensuring predictable response times [2] as required in critical tasks when robots need to perform in autonomous mode, responding to

disturbances and interacting with the physical environment during the execution of a task. Thus, a vital feature of a software framework for robotics is the Real-Time safeness and scheduling, essential for precise robot control, especially when dealing with high frequency and low jittering control cycles.

Furthermore, a software middleware needs to abstract the complex hardware (e.g. actuators and sensors) of the robot providing an easy-to-use, standardized Application Programming Interface (API). As a matter of fact, a robot can be considered a distributed system composed of a set of hardware devices communicating through a fieldbus. The fast prototype and development of control and application software which can be shared, ported and reused in various robotic platforms with minimum effort, is another fundamental requirement for the software architecture. An important component needed to achieve this goal is the Hardware Abstraction Layer (HAL), which can be incorporated to mask the physical hardware differences and limitations (e.g. control frequency, kinematics/ dynamics model, actuators type and size, sensors, etc) varying from one robot to another. The HAL can provide a relatively uniform abstraction layer that assures portability and code reuse: it permits the development of control modules that can be easily ported from one robot to another.

The existing robotics software frameworks address different needs and requirements, therefore one of the key aspects for a brand-new middleware is the interoperability with well-known and established robotic software platforms. Interoperability should ideally allow users to execute existing software without the necessity of (i) changing the current code and (ii) writing hand-coded "bridges" for each use case [3].

**YARP** (Yet Another Robot Platform) [6] and **ROS** (Robot Operating System) [7] are popular component-based frameworks for IPC that do not guarantee RT execution among modules/nodes. It is essential for a robotic system to have a component responsible for the RT control of the robot, making these frameworks only viable as external (high-level) software frameworks. It is worth to mention that a new *ROS* version, called **ROS 2**<sup>2</sup> has been released: it is still in an early stage

*Summary of the features of the available software frameworks for robotics: The XBot was developed from*

No Medium Yes Small

**Complexity**

**ROS** No Yes Low Yes Big and active **YARP** No Yes High Yes Medium and active **OROCOS** Yes No Very High Yes Medium and inactive **OpenRT-M** Yes Yes Very High Yes Part of docs in Japanese **ROS 2** Yes Yes High No Small and Active **PODO** Yes Yes Very High No, not available KAIST group only

*XBot Yes Yes Low Yes Small*

*scratch given the limitations and the missing features of the presented existing framework.*

**PODO** [8], is the framework used by KAIST in HUBO during the DRC (Darpa Robotics Challenge) Finals. Its control system has RT control capabilities and its inter-process communication facilities are based on POSIX IPC; moreover it uses a shared memory system called MPC to exchange data between processes in the same machine. This heterogeneous system has the potential to cause confusion as it is unclear which architectural style must be used to communicate with a specific

In [10] an RT architecture based on OpenJDK is introduced (used by IHMC during the DRC Finals). Nevertheless, to their own admission [11], none of the commercially available implementations of the Java Real Time Specification had the performance required to run their controller. Existing Real-time Java Support is

Considering the above limitations, summarized in **Table 1**, the *XBot* [12–14] was developed from scratch, in order to have a reliable RT control framework with HAL

The development of *XBot* was driven by the need to provide a software infrastructure that abstracts the diverse variability of the robotic hardware (effectively becoming a cross-robot framework), provides deterministic hard Real-Time (RT) performance, incorporates interfaces that permit its integration with state of art robot control frameworks and achieves enhanced flexibility through a plug-in

.

**Ready-to-Use Community**

development phase, so it cannot be used in real-world scenario<sup>3</sup>

**Framework RT HAL IPC**

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

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

performance

**IHMC OpenJDK** Yes, low

**Table 1.**

support and without depending on complex IPC frameworks.

component [9].

insufficient.

architecture.

**3**

**3. XBot framework**

<sup>2</sup> https://index.ros.org/doc/ros2/

<sup>3</sup> https://index.ros.org/doc/ros2/Features/

In this chapter the *XBot* software framework is presented. The development of the *XBot* was driven by the need to provide a software framework that abstracts the diverse variability of the robotic hardware (effectively becoming a cross robot platform framework), providing deterministic hard Real-Time (RT) performance, incorporating interfaces that permits it to integrate state of art robot control frameworks and achieve enhanced flexibility through a plug-in architecture.

### **2. Related works**

In this section the state of the art of robotic software architectures will be analyzed.

In [4] the low level control framework, called **OROCOS** (Open Robot Control Software), is introduced, which provides a set of components for RT control of robotic systems. **OROCOS** relies on the Common Object Request Broker (CORBA) architecture, that allows inter-process and cross-platform interoperability for distributed robot control. Depending on any Inter-Process-Communication (IPC) framework can critically increase the complexity of the software platform. Despite *OROCOS* is used in a fair number of robotics projects, the framework maintenance as well as the community looks not being very active anymore<sup>1</sup> .

Very similar to OROCOS is **OpenRT-M** [5], developed in Japan from 2002 under NEDO's (New Energy and Industrial Technology Development Organization) "Robot challenge program". It is based on CORBA, so similar considerations as for OROCOS can be made with respect to the software complexity; moreover part of OpenRT-M documentation is in Japanese.

<sup>1</sup> In particular we refer to the discontinuity in maintaining the framework under last versions (≥3.X) of Ubuntu Xenomai, where the OROCOS porting is still experimental.

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


#### **Table 1.**

*Summary of the features of the available software frameworks for robotics: The XBot was developed from scratch given the limitations and the missing features of the presented existing framework.*

**YARP** (Yet Another Robot Platform) [6] and **ROS** (Robot Operating System) [7] are popular component-based frameworks for IPC that do not guarantee RT execution among modules/nodes. It is essential for a robotic system to have a component responsible for the RT control of the robot, making these frameworks only viable as external (high-level) software frameworks. It is worth to mention that a new *ROS* version, called **ROS 2**<sup>2</sup> has been released: it is still in an early stage development phase, so it cannot be used in real-world scenario<sup>3</sup> .

**PODO** [8], is the framework used by KAIST in HUBO during the DRC (Darpa Robotics Challenge) Finals. Its control system has RT control capabilities and its inter-process communication facilities are based on POSIX IPC; moreover it uses a shared memory system called MPC to exchange data between processes in the same machine. This heterogeneous system has the potential to cause confusion as it is unclear which architectural style must be used to communicate with a specific component [9].

In [10] an RT architecture based on OpenJDK is introduced (used by IHMC during the DRC Finals). Nevertheless, to their own admission [11], none of the commercially available implementations of the Java Real Time Specification had the performance required to run their controller. Existing Real-time Java Support is insufficient.

Considering the above limitations, summarized in **Table 1**, the *XBot* [12–14] was developed from scratch, in order to have a reliable RT control framework with HAL support and without depending on complex IPC frameworks.

### **3. XBot framework**

The development of *XBot* was driven by the need to provide a software infrastructure that abstracts the diverse variability of the robotic hardware (effectively becoming a cross-robot framework), provides deterministic hard Real-Time (RT) performance, incorporates interfaces that permit its integration with state of art robot control frameworks and achieves enhanced flexibility through a plug-in architecture.

<sup>2</sup> https://index.ros.org/doc/ros2/

<sup>3</sup> https://index.ros.org/doc/ros2/Features/

In the next sections, the *XBot* design goals and the software architecture insights are going to be described following a bottom-up approach going from the hardware towards the high-level control of the robotic system.

• **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.

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

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

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

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

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.*

the kinematic/dynamic engine to use.

**3.2 Software architecture**

**Figure 1.**

**5**
