Transition from teleoperation towards Object Action Complexes

The most powerful robot can be realized with teleoperation. Teleoperation means, that the robot is equipped with human level skills and can adapt to any situation. A pick&place with a teleoperated robot arm works perfect. The most interesting feature of remote control is, that no program is needed. The only piece of software transmits the joystick signals to the robot, but the robot movements itself are not determined by a program.

Suppose the idea is to program a robot which means, that the steering signal is not generated in realtime by a human but from a macro, script or any other robot program. The resulting question is which kind of software is needed for controlling the robot? In the easiest case a robot program is a list of points which are forming a trajectory. In the python language a typical robot program looks like the following example:


moveto(250,200)
time.sleep(1)
moveto(60,210)
time.sleep(1)
moveto(50,325)
time.sleep(1)


The robot program looks different from normal Python sourcecode, it has more in common with a list of absolute values which are executed by the robot. Will this program work? Oh yes it works great, the movements are executed precisely. The more complicated question is, if the robot movements are useful for the environment. That means, in a real life application an industrial robot is asked to do a task, for example to pick&place an object. The robot can fulfill the task or not.

The same robot program can become a failed robot project or a successful robot project. It depends on the task. If the task is easy the given robot trajectory will solve the problem. But if the environment changes to much, the trajectory of the robot doesn't make sense and it won't be able to pick&place any objects.

The overall successrate of the robot project depends on two factory. The robot program and the task description. The combination of a simple repetitive task and a simple robot program is a great choice. The problem is, if the task description is complicated but the robot program is an easy one. The result is a failed robot program.

Let us take a look into real applications. A welding robot is a typical example of an easy task description plus an easy robot program. The task for the robot is, to move the endeffector precisely along a list of points. The trajectory is always the same, and not kind of planning is needed. Such a task can be realized with the mentioned robot program which contains of two simple actions: moveto and time.sleep. The problems will upraise if the task description is more complicated. For example, if the robot should pick&place objects, but the objects can have a different location. In such a case, the easy fixed trajectory of the robot won't be succesful anymore. There are two options available to overcome the issue: first reduce the task description into something more easier or secondly, increase the complexity of the robot program.

A slightly more advanced form of creating a robot program is working with Object action complexes. This technique is derived from the STRIPS notation. The idea is not only provide a list of points, but provide a list of actions which can have preconditions and postconditions. Such motion primitives can be reordered so that the robot isn't executing a fixed trajectory, but is able to create different plans. The good news is, that the STRIPS notation can be used to generate a fixed trajectory as well.