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

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 scheduling table using GCD/LCM based on **Figure 1**.

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 n-th jitter, as shown in Eq. (1) [15]:

$$J\_m \rightleftharpoons P\_n - T\_n \rightleftharpoons T\_0 + n \quad \text{ \* } p \text{-point} \quad \text{ \* } T\_n \tag{1}$$

where

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

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

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

The comparison of the results of whether the existing middleware satisfy each of

R1 O O O O O O O O R2 General △<sup>1</sup> <sup>O</sup><sup>2</sup> OO O O OO

> △ (10 ms)

> > △t 4

R4 △<sup>5</sup> OO O O △ O O R5 △<sup>1</sup> OO O O O O O R6 X X X X X X n.a X R7 X △ X X X X n.a X

△ (10 ms)

4

**OPRoS openRTM OROCOS XbotCore CODESYS RTMIA**

△t

△ (1 ms) n.a O

<sup>4</sup> n.a O

△ (10 ms)

> △t 4

period, priority, application name, etc. through a configuration file.

operate in the order of RS, GC, and WM.

*Industrial Robotics - New Paradigms*

the presented requirements, is presented in **Table 2**.

**ROS RT-CORBA**

> <sup>X</sup> △ (25 ms)

R3 △p3 <sup>O</sup> △<sup>t</sup>

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

*Comparing existing middleware to platform requirements.*

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

*Leverage OS features rather than middleware.*

*Realtime only supports threads.*

*p means only process type.*

*t means only thread type.*

related to safety.

**Requirement number**

> period of 100 μs

*n.a, not available.*

*2*

*3*

*4*

*5*

**108**

**Table 2.**

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

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

: start time of the n-th module

: basic period

From Eq. (1) and **Figure 2**, we can observe that it is important to keep the period (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


**Table 3.** *Periodic scheduling table for Figure 1.*

R2 and R5. In addition, the platform should be designed using the POSIX (Portable

The real-time robot SW platform should be able to exchange data or remotely perform necessary functions among periodic SW module, sporadic SW module and non-real-time SW module. This is because only cooperation between SW modules can achieve the desired result. For this purpose, the proposed middleware implements a method of obtaining the desired results by performing exchange of data and remote functions using shared memory. The advantage of using shared memory is that it is easy to maintain data consistency and to use the data. In other words, when SW modules including input module write input data to shared memory, other SW modules read them and calculate the control values at the same time. And if necessary, the module writes the result to shared memory for other modules to use the data. In addition, it provides a shared function in the shared memory method so that other SW modules can use the shared functions of the modules. Of course, when using shared memory, the problem of mutual exclusion between

A file named .glb is used to define shared variables that are implemented using shared memory. For example, if a file called knuRobot.glb is created as shown in **Figure 3**, a conversion function creates the header file and a .cpp function to access shared variables. The difference from existing shared variable is that, just like global variables, the shared variable that resides in shared memory can be used in all the software modules. This method makes the program very simple. Example programs that use shared variables in **Figure 3** are shown in **Figures 4** and **5**, in which,

Operating System Interface) standard.

*Example of execution timing diagram of SW modules.*

*Real-Time Robot Software Platform for Industrial Application*

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

threads is solved.

**Figure 3.**

**111**

*Example code of a file defined shared variables.*

**Figure 2.**

**Figure 1.** *Example of module.xml.*

### *Real-Time Robot Software Platform for Industrial Application DOI: http://dx.doi.org/10.5772/intechopen.91014*

### **Figure 2.**

*Example of execution timing diagram of SW modules.*

R2 and R5. In addition, the platform should be designed using the POSIX (Portable Operating System Interface) standard.

The real-time robot SW platform should be able to exchange data or remotely perform necessary functions among periodic SW module, sporadic SW module and non-real-time SW module. This is because only cooperation between SW modules can achieve the desired result. For this purpose, the proposed middleware implements a method of obtaining the desired results by performing exchange of data and remote functions using shared memory. The advantage of using shared memory is that it is easy to maintain data consistency and to use the data. In other words, when SW modules including input module write input data to shared memory, other SW modules read them and calculate the control values at the same time. And if necessary, the module writes the result to shared memory for other modules to use the data. In addition, it provides a shared function in the shared memory method so that other SW modules can use the shared functions of the modules. Of course, when using shared memory, the problem of mutual exclusion between threads is solved.

A file named .glb is used to define shared variables that are implemented using shared memory. For example, if a file called knuRobot.glb is created as shown in **Figure 3**, a conversion function creates the header file and a .cpp function to access shared variables. The difference from existing shared variable is that, just like global variables, the shared variable that resides in shared memory can be used in all the software modules. This method makes the program very simple. Example programs that use shared variables in **Figure 3** are shown in **Figures 4** and **5**, in which,

**Figure 3.** *Example code of a file defined shared variables.*

**Figure 1.**

**110**

*Example of module.xml.*

*Industrial Robotics - New Paradigms*

**Figures 7** and **8** show examples of sporadic thread and process-related programs

**Figure 6** depicts an algorithm that describes the event handler's operation. It can execute the thread program of **Figure 7** and the process program of **Figure 8**. The event handler first calls the thread's 'condition()' function and if the execution result is true, calls the 'run()' function to handle the event. Then it sends signal to the processes to handle the event occurred. In case of thread, event handling function can be specified separately, but, in this study, 'run()' function is used for simplicity, whose example is shown in **Figure 7**. **Figure 8** shows an example of a process that handles an event. In this example, it utilizes signal because the process cannot be called directly from an event handler. **Figures 7** and **8** also illustrate the

that allow event handling, respectively.

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

*Real-Time Robot Software Platform for Industrial Application*

use of shared variables.

**Figure 6.**

**Figure 7.**

**113**

*Example code of a sporadic thread program handled by an event handler.*

*Algorithm for event handler.*

### **Figure 4.**

*Example program 1 that reads and prints shared variable defined in Figure 3.*

### **Figure 5.**

*Example program 2 to update shared variables defined in Figure 3.*

"#include <indurop/generated.h>" is a header file that should be added when shared variables are used, which is generated from .glb file during preprocessing. Therefore, simply by adding "indurop/generated.h", the variables 'tick' and 'joints [10]' defined in the knuRobot.glb file can be accessed. The INDUROP\_MODULE statement in **Figures 4** and **5** represents information about the module's name, description, author, license, and callback function. The middleware periodically executes the module, where the function to be called is specified as "run = &:: onRun." Furthermore, 'run' is the tag name of the periodically called callback function and "&::onRun" defines the address of the function "void onRun()" presented in each figure. Using INDUROP\_TYPEOF(argument) in **Figure 5**, the same data type as the variable defined in .glb file can be created and used.

The event handler in **Figure 5** is invoked using the basic period in **Figure 2**. In other words, it is invoked after executing periodic modules and before processing the sporadic service. Event handlers can be implemented using sporadic threads or sporadic processes. The algorithm of the event handler is shown in **Figure 6**.

*Real-Time Robot Software Platform for Industrial Application DOI: http://dx.doi.org/10.5772/intechopen.91014*

**Figures 7** and **8** show examples of sporadic thread and process-related programs that allow event handling, respectively.

**Figure 6** depicts an algorithm that describes the event handler's operation. It can execute the thread program of **Figure 7** and the process program of **Figure 8**. The event handler first calls the thread's 'condition()' function and if the execution result is true, calls the 'run()' function to handle the event. Then it sends signal to the processes to handle the event occurred. In case of thread, event handling function can be specified separately, but, in this study, 'run()' function is used for simplicity, whose example is shown in **Figure 7**. **Figure 8** shows an example of a process that handles an event. In this example, it utilizes signal because the process cannot be called directly from an event handler. **Figures 7** and **8** also illustrate the use of shared variables.

### **Figure 6.** *Algorithm for event handler.*

"#include <indurop/generated.h>" is a header file that should be added when shared variables are used, which is generated from .glb file during preprocessing. Therefore, simply by adding "indurop/generated.h", the variables 'tick' and 'joints [10]' defined in the knuRobot.glb file can be accessed. The INDUROP\_MODULE statement in **Figures 4** and **5** represents information about the module's name, description, author, license, and callback function. The middleware periodically executes the module, where the function to be called is specified as "run = &:: onRun." Furthermore, 'run' is the tag name of the periodically called callback function and "&::onRun" defines the address of the function "void onRun()" presented in each figure. Using INDUROP\_TYPEOF(argument) in **Figure 5**, the same data type as the variable defined in .glb file can be created and used.

*Example program 2 to update shared variables defined in Figure 3.*

*Example program 1 that reads and prints shared variable defined in Figure 3.*

**Figure 4.**

*Industrial Robotics - New Paradigms*

**Figure 5.**

**112**

The event handler in **Figure 5** is invoked using the basic period in **Figure 2**. In other words, it is invoked after executing periodic modules and before processing the sporadic service. Event handlers can be implemented using sporadic threads or sporadic processes. The algorithm of the event handler is shown in **Figure 6**.

```
Figure 7.
Example code of a sporadic thread program handled by an event handler.
```

```
Figure 8.
Example code of a sporadic process program handled by an event handler.
```