On the first look the task can be solved with creating a script, very similar to automating a task on the computer with a Visual basic script. A potential program consists of building blocks like if-then, for loops and action statements. This will allow the human operator to take away the hands from the remote control and the robot will work by it's own. Really? No it was a rhetorical question because one important thing was ignored in that tutorial. The interesting fact with scripts for robots is, that they doesn't work in reality but only in a synthetic challenge.
Let us describe the pattern what is used by self-claimed robotics experts who like to proof that autonomous robotics is available. At first they are creating a macro for the robot. The script is doing a concrete task. For example, the robot is searching for line on the ground, then the robot follows the line, and if an obstacle is there it will activate a submodule to move around the box. In the next step, a game is constructed which contains of a line on the ground, a robot and an obstacle. Then the start button is pressed and the robot is working autonomously.
The problem with this demonstration is, that the task was created in response to the script. That means in the first step the macro was written and in the second step the problem for the macro was imagined. Unfortunately, the macro can't solve real tasks. This kind of bottleneck is often ignored. The assumption is, that the script can be extended to more demanding applications. It's funny to realize that not a single autonomous robot is available which is solving a practical application. So called autonomous robots are only available for trivial examples.
A possible explanation for this mismatch has to do with sorting tasks by it's complexity. The hypothesis is, that two sorts of problems are available: easy to automate problems and hard to automate problems. The problem “Follow a line” is an easy to automate problem. Replacing a human worker with a robot is a hard to automate task. What robotics engineers are able to automate are only trivial tasks. These tasks are constructed so that a robot is able to fulfill it autonomously. What robotics engineers aren't able to automate a real tasks which are important in the real life.
The funny thing is, that on the first look both task categories are looking the same. Suppose, in a factory there is a line on the ground and the transport vehicle has to move on that line from start to finish. It's exactly the same task which was automated by a script, so is the hypothesis wrong and it's possible to automate real life tasks? No it's not. A simple look into the reality will show, that not a single automated robot is available which is used for a line following task. If a company is using a robot for this task, a human operator controls the robot all the time.
Or let me explain the situation from a different perspective. Suppose, in a factory there is a transport vehicle which is moving on a line. The robot is remotely controlled by a human operator. The prediction is, that it's not possible to replace the human operator with a software program. Because what the human is doing is a little different from executing a simple line following algorithm.
To understand the paradox better we have to take a look at a task which is remote controlled already. The best example is a crane. A human operator sits behind a joystick and has to press the buttons. The operator doesn't invest physical energy into the system but only his ability to control the crane is requested. Such a crane is available on most construction sites in the reality. Now it make sense to think about increasing the productivity. The idea is, that the human operator costs too much and he can be replaced with software. Technically, a simple USB cable can be plugged into the joystick of the crane operator and then a computer is in charge of all the operation. The only what is missing is a piece of software. And at this point the problem will start. There is no such thing available like a crane control software. What the engineers have to do is to create it's own sort of software. A first step would be to create submodules for a program for the basic features of the crane like open the gripper, unload the box and so on. And then an overall highlevel planner has to decide which operation is next.
The problem with such an automation attempt is, that it will fail in reality. The computer controlled crane will behave different from a human controlled crane. That means, the system can't be used in the reality. What the human operator will do is to deactivate the program and control the crane with the normal joystick. And he is right, because it's the only option available.
The problem is not located in the crane itself. Because in the lab the software auto mode will work great. The crane is able to execute a longer program for pick&place objects. What is wrong is the reality, which provides a different kind of problem. That means, the task which is solved by the software and the task on a real construction site are different. A human operator is needed, because the real crane has to do with unstructured situations. Each day the problems on the construction site are a bit different.
A robot program
The idea of a teleoperated robot is, that all the actions are initiated by the human. Apart from the human-machine-interface no additional software is there. The opposite of teleoperation is a system which has to be programmed. A robot program is a script which runs without human intervention. For most real life applications no script is available. The answer to the problem is, to modify the application into the direction of an easy to automate task.
The reason why a program controlled robot is prefered over a teleoperation system is because it has a higher productivity. Instead of training a human operator, the idea is, that the robot can execute the task by it's own. Apart from the written script no additional input data are needed. The only problem is how to write a robust script which is able to solve important tasks?
Industrial robots are usually programmed with a trajectory table. That is a list of points in the space which are reached by the robotarm in a sequence. A typical robot program looks like:
p1, p2, p3, p4, p5, stop
The disadvantage of such script is, that it's not very robust. But in some cases it works. The question is, why exactly is a list of points powerful enough to control an industrial robot? The answer is, that the task was modified in a way, that the robot is doing something useful if he repeats over and over the same sequence. In general there are two strategies available for robot programming. The first one is to make the original task more easier for a robot, and secondly improve the software so that it can handle more complicated tasks. Let us try to improve the robustness of a robot program. A more elaborated example if formulated in the STRIPS notation. The robot executes steps, and each step has a precondition and a postcondition. For example:
step1, pre=gripper(100,100), box(50,50), post=gripper(200,100), box(50,50), action
step2, pre=gripper(200,100), box(50,50), post=gripper(250,100), box(150,50), action
step3, pre=gripper(100,100), box(50,50), post=gripper(200,100), box(50,50), action
Similar to the first example, the scripts executes a predefined robot trajectory. In this case, the some constraints checks are made to investigate if the robot and the box are inside the expected range. If not, the script stops with an error message. The advantage is, that smaller problems during the execution are recognized autonomously.
Both examples have the disadvantage that the script is static. That means, the script is executed from top to bottom and no planning is available.
Instead of explaining how to create more advanced robotics script the better idea is to focus on the most simple robot program which was given in the first example. In the simple case, the robot program contains of a point list which are traversed by the robot. It's not like a classical computer program but it looks like a pattern. The program is equal to a trajectory which gets executed with the start button. The only open problem is to find a task for such a program. That means, the robot by itself is working great, but what is missing is a situation in which the program makes sense. A very easy pick&place robot can be programmed with that principle in mind. The robot isn't able to detect objects, nor the system is able to avoid obstacles. Instead the environment has to be static so that the same trajectory results into a success. A possible usecase is, if all the products on the assembly line are at the same position and there is only size of the product available. The robot picks the object and transports it into the box, where the objects gets released.