Introduction to Industrial Robot Control System Architecture

This article compares the control system solutions of two types of industrial robots: robotic arms and mobile robots, introducing their characteristics.

The above classification is based on the application objects. In addition, the market has more general-purpose motion controllers that control non-standard equipment.

1 Controller Bottom Layer Solutions

1.1 Robotic Arms

The controllers for robotic arms have developed earlier and are relatively mature. Let’s first look at the existing bottom layer solutions for control systems.

1.2 Mobile Robots

The controllers for mobile robots belong to a newer direction. Industrial mobile robots include AGVs, autonomous construction machinery, etc. The bottom layer solutions for the control systems are as follows:

1.3 Comparison

Robotic arms have higher requirements for precision and motion stability, thus requiring larger computation and shorter cycles, generally one to two orders of magnitude higher than mobile robots. Mobile robots generally have lower synchronization precision requirements and a relatively lower configuration.

Robotic arms typically operate in fixed areas, and their controllers are usually placed inside a casing, hence the protection level is not high, generally IP20.

Mobile robots, due to the need for frequent movement, especially outdoor construction machinery, must consider waterproofing and dustproofing, leading to a higher protection level, generally IP67.

2 CoDeSys Introduction

2.1 CoDeSys Composition

You will find that many robot control software is implemented using CoDeSys. So what is CoDeSys?

CoDeSys is a paid soft PLC development software. Simply put, it consists of two parts: the Development System and the Runtime System. The Development System is the software interface used for programming (like Visual Studio, Eclipse, etc., also called IDE). Designing, debugging, and compiling PLC programs are all done in the IDE, which is the part that users frequently interact with;

Once the PLC program is written, it needs to be transferred to the hardware device to run. However, the generated PLC program cannot run by itself; it must operate in a specific software environment, which is the Runtime System, this part is not visible to users.

The installation locations of the two are usually different; the IDE is generally installed on the development computer, while the Runtime System is located on the hardware device that controls the operation. The two are usually connected by network cables, and the program is downloaded via the network cable to run in the Runtime.

CoDeSys is not very well-known in China but has a long-standing reputation in Europe, especially in the field of industrial control. Many robot companies mentioned above use its products, such as KEBA, Beckhoff, GSK, and almost all mobile robot controller manufacturers.

The 3S company that designs CoDeSys only sells software, not hardware. The hardware circuits need to be designed by the user, and the 3S company is responsible for porting the Runtime System to the customer’s hardware. The Runtime System can run bare on hardware but is generally run on an operating system, and configuring the operating system is also the customer’s responsibility.

If requested, CoDeSys’s 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 but have a similar style.

Of course, users can also use other IDEs; for example, Beckhoff uses Microsoft’s Visual Studio, while the underlying compiler and other kernels and function libraries still use CoDeSys’s solution.

CoDeSys’s Runtime has powerful adaptability and supports most operating systems and hardware chip architectures.

2.2 CoDeSys Runtime Principles

The IDE part of CoDeSys is free, and you can download and experience it from its official website. The truly charged part is the Runtime System.

CoDeSys was designed from the beginning to divide functions into several component modules, such as bus protocol stacks, visual interfaces, motion control, safety control, etc. Users can purchase the necessary modules like building blocks to build their system, ultimately forming a customized control software platform.

Some first-time users of soft PLC may find this part unfamiliar, but this design method is very common. A few examples include MATLAB Simulink’s Real-Time toolbox, which works in a similar way, allowing users to design control programs through drag-and-drop in Simulink’s graphical interface and then download them to run on real hardware.

Similarly, Beckhoff uses this method, where users program in the TwinCAT IDE and then download to Beckhoff’s controllers, which have a pre-installed Runtime. Siemens’ STEP7 is also an IDE, and its PLC also has a matching Runtime.

The PLC programs written by users are like application programs on our computers; they run on the Runtime System, which in turn runs on top of the operating system.

The Runtime System is located between the application program and the operating system, so it can be referred to as middleware. In robot software, similar middleware includes ROS, OROCOS (Real-Time Toolkit), etc.

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. But fortunately, some have been modified to include real-time patches.

Common real-time operating systems include:VxWorks, QNX, Windows RTX, Xenomai, RT Linux, Linux RTAI, WinCE, μC/OS, SylixOs, etc. Considering that Windows and Linux are widely used operating systems, CoDeSys has introduced corresponding real-time patches (RTE) to spare users the hassle of modifications.

If you want to learn more about CoDeSys Runtime, you can read the official documentation [Math Processing Error] [1][2][1][2].

2.3 CoDeSys’s Disadvantages

CoDeSys has brought convenience to our controller development, saving us from starting from scratch, but relying on commercial software like CoDeSys to develop our controller products has several disadvantages:

(1) Bottom Layer Algorithms Are Not Public

The motion control components and bus protocol stacks integrated into CoDeSys are packaged, and users cannot understand their internal details or customize optimizations for their specific needs; they can only call them simply. Users can only depend on the CoDeSys platform, making it difficult to form their core technologies.

(2) Limited Functionality, 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, which involves considerable matrix calculations.

However, current PLCs can only perform outdated one-dimensional digital calculations, making it difficult to implement complex algorithms. In contrast to the open-source style favored by the artificial intelligence community, the industrial control community is relatively closed, with few open-source function libraries (OSCAT), and even the most basic filtering algorithms and matrix calculations need to be written from scratch. Moreover, the basic functions provided by international standards are too limited to adapt to new scenarios, necessitating expansion.

(3) Difficult to Update

Due to complete reliance on CoDeSys, upgrading the hardware of the customer’s products requires re-customization and porting, leading to increased costs.

3 Open Source Solutions

Currently, there are some open-source control system solutions, such as Beremiz, Orocos, OpenPLC, OpenRTM,ORCA.

Developing robot controllers is a heavy task that requires clarifying a series of performance requirements, with real-time performance being the first priority.

Real-time performance is generally essential for industrial robots, but not necessarily for service or entertainment robots. Many people easily misunderstand “real-time performance” as fast processing or response speed, but in fact, “real-time performance” indicates temporal “determinism,” such as the interrupt response or process switching delay time in a real-time operating system (RTOS) being within a certain time range.

The commonly used operating systems (Windows, Linux) are not real-time operating systems, as they are designed for throughput and cannot guarantee that every event is processed within a certain range. Similarly, standard Ethernet transmission speeds are much faster than real-time industrial Ethernet, but it is not real-time either, as it cannot guarantee that data is transmitted within a given time.

Understanding real-time performance is not difficult, but which tasks of robots require real-time execution? How to determine the program execution time interval based on the performance requirements of the robot (is it 1ms or 10ms)? Does real-time performance depend on hardware or software?

How to choose specific software and hardware based on real-time performance (should I choose ARM or X86, Linux RTAI or VxWorks)? There is a lack of in-depth discussions on this topic online, and major robot manufacturers do not disclose their testing and experimental results, seeming to rely mainly on experience and trial and error.

Here, I can only provide a few indicators; currently, the control cycle for industrial robotic arms is about 1ms, and high-performance servo drive position loops can achieve control cycles of 125 [Math Processing Error] mu sμs. 　

PLCopen has defined some standards for servo and motion control, including programming languages, basic function blocks for motion control (Function Block), and parameters for input and output interfaces, etc. [Math Processing Error] ^{[3]}

[3]The specific implementation code details are provided by various manufacturers.