Comparison of two control system solutions for robotic arms and mobile robots

This article compares the arm and mobile solutions and introduces their characteristics.

The above classification is based on the application object. In addition, there are more general-purpose motions on the market, that is, those that control non-standard equipment.

1 Controller underlying solution

1.1 Robotic Arm

Robotic arm controllers were developed early and are relatively mature. Let’s first look at the underlying solutions of existing control systems.

1.2 Mobile Robots

The controller of mobile robots belongs to a relatively new direction. Mobile robots are in the form of AGV, engineering machinery, etc. The underlying solution of the control system is as follows:

1.3 Comparison

The robot arm has high requirements for accuracy and motion stability, so the amount of calculation 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.

Robotic arms generally work in a fixed area, and their controllers are usually placed in a chassis, so the protection level is not high, generally IP20.

Since mobile robots need to move frequently, especially outdoor engineering machinery, they must be waterproof and dustproof, and their protection level is relatively high, 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 software development software. In simple terms, it consists of two parts: Development System and Runme System. Development System is the software interface used (just like Visual Studio, Eclipse and other software, also known as IDE). Designing, debugging and compiling PLC programs are all done in IDE, which is what users often deal with.

After the PLC program is written, it must be transferred to the device for execution. However, the generated PLC program cannot run by itself, and it must work in a certain software environment, which 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 platform, while Runtime System is located on the hardware device that plays a controlling role. The two are generally connected using a network cable, and the program runs in Runtime through the network cable.

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

3S, which 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 , and configuring the operating system is also the customer's job.

If the customer requires, CoDeSys' IDE can be customized with the customer's logo and appearance. This is why you will find that development platforms from different manufacturers look different but have similar styles.

Of course, users can also use other IDEs. For example, Beckhoff uses Microsoft's Visual Studio, while the compiler and other kernels and function libraries behind it still use the CoDeSys solution.

CoDeSys Runtime has strong adaptability and supports most operating systems and hardware architectures.

2.2 CoDeSys Runtime Principle

The IDE part of CoDeSys is free, you can download it from its official website to try it out. The runtime system is actually charged.

At the beginning of its design, CoDeSys divided its 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 be unfamiliar with this part, but in fact this design method is very common. For example, the real-time toolbox of ulink works in this way. Users design the control program by dragging and dropping in the ulink graphical interface, and then download it to the real hardware to run. You can learn more about it here.

Beckhoff also uses this method. Users program in TwinCAT IDE and then download it to the Beckhoff controller, which actually has a pre-installed runtime. 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, OCOS (Real-Time Toolkit) and so on are in the same position.

Robot control, like machine tools, requires real-time performance, so the operating system we choose is preferably a real-time operating system (). Unfortunately, the operating systems we often use are not real-time, such as Windows and. But fortunately, someone has modified them, that is, adding real-time patches.

Commonly used real-time operating systems include: QNX, Windows RTX, Xenomai, RT Linux, Linux RT, WinCE, μC/OS, SylixOs, etc. Considering that there are many users of Windows and Linux operating systems, CoDeSys has launched corresponding real-time patches (RTE) to save users from the trouble of transformation.

To learn more about CoDeSys Runtime, please read the official documentation [Math Processing Error] [1][2][1][2].

2.3 Disadvantages of CoDeSys

CoDeSys brings convenience to our controller development, saving 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 structure is not open to the public

The motion control components and bus protocol stacks integrated in CoDeSys are all packaged, and users cannot understand their internal details, nor can they customize and optimize them according to their specific needs. They can only simply call them. Users can only rely on the CoDeSys platform and find it difficult to form their own core technology.

(2) Limited functionality and difficult to expand

Nowadays, new technologies represented by AI, AI, and AI are advancing by leaps and bounds, while many technologies in industrial control are still stuck in the past 20 years. Taking the navigation scene in mobile robots 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 considerable amount of matrix calculation.

However, 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, and no one is willing to open their own function libraries. There are very few open source function libraries (OSCAT), and 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 and cannot adapt to new scenarios at all, and they are in urgent need of expansion.

(3) Difficult to update

Since customers are completely dependent on CoDeSys, the upgrade of their own product hardware needs to be customized and transplanted, which increases costs.

3 Open Source Solutions

There are currently some open source control system solutions, such as Beremiz, Orocos, OpenPLC, OpenRTM, and ORCA.

Developing a robot controller is a daunting task, requiring the identification of a series of performance requirements, 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 people to mistakenly understand "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 will be processed within a certain range. For example, the standard transmission speed is much faster than real-time industrial Ethernet, but it is not real-time because it also cannot guarantee that data will be transmitted within a given time.

It is not difficult to understand real-time, but what tasks of the robot need to run in real time? How to determine the time interval for program running based on 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 performance (X86, Linux RTAI or VxWorks)? There is a lack of in-depth discussion on this topic online, 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 period of industrial robot arms is about 1ms, and the control period of high-performance servo position loops can reach 125μs.

PLCopen defines some standards for servo and motion control, including programming language, basic motion control function blocks, input and output, etc.