Approach to Robot Programming

The industrial robot programming task is done basically in two ways:
1. The programmer in task charged can use some modeling technique but, instead of thinking only about the problem, it is necessary to think about the robot that will run the program, and about its programming language. Both the language and the robot will limitate the specification of the problem; moreover it is not possible to reuse the same program in a different robot.

2. The programmer uses some environment of graphical development, where is possible to test the program before using it in the robot. It is also possible to develop programs for different robots, but it is necessary to have a library for each robot. Even with these facilities, these tools do not solve the programming problem of the robot to interact with its environment.

The programming languages of industrial robot did not evolved in the same manner as the computer languages. Those environments and languages have some drawbacks:
• The typical languages are low-level, imperative, or structured. Both of them are more closed to the robot specification than to the problem, difficult the problem modeling task and all other good practices that a correct software engineering should require.
• Each industrial robot has its own programming language, which difficulties, or even turns impossible, to reuse the source code.

There is the problem to be solved. It will be used an adequate modeling technique, responsible for decompose the problem into simple problems, that would be easily programmed; formal models are employed to describe data structures and operations necessary to solve the elements sub-problems. To describe formally the overall problem and the sub-problems, a truly high level language, closed to the specification instead of the robot, should be used. Then we advocate the use of an easy-to-use compiler front-end, like Grafcet, that can interpret the specification language and generate an intermediate description for the program specified. An intermediate representation is used because the front-end must be focused on the specification of the problem, and not on the robot.