**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 control/sensor data.

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 interlocked with each other in terms of control.

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

R1: Support data exchange

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

R3: Supports thread and process types for user defined programs

R4: Easy configuration of applications (robot control SW, PLC SW, vision inspection SW, non-real-time SW, etc.)

R5: Support multiple periods.

R6: Threads or processes running in the same period are classified by priority. R7: Check and handle the event through the event handler.

R1 serves as a communication middleware by providing a method for exchanging 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


**Table 1.**

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

be used for soft real-time execution. Process support, as mentioned earlier, is about using legacy programs. R4 does not control the developed application software modules in a hard-coded program, but rather configures them by freely setting the period, priority, application name, etc. through a configuration file.

**3. Implementation and motion analysis of real-time robot SW platform**

The middleware must be implemented to execute the periodic threads and processes, the sporadic threads and processes, as well as the non-real-time processes, as shown in **Figure 1**. Periodic threads and processes should be executed within given periods, while sporadic threads and processes should be executed within the deadline once the corresponding events occur. An example of this behavior is shown in **Figure 2**. Of course, non-real-time modules are executed only when execution time remains in a period. As shown in **Figure 2**, periodic execution has the highest priority, followed by sporadic execution. After the execution of periodic modules, sporadic execution checks whether the event occurs and if true, the event handler invokes the corresponding event processing function to handle it. These operations demonstrate that requirements R2, R3, R5, R6, and R7 are satisfied. Especially, we use time-based interrupts to keep the period strict and calculate

: the first execution time of the target module (reference time)

From Eq. (1) and **Figure 2**, we can observe that it is important to keep the period

**Execution module (in priority)**

0 0 cntr3 > cntr2 > cntr1 > cntr4 Repeat basic periods every

0.5 ms <sup>1</sup> 0.1 cntr3 <sup>&</sup>gt; cntr2

(n = 0,1,2, … ) correctly. There are two approaches to implement the periodic execution: use timer interrupt and use the sleep function. The second method is the most frequently used one and its usage can be described as follows: after executing the SW modules, the operating system sleeps during the remaining time until the next period. However, this method has a disadvantage that the remaining time period does not keep up correctly, leading to increasing jitter. Therefore, in this study, we use a method of implementing period based on timer interrupts. That is, the minimum period is the minimum interval of the timer interrupt generated by the operating system. This allows middleware to be designed to meet requirements

ð1Þ

**Macro period**

scheduling table using GCD/LCM based on **Figure 1**.

*Real-Time Robot Software Platform for Industrial Application*

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

the n-th jitter, as shown in Eq. (1) [15]:

: start time of the n-th module : basic period

: start time of the n-th period, indicated by

**Execution time (ms)**

2 0.2 cntr3 > cntr2 3 0.3 cntr3 > cntr2 4 0.4 cntr3 > cntr2

where

**No. of basic period**

**Table 3.**

**109**

*Periodic scheduling table for Figure 1.*

In general, multiple periods are controlled by using the greatest common divisor (GCD) and the least common multiple (LCM) of the periods. If the period, which is the greatest common divisor, is less than the minimum period provided by the middleware, the multiple periods must be adjusted so that the GCD period is equal to or greater than the minimum period. The smaller the provided period, the better it is because it can be used for various applications. Let the GCD period be the basic period and the LCM period be the macro period [15]. **Table 3** illustrates a periodic

R5 and R6 are about the execution period. As shown in **Table 1**, various execution periods are required. For example, in the case of motor control, if the order of sensor reading (RS), control value generation (GC), and motor value writing (WM) are different, the value sampled in the previous period is used. In other words, when RS, GC, and WM are executed, the control value can be read within one period and sent to the motor. However, when operating in the order of GC, RS, and WM, the control value calculated using the value read in the previous period affects the motor. That is, the previous value without using the current motor related data may affect the motor control. Therefore, to avoid such effects, it is necessary to set the execution priority of SW module within the same period so that they can operate in the order of RS, GC, and WM.

R7 relates to how to handle events. Depending on the event behavior utilized by the operating system, there exist interrupt-based and program-based event handling methods. Interrupt-based events can be used if the HW interrupt can be controlled directly, however, modern operating systems prevent such handling for system stability. Therefore, it is common to introduce an event handler to first check whether an event has occurred, and further handle it. Even those manufacturing robots can generate and handle relevant events such as when there is an emergency stop switch, or the maximum value of sensor input or output exceeds a certain limit. Meanwhile, the processing time for these events is also important. Emergency stop switches should be used as quickly as possible because they are related to safety.

The comparison of the results of whether the existing middleware satisfy each of the presented requirements, is presented in **Table 2**.


*n.a, not available.*

*O, support; X, not support; , support under some constraints. <sup>1</sup>*

*Leverage OS features rather than middleware.*

*2 Realtime only supports threads.*

*3 p means only process type.*

*4 t means only thread type.*

*5 All source code is public, but all applications are compiled/linked.*

#### **Table 2.**

*Comparing existing middleware to platform requirements.*
