This article compares the control system solutions for two types of industrial robots: robotic arms and mobile robots, introducing their characteristics.
The above classifications are based on the application objects. In addition, there are more general-purpose motion controllers on the market, which control non-standard equipment.
1 Controller Underlying Solutions
1.1 Robotic Arms
The controllers for robotic arms have developed relatively early and are mature. Let’s first look at the existing underlying solutions for control systems.
1.2 Mobile Robots
The controllers for mobile robots belong to a newer direction. Industrial mobile robots include forms like AGV and unmanned construction machinery, and the underlying solutions for control systems are as follows:
1.3 Comparison
Robotic arms have higher requirements for precision and motion stability, resulting in larger computational loads and shorter cycles, generally one to two orders of magnitude higher than mobile robots. Mobile robots typically do not have high requirements for synchronization accuracy, and their configurations are relatively lower.
Robotic arms usually operate in fixed areas, and their controllers are typically placed inside enclosures, so their protection levels are not high, usually IP20.
Mobile robots, due to the need for frequent movement, especially outdoor construction machinery, must consider waterproofing and dustproofing, leading to higher protection levels, 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. In simple terms, 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 referred to as IDE), where designing, debugging, and compiling PLC programs are done; this part is frequently interacted with by users.
Once the PLC program is written, it must be transferred to the hardware device for operation. However, the generated PLC program cannot run by itself; it needs to operate within a certain software environment, which is the Runtime System. This part is not visible to the user.
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 typically connected via a network cable, and the program is downloaded to the Runtime for execution.
CoDeSys is not well-known in China but has a long-standing reputation in Europe, especially in the field of industrial control. Many of the robot companies mentioned above use its products, such as KEBA, Beckhoff, and almost all mobile robot controller manufacturers.
The company that designs CoDeSys, 3S, only sells software and does not sell hardware. The hardware circuits need to be designed by the user, and 3S is responsible for porting the Runtime System to the customer’s hardware. The Runtime System can run directly on the hardware but is generally run on an operating system, and configuring the operating system is also the customer’s responsibility.
If requested by the customer, the CoDeSys IDE can be customized with the customer’s logo and appearance, which is why you may find different manufacturers’ development platforms look different yet 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 adopt CoDeSys’s solutions.
CoDeSys’s Runtime has powerful adaptability, supporting most operating systems and hardware chip architectures.
2.2 CoDeSys Runtime Principles
The IDE part of CoDeSys is free; you can download and experience it from its official website. The truly paid 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 select the necessary modules to build their system like building blocks, ultimately forming a customized control software platform.
Some users who are new to soft PLC may find this part unfamiliar, but this design approach is quite common. For example, the Real-Time Toolbox in MATLAB Simulink works in this way, where users design control programs through drag-and-drop in the Simulink graphical interface and then download them to real hardware for execution, which can be explored here.
Similarly, Beckhoff uses this method; users program in the TwinCAT IDE and then download to the Beckhoff controller, which already has a pre-installed Runtime. Siemens’ STEP7 is also an IDE, and its PLC also has a corresponding Runtime.
The PLC programs written by users are like applications on our computers, running on the Runtime System, which in turn runs on the operating system.
The Runtime System is located between the application program and the operating system, thus it can be referred to as middleware. In robot software, there are also ROS, OROCOS (Real-Time Toolkit), etc., that occupy the same position.
Robot control, like CNC machine tools, requires real-time performance, so the operating system we choose is best to be a real-time operating system (RTOS). Unfortunately, the operating systems we commonly 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 the large user base of Windows and Linux, CoDeSys has introduced corresponding real-time patches (RTE) to relieve users from the hassle of modifications.
If you want to learn more about CoDeSys Runtime information, you can read the official documentation.
2.3 Disadvantages of CoDeSys
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 its drawbacks:
(1) Underlying algorithms are not public
The motion control components and bus protocol stacks integrated into CoDeSys are encapsulated, and users cannot understand their internal details or customize optimizations for specific needs; they can only make simple calls. Users can only rely on the CoDeSys platform, making it difficult to form their core technologies.
(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 for 20 years. For example, in the navigation scenarios of mobile robots, vision or laser-based navigation methods require collecting and processing a large amount of data, involving 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 in the artificial intelligence community, the industrial control community is relatively closed, with reluctance to open their function libraries, and there are very few open-source function libraries (OSCAT). Even the most basic filtering algorithms and matrix calculations must be written from scratch. Moreover, the basic functions provided by international standards are too limited to adapt to new scenarios, making expansion urgently needed.
(3) Difficult to update
Due to complete reliance on CoDeSys, upgrading the hardware of the customer’s product 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 clear 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. It is easy for most people to mistakenly interpret “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 real-time operating systems (RTOS) must be within a specific time range.
The operating systems we commonly use (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. For example, standard Ethernet transmission speed is much faster than real-time industrial Ethernet, yet it is not real-time either, as it also cannot guarantee data transmission within a given time.
Understanding real-time performance is not too difficult, but which tasks of robots need to run in real-time? How to determine the time interval for program execution based on the robot’s performance requirements (is it 1ms or 10ms)? Does real-time performance depend on hardware or software?
How to select specific hardware and software based on real-time performance (should you choose ARM or X86, Linux RTAI or VxWorks)? There is a lack of in-depth discussion 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 around 1ms, and high-performance servo drive position loop control cycles can reach 125 μs.
PLCopen defines some standards for servo and motion control, including programming languages, basic function blocks for motion control, input-output interface parameters, etc.
Specific implementation code details are provided by various manufacturers.
Disclaimer:This article is a network reprint, and the copyright belongs to the original author.Due to numerous reprints, the true original author cannot be confirmed, hence only the source of reprint is indicated.If any videos, images, or texts used in this article involve copyright issues, please inform us immediately, and we will confirm the copyright based on the proof materials you provide and pay remuneration according to national standards or delete the content immediately!The content of this article represents the original author’s viewpoint and does not represent the endorsement of this public account or its responsibility for its authenticity.