This article compares the control system solutions of two industrial robots, the manipulator and the mobile robot, and introduces their characteristics.
The above classification is based on the application object. In addition, there are more general motion controllers on the market, that is, those that control non-standard equipment.
1 Controller bottom-level solution 1.1 Manipulator type The controller of the manipulator type developed earlier and is relatively mature. Let's take a look at the existing control system bottom-level solution. 1.2 Mobile robot type The controller of the mobile robot belongs to a relatively new direction. Industrial mobile robots are in the form of AGV, unmanned engineering machinery, etc. The bottom-level solution of the control system is as follows:
1.3 Comparison
The manipulator has high requirements for accuracy and motion stability, so the calculation amount is large and the cycle is short, which is generally 1 to 2 orders of magnitude higher than that of mobile robots. Mobile robots generally do not have high requirements for synchronization accuracy, and their configuration is relatively low.
The manipulator generally works in a fixed area, and its controller is usually placed in the chassis, so the protection level is not high, generally IP20. Mobile robots need to be waterproof and dustproof because they need to move frequently, especially outdoor engineering machinery, so they need to consider waterproofing and dustproofing. Their protection level is higher, generally IP67.
2 Introduction to CoDeSys 2.1 Composition of CoDeSys
You will find that many robot control software are implemented with the help of CoDeSys, so what is CoDeSys?
CoDeSys is a paid soft PLC development software. Simply put, it consists of two parts: Development System and Runtime System. Development System is the software interface used for programming (just like Visual Studio, Eclipse and other software, which can also be called IDE). Design, debugging, and compiling PLC programs are all carried out in IDE, which is the part that users often deal with;
After the PLC program is written, it must be transferred to the hardware device for operation. However, the generated PLC program cannot run by itself at this time. It must work in a certain software environment. This environment is the Runtime System, which is invisible to users.
The installation locations of the two are usually different. IDE is generally installed on the development computer, and Runtime System is located on the hardware device that plays a control role. The two are generally connected by network cables, and the program is downloaded to Runtime through the network cable for operation.
CoDeSys is not well-known in China, but it has a long-standing reputation in Europe, especially in the field of industrial control. Many robot companies we 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 software, not hardware. The hardware circuit needs 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 naked on the hardware, but it usually runs on the operating system, and configuring the operating system is also the customer's job.
If the customer requires, CoDeSys's IDE can be customized to change the customer's logo and appearance, which is why you will find that the development platforms of different manufacturers look different, but the styles are relatively similar.
Of course, users can also use other IDEs. For example, Beckhoff uses Microsoft's Visual Studio, while the kernel and function library behind the compiler still use CoDeSys's solution.
The Runtime of CoDeSys has strong adaptability and supports most operating systems and hardware chip architectures.
2.2 CoDeSys Runtime Principle
The IDE part of CoDeSys is free, and you can download it from its official website to experience it. The real charge is the runtime system Runtime System.
At the beginning of its design, CoDeSys divided the functions into several component modules, such as bus protocol stack, visual interface, motion control, safety control, etc. Users can choose the necessary modules to build their own system like building blocks, and finally form a customized control software platform.
Some users who are new to soft PLC may feel unfamiliar with this part, but in fact this design method is very common. For example, the real-time toolbox (Real-Time) of MATLAB Simulink works in this way. Users design control programs by dragging and dropping in the graphical interface of Simulink, and then download them to the real hardware to run. You can learn about it here.
There is also such a way of use like Beckhoff. Users program in TwinCAT IDE and then download them to the controller of Beckhoff. In fact, a runtime is pre-installed in the controller. Siemens STEP7 is also an IDE, and its PLC also has a matching runtime.
The PLC program written by the user is like the application in our computer. It runs on the runtime system, and the runtime system runs on the operating system.
The runtime system is located between the application and the operating system. So it can be called middleware. In robot software, ROS, OROCOS (Real-Time Toolkit), etc. are in the same position.
Robot control, like CNC machine tools, requires real-time performance, so the operating system we choose is preferably a real-time operating system (RTOS). Unfortunately, the operating systems we often use are not real-time, such as Windows and Linux. But fortunately, someone has modified them, that is, added 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 that there are many users of Windows and Linux operating systems, CoDeSys has launched a corresponding real-time patch (RTE) to save users the trouble of modification.
For more information about CoDeSys Runtime, you can read the official document [Math Processing Error] [1][2][1][2].
2.3 Disadvantages of CoDeSys
CoDeSys brings convenience to our controller development and saves us the trouble of starting from scratch. However, there are also many disadvantages in developing our own controller products based on commercial software such as CoDeSys:
(1) The underlying algorithm is not open
The motion control components and bus protocol stacks integrated by CoDeSys are all encapsulated. Users cannot understand their internal details, nor can they customize and optimize them according to their specific needs. They can only call them simply. Users can only rely on the CoDeSys platform and find it difficult to form their own core technology.
(2) Limited functions and difficult to expand
New technologies represented by machine vision, artificial intelligence, and autonomous driving are now advancing by leaps and bounds, while many technologies in industrial control are still 20 years old. Taking the navigation scene in a mobile robot as an example, the navigation method based on vision or laser needs to collect a large amount of data and process it, which involves a lot of matrix calculations.
Now PLC can only perform backward one-dimensional digital calculations, making it difficult to implement complex algorithms. In contrast to the open source style of the artificial intelligence community, the industrial control community is closed to each other. No one is willing to open their own function libraries. There are very few open source function libraries (OSCAT). Even the most basic filtering algorithms and matrix calculations have to be written from scratch. Moreover, the basic functions provided by international standards are too limited and cannot adapt to new scenarios at all. They are in urgent need of expansion.
(3) Difficult to update
Due to the complete reliance on CoDeSys, the upgrade of customers' own product hardware needs to be customized and transplanted, resulting in increased costs.
3 Open source solutions
Currently, there are some open source control system solutions, such as Beremiz, Orocos, OpenPLC, OpenRTM, and ORCA.
Developing robot controllers is a heavy task. A series of performance requirements must be clarified, the first of which is real-time performance.
Real-time performance is generally necessary for industrial robots, but not necessarily for service or entertainment robots. It is easy for ordinary people to mistake "real-time performance" as fast processing or response speed, but in fact "real-time performance" means "determinism" in time. For example, the delay time of interrupt response or process switching in the real-time operating system (RTOS) must be within a time range.
The operating systems we commonly use (Windows, Linux) are not real-time operating systems, because they are designed for throughput and cannot guarantee that every event is processed within a certain range. For example, the transmission speed of standard Ethernet is much faster than that of real-time industrial Ethernet, but it is not real-time either, because it also cannot guarantee that data is transmitted within a given time.
It is not difficult to understand real-time, but which tasks of the robot need to run in real time? How to determine the time interval for program running according to the performance requirements of the robot (1ms or 10ms)? Does real-time depend on hardware or software?
How to choose specific hardware and software based on real-time (ARM or X86, Linux RTAI or VxWorks)? There is a lack of in-depth discussion on this aspect on the Internet, and major robot manufacturers will not disclose their test and experimental results. It seems that this aspect mainly relies on experience and trial and error.
Here I can only provide a few indicators. At present, the control cycle of industrial robot arms is about 1ms, and the control cycle of the position loop of a high-performance servo drive can reach 125[Math Processing Error] mu sμs. PLCopen defines some standards for servo and motion control, including programming language, basic motion control function blocks, parameters of input and output interfaces, etc. [Math Processing Error] ^{[3]}
[3] The specific implementation code details are provided by various manufacturers.
