This article compares two control system schemes for industrial robots : robotic arms and mobile robots, and introduces their characteristics.
The above classification is based on the application. In addition, there are more general-purpose motion controllers on the market, which are used to control non-standard equipment.
1. Controller underlying solution
1.1 Robotic Arms
Controllers for robotic arms have been developed earlier and are relatively mature. Let's first take a look at the underlying solutions of existing control systems.
1.2 Mobile Robots
Mobile robot controllers are a relatively new area of research. Industrial mobile robots include AGVs and unmanned construction machinery, among other forms. The underlying solution for the control system is as follows:
1.3 Comparison
Robotic arms have high requirements for precision and motion stability, resulting in large computational loads and short cycles, typically one to two orders of magnitude higher than mobile robots. Mobile robots generally do not require high synchronization precision and have relatively lower configurations.
Robotic arms typically operate in fixed areas, and their controllers are usually housed inside a chassis, so their protection level is not high, generally IP20.
Mobile robots, especially outdoor construction machinery, need to be waterproof and dustproof, so their protection level is relatively high, generally IP67.
2. Introduction to CoDeSys
2.1 Composition of CoDeSys
You'll find that many robot control software programs are implemented using CoDeSys. So what is CoDeSys?
CoDeSys is a paid software PLC development tool. Simply put, it consists of two parts: the Development System and the Runtime System. The Development System is the software interface used for programming (similar to software like Visual Studio and Eclipse, also known as an IDE). Designing, debugging, and compiling PLC programs all take place within the IDE, and this is the part users interact with most frequently.
Once the PLC program is written, it needs to be transferred to the hardware device for execution. However, the generated PLC program cannot run on its own at this point; it requires a specific software environment to function. This environment is the Runtime System, which is invisible to the user.
The two are usually installed in different locations. The IDE is generally installed on the development computer, while the Runtime System is located on the hardware device that plays a control role. The two are usually connected by a network cable, and the program is downloaded to the Runtime System through the network cable to run.
CoDeSys is not well-known in China, but it enjoys a long-standing reputation in Europe, especially in the field of industrial control. Many of the robotics companies mentioned above use its products, such as KEBA, Beckhoff, Googol, and almost all mobile robot controller manufacturers.
3S, the company that designed CoDeSys, only sells the software, not the hardware. Users need to design the hardware circuitry themselves; 3S is responsible for porting the Runtime System to the customer's hardware. The Runtime System can run on the hardware without a physical interface, but it typically runs on an operating system, which is also the customer's responsibility.
If requested by the client, CoDeSys' IDE can be customized with the client's logo and appearance. This is why you'll find that development platforms from different manufacturers look different, but their styles are quite similar.
Of course, users can also use other IDEs. For example, Beckhoff uses Microsoft's Visual Studio, while the underlying compiler and other kernel and function libraries still use the CoDeSys solution.
CoDeSys's runtime is highly adaptable, supporting the vast majority of operating systems and hardware chip architectures.
2.2 CoDeSys Runtime Principles
The IDE portion of CoDeSys is free; you can download and try it from their official website. The actual paid component is the Runtime System.
CoDeSys was designed from the outset to divide its functions into several component modules, such as bus protocol stack, visual interface, motion control, safety control, etc. Users can select the necessary modules to build their own system like building blocks, and finally form a customized control software platform.
Some users new to software PLCs may find this unfamiliar, but this design approach is actually very common. For example, MATLAB Simulink's Real-Time toolbox works this way. Users design control programs by dragging and dropping within the Simulink graphical interface, then download them to real hardware to run. You can learn more about this here.
Beckhoff also uses a similar approach. Users program in the TwinCAT IDE and then download the program to the Beckhoff controller, which actually comes pre-installed with a runtime. Siemens' STEP7 is also an IDE, and its PLCs also have a corresponding runtime.
The PLC program written by the user is like an application on our computer. It runs on the Runtime System, which in turn runs on the operating system.
The Runtime System sits between the application and the operating system. Therefore, it can be called middleware. In robotics software, ROS, OROCOS (Real-Time Toolkit), and others occupy a similar position.
Like CNC machine tools, robot control requires real-time performance, so a real-time operating system (RTOS) is the best choice. Unfortunately, most operating systems we use are not real-time, such as Windows and Linux. Fortunately, however, some people have modified them by adding real-time patches.
Commonly used 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 released corresponding real-time patches (RTEs), saving users the trouble of modification.
For more information on CoDeSys Runtime, please refer to the official documentation [Math Processing Error] [1][2][1][2].
2.3 Disadvantages of CoDeSys
CoDeSys has brought convenience to controller development, saving us the trouble of starting from scratch. However, relying on commercial software like CoDeSys to develop our own controller products also has many drawbacks:
1. The underlying algorithm is not publicly disclosed.
CoDeSys integrates pre-packaged motion control components and bus protocol stacks, preventing users from understanding their internal details and customizing them to their specific needs; they can only make simple calls. Users are forced to rely on the CoDeSys platform, making it difficult to develop their own core technologies.
2. Limited functionality and difficult to expand.
While new technologies such as machine vision, artificial intelligence, and autonomous driving are advancing rapidly, many technologies in industrial control remain stuck 20 years in the past. Taking navigation in mobile robots as an example, vision-based or laser-based navigation methods require the collection and processing of large amounts of data, involving a considerable amount of matrix calculations.
Currently, PLCs can only perform outdated one-dimensional digital calculations, making it difficult to implement complex algorithms. Contrary to the open-source-oriented approach of the artificial intelligence community, the industrial control community is largely closed off, with no one willing to release their function libraries. Open-source function libraries are extremely rare (OSCAT is an example), and even the most basic filtering algorithms and matrix calculations must be written from scratch. Furthermore, the basic functions provided by international standards are far too limited to adapt to new scenarios and urgently require expansion.
3. Difficult to update
Because of the complete reliance on CoDeSys, customers need to completely re-customize and port their own product hardware when upgrading or replacing it, which increases costs.
3. Open source solutions
Currently, there are several open-source control system solutions, such as Beremiz, Orocos, OpenPLC, OpenRTM, and ORCA.
Developing a robot controller is a demanding task, requiring the definition of a series of performance requirements, the most important of which is real-time performance.
Real-time performance is generally essential for industrial robots, but not necessarily for service or entertainment robots. People often mistakenly interpret "real-time performance" as fast processing or response speed, but it actually refers to "determinism" in time. For example, the delay time for interrupt responses or process switching in a real-time operating system (RTOS) is always within a certain time range.
The operating systems we commonly use (Windows, Linux) are not real-time operating systems because they were designed for throughput and cannot guarantee that every event will be processed within a certain range. Similarly, standard Ethernet is much faster than real-time industrial Ethernet, but it is not real-time either, because it also cannot guarantee that data will be transmitted within a given time.
Understanding real-time performance isn't too difficult, but which tasks of a robot need to run in real time? How do we determine the program execution time interval (1ms or 10ms) based on the robot's performance requirements? Does real-time performance depend on hardware or software?
How do we choose specific hardware and software based on real-time requirements (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 test and experimental results. It seems that this aspect mainly relies on experience and trial and error.
I can only provide a few indicators here. Currently, the control cycle of industrial robotic arms is about 1ms, while the control cycle of the position loop of high-performance servo drives can reach 125ms.
PLCopen defines some standards for servo and motion control , including programming languages, motion control function blocks, input/output interface parameters, etc. [Math Processing Error] ^{[3]}
[3] The specific implementation code details are provided by each manufacturer.
Disclaimer: This article is a reprint. If it involves copyright issues, please contact us promptly for deletion (QQ: 2737591964). We apologize for any inconvenience.
