Bomb disposal robots (EOD robots) are remotely operated ground mobile robots. The main body typically consists of a robotic arm and a movable platform. They are primarily used to dismantle suspected explosive devices, minimizing personnel casualties at the work site, and are essential equipment for military and police departments. Currently, the most popular international EOD robots are the Andros series from Remotec (USA) and the TRS200 medium-sized EOD robot developed by CybernetICs (France). However, foreign EOD robots are too expensive, and maintenance is particularly inconvenient after malfunctions. Therefore, the National 863 Program expert group has included the research and development and localization of high-performance EOD robots as a key supported project. Due to various reasons, many current EOD robots only use PLCs for inching control, resulting in limited functionality and poor operability. Researching high-performance controllers has become a common challenge for various remotely operated ground mobile robots used in bomb disposal, firefighting, and other applications. Utilizing advanced embedded system technology can effectively solve these problems. This article outlines 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). It mainly describes the development of the firmware for the PBJ-1 embedded control system based on the RTX51 embedded real-time operating system (RTOS). Developing an embedded control system suitable for various remote-controlled ground mobile robots, including bomb disposal robots, using embedded system technology can resolve the aforementioned contradictions. [align=center] Figure 1 Remote-operated bomb disposal robot PBJ-1 [/align] 1. Introduction to PBJ-1 Functions Currently, the more popular bomb disposal robots internationally require specially trained operators to control them by operating a set of buttons that individually control the drive motors of each joint on the robotic arm. This is very inconvenient. Operators need to determine the actions the robotic arm needs to perform based on the situation at the scene, then manually control the sequential movements of each joint of the robotic arm after processing the information in their brains. This allows the robotic arm to fit a spatial trajectory to complete the task, greatly reducing work efficiency. These types of bomb disposal robots generally require a large number of cameras to continuously display the position of the explosive relative to the robotic arm, so that operators can decide on the next action. To enhance operator convenience, the new PBJ-1 bomb disposal robot incorporates robot kinematics calculations into its embedded controller, enabling autonomous linkage control of the robotic arm. Operators can directly manipulate the controller by viewing the display on the control box, commanding the robot to move horizontally forward/backward or vertically up/down. The robotic arm performs real-time kinematic calculations and decomposes motion control, guiding the robotic gripper to complete linear fitting movements in space. This operation method eliminates the need for operators to mentally translate actions, greatly facilitating operations at high-risk bomb disposal sites. For further convenience, the embedded controller system also incorporates semi-autonomous robot functions. For example, the robotic arm can automatically fold back into its original position after completing a task; it can automatically enter the optimal operating posture; and the controller can autonomously cancel commands sent by the operator to avoid interference or collisions between the robotic arm and the vehicle body if the operation is inappropriate. To prevent explosives from being remotely detonated by terrorists, electromagnetic shielding is generally required at bomb disposal sites, prohibiting the use of wirelessly remote-controlled robots and necessitating the use of tethered mobile robots. Due to the high risk of explosive ordnance disposal operations, the reliability requirements for the wired communication system of the bomb disposal robot are very high. The PBJ-1 achieves long-distance, high-speed, and highly reliable communication with each other via the RS-485 protocol. Operators can monitor the status of the work site through the LCD display in the upper control box; and control the robot to complete various tasks by operating various action buttons and joysticks. The control box has six sets of 4-digit LED displays, showing the robot model (PBJ1), communication status (run or Err), arm and boom joint angles, robot and vehicle movement speeds, and real-time robot power supply voltage. These ensure that operators can fully understand the robot's specific operating status and successfully complete tasks. 2. PBJ-1 Embedded Control System Design Since the teleoperated robot operates in an unstructured environment, the actual expected motion trajectory is unknown. Therefore, it is necessary to dynamically generate the target position and plan the trajectory based on the operator's real-time operation, and complete the corresponding motion control. Due to the enhanced functionality of this new bomb disposal robot, the lower-level microcontroller needs to perform real-time kinematic and decomposed motion control calculations, drive various interface devices to control the robot's movement in real time, ensure normal communication between the upper and lower-level machines, respond promptly, quickly, and reliably to the processed data from the upper-level machine, and upload various status information of the robot itself—a heavy burden. Therefore, how to rationally design the system firmware program becomes crucial to the robot's actual operational performance. To achieve the aforementioned functions, the microcontroller application must be able to perform multiple tasks or jobs simultaneously. Traditional programming methods based on single-task sequential loop mechanisms are insufficient for this, as shown in Figure 2. Therefore, a new and suitable controller design method is needed. Since the functions of a microcontroller system can usually be decomposed into multiple relatively independent modules, these modules can be understood as tasks, thus allowing for the introduction of a multi-tasking mechanism for management. Introducing a multi-tasking mechanism can effectively improve the program structure and meet the complex timing requirements of the application system. Under the multi-tasking mechanism, the CPU's running time is divided into many small time slices, which are allocated to different tasks according to different priority levels by a scheduling algorithm. Multiple tasks access the CPU within their respective time slices, resulting in a multi-tasking effect that operates in turn on a micro scale and in parallel on a macro scale, as shown in Figure 3. [align=center] [/align] In multi-tasking embedded systems, reasonable task scheduling is essential. Simply increasing processor speed is insufficient; therefore, the embedded system software must possess multi-tasking scheduling capabilities. Thus, embedded system firmware development must be based on a multi-tasking 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; only secondarily does it focus on improving the efficiency of the computer system. Its key characteristic is the ability to respond correctly to important events within a specified timeframe through task scheduling. A real-time operating system can ensure that external information is processed at a sufficiently fast speed and can run multiple tasks in parallel, possessing both real-time and parallel characteristics. Therefore, it can effectively perform real-time measurement, processing, and corresponding real-time control of multiple pieces of information. The PBJ-1 upper and lower computer embedded controllers are based on the industry-classic 51 core enhanced single-chip microcomputer AT89C55WD; firmware is developed based on the embedded real-time operating system RTX51Tiny. By providing essential system services such as semaphore management, message queues, and delays, the real-time kernel makes CPU utilization more efficient. 2.1 Introduction to RTX51 RTX51 is a powerful real-time operating system developed by Keil Systems, Germany, for the MCS51 series of microcontrollers. It is compatible with over 350 enhanced microcontrollers derived from the Intel 8051 standard core worldwide. RTX51 enables time-slice round-robin and preemptive task scheduling, and supports event- and signal-driven operations. There are two versions of RTX51: RTX51Full and RTX51Tiny. RTX51Full allows for the rotation and switching of four priority tasks and can utilize interrupt functionality in parallel. RTX51Full can allocate and release memory from the memory pool, and can force a task to stop execution and wait for an interrupt, or a semaphore or message from another interrupt. RTX51Tiny is a compact and efficient subset of RTX51Full, occupying only 900 bytes of ROM, 7 bytes of DATA type RAM, and three times the number of IDATA type RAM as the number of tasks. It can easily run on microcontroller systems without external memory expansion. Programs using RTX51Tiny can access external memory, allow cyclic task switching, support signal passing, and utilize interrupt functionality in parallel. RTX51Tiny allows "quasi-parallel" execution of several tasks simultaneously. Each task executes within a predefined time slice. When the time slice expires, the currently executing task is suspended, and another task begins execution. The latest RTX51Tiny 2.0 has a redesigned kernel structure, offering greater flexibility, faster execution, and lower resource consumption, along with several new features. The RTX51Tiny kernel is fully integrated into the Keil C51 compiler and runs via system function calls, making it easy to write and compile a multitasking program using the Keil C51 language and embed it into a real-world application system. The kernel primarily provides the following functions for application use, as shown in Table 1. RTX51Tiny user tasks have several states listed in Table 2, which are switched as shown in Figure 4. To ensure coordination in task execution order, a synchronization mechanism must be used. The kernel uses the following events for inter-task communication and synchronization: (1) SIGNAL: A bit used for communication between tasks, which can be set or cleared using 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 returns to the READY state and can be executed again. (2) TIMEOUT: A time delay started by the os_wait function, the duration of which can be determined by the number of timer ticks. A task that calls the os_wait function with a TIMEOUT value will be suspended until the delay ends, then returns to the READY state and can be executed again. (3) INTERVAL: A time interval started by the os_wait function, the duration of which can be determined by the number of timer ticks. A task that calls the os_wait function with an INTERVAL value will be suspended until the interval ends, then returns to the READY state and can be executed again. Unlike TIMEOUT, the task's tick counter is not reset. RTX51Tiny uses the microcontroller's (51) internal timer T0 to generate timing ticks, and each task only executes within its allocated number of timing ticks (time slices). When the time slice is used up, the task switches to the next task, so the tasks are executed concurrently. The RTX51Tiny scheduler defines these tasks to run according to the following rules: (1) The currently running task is interrupted if the following occurs: ① The task calls the os_wait function and the specified event has not occurred. ② The task's running time exceeds the defined time slice round-robin timeout. (2) Another task is started if the following occurs: ① No other tasks are running. ② The task to be started is in the READY or TIME-OUT state. 2.2 Special Issues Handling in Embedded Operating Systems Multitasking in RTX51 differs from traditional sequential single-task programming in several noteworthy ways: (1) In multitasking, the CPU executes each task in turn, allowing each task to be designed as an infinite loop, repeatedly performing data calculations or accessing hardware without affecting the execution of other tasks. Once a task's data calculation is complete, the CPU can be handed over to execute other tasks using the os_wait function. In contrast, single-task mode monopolizes all CPU resources, often raising concerns about whether the execution time is too long to respond promptly to external asynchronous events. (2) Multitasking has a drawback: resource conflicts and reentrancy issues. Resource conflicts occur when task A accesses a resource and a task switch happens, with task B also accessing the resource and changing its state. This can lead to conflicts or uncertainty when task A is executed again. Reentrancy occurs when task A is running a function, and after a task switch, task B also runs the same function, disrupting the execution context of task A and potentially causing 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, and D/A devices. In the development of this embedded robot controller, the following approach is adopted: the driver segment for each independent hardware (e.g., serial communication) is placed in a separate task. That is, to operate on a certain device resource, one must execute the corresponding task. This way, switching tasks will not affect any independent "peripherals." This completely avoids resource conflicts and reentrancy issues and facilitates system maintenance and upgrades. Communication between tasks can be achieved by calling the `os_send_signal` function and global variables. The embedded control system development borrows the Windows message-driven approach, keeping some tasks that do not need to be executed constantly in a waiting signal state, thus preventing them from consuming resources. Only when corresponding processing is required, they are sent a `SIGNAL` signal by the task that needs to run them, and then they enter the `RUNNING` task queue for execution. This approach allows the microcontroller to focus on handling time-consuming and important tasks with limited resources. 2.3 Embedded Control System Firmware Development for Bomb Disposal Robot The firmware structure of the host embedded controller is shown in Figure 5. The system is divided into several task segments based on the independence of the tasks to be completed by the controller. Figure 5 shows the relationship between each task and its connection to peripherals. The entire system is divided into three layers. Reducing the number of data exchanges and the amount of data between the upper and lower control units helps to reduce the probability of the lower control unit interrupting the robot's motion control and switching to communication protocol processing, which can improve the quality of motion control. Therefore, the firmware design of the communication part of PBJ-1 does not adopt the traditional method of periodically transmitting the status of the input device to the lower control unit, which has a high communication burden. Instead, it is based on the message-driven approach. The communication task relies on the input device to detect the result of the task execution to determine whether to activate and enter the message queue to realize communication between controllers. In this way, the upper control unit only sends the corresponding information to the lower control unit when the operator actually changes the status of the input device. Using the message-driven approach to develop the communication program is very convenient and reliable, and greatly reduces the burden on the communication line. In order to ensure high reliability of data transmission, each data exchange first goes through a handshake to ensure that there are no errors. The firmware structure of the lower control embedded controller is shown in Figure 6. [align=center]Figure 5 Firmware Structure of the Upper Computer Embedded Control System Figure 6 Firmware Structure of the Lower Computer Embedded Control System[/align] Since some tasks do not need to be executed continuously, such as the robot needing to respond to instructions from the upper computer to complete relay switching, the os_wait function will be used to handle these tasks, preventing them from entering the RUNNING task queue and reducing resource waste. The isr_send_signal is used in the lower computer's serial port interrupt to send a signal to the task to activate it, ensuring the request is executed. Through the combination of Windows message-driven design and the RTX51 Tiny real-time operating system, system resources are rationally allocated. The lower computer controller "concentrates" on completing time-consuming tasks such as robot kinematics calculation and decomposition motion control operations, controlling the robotic arm's movement in real time. Embedding the operating system in the microcontroller firmware development also greatly improves system stability. Even if a peripheral device or task fails, unrelated tasks are generally not affected, unlike traditional sequential loop programming methods where a problem in one part can immediately cause the entire system to crash. In practice, the entire system's upper and lower computer microcontrollers, operating solely on the AT89C55WD at 22.1184MHz, successfully achieved the expected goals. The system demonstrated exceptionally high stability and data transmission accuracy during rigorous testing, including frequent switching of the upper and lower computer power supplies, exposure to strong electromagnetic interference, frequent starting of high-power motors, and significant voltage fluctuations caused by braking. Even in the event of communication failures (due to manual disconnection of the communication line or partial power supply), the upper and lower computers quickly and automatically restored normal communication without any malfunctions after the fault was resolved. For the new bomb disposal robot PBJ-1, the author developed two sets of controller firmware programs, using the exact same hardware platform. One set was based on a traditional sequential loop mechanism, which initially performed poorly. Later, the program architecture was improved by incorporating message-driven design principles to meet the requirements. Significant time was spent debugging during development. The other set, as described in this paper, was developed based on the RTX51 Tiny embedded real-time operating system. Its actual performance was excellent, requiring significantly less time and allowing for easy addition of new features. Practice has shown that RTX51Tiny is a good solution for motion control systems that are complex, have strict requirements for real-time performance and accuracy, and require a large number of parallel processing tasks. Furthermore, using the RTX51Tiny real-time operating system accelerates the development of embedded control systems, reduces software complexity, and improves product development efficiency. Maintenance and feature expansion are also very convenient.