Development of Embedded Controller Firmware for Explosive Ordnance Disposal Robot Based on RTX51

An EOD robot is a teleoperated ground mobile robot. The main body of the robot is generally composed of a manipulator and a movable platform. It is mainly used to dismantle suspected explosives to reduce casualties at the work site. It is a must-have facility for military and police departments. At present, the Andros series of EOD robots developed by Remotec in the United States and the TRS200 medium-sized EOD robot developed by Cybernetics in France are popular internationally. However, foreign EOD robots are too expensive and are particularly inconvenient to repair after a malfunction. Therefore, the National 863 Expert Group has included the research and development and localization of high-performance EOD robots in the key support topics.

Due to various reasons, many current bomb disposal robots only use PLC to realize inching control, which has limited functions and poor operability. Researching high-performance controllers has become a common topic for various remote-controlled ground mobile robots such as bomb disposal and firefighting. Using advanced embedded system technology can better solve this kind of problem.

This paper summarizes the embedded control system of the new remote-controlled mobile bomb disposal robot PBJ-1 developed by the Robotics Institute of Shanghai Jiao Tong University (as shown in Figure 1), and mainly describes the development of the embedded control system firmware of the bomb disposal robot PBJ-1 based on the RTX51 embedded real-time operating system (RTOS). Using embedded system technology to develop embedded control systems suitable for various remote-controlled ground mobile robots such as bomb disposal can solve the above contradictions.

Figure 1 Teleoperated bomb disposal robot PBJ-1

1PBJ-1 Function Introduction

At present, the more popular bomb disposal robots in the world need to be controlled by specially trained operators through a set of buttons that control the drive motors of each joint on the robot arm, which is very inconvenient to operate. The operator needs to judge the action that the robot needs to perform based on the situation on the scene, and then manually control the sequential actions of each joint of the robot arm after brain conversion, so that the robot claw fits a spatial trajectory to complete the operation, which greatly reduces the work efficiency. This type of bomb disposal robot generally requires a large number of cameras to display the position of the explosive relative to the robot claw at any time, so that the operator can decide the next action.

In order to make the operation more convenient for operators, the new bomb disposal robot PBJ-1 has robot kinematics calculation embedded in the embedded controller, which can realize the autonomous linkage control of the robot arm. The operator only needs to watch the display on the control box and directly operate the controller to command the robot to move forward and backward horizontally or up and down vertically. The robot arm can perform robot kinematics calculation and decompose motion control in real time, and control the robot claw to complete the linear fitting motion in space. This operation method skips the step of the operator's action conversion in the brain, which greatly facilitates the operation of bomb disposal, a high-risk operation site.

In order to facilitate on-site operation, some semi-autonomous motion functions of the robot are also added to its embedded controller system. For example, when the robot completes the operation, the robot arm can automatically fold back to its original position; the robot arm can automatically enter the best operating posture for the operation; when the operation is inappropriate, the controller can automatically cancel the command sent by the operator to avoid interference and collision between the robot arm and the vehicle body, etc.

In order to prevent explosives from being remotely detonated by terrorists, the demolition site of explosives is generally subject to electromagnetic shielding. Wireless remote control robots cannot be used, and only mobile robots with cable remote control can be used. Since the demolition of explosives is very dangerous, the reliability of the wired communication system of the bomb disposal robot is very high. PBJ-1 realizes long-distance, high-speed, and high-reliability communication between each other through the RS-485 protocol.

The operator can monitor the status of the work site through the LCD display in the upper control box; and control the robot to complete various operations by operating various action buttons and joysticks. The control box has six groups of 4-digit LEDs, which respectively display the robot model (PBJ1), communication status (run or Err), joint angles of the upper and lower arms, movement speeds of the robot and the vehicle body, and real-time voltage of the robot power supply. These ensure that the operator can fully understand the specific operating status of the robot and complete the operation smoothly.

Design of 2PBJ-1 Embedded Control System

Since the teleoperated robot works in an unstructured environment, the actual expected motion trajectory is unknown, so it is necessary to dynamically generate real-time target positions and trajectory planning based on the operator's real-time operation and complete the corresponding motion control.

Due to the enhanced functions of this new bomb disposal robot, the lower computer microcontroller needs to complete the robot kinematics and decomposed motion control calculations in real time, and drive various interface devices to control the robot movement in real time. It also needs to ensure the normal communication connection between the upper and lower computers, respond to the processed data of the upper computer in a timely, rapid and highly reliable manner, and upload various status information of the robot body. The burden is very heavy. Therefore, how to reasonably design the system firmware program becomes the key to determining the actual operation effect of the robot.

To achieve the functions described above, the application of the microcontroller must be able to perform multiple tasks or work at the same time. For this, the traditional programming method based on the single-task sequential loop mechanism is not competent, as shown in Figure 2. Therefore, it is necessary to find a new and suitable controller design method. Since the functions of the microcontroller system can usually be decomposed into multiple relatively independent modules, these modules can be understood as tasks, so that a multi-task mechanism can be introduced for management. After the introduction of the multi-task mechanism, the program structure can be effectively improved to meet the complex timing requirements of the application system. Under the multi-task mechanism, the CPU's running time is divided into many small time slices, which are assigned to different tasks according to different priority levels by a certain scheduling algorithm. Multiple tasks access the CPU in their respective time slices, resulting in a multi-task effect of taking turns to run at the micro level and running in parallel at the macro level, as shown in Figure 3.

Fig.2 Program flow of sequential loop mechanismFig.3 Program flow of multi-tasking mechanism

In multi-task embedded systems, reasonable task scheduling is essential. Simply increasing the processor speed cannot achieve the goal, so the embedded system software must have multi-task scheduling capabilities. Therefore, embedded system firmware development must be based on a multi-task real-time operating system.

The primary task of a real-time operating system is to schedule all available resources to complete real-time control tasks; the second is to focus on improving the efficiency of the computer system. Its important feature is to respond correctly to important events within a specified time through task scheduling. A real-time operating system can not only ensure that external information is processed at a sufficiently fast speed, but also run multiple tasks in parallel. It has the characteristics of real-time and parallelism, so it can well complete the real-time measurement and processing of multiple information and perform corresponding multiple real-time controls.

The embedded controllers of PBJ-1 are based on the industry's classic 51 core enhanced single-chip AT89C55WD; the firmware program is developed based on the embedded real-time operating system RTX51Tiny. By providing essential system services such as semaphore management, message queues, delays, etc., the real-time kernel makes the use of CPU more efficient. [page]

2.1 Introduction to RTX51

RTX51 is a powerful real-time operating system developed by Keil in Germany for MCS51 series microcontrollers. It can be used for more than 350 enhanced microcontrollers derived from the Intel 8051 standard core in the world. RTX51 can realize time-slice rotation and preemptive task scheduling, and supports event and signal drive.

RTX51 has two versions: RTX51Full and RTX51Tiny. RTX51Full allows the looping and switching of 4 priority tasks, and can use the interrupt function in parallel. RTX51Full can apply for and release memory from the memory pool, and can force a task to stop executing and wait for an interrupt, or a signal or message from other interrupts. RTX51Tiny is short and powerful, and is a subset of RTX51Full. It only occupies 900 bytes of ROM, 7 bytes of DATA type and 3 times the number of tasks IDATA type RAM space. It can easily run on a single-chip system without extended external memory. Programs using RTX51Tiny can access external memory, allow loop task switching, support signal transmission, and can use interrupt functions in parallel. RTX51Tiny allows "quasi-parallel" execution of several tasks at the same time. Each task is executed within a pre-defined time slice. When the time is up, the task being executed is suspended and another task starts executing. The latest RTX51Tiny2.0 has readjusted the kernel structure, making it more flexible to use, faster to execute, and occupy fewer resources. It also adds several new features.

The RTX51Tiny kernel is fully integrated in the KeilC51 compiler and runs in the form of system function calls, so it is easy to use the KeilC51 language to write and compile a multi-task program and embed it into the actual application system. The kernel mainly provides the following functions for application reference, see Table 1.

Table 1 RTX51Tiny main system function description

The user tasks of RTX51Tiny have several states listed in Table 2, which are switched as shown in Figure 4.

In order to ensure the coordination of tasks in the execution order, a synchronization mechanism must be used. The kernel uses the following events for communication and synchronization between tasks:

(1) SIGNAL: A bit used for communication between tasks. It can be set or cleared by system functions. If a task calls the os_wait function to wait for SIGNAL and SIGNAL is not set, the task is suspended until SIGNAL is set, then it returns to the READY state and can be executed again.

(2)TIMEOUT: The time delay started by the os_wait function, whose duration can be determined by the number of timer ticks. The task that calls the os_wait function with a TIMEOUT value will be suspended until the delay ends, then it will return to the READY state and can be executed again.

(3) INTERVAL: The time interval started by the os_wait function, whose duration can be determined by the number of timer ticks. The task that calls the os_wait function with an INTERVAL value will be suspended until the interval ends, then it will return to the READY state and can be executed again. Unlike TIMEOUT, the task's tick counter is not reset.

RTX51Tiny uses the internal timer T0 of the microcontroller (51) to generate timing beats. Each task is executed only within the number of timing beats (time slices) allocated to it. When the time slice is used up, it switches to the next task to run, so each task is executed concurrently. The RTX51Tiny scheduler defines these tasks to run according to the following rules:

(1) If the following situations occur, the current running task is interrupted:

①The task calls the os_wait function and the specified event does not occur.

②The task running time exceeds the defined time slice rotation timeout.

(2) Start another task if the following occurs:

①No other tasks are running.

②The task to be started is in READY or TIME-OUT status.

Figure 4 RTX51 task switching diagram

2.2 Special Problem Handling of Embedded Operating Systems

There are several noteworthy differences between multi-task programming under RTX51 and traditional sequential loop single-task programming: (1) In multi-task programming, the CPU executes each task in turn. Each task can be designed into an infinite loop mode, which repeatedly performs data calculations or accesses hardware without affecting the execution of other tasks. When the data calculation of a task is completed, the CPU can be handed over to execute other tasks through the os_wait function. However, the single-task mode monopolizes all CPU resources, and one often has to worry about whether the execution time is too long and cannot respond to external asynchronous events in time. (2) Multi-task programming has a disadvantage, namely resource conflict and reentry. The so-called resource conflict means that when task A accesses a certain resource, a task switch happens, and task B also accesses the resource and changes its state. In this way, when task A is executed again, a conflict or uncertainty may occur. The so-called reentry means that if task A is running a certain function, after a task switch occurs, task B also runs the function, which will destroy the scene of task A executing the function, which may cause incorrect results when task A executes the function. This problem is particularly prone to occur in the operation of serial interface devices, such as serial ports, serial A/D, D/A devices, etc.

In the development process of this embedded robot controller, this approach is adopted: the driver segment that operates each independent hardware (such as serial communication) is placed in a task, that is, if you want to operate a certain device resource, you can only rely on executing the corresponding task. In this way, no matter when switching tasks, it will not affect any independent "peripheral". This completely avoids resource conflicts and reentry problems and is conducive to system maintenance and upgrades. To achieve communication between tasks, you can call the os_send_signal function and global variables.

In the development of embedded control systems, the idea of ​​Windows message drive is used to make some tasks that do not need to be executed all the time in a waiting signal state, so that they will not occupy resources. Only when the corresponding processing is required, the task that needs them to run sends them a SIGNAL, and they will enter the RUNNING task queue and be executed. The relevant system functions are:

os_wait(K_SIG,0,0);//Wait for signal

os_send_signal(Task_ID); //Send a signal to the Task_ID task.

Such processing allows the microcontroller to focus on handling time-consuming and important tasks with limited resources.

2.3 EOD Robot Embedded Control System Firmware Development

The firmware structure of the host embedded controller is shown in Figure 5. It is divided into several task slices according to the independence of the tasks to be completed by the controller. Figure 5 shows the relationship between each task and the connection relationship with the peripherals. The entire system is divided into three levels.

Reducing the number and amount of data exchange between the upper and lower computers is conducive to reducing the probability of the lower controller interrupting the robot's motion control and switching to communication protocol processing, which can improve the quality of motion control. Therefore, the firmware program design of the communication part of PBJ-1 does not adopt the traditional method of transmitting the status of the input device to the lower computer at a time, which is a high communication burden, but is based on the idea of ​​message driving. The communication task depends on the result of the input device detection task execution to decide whether to activate and enter the message queue to realize the communication between controllers. In this way, only when the operator actually changes the state of the input device, the upper computer sends the corresponding information to the lower computer. Using the message-driven idea to develop communication programs is very convenient and reliable, and it greatly reduces the burden on the communication line. In order to ensure the high reliability of data transmission, each data exchange is first handshaked to ensure that it is correct.

[page]

The firmware structure of the lower computer embedded controller is shown in Figure 6.

Figure 5 Host computer embedded control system firmware structure

Figure 6 The firmware structure of the embedded control system of the lower computer

Since some tasks do not need to be executed all the time, for example, the robot needs to respond to the instructions of the host computer to complete the switching of the relay, etc., they will also be processed using the os_wait function so that they do not enter the RUNNING task queue at ordinary times to reduce resource waste. In the serial port interrupt of the lower computer, use isr_send_signal to send a signal to the task to activate the task so that the requirement can be executed. The specific calling method is as follows:

isr_send_signal(Task_ID); //Send a signal from an interrupt to the Task_ID task.

Through the Windows message-driven idea and the cooperation of RTX51Tiny real-time operating system, the system resources are reasonably allocated. The lower computer controller "concentrates on" completing the robot kinematics solution and decomposition motion control calculation, which are quite time-consuming tasks, and controls the movement of the robot arm in real time.

Embedding an operating system in microcontroller firmware development also greatly improves system stability. Even if a peripheral or task fails, unrelated tasks are generally not affected, unlike the traditional sequential loop mechanism programming method where a problem in a certain link will immediately cause the entire system to crash.

In fact, the whole system's upper and lower microcontrollers only use AT89C55WD running at 22.1184MHz to achieve the expected goal. The system has shown very high stability and data transmission accuracy in harsh operation tests such as frequent switching of upper and lower power supplies, strong electromagnetic interference, frequent starting of high-power motors, and braking, which cause large fluctuations in system power supply voltage. Even if the whole system fails to communicate during operation (manually cutting off the communication line or part of the power supply), when the fault is eliminated, the upper and lower computers can quickly and automatically restore the normal communication state without malfunction.

The author has developed two controller firmware programs for the new bomb disposal robot PBJ-1, using the same hardware platform. One is based on the traditional sequential loop mechanism, which did not work well at first. Later, the program architecture was improved by borrowing the message-driven idea to meet the requirements. It took a lot of time to debug during the development process. The other is developed based on the RTX51Tiny embedded real-time operating system described in this article. The actual running effect is quite good, but it takes very little time and it is easy to add new functions.

Practice shows that using RTX51Tiny is a good solution in motion control systems with complex systems, strict requirements on real-time performance and accuracy, and many tasks that need to be processed in parallel. In addition, using the RTX51Tiny real-time operating system will speed up the development of embedded control systems, reduce the complexity of software writing, and improve product development efficiency. Maintenance and function expansion are very convenient.

References

1. Wang Tianmiao. Embedded System Design and Case Development[M]. Beijing: Tsinghua University Press, 2003

2 Ma Zhongmei. Single-Chip Microcomputer C Language Application Programming Design (Revised Edition) [M]. Beijing: Beijing University of Aeronautics and Astronautics Press, 1999

3 Liu Tianquan, Huang Hai, Wang Shuqing. Application of RTX51 in motion control system[J]. Mechanical and Electrical Engineering, 2004; 21(1): 30～33

4 Liu Yuhong. Analysis and application of KEILRTX51TINY kernel [J]. Microcontroller and Embedded System Application, 2003;10:23～25

5HorowitzB, LiebmanJ.Platform-basedembeddedsoftwaredesignandsystemintegrationfor

autonomousvehicles[J].ProceedingsoftheIEEE,2003;91(1):198～211

6JaehwanLee,MooneyVJ.A comparison of theRTUhard-wareRTOSwithahardware/software

RTOS[A].DesignAu-tomationConf.ProceedingsoftheASP-DAC[C].AsiaandSouthPacific,

2003:683～688