Abstract: This paper focuses on improving the real-time performance of robot control systems and proposes a real-time robot control system based on RT-Linux. The paper elucidates the idea of ​​dividing robot controller tasks into real-time and non-real-time domains and provides an example of implementing a remote robot real-time control system under the RT-Linux operating system. Finally, the performance test results under RT-Linux and standard Linux are compared. Keywords: Real-time system; RT-Linux; Robot controller; Response time. A real-time system is a computer system capable of performing calculations or processing transactions within a defined time and responding to external events. For industrial robot control, real-time performance is crucial, especially in remote robot control. Failure to adequately meet the system's real-time requirements renders the research meaningless. Currently, many dedicated real-time operating systems exist, but unfortunately, their high cost increases development costs. Beyond considering the performance of the real-time operating system kernel, a comprehensive consideration should be given to the development environment, including development tools, compilers, and debuggers. Especially with the continuous upgrading of applications, real-time operating systems are required to support various network protocols and programming languages; system versatility and portability should also be taken into account. Therefore, the goal was to find a high-performance, low-cost, or even free real-time operating system that was fully functional and highly versatile. The combination of RT-Linux and Linux is a relatively new technology. On the one hand, it provides standard POSIX.1 functionality for non-real-time tasks; on the other hand, it provides highly efficient real-time performance to meet the needs of underlying hardware devices. This implementation method can fully utilize the powerful features of Linux and the real-time performance of RT-Linux. Moreover, RT-Linux is free, completely open-source, reducing development costs and having a wide range of applications. 1. RT-Linux System Architecture The basic idea of ​​RT-Linux is to run Linux under a real-time kernel, as shown in Figure 1. RT-Linux is a loadable kernel module. A small RT-Linux real-time kernel, together with the original Linux kernel, controls the processor. The real-time kernel directly manages hardware interrupts, thus manipulating the machine's response time, and the original Linux cannot affect real-time tasks. Two types of interrupts are designed in RT-Linux. Software interrupts are normal Linux interrupts, while hardware interrupts are true real-time interrupts with almost no execution delay. In implementation, RT-Linux achieves this by designing a simulation software between the Linux kernel and the interrupt handler. Real-time interrupts bypass the interrupt emulator. All hardware interrupts in standard Linux are first captured by the interrupt emulator, so they cannot affect the processing of real-time processes. When the real-time kernel disables interrupts, a flag in the emulator is set to 0. When other non-real-time interrupts occur, the emulator checks that flag; if it's 0, interrupts are not allowed; otherwise, the Linux interrupt handler can be executed immediately. In short, Linux cannot interrupt itself, but RT-Linux can interrupt Linux, achieving the so-called "RT-Linux kernel preemptive mechanism." Communication between real-time tasks and ordinary processes is accomplished through blocking and releasing queues. Specifically, when a real-time task needs to be completed, the real-time operating system runs the task under the real-time kernel; when there are no real-time tasks, the real-time kernel schedules Linux to run. Therefore, Linux is the lowest priority task in the real-time kernel. Currently, RT-Linux uses two scheduling strategies: a priority-based preemptive scheduling algorithm and the EDF (Earliest Deadline First) algorithm implemented by lsmaelRipoll. For periodic tasks, a monotonic scheduling algorithm can be used, where tasks with shorter cycles receive higher priority. The scheduling strategy treats Linux as a real-time task with the lowest priority. Linux only runs when there are no other tasks on the real-time system. The transition between Linux and real-time tasks depends on the aforementioned soft interrupt state. RT-Linux, through this design approach, transforms the standard Linux kernel into a preemptive real-time system with low-latency interrupt handling. 2. Hardware/Software Structure of the Real-Time Robot Control System 2.1 Hardware System Structure The main hardware components of the entire real-time robot control system are: an IBM-PC compatible Pentium III 733MHz industrial control microcomputer (IPC) with 128MB of memory; a three-axis position control card (PCL-832); 10/100M adaptive network card, hub, and other Ethernet connection devices; and the robot body is a 5-DOF Japanese-made PT500 robot. The robot controller runs on an industrial control microcomputer (IPC). Two three-axis position control cards are installed on this IPC. Each three-axis position control card can perform linkage interpolation control on the three axes. Each axis has a dedicated position chip for control, forming a servo position and speed loop. The three-axis position control card continuously issues interrupts with the interpolation time period. We need to write the position information into the buffer of the position control card's motion control chip before the start of the DDA cycle. The pulse count placed in the DDA pulse buffer is transmitted to the DDA generator and output in the next DDA cycle. Then, the three-axis position control card interprets the pulse count corresponding to each axis into corresponding level signals, driving the servo driver to drive the robot's movement. 2.2 Software System Structure The system structure of the entire robot real-time controller is shown in Figure 2. The entire system is divided into two domains: the real-time domain and the non-real-time domain. The real-time domain implements the real-time device driver, responsible for the control and interrupt response of the PCL-832 position control card, driving the robot's movement; the non-real-time domain implements the upper-level robot control interface and remote monitoring subsystem; data exchange between the two is achieved through a real-time first-in-first-out (RT-FIFO) buffer queue. The kernel scheduling strategy treats Linux as the lowest priority real-time task. Non-real-time tasks in Linux only run when there are no other tasks in the real-time system, ensuring the highest real-time priority for real-time tasks. (1) Real-time Modules in RT-Linux The main software module in the real-time domain is the device driver for the three-axis position control card (PCL-832). The driver is a module that can directly access the hardware and has the ability to handle interrupts and read/write ports, which the application does not have. It is the underlying software embedded in the operating system kernel. The three-axis position control card issues DDA interrupt requests in milliseconds. The speed of response to DDA interrupts is the key indicator that determines the real-time performance of the entire robot controller. The real-time device driver we developed is located in the real-time domain of RT-Linux and enjoys the highest real-time priority of the system. It is the premise and foundation of the entire real-time robot control system. The real-time device driver for the three-axis position control card in RT-Linux must handle the following tasks: 1) Respond to the interpolation cycle interrupt (DDA) of the three-axis position card and output the position pulse value; 2) Respond to the error overflow interrupt (Ov) of the three-axis position card and notify the application to perform corresponding processing; 3) Provide services to the application, such as reading and writing I/O ports, setting parameters, reading status, etc. (2) Non-real-time Modules in Linux The software modules in the non-real-time domain consist of the robot controller and the remote monitoring subsystem. The local robot controller interprets text-based robot commands into corresponding position pulse data and sends them to the driver program in the real-time domain via a first-in-first-out (RT-FIFO) buffer queue to drive the robot's movement. The graphical simulation and monitoring system runs on another microcomputer. It receives the real-time robot status from the robot controller or the offline programming and simulation data generator and displays it in real-time using 3D graphical simulation, providing users with intuitive robot operation status information and allowing them to monitor the robot's motion at any time. Authorized users can connect to the offline programming and simulation data generator and the robot controller via high-speed Ethernet, either offline or online, to achieve offline programming and actual robot control. 3. Performance Evaluation of the Real-Time System The performance evaluation of the real-time system mainly focuses on eight aspects: task switching performance, task priority performance, memory allocation performance, internal task communication performance, interrupt latency, operating system runtime efficiency, initialization time, and shutdown time. In robot control, interrupt response time is the most critical factor. For this project, our primary concern is the response time of the RT-Linux system to the DDA interrupt of the three-axis position control card (PCL-832). All our work aims to minimize this interrupt response time. 3.1 Test Environment and Methods: The industrial control microcomputer used for testing was configured with an Intel Pentium (120MHz clock speed) and 64MB RAM; the server software was Red Hat Linux 6.0 (kernel version 2.2.5-15), and RT-Linux version 2.2; the network environment was a 10/100M adaptive network card. The interrupt response time directly reflects the speed of the following process: the user process at the user level writes pulse data to the data buffer queue of the real-time driver located at the kernel level through system calls. When the next DDA interrupt request arrives, the interrupt service routine writes the pulse data in the data buffer queue to the buffer of the motion control chip of the three-axis position control card, driving the robot body to run. Therefore, we take the moment when the user process in the user layer starts calling the system call to send pulse data as the test start time, and the moment when the next DDA interrupt request arrives, the corresponding DDA interrupt service routine writes the data into the buffer of the motion control chip of the three-axis position control card to drive the robot body to run as the test end time. Figure 3 reflects the above process. 3.2 Test results We set four cases with DDA period of 8, 12, 16 and 24ms respectively for testing. After calculation, the results shown in Table 1 can be obtained. Table 1 Test results of DDA interrupt response processing time under low load It can be seen that the measurement time of RT-Linux under low load is about 0.5-0.6ms faster than that of Linux, which proves that the use of RT-Linux system can indeed improve the real-time performance of the system. Here are a few points to note: (1) RT-Linux directly accepts hardware interrupts, so we installed the DDA interrupt and OV interrupt of PCL-832 card in the real domain, so that RT-Linux can capture these two real-time interrupts first and process them. However, the standard Linux uses the concept of soft interrupts, which means that it cannot guarantee that DDA interrupts and OV interrupts will be executed first. Once our robot controller is equipped with a network communication module for monitoring and simulation, DDA interrupts and OV interrupts will be affected by network card interrupts during operation. Therefore, in this case, the advantage of using RT-Linux is evident in order to ensure the real-time performance of the robot's movement. If tested with network card intervention, the interrupt handling time under standard Linux will be longer than that under RT-Linux. (2) If a large number of user processes are opened in the user application layer, it will be greatly affected for time-sharing standard Linux. However, for RT-Linux, real-time processes will not be affected by user processes in non-real-time domains. Therefore, under such heavy load conditions, the real-time performance of RT-Linux is higher than that under standard Linux. The test results show that the interrupt response time of the RT-Linux system is shorter than that of standard Linux. This result also indicates that the real-time performance advantage of the RT-Linux system will be more obvious under high system load conditions. When using the real-time robot controller in practice, the robot runs very stably and can meet the needs of real-time control. 4. Conclusion In the design of robot controllers, maximizing the real-time performance of robot control is a key issue. This paper proposes and implements a real-time robot control system combining RT-Linux and Linux, using the idea of ​​dividing software tasks into real-time and non-real-time domains. The advantages of this system are: on the one hand, it provides highly efficient real-time performance to meet the needs of the underlying hardware devices; on the other hand, it fully utilizes the powerful functions of Linux. Moreover, RT-Linux is completely open-source and free software, reducing development costs. Therefore, this technology has a very broad prospect for industrialization. References: 1. Rubini A. Linux Device Drivers. O'Reil & Associates, 1998 2. Maxwell S. Linux Kernel Source Code Analysis. Beijing: Machinery Industry Press, 2000.06 3. Yodaiken V. Barabanov M. RT. Linux Version Two. WWW.thinkingnerds.com/fsmlabs/archive/design.pdf, 1999-11 4. Li Kaisheng, Zhang Huihui, Fei Renyuan et al. Current Status and Development of Robot Controller Architecture Research. Robotics, 2000, 22(3) 5 Mao Yugang, Jin Shirao, Zhang Yongjun, et al. Research on the predictability of distributed strong real-time systems. Computer Research and Development, 2000, 37(6) Click to download: Research on the real-time performance of robot control systems