**1. Introduction**

A robot software (SW) platform is an execution environment that provides various functions to easily execute various robot softwares. Therefore, a middleware that provides such functions can be considered as a platform.

Middleware is a type of software that exists between an application and an operating system, and it employs communication protocols on the hardware, thereby facilitating the development applications by users and reducing the cost and risk when developing them [1]. Several types of middleware have been applied in the field of robotics, such as Common Object Request Broker Architecture (CORBA) [2, 3], Real-Time CORBA (RT-CORBA) [2, 4], Data Distribution Service (DDS) [2, 5], OPC Unified Architecture (OPC-UA) [6], Robot Operating System (ROS) [7, 8], Open Platform for Robotic Services (OPRoS) [9–11], OpenRTM (open robotics technology middleware) [12], open robot control software (OROCOS) [13], XbotCore [14], and real-time middleware for industrial automation devices [15] (hereafter, referred to as RTMIA).

A common feature of these middleware is that they support message-based communication. Thus, a majority of middleware can be implemented in multiple nodes, such as processes, threads, or CPU boards that support middleware-unique communication protocol to facilitate data exchange between them. The difference among these middleware is whether the real-time constraint is satisfied or not, from the perspective of the application thread or process. Even in the real-time viewpoint, providing real-time from a communication point of view is different from providing real-time from a (application) process point of view. In general, the term "real-time" in this study indicates the real-time used in the process viewpoint. Hence, middleware must be able to control user-created programs using processes or threads.

discuss whether various kinds of existing middleware satisfy them. Section 3 presents the implementation of the real-time robot SW platform, and Section 4 describes the practical results obtained by mutually interlocked work of programs of robot task and PLC on the proposed platform. Finally, Section 5 concludes the

*Real-Time Robot Software Platform for Industrial Application*

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

**2. Operation requirements and analysis of real-time robot SW platform**

For a real-time robotic SW platform for various industrial applications, we must know the characteristics (period, etc.) of the data used for processing periods and events. Referring to the data presented in [19], the data used in the manufacturing robot can be roughly described as in **Table 1**. It may differ slightly from other classifications because it is categorized based on type and period (or delay time) of

In fact, the data generated at each level in **Table 1** is used as basis for the target data. For example, upon recognizing an obstacle at level 4, its position data is used to generate a level 3 position profile that provides relevant position data of level 2, based on which, at level 1, a position control loop moves the motor to the desired position by controlling the speed or torque of the motor. That is, data of each level is

A real-time robot SW platform should satisfy the following requirements.

R2: Real time support (strict period execution and sporadic performance

R4: Easy configuration of applications (robot control SW, PLC SW, vision

R6: Threads or processes running in the same period are classified by priority.

R1 serves as a communication middleware by providing a method for exchang-

ing data between configured applications. R2 supports real time operation and requires a minimal amount of jitter to perform periodic operations. It must also be able to handle real-time events. For instance, conditions for use in various control loop programs are strict periodic execution conditions, including the program for directly controlling the motor without using a separate controller, and sporadic to handle emergency event such as an emergency stop. In many cases, such execution condition is required. In particular, the 100 μs period can be used to control the motor current. R3 uses threads for real-time support, but also allows the process to

**Level Data type Period (delay time)**

 Obstacle recognition, object recognition, device status Seconds Position profiles Hundreds of ms Position data Tens of ms Motor torque and speed control data 100 μs

*Types of control/sensor data used in manufacturing robots and their associated periods (delays).*

R3: Supports thread and process types for user defined programs

R7: Check and handle the event through the event handler.

study.

control/sensor data.

support)

**Table 1.**

**107**

interlocked with each other in terms of control.

R1: Support data exchange

inspection SW, non-real-time SW, etc.) R5: Support multiple periods.

Even though middleware such as CORBA, RT-CORBA, OPRoS, openRTM, OROCOS, XbotCore, and RTMIA control threads, in other middleware such as OPC-UA, ROS, and DDS, the control of threads or processes is implemented by the operating system. Hence, they do not directly control threads or processes. Except CORBA, all of the above-mentioned thread controlling middleware satisfy the real time constraint. However, if they are analyzed in detail, RT-CORBA, OPRoS, openRTM, and OROCOS have conditions to satisfy the real time, in which the execution type is limited to thread type and threads can be controlled in the time range such as over 1 ms [8] or 10 ms [11]. In [14] EtherCAT-based robot real-time SW platform is proposed, which is a Xenomai-based robot control middleware that satisfies the hard real-time requirements and is designed to perform 1 kHz control loops in a multi-axis system consisting of 33 axes. RTMIA is middleware that can execute control loops in 100 μs and can simultaneously control both processes and threads in real-time.

OPC-UA, ROS, and DDS are a kind of communication middleware. That is, they do not satisfy the real time requirement since they are in charge of the data exchange part between multiple nodes. Note that ROS 2.0 utilizes DDS. OPC-UA is a middleware that performs data exchange among various robots and controls devices such as the FMS controller or the server on the upper level. OPC-UA is not a middleware that can be used for robot control like ROS. The use cases of ROS shows that most types of the user program are process types rather than thread types. In other words, the thread type provided by the real-time middleware is reluctant to be used because their basic usage forms may introduce inconvenience and unfamiliarity for robot software developers. ROS has big advantage of using the conventional programming method, which users are familiar with, and utilizes the readymade existing robot program. However, ROS must use 'sleep()' function for periodic processing. 'sleep()' function does not always wake up at the correct time, resulting in time shift occurrence. Accumulation of such shifts cause loss of some periods, which may lead to states that cannot be controlled properly. In order to avoid such situation, some constraints must be kept to strictly control the number of applications and the execution environment.

The current trend of commercial PLC-related products [16, 17] shows that platforms such as CODESYS [16] and TwinCAT [17] control robot systems, including grippers, by embedding robot motion control SWs to PLC SWs. The feature of these platform is that they use the robot block language proposed by PLCopen [18], while their principal advantage is the ability to link robots to related automation devices efficiently using PLC program. However, the types of robots that can be controlled through these platforms are still limited. To solve this, the platform should simultaneously perform both PLC function blocks, including robot function blocks, and robot (task) programs defined directly by users or robot developers.

In this study, we presented the requirements of the real-time robot SW platform for industrial robots and examined whether various types of existing middleware satisfy them. Additionally, we extend the RTMIA [15] and propose a real-time robot SW platform that can be used for various industrial applications and satisfies the presented requirements. We implemented our proposed platform on the Xenomai real-time operating system and Linux, and verify it via a few practical examples, wherein the interlocking programs of robot task and PLC are simultaneously performed.

The remainder of the study is organized as follows. In Section 2, we present the requirements of the real-time robot SW platform for industrial applications and

"real-time" in this study indicates the real-time used in the process viewpoint. Hence, middleware must be able to control user-created programs using processes

Even though middleware such as CORBA, RT-CORBA, OPRoS, openRTM, OROCOS, XbotCore, and RTMIA control threads, in other middleware such as OPC-UA, ROS, and DDS, the control of threads or processes is implemented by the operating system. Hence, they do not directly control threads or processes. Except CORBA, all of the above-mentioned thread controlling middleware satisfy the real time constraint. However, if they are analyzed in detail, RT-CORBA, OPRoS, openRTM, and OROCOS have conditions to satisfy the real time, in which the execution type is limited to thread type and threads can be controlled in the time range such as over 1 ms [8] or 10 ms [11]. In [14] EtherCAT-based robot real-time SW platform is proposed, which is a Xenomai-based robot control middleware that satisfies the hard real-time requirements and is designed to perform 1 kHz control loops in a multi-axis system consisting of 33 axes. RTMIA is middleware that can execute control loops in 100 μs and can simultaneously control both processes and

OPC-UA, ROS, and DDS are a kind of communication middleware. That is, they

exchange part between multiple nodes. Note that ROS 2.0 utilizes DDS. OPC-UA is a middleware that performs data exchange among various robots and controls devices such as the FMS controller or the server on the upper level. OPC-UA is not a middleware that can be used for robot control like ROS. The use cases of ROS shows that most types of the user program are process types rather than thread types. In other words, the thread type provided by the real-time middleware is reluctant to be used because their basic usage forms may introduce inconvenience and unfamiliarity for robot software developers. ROS has big advantage of using the conventional programming method, which users are familiar with, and utilizes the readymade existing robot program. However, ROS must use 'sleep()' function for periodic processing. 'sleep()' function does not always wake up at the correct time, resulting in time shift occurrence. Accumulation of such shifts cause loss of some periods, which may lead to states that cannot be controlled properly. In order to avoid such situation, some constraints must be kept to strictly control the number

The current trend of commercial PLC-related products [16, 17] shows that platforms such as CODESYS [16] and TwinCAT [17] control robot systems, including grippers, by embedding robot motion control SWs to PLC SWs. The feature of these platform is that they use the robot block language proposed by PLCopen [18], while their principal advantage is the ability to link robots to related automation devices efficiently using PLC program. However, the types of robots that can be controlled through these platforms are still limited. To solve this, the platform should simultaneously perform both PLC function blocks, including robot function blocks, and robot (task) programs defined directly by users or robot developers. In this study, we presented the requirements of the real-time robot SW platform for industrial robots and examined whether various types of existing middleware satisfy them. Additionally, we extend the RTMIA [15] and propose a real-time robot SW platform that can be used for various industrial applications and satisfies the presented requirements. We implemented our proposed platform on the Xenomai real-time operating system and Linux, and verify it via a few practical examples, wherein the interlocking programs of robot task and PLC are simultaneously

The remainder of the study is organized as follows. In Section 2, we present the requirements of the real-time robot SW platform for industrial applications and

do not satisfy the real time requirement since they are in charge of the data

of applications and the execution environment.

or threads.

*Industrial Robotics - New Paradigms*

threads in real-time.

performed.

**106**

discuss whether various kinds of existing middleware satisfy them. Section 3 presents the implementation of the real-time robot SW platform, and Section 4 describes the practical results obtained by mutually interlocked work of programs of robot task and PLC on the proposed platform. Finally, Section 5 concludes the study.
