**4. Experimental validation**

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. 1 kHz) control loop.

#### **4.1 Experimental setup**

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

#### **Figure 5.**

XBot *validation experiment set 1 software components: How they are allocated in the two WALK-MAN embedded PCs (i.e. N-RT WALKMAN EXP and RT WALKMAN EXP).*

for motion feasibility analysis and collision checking and a manipulation GYM

*Experiment set 1: WALK-MAN EtherCAT slaves RTT measured by EtherCAT master during manipulation actions:* XBot *assures always a control period below 1000 μs while providing integration with external software*

The **set 1** experiments were carried out in a DRC-inspired scenario targeting the removal of debris in front of a valve. In **Figure 6** the experimental setup is shown. In [28], ArmarX was integrated with the robot software environment YARP taking advantage of the built-in YARP CommunicationInterface for the external

In the experiment **set 2** an RT end-effector Cartesian Control on two different robots was performed: the aforementioned WALK-MAN and CENTAURO (in **Figure 6**). CENTAURO [20, 29, 30] upper body is a high performance human size and weight compatible bi-manual manipulation platform with 15 DOFs. Each arm has 7 DOF and the trunk has 1 DOF that permits the yaw motion of the entire upper

In the **set 2** experiments two RT Plugins were used: the first one, called IKCommunication to receive the end-effector pose from the Communication Handler (with the built-in ROS CommunicationInterface) through the XDDP pipes and OpenSoTRTIK to solve the inverse kinematics. The evaluation was focused on the overhead introduced by the IKCommunication RT plugin that exploits two communication mechanism offered by *XBot*: XDDP to receive the data from the non-RT layer and XBotSharedMemory to communicate these data to the other RT

In the **set 1**, *XBot* performance in terms of control period of the RT plugin XBotCommunicationPlugin and CPU usage were analyzed: during the experiments, each millisecond, all the data flowing from/to the R-HAL were recorded,

module, OpenSoT based, using the *YARP* communication framework.

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

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

body and extends the manipulation workspace of the robot.

software framework integration with *XBot*.

using the *XBot* RT low-level logging tools.

plugin (OpenSoTRTIK).

**4.2 Results**

**11**

**Figure 7.**

*frameworks as described in Figure 5.*

#### **Figure 6.**

XBot *validation experiment. On the left set 1 setup: WALK-MAN needs to remove a set of objects in order to perform the task of turning the valve. On the right CENTAURO bi-manual robot platform used in experiment set 2.*

modules in simulation. Whole-body control and inverse kinematics are solved through the OpenSoT control framework [25]. **Figure 5** reports a representation of the software components in use for experiment **set 1**.

In the **set 1** evaluation different high-level software frameworks were successfully integrated on top of *XBot*: *ArmarX* [26] perceptual pipeline for hierarchical affordance extraction [27], OpenSoT previewer based on the *MoveIt! ROS* library

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

#### **Figure 7.**

*Experiment set 1: WALK-MAN EtherCAT slaves RTT measured by EtherCAT master during manipulation actions:* XBot *assures always a control period below 1000 μs while providing integration with external software frameworks as described in Figure 5.*

for motion feasibility analysis and collision checking and a manipulation GYM module, OpenSoT based, using the *YARP* communication framework.

The **set 1** experiments were carried out in a DRC-inspired scenario targeting the removal of debris in front of a valve. In **Figure 6** the experimental setup is shown.

In [28], ArmarX was integrated with the robot software environment YARP taking advantage of the built-in YARP CommunicationInterface for the external software framework integration with *XBot*.

In the experiment **set 2** an RT end-effector Cartesian Control on two different robots was performed: the aforementioned WALK-MAN and CENTAURO (in **Figure 6**). CENTAURO [20, 29, 30] upper body is a high performance human size and weight compatible bi-manual manipulation platform with 15 DOFs. Each arm has 7 DOF and the trunk has 1 DOF that permits the yaw motion of the entire upper body and extends the manipulation workspace of the robot.

In the **set 2** experiments two RT Plugins were used: the first one, called IKCommunication to receive the end-effector pose from the Communication Handler (with the built-in ROS CommunicationInterface) through the XDDP pipes and OpenSoTRTIK to solve the inverse kinematics. The evaluation was focused on the overhead introduced by the IKCommunication RT plugin that exploits two communication mechanism offered by *XBot*: XDDP to receive the data from the non-RT layer and XBotSharedMemory to communicate these data to the other RT plugin (OpenSoTRTIK).

#### **4.2 Results**

In the **set 1**, *XBot* performance in terms of control period of the RT plugin XBotCommunicationPlugin and CPU usage were analyzed: during the experiments, each millisecond, all the data flowing from/to the R-HAL were recorded, using the *XBot* RT low-level logging tools.

**Figure 8.**

*Experiment set 1:* XBot *CPU core usage comparison: Robot idle vs. robot running the experiments. The difference between the two bold lines represents the actual overhead introduced by the middleware when executing the control modules described in the experimental setup for set 1.*

clear that the mean control period is below the 1000 μs (i.e. 1 kHz control frequency) even if the RT system is communicating with the high-level software components through *XBot* the built-in YARP CommunicationInterface non-RT threads. Only two of the RTT measurement (over 200000) were above the requested control period because of missing PDO (Process Data Objects) round in

XBot *framework usage examples: WALK-MAN robot in Pisa (top left), CENTAURO robot untethered and outdoor (bottom left), and the COMAN and its scaled-up version COMAN+ humanoid robots shaking hands*

In **Figure 8** a comparison is presented between *XBot* CPU usage while the robot is idle (i.e. not moving, nor communicating with external software frameworks) and when the **set 1** manipulation experiments are running: the CPU core usage overhead introduced by *XBot* when the robot is performing the manipulation task as described above, is only 1.2% (on average). Furthermore it is clear that the CPU

In the **set 2** the focus was placed on the communication overhead introduced by *XBot*: both the XDDP pipes (communication between RT and non-RT layers) and the XBotSharedMemory (RT plugins communication) are taken into account. As shown in **Figure 9** the mean execution time of the IKCommunication RT plugin is around 1.2 μs for both WALK-MAN and CENTAURO experiments. This means that it is possible to send end-effector reference poses and receive back the robot state from a non-RT framework, while controlling the robot (at 1 kHz in the experiments) using a RT plugin implementing the IK (OpenSoTRTIK in the experiments),

the beckhoff<sup>6</sup> chip responsible for the EtherCAT communication.

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

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

usage of *XBot* is very low (always ranging from 11.7% to 14.2%).

with negligible overhead (**Figure 10**).

<sup>6</sup> https://www.beckhoff.it/

**13**

**Figure 10.**

*(right).*

**Figure 9.**

*Experiment set 2: Communication overhead (RT - RT and N-RT - RT) introduced by* XBot*. Experiment results on both WALK-MAN and CENTAURO are shown.*

In **Figure 7** the RTT (Round Trip Time) measured by the EtherCAT master implementation of the R-HAL during the **set 1** experiments in the worst-case scenario is shown, i.e. while the robot was performing the manipulation actions: it is

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

**Figure 10.**

XBot *framework usage examples: WALK-MAN robot in Pisa (top left), CENTAURO robot untethered and outdoor (bottom left), and the COMAN and its scaled-up version COMAN+ humanoid robots shaking hands (right).*

clear that the mean control period is below the 1000 μs (i.e. 1 kHz control frequency) even if the RT system is communicating with the high-level software components through *XBot* the built-in YARP CommunicationInterface non-RT threads. Only two of the RTT measurement (over 200000) were above the requested control period because of missing PDO (Process Data Objects) round in the beckhoff<sup>6</sup> chip responsible for the EtherCAT communication.

In **Figure 8** a comparison is presented between *XBot* CPU usage while the robot is idle (i.e. not moving, nor communicating with external software frameworks) and when the **set 1** manipulation experiments are running: the CPU core usage overhead introduced by *XBot* when the robot is performing the manipulation task as described above, is only 1.2% (on average). Furthermore it is clear that the CPU usage of *XBot* is very low (always ranging from 11.7% to 14.2%).

In the **set 2** the focus was placed on the communication overhead introduced by *XBot*: both the XDDP pipes (communication between RT and non-RT layers) and the XBotSharedMemory (RT plugins communication) are taken into account. As shown in **Figure 9** the mean execution time of the IKCommunication RT plugin is around 1.2 μs for both WALK-MAN and CENTAURO experiments. This means that it is possible to send end-effector reference poses and receive back the robot state from a non-RT framework, while controlling the robot (at 1 kHz in the experiments) using a RT plugin implementing the IK (OpenSoTRTIK in the experiments), with negligible overhead (**Figure 10**).

<sup>6</sup> https://www.beckhoff.it/
