Runtime programming industrial robot on RCML

Runtime programming in this article refers to the process of creating an executable program for a robot controller (hereinafter referred to as just a robot) on an external controller. The process of execution of the created program by the robot in this case occurs iteratively, by transferring to it the minimum executable command or batch of commands. In other words, during runtime programming, the executable program is transferred to the robot in portions, while the robot does not possess, does not store and does not know in advance the entire executable program. This approach allows you to create an abstract parameterized executable program that is generated by an external device “on the fly”, i.e. runtime.

Under the cat description and a real example of how runtime programming works.

Typically, a robot program is a sequence of positions to which the robot arm must come. Each of these positions are characterized by the position of TCP (Tool Center Point) - the point of the tip of the tool installed on the manipulator. By default, TCP is located in the center of the robot flange, see the figure below, but its position can be reconfigured and most often so that TCP coincides with the tip of the installed tool on the robot arm. Therefore, usually when programming, the TCP position is set in space, and the robot determines the position of the joints of the manipulator itself. Further in the article the term “TCP position” will be used, or in other words the point to which the robot must “come”.
The program for the robot can also contain primitive control logic (branches, cycles), simple mathematical operations, as well as peripheral control commands — analog and digital inputs / outputs. In the proposed approach, runtime programming, as an external controller, a regular PC is used, which can use powerful programming tools that give the necessary level of abstraction (OOP and other paradigms) and tools that ensure the speed and ease of developing complex logic (high-level programming languages). At the robot, however, only logic that is critical to the speed of reaction remains, for the execution of which the reliability of an industrial controller is needed, for example, an operational and adequate response to an emergency situation. The control of the peripherals connected to the robot is simply “proxied” by the robot itself to the PC, allowing the software from the PC to turn on or off the corresponding signals on the robot. This is somewhat similar to the management of the "legs" on the Arduino.
')


As noted earlier, runtime programming allows the program to transfer the program in portions. Usually, a set of states of the output signals and a small number of points or only one point at all is transmitted at once. Thus, the TCP movement path, performed by the robot, can be built dynamically and its individual parts can belong to different technological processes, or even to different robots (connected to one external controller), if the group of robots is working, i.e. There are prerequisites for the dynamic replacement of robots in the process.

For example, moving the robot between work areas. In each zone, he performs the necessary operations and then moves to the next zone, then to another, and then again to the first, and so on. In different work areas, the robot performs the operations necessary for different technological processes, the execution of programs of which flows in parallel threads on an external controller, which allocates the robot to different processes that do not require the constant presence of the robot. This mechanism is similar to how the OS allocates the time of the processor core (executive resource) to different threads (tasks) and at the same time, different executors are not tied to threads throughout the entire program execution period.

A little more theory and turn to practice.


As an example, consider the creation of a robot program in runtime mode, which provides the technological process of writing ads with a marker.



To write this text, it was necessary to transfer more than 1700 points to the robot.

As an example, in the spoiler there is a screenshot, from the robot console, the program that draws a square. There are only 5 points (lines 4-8), each point is essentially a complete expression (operator) and occupies one line. The manipulator bypasses each of the four points and upon completion returns to the starting point.


If to write the program in a similar way, then it would be at least 1700 operators - lines of code, by operator per point. And what if later it was required to change the text or the height of the letters, or the distance between them? Edit all 1700 dot-lines? This is contrary to the spirit of automation!

So let's get down to solving ...

We have a FANUC LR Mate 200iD robot with a controller R-30i series B cabinet. The robot has a TCP pre-configured at the end of the marker and the desktop coordinate system, so we can send coordinates without worrying about converting the coordinates from the table coordinate system to the robot coordinate system.

To implement the coordinate transfer program for the robot, which will calculate the absolute values ​​of each specific point, we will use the RCML programming language, which supports the proposed approach, has modules for communicating with this robot and which is importantly free for any use.

We describe each letter with dots, but not in real coordinates of space, but relative ones inside the frame in which the letter will be inscribed. Each letter will be drawn by a separate function that receives as input parameters the sequence number of the letter in the line, the line number, and the size of the letter, and sends a set of points to the robot with the calculated absolute coordinates of each point.

To write the text we need to call a sequence of functions that draw letters in the same sequence in which they (the letters) are indicated in the text. RCML has scant tools for working with strings, so we will make an external Python script that will generate an RCML program — in fact, only generate a sequence of function calls for the corresponding sequence of letters.

All code is available in the repository on GitHub: rct_paint_words

Let's take a closer look at the output file, the execution starts with the function main ():





All configuration constants, including the size of the letters, their number in a line, etc., were moved to a separate file chars_config.rcml.


As a result, we received a total of about 300 lines of high-level code, the design and writing of which took no more than 2 hours.

If this problem were solved "in the forehead" by online point programming, it would take more than 9 hours (approximately 20-25 seconds per point, taking into account that there are more than 1700 points). In this case, the developer’s suffering is hard to imagine :), especially when it turned out that he had forgotten about the indents between the letters, or made a mistake with the height of the letters and the text did not fit, and now I’ll have to start from the beginning.

Conclusion:

Runtime programming allows you to solve the task of moving the robot in general, dynamically composing a private program of movement depending on the specified parameters. Moreover, the program that solves the problem in general can be developed without the need for a robot, which on the one hand can be attributed to the offline programming approach of an industrial robot. On the other hand, the program for moving directly to the robot is already created for a specific instance and particular parameters for solving the problem on the spot, as in online programming.

In the considered example, the general algorithm was the outline of letters, and such parameters as their size, indents between them, the number of letters in a line, etc. depended on the particular conditions on the site with the robot.

As noted, such an approach with the dynamic construction of the trajectory of movement creates the prerequisites for the implementation of the switching of the robot (on an event basis), as an executive resource, between several simultaneously proceeding tasks.


I hope the article was useful to you.

I am happy to answer your questions.