Industrial Robot Controller Research

Research on Industrial Robot Controllers

Just as the brain is to humans, the controller is also the most important component of a robot, defining its functions and behaviors. Many scholars have studied it or proposed design schemes[ 1 , 2 , 3 ] ^{[1,2,3]}[1,2,3], but there has been little discussion on the overall architecture and specific implementation of controllers, which is severely disconnected from the front line of industrial production and has long been outdated. This article compares the controller schemes of two types of industrial robots: robotic arms and mobile robots, analyzes their functional requirements and characteristics, and explores implementation schemes for open controllers.

　 Robotic Arm Controller　　　　Mobile Robot Controller

The above classification is based on the type of robot. Currently, more controller products on the market are general motion controllers or motion control cards, which control the movement of various non-standard equipment, such as CNC machine tools, laser cutting machines, and other automated devices. Of course, these products can also be repurposed for controlling robots through secondary development.

General Motion Controller Products

1　Software and Hardware Solutions

We first examine the software and hardware solutions of common industrial robot controllers.

1.1　Robotic Arm

Robotic arm controllers have developed earlier, and the products are relatively mature. Their implementation schemes are shown in the table below. Most international leading brands use X86 chips and construct the underlying software with real-time operating systems.

Manufacturer	Hardware	Operating System
ABB	x86	VxWorks
KUKA	x86	VxWorks + Windows (VxWin)
KEBA	x86	VxWorks
B&R	x86	Windows 10/B&R Linux 9
Goko	x86	Windows CE
MUJIN	x86	–
Navbot	x86	VxWorks or Linux (PREEMPT_RT) or SylixOS

1.2　Mobile Robot

The controllers for mobile robots belong to a newer direction, including AGVs, drones, and construction machinery. The recently popular autonomous driving can also be regarded as a type of mobile robot. The underlying schemes of their control systems are shown in the table below.

Manufacturer	Hardware	Operating System	Software	External Interface
Hesmor	Infineon XC167	None	CoDeSys	CAN
Hirschmann	PowerPC	None	CoDeSys	CAN
EPEC	Infineon C166	None	CoDeSys	CAN
NDC	ARM Cortex-A8	Linux	–	Built-in Gyroscope, CAN, WLAN, 485
IFM	Infineon TriCore 1796	None	CoDeSys	CAN

1.3　Comparison

The functional requirements for robotic arms are numerous, with high degrees of freedom, and the demands for motion accuracy and response speed are significantly higher, typically one to two orders of magnitude greater than those of mobile robots. As a result, the computational load and cycle time for the controller are large and short, respectively; mobile robots generally have lower response speed requirements and simpler functions, leading to lower configurations. Additionally, mobile robots typically use battery power, with built-in controllers, thus requiring considerations for power consumption and heat dissipation, which often use embedded chips. Robotic arms usually operate in fixed areas, so their controllers are typically housed in cabinets with lower protection levels, generally IP20; mobile robots, which frequently move, especially outdoor construction machinery, need to consider waterproofing and dustproofing, resulting in higher protection levels, generally IP65.

Robotic Arm	Mobile Robot
Control Accuracy	0.01~0.5mm	1~20mm
Control Cycle	100us~10ms	10ms~100ms
Interpolation	Required	Not Required
Trajectory Planning	Required	Not Required
Logical Control	Required	Required

2　Commercial Controllers

Introducing several representative commercial controller solutions.

2.1　CoDeSys

Many robot control software solutions are implemented using CoDeSys. So, what is CoDeSys? CoDeSys is a paid soft PLC development software launched by the German company 3S. In simple terms, it consists of two parts: the Development System and the Runtime System. The Development System is the programming software interface (similar to Visual Studio, Eclipse, etc., also referred to as IDE) where PLC programs are designed, debugged, and compiled. Once the program is written, it must be transferred to the hardware device for execution. However, the generated PLC program cannot run by itself; it must operate within a specific software environment, which is the Runtime System (also known as the runtime kernel), and this part is not visible to the user. The two are usually installed in different locations; the IDE is generally installed on the user’s development computer, while the Runtime System is located on the hardware device that controls the operation, with programs downloaded to the Runtime for execution via an Ethernet or serial connection.

CoDeSys is widely used in the industrial control field, and many of the robot companies mentioned above use its products, such as KEBA, Beckhoff, Goko, Delta, Guangzhou Qifan Robotics, and New Times Robotics. The 3S company only sells the underlying software and does not sell hardware or upper-level application programs; the application programs and hardware circuits need to be designed by the user, while the 3S company is responsible for porting the Runtime System to the customer’s hardware. The Runtime System can run directly on hardware, but it is generally run on an operating system, and configuring the operating system is also the customer’s responsibility. If required by the customer, the CoDeSys IDE can be customized to replace the customer’s logo and appearance, which is why you may find that different manufacturers’ development platforms look different, yet their styles are quite similar. Of course, users can also use other IDEs; for instance, Beckhoff uses Visual Studio, while the underlying compiler and kernel functions still use CoDeSys solutions. CoDeSys Runtime has strong adaptability, supporting the vast majority of operating systems and chip types.

The IDE part of CoDeSys is free, and you can download it from the official website to experience it. The actual charge is for the Runtime System and a series of communication and motion control components.

CoDeSys is developed using .Net technology, and at the beginning of its design, its functions were divided into several component modules, such as bus protocol stacks, visual interfaces, motion control, safety control, etc. Users can select the necessary modules to build their systems like building blocks, ultimately forming a customized control software platform. Some first-time users of soft PLC may find this design approach unfamiliar, but it is actually quite common. For example, the real-time toolbox of MATLAB Simulink works in this way; users design control programs through drag-and-drop in Simulink’s graphical interface and then download them to real hardware. You can learn more about it here. Similarly, Beckhoff uses this approach, where users program in the TwinCAT IDE and then download to Beckhoff’s controllers, which already have a Runtime pre-installed. Siemens’ STEP7 is also an IDE, and its PLC also has a complementary Runtime. However, Siemens (including Japanese PLCs) has a closed and secretive system, and outsiders do not know its system architecture. The PLC programs written by users are like application programs on our computers; they run on the Runtime System, which in turn runs on the operating system. Since the Runtime System is located between the application program and the operating system, it is also referred to as middleware. In simple terms, you can think of middleware as a software system composed of driver programs, basic function libraries, and other modules. Because these program modules mainly interact with hardware or lower-level software and are of little concern to users, they are organized into a separate block. These software present users with function call interfaces, meaning you only need to know how to use them without worrying about the specific implementation, as these are the tasks of driver engineers and algorithm engineers. Of course, most of the time, you cannot see the specific implementation of this part, as they are provided to you in the form of compiled binary files, which cannot be read. You may at most see some header files, which only contain function and variable definitions without much useful content. In robot software, ROS, OROCOS, and others hold a similar position.

Robot control, like CNC machine tools, requires real-time performance, so the operating system we choose should ideally be a real-time operating system (RTOS). Unfortunately, the operating systems we often use are not real-time, such as Windows and Linux. There are two implementation methods for real-time operating systems: 1. Abandon the general-purpose operating system and start from the bottom up. Representative examples include VxWorks, QNX, WinCE, μC/OS, LynxOS, etc. The downside of this approach is that all tasks are real-time, even if the tasks themselves do not require real-time performance, such as network access and file system access, so you have to specially develop application programs suitable for this type of operating system, which can be quite a workload. VxWorks is widely used in military and industrial applications, such as in fighter jets and rockets. VxWorks has left a gap in the automotive field, which is now occupied by QNX. 2. Patch the general-purpose operating system (add extensions) to make it real-time. Representative examples include Windows RTX, Xenomai, RT Linux, RTAI. The downside of this approach is that the support (resources) for real-time tasks is not as extensive as in the first method. Considering that Windows and Linux are widely used, CoDeSys has introduced corresponding real-time patches (RTE) to relieve users of the hassle of modifications. To learn more about CoDeSys Runtime, you can read the official documentation[ 1 ] [ 2 ] [1][2][1][2]. CoDeSys runtime, if not installed on top of an operating system, requires its own simple scheduler. CoDeSys comes with a simple scheduler that has two types[ 5 ] ^{[5]}[5]: 1. Embedded Scheduler, which is a simple polling mechanism where one task cannot run until another task has finished; tasks cannot preempt each other, and this method is not real-time; 2. Timer Scheduler, which assigns a timer to each task for periodic triggering. CoDeSys has made it convenient for robot manufacturers to develop controllers, but relying on commercial software like CoDeSys to build one’s own controller products also has many drawbacks: 1. The underlying algorithms are not disclosed. The motion control components and bus protocol stacks integrated into CoDeSys are packaged, and users cannot understand the internal details or customize and optimize them for their specific needs; they can only make simple calls. Users can only rely on the CoDeSys platform, making it difficult to form their own technology. 2. Limited functionality and difficult to expand. New technologies represented by machine vision, artificial intelligence, and autonomous driving are advancing rapidly, while many technologies in industrial control remain stagnant at 20 years ago. For example, in the navigation scenarios of mobile robots, vision-based or laser-based navigation methods require collecting and processing a large amount of data, involving considerable matrix calculations. Currently, PLCs can only perform outdated one-dimensional numerical calculations, making it difficult to implement complex algorithms. Contrary to the open-source style favored in the artificial intelligence community, the industrial control circle is relatively closed, with each unwilling to open their own function libraries, and there are very few open-source function libraries. Even the most basic filtering algorithms and matrix calculations have to be written from scratch. Moreover, the standard functions provided by the international standard IEC are too limited to adapt to new scenarios, requiring urgent expansion. 3. High costs and difficult updates. Commercial soft PLCs can cost tens of thousands, not including various bus communication libraries, motion control libraries, and visualization libraries, which must be purchased separately and require a commission from sold products, making costs difficult for small teams to accept. Since they rely entirely on CoDeSys, upgrading or replacing the hardware of their products requires custom porting, leading to increased costs. This reminds the author of how Microsoft gradually killed its operating system Windows Phone for mobile devices; a key factor was charging high licensing fees to phone manufacturers, possibly due to Microsoft being accustomed to being the dominant player, and even more shamelessly creating barriers for users, making it impossible to upgrade the same phone system consecutively.

GEB Automation has also launched a soft PLC similar to CoDeSys, supporting programming, debugging, and simulation, aimed at OEM products priced at $9,500. The advantage over CoDeSys is that it is a one-time payment without additional per-unit royalties, and it can be ported to commonly used hardware platforms, with its IDE developed based on Eclipse.

2.2　Phoenix PLCnext

In 2019, Phoenix launched a new generation PLC, known as PLCnext technology. PLCnext uses general soft and hardware, such as ARM processors and RTLinux operating systems, so it can also be viewed as a soft PLC installed on a standard hardware platform, while PLCnext still uses KW’s soft runtime kernel in the middle layer. PLCnext supports programming languages like C/C++, IEC 61131-3 standard PLC languages, and Matlab, providing convenience for different users developing projects. The underlying layer of PLCnext is a real-time operating system RTLinux, which allows customers to run their non-real-time applications and provides data access interfaces for non-real-time applications to PLC real-time programs. Open PLCs are the trend of the future, and PLCnext aligns with this trend, whereas if you use Siemens’ PLC, there is no way to make any extensions.

The core technology of PLCnext is reflected in two aspects: the Task Execution Manager (ESM) and the Global Data Manager (GDS). Phoenix has applied for patents for ESM and GDS. The Task Execution Manager ensures that tasks of different priorities run in the correct priority and timing order and guarantees data consistency when low-priority tasks are preempted. The following is a simple example where there are two tasks (the top row is Task 1 and the bottom row is Task 2); Task 1 runs every 5ms and has a higher priority than Task 2, so it will preempt Task 2 during its execution.

The Global Data Manager is responsible for communication between tasks, which is the interaction data. In addition to communication between tasks, each task may have function modules written in different languages that also require interaction data. The Global Data Manager ensures the consistency of all data during the exchange process. In the example above, when Task 2 resumes after being preempted, the data should be the same as before it was preempted (i.e., the variables 5 and 8 indicated by the green arrows); if they are different, it will result in what is known as “data inconsistency,” which is generally not allowed in real-time systems. The role of the Global Data Manager is to ensure the consistency of data exchange.

2.3　KEBA

KEBA is an Austrian manufacturer of robot controllers, and its programming and control software is entirely built on the CoDeSys soft PLC. CoDeSys provides KEBA with basic editing, compiling, debugging, and other functions. However, CoDeSys itself has very few functions related to robots, so the functions and libraries involved in robots are developed by KEBA and called in the form of libraries in CoDeSys. To ensure real-time performance, the CoDeSys Runtime in the controller is installed on top of VxWorks.

2.4　KUKA

KUKA’s new generation controller is called KR C4, which also adopts a soft PLC scheme. This scheme is provided by KW[ 4 ] ^{[4]}[4], and the soft PLC consists of an IDE part (called Multiprog) and a Runtime (called ProConOS). ProConOS is developed in C#. The ProConOS Runtime also runs on VxWorks, and they are installed in the controller hardware, which uses an Intel dual-core CPU.

2.5　Omron

Omron has launched a “Robot Integrated Controller” – NJ501-R, which integrates PLC, motion, and robot control into a single controller. The programming languages for PLC and robots are unified in the general IEC language, allowing engineers who usually manage PLCs to also manage robots. PLC and NC programs run on the same machine, enabling multiple tasks to synchronize.

2.6　Baidu Autonomous Driving Computing Platform

Baidu’s Apollo autonomous vehicle project has launched a dedicated computing platform for autonomous driving – ACU (Apollo Computing Unit). The principles and implementations of ACU were introduced in the live broadcast “Baidu ACU Soft and Hardware Optimization Experience Sharing.” ACU uses the Xilinx ZU5 chip, which is a heterogeneous multi-core SoC processor that integrates a CPU (ARM V8 core), FPGA, DDR memory (2GB), and a small GPU.

Development engineers believe that computing power is not strictly proportional to frame rate; for example, commonly used chips have computing power in the TFLOPS range, while memory bandwidth is in the GFLOPS range. This means that computing power is 1000 times the memory reading speed, and simply increasing computing power can no longer improve computing speed because memory becomes the bottleneck. The choice of this chip is related to the specific computational tasks executed in autonomous driving. Autonomous driving involves various computational tasks, with the most significant being artificial intelligence algorithms, specifically deep learning. The computational requirements for deep learning are more than ten times that of other tasks, so strong computing hardware support is essential. FPGAs are the most powerful for executing compute-intensive tasks, making them very suitable for tasks like deep learning. Although the computational load of deep learning accounts for the vast majority of overall tasks, there are still many other tasks in autonomous driving, such as image processing and SLAM, that may not require significant computation but have non-negligible computation times, which need to be handled by the CPU. Baidu has optimized the underlying calculations for deep learning, such as using 8-bit INT data types to reduce computational load (while not reducing accuracy), merging commonly used “multiple operator combinations” into one, using Average pooling instead of Max pooling, and implementing zero-copy with shared memory.

3　Open Source Control Software

Currently, there are some open-source control system solutions, such as ROS, Orocos, OpenRTM, Beremiz, OpenPLC, XBotCore, ArmarX, ORCA, AMiRo-OS. PLCopen defines some standards for servo and motion control, including programming languages, basic function blocks (Function Block), parameters for input and output interfaces, etc.[ 3 ] ^{[3]}[3], but does not provide specific implementation code details, which are provided by various manufacturers.

3.1　ROS

The predecessor of ROS can be traced back to the work of Stanford University PhD students Eric Berger and Keenan Wyrobek in 2007, mainly developed in C++. Although the name ROS sounds like a robot operating system, it is not. ROS is a middleware that is installed on top of a real computer operating system. Initially, ROS resembled a mishmash, including some components for communication, visualization and simulation components, and coordinate management components. Many people describe ROS as a software framework, but I try to avoid using these abstract and intimidating terms, as most people are not familiar with robot software systems, which can make confused readers even more bewildered. The features provided by ROS include: 1. Node definitions and communication methods between nodes: a node is an application program template where users add their algorithm code, leaving the rest to ROS; 2. Basic tools: commonly used function libraries for robots (motion planning, SLAM, inverse kinematics), visualization tools, data logging, and other commonly used features for robot development; 3. Device drivers: users no longer need to develop from scratch when they receive hardware, saving time. ROS is not widely used in industry, which is not surprising because it was designed with more focus on generality and code reuse, rather than reliability and real-time performance. Initially, Baidu used ROS as a platform for its autonomous vehicles, possibly considering rapid validation of autonomous driving algorithms. However, they later realized some issues with ROS and attempted to modify it. Ultimately, they abandoned it and chose to rebuild a software system – Apollo Cyber RT. ROS has become unexpectedly popular today, which the designers did not anticipate; they never thought it would be used in various types of robots. Some people in China also plan to design their own robot software systems, such as micROS from Shanghai Jiao Tong University and the Chinese Academy of Sciences.

3.2　Orocos

Orocos is an open-source robot control program development software developed by Herman Bruyninckx and his PhD student Peter Soetens from KU Leuven in Belgium, programmed in C++. The introduction documents for Orocos are more software development-oriented, making it difficult for non-programmers to understand. Orocos has a position similar to ROS, but it is focused on control and is located on top of a real-time operating system, providing basic functions such as a toolchain (compiler) for generating real-time control programs, component templates, and basic functions commonly used in robots. Orocos solves basic functionalities such as module functionality and interface definitions, and real-time communication between modules for users, allowing them to develop and deploy their application software more quickly. Orocos focuses on both upper-level applications and lower-level control layers. Compared to ROS, Orocos considered real-time performance from the outset. In Peter Soetens’ doctoral thesis[ 4 ] ^{[4]}[4], a significant portion discusses real-time performance. Orocos directly uses the task scheduling module of the underlying operating system (e.g., Xenomai), so Orocos must be installed on a real-time operating system to ensure real-time performance.

3.3　Beremiz

Beremiz is a free, open-source soft PLC control system developed by Edouard Tisserant from France[ 4 ] ^{[4]}[4]. Dissatisfied with the strict barriers of traditional PLCs, Tisserant advocated for the open-source project Beremiz, and he is also the author of CANfestival.

The Beremiz project began in 2005, initially as just an editor, and gradually added other functions to form a complete soft PLC development environment. Its functional characteristics are as follows: 1. Supports multiple tasks, where different priorities can be configured, and the task running mode can be periodic or triggered by interrupts; 2. Supports five standard PLC programming languages, including ST and ladder diagrams; 3. Provides basic functions specified by IEC 61131-3 standard (timers, comparisons, mathematical operations, type conversions, bit operations, strings, and hundreds of other functions); 4. Extensible Modbus, CANopen, EtherCAT bus communication modules (to be ported to the selected platform); 5. Supports C and Python languages, allowing users to call C programs or Python programs in the PLC, or call C programs from Python; 6. Supports simulation but does not support online debugging; 7. Has a visual interface (HMI), where variable values can be intuitively displayed as charts. The working method of Beremiz is as follows: users write application programs using PLC languages, regardless of whether they use ST language, ladder diagrams, or other PLC languages, Beremiz translates them into C language, which is done by the MatIEC component. Subsequently, the gcc compiler links the generated C programs with bus communication programs to obtain binary target files (so files on Linux, dll files on Windows). After that, the binary target files are downloaded to the target device, which has a runtime pre-installed, and the runtime calls the target files to complete the corresponding control functions[ 6 , 7 , 8 , 9 ] ^{[6,7,8,9]}[6,7,8,9].

The development languages for both the IDE and runtime components of Beremiz are Python. As long as the operating system can run Python, Beremiz can run on various operating systems, including Windows, Linux, and Mac OS, as long as there is an operating system. The task scheduling of Beremiz entirely relies on the operating system, meaning its real-time performance is greatly affected by the operating system, so it is best to choose a real-time operating system, such as Xenomai or WinCE. The choice of Python for development is due to its simplicity and ease of use, but Python is rarely used in industrial control because it cannot provide real-time performance (affected by memory allocation and other factors). Nevertheless, [ 10 ] {[10]}[10] analyzed the real-time performance of Beremiz runtime and compared it with CoDeSys runtime, with results indicating that Beremiz’s real-time performance is even superior to that of CoDeSys. This may be due to the core program being translated into C code, while the Python-written runtime is only responsible for calling. This article compares the performance of C and Python calling C, showing that the performance gap is not particularly significant. There is little introductory material on Beremiz, and part of it is written in Russian and French, lacking in-depth literature discussing its internal principles.

3.4　OpenPLC

OpenPLC is a free open-source soft PLC software system derived from the Beremiz project, developed by Thiago Rodrigues Alves, a PhD student at the University of Alabama in the United States[ 13 ] ^{[13]}[13].

3.5　Comparison

Most software delegates task scheduling to the operating system, which brings about a problem: for general-purpose operating systems, each process is generally independent of one another, whereas for robotic applications, tasks are often interdependent, causing the operating system’s scheduler to be unsuitable for scheduling tasks with dependencies.

4　Controller Development

Developing robot controllers involves many specialties and requires a team to complete. A PhD in robotics who is proficient in control algorithms may know little about software development, feeling overwhelmed by terms like processes, task scheduling, and mutex; a trained software engineer may be completely baffled by concepts like homogeneous transformation matrices and quaternions; in addition, the project also needs drive engineers, hardware engineers, and engineers familiar with bus communication and processes. If you want to find employees with solid business capabilities, you have to bear high costs, and it is difficult to retain these professionals without attractive salaries. Moreover, the education of robotics in China is still relatively backward, making it not easy to find employees with solid professional skills. The author wrote this article to promote basic knowledge and flatten the mountain of knowledge asymmetry.

4.1　Choosing Controller Solutions

Single processor or multi-processor? In the early days, CPUs had weak computing capabilities, and to improve running speed, multi-CPU solutions were often adopted, where some computationally intensive tasks were isolated to occupy a single CPU. A representative example is various control board solutions, such as PMAC and Goko. Goko’s GUC-ECAT controller separately designed a DSP and an FPGA to perform interpolation and trajectory planning tasks, while another CPU generally executes non-real-time tasks like human-machine interaction and programming development. If you open Goko’s robot controller, you will find it has two computing cores (Intel CPU and DSP/FPGA), similar to how gaming computers have dedicated graphics cards. Of course, having an additional core is never a disadvantage; for example, NI’s robot controller roboRIO has both an ARM core and an FPGA, which can be imagined to result in faster data acquisition. It is no wonder it is used in scenarios where control cycles and sampling rates are critical, such as MIT’s quadruped robot (which uses cRIO-9082).

With the increasing number of CPU cores and improved computing capabilities, the performance of single CPUs has become stronger, so a robot controller is now sufficient to use a single CPU, running all real-time and non-real-time tasks on this one CPU, with the operating system performing the scheduling. Should we use an operating system or run bare-metal? It is generally believed that operating systems introduce additional overhead, as context switching takes time, but advances in semiconductor technology and software technology have made this difference very small. Running programs bare-metal on hardware is suitable for relatively simple applications with uncomplicated logic, but its drawbacks are also evident; if the hardware platform is upgraded or changed, the program must be rewritten. Therefore, modern robots (especially robotic arms and autonomous vehicles) controllers invariably use operating systems.

Should we use semi-finished software or soft PLC? ROS and OROCOS are semi-finished products that are more suitable for academic research, requiring users to be familiar with the entire system to use them, and have high programming capability requirements. They are generally used in stages where products have not yet been finalized or when users do not need to frequently change application tasks. For example, autonomous driving can use them because the overall business logic and tasks of autonomous driving do not change significantly. Just like in the mobile phone or automotive industries, manufacturers do not sell circuit boards or chassis directly to customers because customers cannot use them. Products aimed at end customers must consider the usability of the product itself and the capabilities of customers. Therefore, if your product is aimed at end customers without development capabilities, it must have a standardized and user-friendly programming interface and a simple and efficient programming language, which ROS or OROCOS lacks.

Soft PLCs come with IDEs, allowing users to intuitively write their application programs directly in the IDE. If the built-in functions are insufficient, users can implement their functions at a lower level. This leads to higher development efficiency and more user-friendly usage. Therefore, modern robot controllers tend to adopt soft PLC implementation methods. The author’s first exposure to robot controllers after graduating from graduate school, regardless of how they looked or operated, resembled PLCs, which frustrated him. Because PLCs are considered low-level devices, and their programming languages are ladder diagrams, which look like elementary school competitions, and apart from some basic functions, they lack anything else, making tasks like matrix calculations impossible. Yes, PLC programming is simple and robust, which is its design purpose, but robots are becoming increasingly complex, with more functions being added, such as machine vision, autonomous navigation, motion planning, and multi-axis motion control, which require controllers to provide stronger support, not just low-end logic control or simple numerical calculations. Therefore, traditional hard PLCs should be eliminated for robot control.

The control software we need should be open enough to allow users to adjust program structures and add new functions at any time, while also providing sufficient basic functions at the lower level, such as linear algebra, mathematical optimization, interpolation fitting, equation solving, and even image processing and motion control. In terms of usage, to accommodate customers (we cannot require all customers to develop advanced functions by themselves), it should still be simple and good, ideally not much different from PLC usage.

4.2　Real-Time Performance

Developing robot controllers is a demanding task that requires clear performance requirements, with real-time performance being the foremost. If you ask what the essential difference is between PLCs or robot controllers and ordinary computers, how would you answer? Is it that PLCs are more stable, or that they have stronger anti-interference capabilities, or perhaps richer interfaces, or that their programming languages are more suitable for industrial control? I believe none of these are the true essential differences; the real essential difference is that PLCs are real-time, whereas ordinary computers are not. The information processing capability of home computers can easily surpass that of PLCs (consider the computational load of playing large games or watching high-definition videos), so why are “backward” PLCs still used in industry? The answer is real-time performance, which is essential for industrial robots (whereas service robots may not require it as strictly). It is easy for most people to mistakenly equate “real-time performance” with fast computation speed or short response delays, but in fact, “real-time performance” indicates temporal “determinism.” For example, in a real-time operating system (RTOS), the interrupt response or process switching delay must occur within a certain time frame. Common operating systems (Windows, Linux) are not real-time operating systems because their design goals are high throughput and cannot guarantee that every event is processed within a certain time frame. For instance, standard Ethernet transmission speeds are much faster than real-time industrial Ethernet (such as EtherCAT), but standard Ethernet is not real-time because it cannot guarantee that data is transmitted within a defined time. All the above are qualitative descriptions; can we quantify it? Of course, determinism must have specific metrics; analyzing real-time performance without specific numbers is meaningless. If we define the response time as one hour, then even an operating system like Windows is real-time because its response, no matter how slow, will not take an hour. In many industrial scenarios, one hour is obviously too exaggerated; we must at least narrow it down to the 10ms range, where a control or interpolation cycle execution time cannot exceed 1ms; thus, Windows systems will certainly not meet the requirements. Recently, the hotly debated 5G communication technology can control latency within about 1ms, and although it is not real-time, its speed is sufficient to replace wired communication in industrial control, which explains why 5G is so popular.

Understanding real-time performance is not too difficult, but what factors influence it? This area of discussion involves operating system principles, and major robot manufacturers will certainly not disclose their testing and experimental results. The main metrics for evaluating real-time performance are latency and jitter, with jitter being greatly influenced by the operating system’s scheduling algorithm. Other factors, such as system load, also have an impact, with scheduling algorithm effects generally in the tens of microseconds. The impact of jitter on robot performance is difficult to quantify due to the complexity of intermediate links (the lower servo closed loop).

Another major factor influencing real-time performance is memory allocation. Dynamic memory allocation takes an uncertain amount of time, which is why many real-time systems avoid using dynamic memory. Here are two examples: 1. PLCs do not provide dynamic arrays, only fixed-length arrays, meaning that the array length must be allocated beforehand. This is clearly inconvenient; for example, when we pass an array during a function call, we may not want to consider the array size in advance. As a result, we have to calculate the array length to be passed each time or set a relatively large array, which obviously leads to space wastage. 2. If you have ever written S functions or user-defined functions in MATLAB Simulink, you will find that in S functions, you must define or allocate space for variables before using them, unlike in m files where you can assign values without prior definition (you can check the MATLAB-provided example: Integrate MATLAB Algorithm in Model). Since modules in Simulink can generate C language and export to hardware for direct execution, this implies a requirement for real-time performance. Some PLCs, such as those mentioned earlier from Phoenix and Beckhoff, support directly generating control programs from Simulink simulation models without needing to reprogram. It’s no wonder that we often feel that writing S functions in Simulink is not as free and easy as programming in MATLAB.

4.3　High-Precision Timers

We often mention “real-time”; real-time requires high-precision time standards, so who provides this high-precision time? The answer is clock cycles, which are the heartbeat (or pulse) of real-time operating systems. Periodic data collection, task timing switching, and delayed output require real-time operating systems to have a stable clock cycle as the time standard for the entire system. What is a clock cycle? A clock cycle relies on a timer, which is essentially a counter. The timer starts with a pre-stored value, and each time hardware (such as a crystal oscillator) generates a pulse, this value is decremented by one. When it reaches zero, it resets to the initial value and generates an interrupt; this specific periodic interrupt is called a “clock cycle” (Tick, sometimes referred to as “clock tick,” “heartbeat,” or “tick”). For example, if the frequency of the crystal oscillator is 72MHz, then the clock period (Clock Period) is 1/72M; if the pre-stored value is 72000, then the clock tick is 1/72M × imes× 72000= 0.001s, meaning that one interrupt is generated every 1ms, and at this point, the controller cannot discern time intervals shorter than 1ms.

5　References　　[1]　Current Status and Prospects of Robot Controllers, Fan Yong, Tan Min, Robotics, 1999.[2]　Overview of Open Robot Controllers, Sun Bin, Yang Ruqing, Robotics, 2001.[3]　Robotics Middleware: A Comprehensive Literature Survey and Attribute-Based Bibliography, Ayssam Elkady, Journal of Robotics, 2012.https://zhuanlan.zhihu.com/p/28052497[4]　CODESYS Control V3 Manual, Document Version 19.0.[5]　CODESYS Control V3 Migration and Adaptation, Document Version 4.0.[6]　Robots Count on Software, KW-Software.[6]　https://www.plcopen.org/technical-activities/motion-control[7]　A Software Framework for Real-Time and Distributed Robot and Machine Control, Peter Soetens, Ph.D. thesis, 2016.[8]　An Open Source IEC 61131-3 Integrated Development Environment, Edouard Tisserant, IEEE, 2007.[9]　OPC UA support for Beremiz softPLC, Martim Afonso, 2018.[10]　An Open-source Development Environment for Industrial Automation with EtherCAT and PLCopen Motion Control, I. Kim, IEEE ETFA, 2013.[11]　Conception and Implementation of a Secure Engineering and Key Exchange Mechanism for the Open Source PLC Beremiz using a Test Driven Approach, M A Rahman, 2016.[12]　Can We Use Beremiz Real-time Engine for Robot Programmable Logic Controller, S Chu, CACS, 2015.[13]　OpenPLC – A fully open source controller An open source platform for PLC research, https://motion.control.com/thread/1464718978[14]　OpenPLC: An Open Source Alternative to Automation, Thiago Rodrigues Alves, IEEE Global Humanitarian Technology Conference, 2014.[15]　Analysis Method for Openness and Real-time of Industrial Robot Controllers and Implementation in Single Processor Mode, Doctoral Dissertation, Tan Shizhe, 2002.[16]　Bare-Metal, RTOS, or Linux? Optimize Real-Time Performance with Altera SoCs, Chee Nouk Phoon, 2014.[17]　Real-time Operating System Timing Jitter and its Impact on Motor Control, F. M. Proctor, SPIE, 2001.