Robot Control Meta Language (RCML)

3.1 Robot Concept in RCML

A robot in RCML is a kind of executive resource that can be engaged to perform a specific task (function) and then released for re-engagement, but in another task for example. The immediate analogy is processing core of CPU, which can be engaged in only one process at a particular time. However, OS means allocating very small quanta of CPU time to different software processes or tasks, can create the illusion that one core handles multiple tasks. In RCML, the robot as a resource is controlled by the interpreter, but the robot is engaged not for a period of time, but to perform a specific function or multiple functions, and thus the time of its engagement may be different.

A robot is an object of the real material world, and its actions are often not as instantaneous as in the above analogy with the CPU core. And it takes time to perform its function, and this time may be different for the same function as a robot is affected by many factors of material object world.

A robot module as such provides RCML environment with robot class description assigned to it. It is assumed that locally in the object world where RCML is used, maybe one or more robots of the same class assigned to one robot module. And there are two key types of objects as part of the robot module in RCML environment, as shown in Figure 4:

  • Robot module acts as a controller for robots of the class entrusted to it, i.e. selects a free robot to be engaged and released after work;
  • Robot representation – a reflection of a specific physical robot in a virtual RCML environment, translating commands to the physical robot.

Figure 4 Virtual representation of objects classes in RCML environment

It should be noted that many robot classes may be connected simultaneously, i.e. many robot modules, and each of them can provide access to multiple robots in its class. Robots within the same class must be completely identical, both in physical and functional performance.

3.2 Using Robots in the Program

For the robot to be used in the program, its class and function should be specified. The class name of the robot coincides with the name of the robot module in the config.ini file. However, the class of the robot in the RCML program should be specified using keyword robot and an underscore. 

The syntax for activating the robot:

robot_class_of_robot

For example, you can call the robot from module test, and then its class will be identified as:

robot_test

Meeting the class name of the robot in the text of the program, the system will send a request to the appropriate module of the robot and will stop program execution until it finds a free robot of the required class.

3.3 Calling Robot Function

After receiving the robot of the required class, the programmer can make him perform the requested action, i.e., cause the execution of a certain robot function. Robot functions are programmed by the robot developer together with robot module and are described in the documentation to robot module.

Calling a function is visually similar to the object method call in C-like programming languages. Robot class must be specified, and then through the pointer character “->” the required function is specified, and then goes the list of arguments to this function in parentheses. 

Robot function call syntax:

robot_robot_class->robot_function(arguments);

For example, you should call do_something function with one argument 1000 from test class robot:

robot_test->do_something(1000);

Reaching such structure, the interpreter will reserve a robot of this class, waits until the real physical robot is engaged and then sends a command of robot representation of the execution of the specified function with the specified parameters. After function execution, the robot will be automatically released and transferred to free status.

It should be noted that when robot function call is specified this way, the interpreter waits for confirmation of the function from robot representation, and only then continues executing the rest of the program. Read more information about flags of function execution in Section "Specifying Function Execution Modes".

Depending on how and where the execution of robot functions is described, they (functions) can be divided into three types:

  • User-defined functions – the functions described in RCML language in the current file of the source program code or in the included files with the source code in RCML. The code of these functions is within the current program and will be compiled into an executable file of the current program;
  • Library functions – the functions of RCML libraries already compiled, linked to the current program, i.e., the code of these functions is outside the current program in RCML;
  • System functions – the functions that are provided to RCML environment by robot module. The execution code of these functions is in robot module or in robot software.

System function can be re-defined by user-defined and library function. Library function can be re-defined by user-defined function only. User-defined function can not be re-defined. When you create two user-defined functions with the same name, the compiler will generate an error. This mechanism allows you to re-define inefficient functions of the level, where it is more difficult to do, to the functions of the level, where it is easier to do. For example, it may be difficult to recompile robot module or library due to the absence of source codes, however, it is easy to re-define the required function in the text of your program.

Thus, in a function call, the specified robot function is first searched among user-defined functions. In case the required function is not found among user-defined functions, the search continues among library functions. Each library is searched for the required function in the order it is included in the source program code. It should be noted that different libraries may include th same function for the same robot, so the first function found will be selected. If the required function is also not found among library functions, the search continues among system functions. There may be multiple system functions with the same name as part of robot module, but the first function found is always selected. If the required function is not found among system functions, then an error is generated.

The function is searched only by its name without taking into account the number of its parameters. If the function found has a number of parameters other than the number of arguments sent in the function call, an error is generated.

Based on this search algorithm, it can be concluded that user-defined functions have a highest priority in the search, followed by library and then system functions.

However, sometimes a programmer faces the need to use system function, which is re-defined by library function. This case is possible when library function implementation is inefficient, the source code of the library is absent, and there is the need to use this library because it includes other functions. It is possible to directly access system function if you include a dot character “.” before the function name. Function call syntax is as follows:

robot_robot_class->.robot_function(arguments);

the above example is as follows:

robot_test->.do_something(1000);

3.4 Working with a Certain Robot

It is often necessary to call multiple robot functions, and they must be performed by a single robot as a predetermined sequence of actions. If the required sequence of functions is called as described above, in case of robots of several classes it is likely that the specified functions will be performed by different robots. If there is a single robot of a given class available, it every time will be engaged and released for each function.

The most effective and rational is to engage a robot once and send commands to it as necessary and then release it, thus implementing a session of robot operation. This requires engaging a robot of the required class and remembering connection to a specific robot engaged. This can be done by saving the robot in a special type of variables with “@” character before the identifier. For example, we engage the robot of test class, and save connection with the specific robot in @r variable:

@r = robot_test;

Reaching such a structure, the interpreter, as in case of a robot function call, will send a request to engage the robot, but now the robot will not be released until the command to release this certain robot is reached.

Now, to call the function of this engaged robot, we need to call the function by applying to this variable, not to the robot class. For example, calling the same do_something function of this robot with the same parameters:

@r->do_something(1000);

After performing this function, the robot will remain engaged, and we can call the next function of this robot.

It is not allowed to use specific variables with @ character in the context of RCML expressions. They can not participate in operations, comparisons and be transferred as arguments to functions (except for hand_control system function). However, a robot can be assigned to another variable of the same type, i.e. communication with the engaged robot can be saved in several variables, for example:

@r = robot_test;
@r2 = @r;
@r4 = @r3 = @r2;

As a result, all variables @r, @r2, @r3 and @r4 will be attributed to the same robot.

The variable already attributed to a specific robot can be assigned with a pointer to a completely different robot, or even a different robot class:

@r = robot_test;
@r2 = @r;
@r = robot_tarakan;

Now @r is attributed to a robot of tarakan class, and @r2 is attributed to a robot of test class. Note that when you change the robot which the variable is attributed to, the robot which it was attributed to previously, will not be released.

3.5 Releasing the Engaged Robot

A robot “saved in the special variable” can be released using a special delete operator, when it is required. This operator must be accompanied by a special variable that holds a pointer to the robot to be released. Example of robot release with a pointer previously assigned to a variable @r is as follows:

delete @r;

It should be noted that all robots involved and not released using delete operator, will be released at the end of the function execution only, where they were engaged. This statement does not apply to robot functions written in RCML, because these functions are executed in the context of a robot instance, and a robot instance be engaged in them. Read more about these functions in Section "Writing Own New Functions for Robots"

Remember that, by analogy with traditional programming languages where the programmer can allow a memory leak, you can now allow a robot leak in RCML language.

Section "Features of Function Execution by Robots in Different Modes" also contains important additional information about the mechanism to release the robot engaged.

3.6 Automatic Robot Selection

One of RCML features is automatic robot selection for a certain task. To use this feature, just specify robot keyword instead of a specific robot class where it is required to specify robot class: robot function call or assignment a robot to a variable. For example:

robot->do_something(1000);
@r = robot;
@r->do_something();

Using only robot keyword instead of the full robot class name will be further called the abstract robot.

When using the abstract robot in a function call, RCML environment will automatically check what robot types from robots available in the system have this function with this number of parameters, and, if they are available, it will generate a list of candidate robot classes that can be used in the function call. Thus, not only different robots within the same class can be engaged in this function call, but also robots different by classes.

In case of using a special variable for communication with the abstract robot, RCML environment analyzes each function call with respect to this variable, and makes a list of candidates only of those robot types which have all called functions with respect to this variable.

3.7 Using the robot choosing module

In the method of robot activation described in section "Using Robots in the Program", specific physical robot, or rather the associated robot representation is chosen by the robot module, which may know nothing about the context of using the activated robot, and therefore it is likely to make not the best choice of the robot. Most often, the first available robot within a specific module of robots is called this way if a specific required class of robots had been specified. Or, if an abstract robot had been called, it would be the first free robot from the first module of robots with unused robots, in the order in which the modules of the robots are listed in theconfig.ini file.

If in the process of the RCML interpreter operation the option to record statistics (see section "Installation and Configuration of RCML Compiler and Interpreter") was activated, the statistical information about robots operation and the speed of executing their functions is collected. For more about data collection, see Section "Working with RCML statistics". The robot choosing modules may have access to this information, and, based on it, can make a more rational decision about the choice of the robot.

Connecting one or several choosing modules is specified in the robot manipulation the operator in angle brackets <>, where all choosing modules are listed, comma-separated. The syntax of this construction is as follows:

robot_class_of_robot<list_of_choice_modules>

An example of connecting choosing module avg to choosing a tarakan class robot:

robot_tarakan<avg>

In this case, the tarakan robot module will request all physical representations of the available robots, and their list will be passed to choosing module avg. From the provided list, the choosing module will choose the most appropriate robot, which will be used. The choice algorithm is determined by the choosing module.

It should be noted that choosing a robot using a choosing module usually takes longer than without the one, since the module has to perform additional actions associated with decision-making (statistics database queries, etc.).

If the robot chosen by the choosing module has become engaged in another process, the choice procedure starts again, querying the robot module for available robots.

The choosing module may be also indicated in case of using an abstract robot. For example, indication of statistics module avg, with abstract robot:

robot<avg>

In this case, RCML get a list of all presentations of the available robots from all robot modules matching this call. From the list of robots representations, only one robot of a particular class will be chosen.

In case several statistics modules were indicated for robot initialization. For example: 

robot_tarakan<test1, test2, test3>

In this case, every choosing module will get a list of representations of the available robots, out of which each module will choose one robot. In this case, the order of modules indication determines the sequence of decision-making by the modules, as well as the priority of the robot chosen by a particular choosing module, which may be expressed in points. The first specified choosing module will be the first to select a robot, and the robot selected by it will have the maximum priority in points that will be equal to the number of the specified choosing modules. Accordingly, the last specified module will be the last to make decision, and the robot it chooses will have the priority equal to one point. If the choosing modules choose for activation different robots from the list of the available robots, the robot with the highest points will be activated, i.e. the robot with the highest priority. If the robots chosen for activation have the same points, the robot chosen by the first choosing module will be selected. 

It is important to note that a situation is possible where a specific statistics module for any reason cannot make the decision about choosing a robot. In this case, the module notifies the RCML environment, and environment's current behavior is determined as though this module has not been specified for robot activation.

Address:

12, Monastyrskaya St., lit. A,
Office 600, Perm, Russia

Phone:

+7 (342) 214 01 84

E-mail:

info@robotct.ru