Off-Line Robot Programming Framework

Vitor Santos Bottazzi

Industrial Electronic Engineering Department
University of Minho
Braga, Portugal 4710-057
Email: bottazzi@dei.uminho.pt
..
Jaime Francisco Cruz Fonseca
Industrial Electronic Engineering Department
University of Minho
Braga, Portugal 4710-057
Email: jaime.fonseca@dei.uminho.pt
Telephone: (351) 253 510193
Fax: (351) 253 510189

Abstract— The industrial robot programming is a work for specialist using teaching techniques, have to be able to program a motion
in robotics. Today, this work is very hard because there are many sequences those results in a specific task. The main steps to program
robot manufacturers with different languages and different programming
an articulated arm are described by (Fuller, 1999): First is defined
environments. Although, off-line programming is an way that can reduce
drastically the machines stop time to maintenance. the problem. After that, outlines the steps of an solution. Next
With the use of object oriented design patterns, it is possible minimize express the steps in the computer robot language, then enter the
the time spent in robot programming. In this work is proposed a steps as instructions into the robot controller, and finally check out
off-line programming environment. This tool is based in one abstract the resulting solution. Specifically enter the steps as instructions into
model to program robots, encapsulate in java classes. This way has the
main advantage of best source code utilization. Grouping the business the robot controller is described in the picture 1.
classes in modules by functionalities, we can reduce complexity between The off-line programming method was created to diminish the
low matching. Recognized patterns like Facade and Template Method integration cell time. But actually, the off-line programming has not
will construct the base to develop this programming framework. The brought significative gains to the manufacture cell integration, also
programming robot languages tested in this work was Rapid, Karel
and Melfa Basic IV, respectively languages used by ABB, Fanuc and
to reduce the robot programmer worked hours. The assembly and
Mitsubishi constructors. program manufacture cell tools were projected without the necessary
abstraction, to generalize the robot programming problem. The
Index Terms— Framework, off-line programming, robot code genera-
tor. available tools presents in the robot kits, can program and interact
only with it platform, files and libraries. The demand grows by an
unified tool that interact between different manufacturers solutions,
I. INTRODUCTION turning easy robot programming to the companies.
Quality and efficiency are characteristics that influence world-wide
economy. After the Total Management Quality(TMQ)(Patterson,
1995) and other quality patterns appearance, product cost reduction is
the main topic discussed by the employs. The employers technologic
level adopted defines the competitive difference between businesses,
and increase concurrence. So, tools development that makes easy
robot programming and may reduce the manufacture cell integration
process costs can be an interesting solution. Actually many employs
are working in the robotic segment and the robot programmer have
to flexibly programming over many different robots interfaces in
many different robot languages. The teach pendant(TP), a joystick
plugged in the robot controller, is one of these used interfaces for
robot programming. This joysticks has layout, weight, buttons and
command sequences completely different between manufacturers.
This interaction become too difficult for professionals that do not
have an affinity with robotics. Knowledge about how to welding,
paint or manipulate industrial tools are also very important to
automate the task. Beyond the robot common knowledge, the
programmer need to know the automatized process bringing real
profits on product quality, equipment durability, and decrease
manufacture time. Using a text editor or some specialized robot
programming tool, an welder may program a robotized welding task Fig. 1. (Fuller, 1999) Point-to-Point Robot Programming Process.
optimizing significantly the process. But commonly, it programs
are made manually by TP, spending a lot of time and requiring Actually, the personal computer(PC) is able to manipulate strings
available equipment to do it. During this process, the programmer and solve matrix operations. We propose to use this intrinsic PCs

Proceedings of the Joint International Conference on Autonomic and Autonomous Systems

and International Conference on Networking and Services (ICAS/ICNS 2005)
0-7695-2450-8/05 $20.00 © 2005 IEEE
 features, through an software implementation that knows the robot used at present work was: Factory, Singleton, Facade, Memento,
programming languages. Respecting the working area(Murray, 1994) Command e Template Method. Next we will discuss this OOP
and using an communication protocol to interact with the robot techniques applied in the generator code development, his labels,
controller is possible develop off-line robot programming. common problems solved by this practices, it micro-architecture,
Sensors technology associated with the power processing of PCs and implantation consequences.
is bringing new possibilities to industrial applications. Obstacle
detection and computer vision are applications examples that are
being tested and improved every year (Fuller, 1999). The interface
proposed process the input data in the system and generate an B. FACTORY
specific command sequence to the robot, that will reproduce the This pattern centralizes the objects creation with high changing
idealized motion by the user. The target activity: weld, assembly, project probability in a single class. It cam be understood like an
inspection or another one, can be programmed by the welder, for objects factory. The demand of a class that centralize the objects
example. He will program a motion sequence described by the creation was the motivation to idealize it. Prohibiting any other
manipulator through software, using a common PC. The emphasis object of business class to instance directly objects. The source
of the present work, is develop a code generator to different robot problem is: if an signature method changes in a specific class, it will
platforms, starting an research line on off-line programming area. be necessary change all of direct instances to it class, becoming hard
This research intends to demonstrate that the manufacturing cell and complex work, considering that this object is being instanced
integration can be accelerated, the communication between different by many classes. The proposed solution was develop an centralized
platforms of robots can be optimized and costs with specialized solution class, responsible to create and return instance references
people can be reduced. Actually, the robot programming is still a from all called objects. If some object charger method changes,
hard work (Wrn, 1998). Some causes are: difficulty of available in the factory class, it will be centralized in the getInstanceX()
equipment reserve to improve it, complex handling, and technologic method, where ”X” is the name of a class that contain the object
approach demanded to learn it. attributes(identity) changed. The strategy was analyze the list of
The main target of this research is develop an tool that makes classes that has an big probability to change and implements the
easy robot programming and learning it. A little approach of object getInstance() methods to them in the class factory.
oriented design pattern(OODP) (Helm, 1995) techniques was used in
this code generator and will be discussed at section II. In section III Example:
frameworks characteristics will be presented. Section IV shows the ;This method returns an instance to the
generator code business classes dynamic. In section V are showed "AbbPoint" object charging by an general "Point"
the experimental results. Finally, in section VI the conclusion and object, the Rapid commands to ABB robots.
future works. method getNewAbbPoint(Point p)
{
return new AbbPoint(p);
II. USED PROJECT TECHNIQUES }
The abstraction is a very important feature when thinking
about industrial machine programming. Code abstraction makes
possible work with industrial equipment that is in the coordinates C. SINGLETON
motion command universe. A good modelling of basic mechanisms
Is a pattern that prohibit the duplication of objects in RAM
structures like: joints, axes, programs and points can facilitate the
memory. Your meaning is ”unique instance”. It was idealized because
routines implementation and strings manipulation composing the
during the program execution many objects are recreated without
motion command that will be transmitted to the robot controller. At
real requirement, reflecting in memory and processing overhead. The
this section we will explain how programming techniques helps to
main problem attacked by it DP is the memory wastefulness caused
represents these structures and organize sequentially robots control
by the sub-utilization of created objects in memory increasing
commands.
the overhead caused by the garbage collector(java virtual machine
service that monitories and deallocate the unreferenced objects in
memory).
A. DESIGN PATTERNS - DP
Experience is an evaluated characteristic in every kind of business.
Also in oriented object programming(OOP) is useful adopt renamed Class
programmers successful experiments and relates, called Design
Patterns.
Object Object
Code reusability is one of the benefits brought by OOP. But,
projecting an reusable object oriented software is a hard work. Request Reference
In the project phase, it is necessary partition the problem in
general modules capable to be used in the future in convenient Object in
situations. During the analysis process is necessary identify class Memory? Yes
and communication models(or templates) between objects that can
be reused in the object oriented system. Specific development No
problems are targeted by OODP bringing flexibility, elegance and
reusability code. Resuming, DP is an high level mechanism that Object Creation
relates the best programmers practices(successful experiences) to
solve software projects common problems. The DPs (Helm, 1995) Fig. 2. Singleton pattern.

Proceedings of the Joint International Conference on Autonomic and Autonomous Systems

and International Conference on Networking and Services (ICAS/ICNS 2005)
0-7695-2450-8/05 $20.00 © 2005 IEEE
 The present solution was, to verify during object creation, if it Example:
still exists in memory. The direct consequences to it practice will: Charger Class method ProgramTypeCharger()
decrease process overhead caused by garbage collector and increase {
the objects useful life, reflecting in a better memory resources ;request a new robot program to factory receiving
allocation . The follow strategy was represented in picture 2. If the the protocol and the program name from interface.
object still exists in memory is returned an reference to him, else }
the object is created and also is returned an pointer to it new object. method PointCharger()
{
Example: ;request new coordinate point to factory Charger
;This method verify the existence of an and insert the command in the program using
object that knows Karel Language used by Fanuc supplied parameters from interface.
Robotics. If it is, returns an reference to this }
object, also create a new object and returns it method FileCharger()
reference. {
method FanucPoint getNewFanucPoint() ;request the file creation from interface to
{ storage class setting program and protocol used.
exists in memory a FanucPoint? }
If yes, return a reference to it;
Else create new FanucPoint and return a pointer
to it in memory; E. MEMENTO
}
It is a pattern that stores the last recent memory interactions with
the software, making possible recoup effected operations. Can be
understood like ”Undo”. This demand was perceived when the user,
D. FACADE seeking an program creation though line needs to undo(turn back)
some interactions in the code. The problem detected is: how to
The facade pattern decouple user interface and business classes, store the working structures? The proposed solution was store the
through a knew default data input point. The meaning of facade objects state in a list, to restore it if necessary. Thus the user can
can be understood like ”consensus”. It was implemented to make undo executed steps if it is necessary. The main objective of this
possible connect different interfaces with the business classes, pattern is creating an user-friendly interface. The strategy is create
through an centralized data input, decoupling interface and business a collection that memorize the user steps, defining a structure that
layers. That problem is: if the interface changes, also will be stores and restore the objects attributes, making it persists in memory.
necessary changes the businesses classes to compatible it. This
pratique suggests the creation of a class that hide interface layer Example:
system complexity and alow interaction with any kind of input, like ;Two lists are instanced in the Program class the
command prompts, database querys, applets or simple applications. first is used to generate the robot program and
The direct consequences will be decrease interface interaction the second to implements the memento pattern.
complexity and decouple interface from business layer. Thus all method Program()
dependencies between involved entities in the use cases, will be {
transparent to the user. Another visible gain is, the easy software String idprog;
maintenance. Reflect in fast interface modifying and new interface List PointsList;
input creation. List PointsListVarCoord;
The strategy was implements a Charger class, that knows how to }
talk with the business layer and known by interfaces that want to
use the service. This way will make possible change the presentation
layer(interface) without big software set adjustments. The picture 3 F. COMMAND
show the functionality of this pattern. Is possible see in the example
above how Charger class talks with business layer and the data This pattern generates interface command decoupling actions of
inputs centralized model. it causing events. The name of this pattern can give na idea of his
functionality. Command pattern is necessary because the user is
forced to execute system functionalities through data input interface
objects(Menu, Button, CheckBox,...). The user interface generation
tools has menus and buttons objects responsible for ”commands”
entered by the user. Action are responsibility of business classes.
The user interface objects should not implement the explicit action,
because only the business layer should know how to do it.

The solution adopted is showed in picture 4. All current interface

instanced objects know only a reference to the method responsible to
execute the user desired action. It decouples interface and business
layer functions. The chosen strategy is, the interface objects only will
know the system default input point(the Charger class implemented
with Facade pattern). Thus interface objects invoked by the user,
Fig. 3. Facade pattern. have to reference the method located in the business layer to execute

Proceedings of the Joint International Conference on Autonomic and Autonomous Systems

and International Conference on Networking and Services (ICAS/ICNS 2005)
0-7695-2450-8/05 $20.00 © 2005 IEEE
 Fig. 4. Command pattern.

Fig. 5. Template Method pattern.

actions, using the common input point, the Charger class.

Example:
;Interface Applet
the abstract and child classes. This practice allied to dynamic
class Applet
binding are the bases to a framework building. A little introduction
{
of frameworks will presented in the next section. An TM example
Charger charge = new Charger();
is showed below.
;The method ProgramGeneratorButton() delegates
through an object instance called "charge" the Example:
responsibility, robot program file generation.
;Abstract Class
method ProgramGeneratorButton()
abstract class TemplateFile
{
{
this.charge.FileCharger(); abstract method ProgramHeader ();
;call FileCharger() through instanced object abstract method ProgBodyVarsDeclaration();
charge. abstract method CloseProgram();
} method FileCreator()
} {
;create a robot program and return a report
class Charger message.
}
{
}
;The Charger class is remodelled like Command
pattern receiving requisitions and distributing
;Concrete Class
competencies. class KarelFiles extends TemplateFile
int prot; {
List prog; method PointsCoordVarsReturn()
Factory f = new Factory(); {
;Method FileCharger() calls the responsible robot ;while exists variable names in list, write
program file creator object setting the generic (varName+":POS(0,0,0,0,0,0’’);");
program and the desired protocol. }
method FileCharger() method ProgramHeader()
{
{
write("PROGRAM "+ this.nome);
RapidFile createfile = f.getFileInstanceRapid();
write("-- ! LANGUAGE KAREL 2");
createfile.FileCreator(this.prog,this.prot); write("-- ! MEMORY 8192");
} write("-- !ROBOT ARC MATE 120iB");
... write("-- TEACHPOINT DECLARATIONS");
} }
method ProgBodyVarsDeclaration();
{
;Var declaration
G. TEMPLATE METHOD-TM write("VAR");
This pattern helps to define an skeleton algorithm. This skeleton ;insert coordinates and quadrants seetings using
will be used to specialize subclasses that inherit the object abstract PointsCoordVarsReturn();
common model. ;Main program
write("BEGIN");
It allows an father class refinement from child classes realizing it
;insert motion command lines;
reality. This technique consists in create a template to be specialized }
by child classes. It classes will materialize its behavior over charging method CloseProgram()
father class methods through polymorphism, showed in picture {
5. The TM direct consequence is increase code reuse. Although ;insert the end instruction into robot program;
reflects in couple caused by the implemented inheritance between }

Proceedings of the Joint International Conference on Autonomic and Autonomous Systems

and International Conference on Networking and Services (ICAS/ICNS 2005)
0-7695-2450-8/05 $20.00 © 2005 IEEE
 } features and easy project maintenance. It exceptional capability at-
tends fully to OO concepts making viable the code generator develop-
ment. The Project is composed basically in 5 packages that subdivide
III. FRAMEWORK the off-line programming basic responsibilities. This packages was:
interf, optimize, service, protocol, and persist. How its packages
Is an work layer where all knowledge about the predefined activity
works will be explained in this section. The development model
is encapsulated. Some characteristics of OO like dynamic binding,
adopted was 3 layer project. This model is divided in presentation,
polymorphism, and inheritance make easy structures modelling it.
business, and persistence layer.
These techniques were widely used to reusable, abstract, and spe-
cialized object creation. Make objects interact and communicate
dynamically is the most important thing in the framework building.
The framework concept is so important to develop the robot code
generator presented in this research, because it has to generate
many different specific robot languages. Sometimes to implant the
framework model is necessary redesign all the application to support
its powerful interaction. Wherefore, the OODP and framework docu-
mentation is so important, prevents completely remodel the projected
system if appear some located change demand.

IV. CODE GENERATOR FOR THE ROBOTS

Quick Teach(ABB), WinOLPC(Fanuc), and Cosirop(Mitsubishi)
are some of off-line programming simulators available in industry.
This simulators are able to command its respective robots, using his
proprietary robot programming languages, without worry in interac-
tion between this platforms. In this work, the programs structures
composed in the code generator were builded using the basic robot
motion commands found at ABB, Mitsubishi, and Fanuc technical
manuals. Using robot programming common parameters like: Motion
type, Point Name, Manipulator position coordinates, displacement
velocity, and precision target. This knowledge is represented into Fig. 7. Classes Diagram.
special classes and validating it with the convenient DP was possible
implements an intermediate generic language responsible to represent
robot commands. It intermediate language is showed in picture 6 and A. PRESENTATION LAYER
can be used to write the same program to 3 different robot platforms.
The interf package represents the interface layer and is responsible
Insert a new robot language becomes easy through new protocol class
to system data input. It can be an database query, an application
creation shall the OO project nature. We can see in the picture 6, the 4
running in the host PC or an Applet browser showed in picture 7.
columns that compose the robot intermediate code. The first column
At present moment, the package interface is the unique framework
represents the motion type, the second one the name of position
module that is completely decoupled of the business layer. It can was
variables, the third is the motion velocity, and finally fourth column
explained widely at section II-D.
shows the point reach precision.

B. BUSINESS LAYER
It was drew up by service, protocol, and optimize packages.
At service package is generated the intermediate code using input
interface instructions. It package hold the most important system
classes because there is generalized points, axis, coordinates, and
robot program. In protocol package was the classes responsible
to convert the intermediate code to specific robot code chosen at
interface layer. Optimize package is a set of classes that regulates
interaction between different business classes. In other word, this
package brings benefits to application centralizing data input and
object creation through Charger and Factory classes respectively.

C. PERSISTENCE LAYER
It main function is taken care of robot code generated store.
The persist package automatize the natives manufacture languages
Fig. 6. Intermediate generic language. structure and extension knowledge through Java classes. Each class
responsible to an specific robot language template. This Project
Components reuse is an OO language intrinsic feature and can be adopts OO techniques using J2EE applied to robot programming.
reached through many ways. Good practices to increase reuse are The proposed software intends to enable professionals that were being
applying the OODP techniques described in section 2. The chosen substituted by robots work, to program it. Using an class formalized
language was Java 2 Enterprize Edition(J2EE) to bring this powerful knowledge, this software have to facilitate program an robot motion

Proceedings of the Joint International Conference on Autonomic and Autonomous Systems

and International Conference on Networking and Services (ICAS/ICNS 2005)
0-7695-2450-8/05 $20.00 © 2005 IEEE
 type, with it own precision and velocity between two different points
in a 3D reality. Everyone PC can be used to programming and
communicate with robots. Because the portability brought by Java
virtual machine and the PC communication devices are compatible
with all contemporaries robots. The abstraction adopted using the
OODP described in section II allow increase interfaces, communica-
tion protocols, and robot languages.

V. EXPERIMENTAL RESULTS
The experience proposed to demonstrate the software function-
alities was, write the acronym UCSAL in a white board using
two different robots. The robots were programmed using the code
generator described in this research and showed in the picture 8.
To explain the experience and the software utility, was idealized the
motion sequence to write the acronym UCSAL in the white board
using a pen griped by the manipulator. To make the character ”U” Fig. 9. Communication proposed to future works.
is required 1 circular motion, to ”C” another circular motion, to ”S”
two circular motions, to ”A” tree linear motions and finally to ”L”
two linear motions. Beyond the motion type, for each displacement, Because the development focus was made an portable software,
is essential set up point names, velocities, and precision. Is also capable to write robot programs to different manufacturers languages.
necessary set up points out of the white board between the characters Hence actually, RoBott is able to generate particular files to different
writing, to define the attack angle of the pencil. Like the coordinates platforms through different interfaces running in different operating
capture was not also implemented, it is been made by teaching, using systems. The next step is use piece neutral project files like: step-nc,
the joystick linked to the robot controller to set the xyz coordinates. iges, dxf, and sat files. Capturing the intrinsic piece coordinates
through his neutral projects and calculating the extrinsic coordinates
will allows the piece manipulation. The position coordinates input,
simulation, and the PC to robot communication will be discussed in
a better chance.

Acknowledgements. This research was carried on in the con-

text of the Master Industrial Electronic Engineering. Project Sup-
ported by the Programme ALBAN, the European Union Programme
of High level Scholarships for Latin America, scholarships no.
E04M033540BR. Thanks to CIMATEC - Technology and Manu-
factory Integrated Center of SENAI-BA, Brazil.

REFERENCES
Fuller, J. L. (1999). Robotics: introduction, programming, and projects.
Prentice-Hall Inc., London, 2nd edition.
Helm, R. (1995). Design Patterns: Elements of Reusable Object-Oriented
Software. Addison-Wesley, ISBN 0-201-63361-2, 1st edition.
Fig. 8. Application interface. Murray, R. M. (1994). A Mathemetival Introduction to Robotic Manipu-
lation. CRC Press, Florida, 1st edition.
Patterson, J. G. (1995). ISO 9000: Worldwide Quality Standard. Crisp
The experiment was successful. Creating an intermediate program
Publications, Inc., California, 2nd edition.
using RoBott and seeting the coordinates by teaching. It was able Wrn, H. (1998). Automatic off-line programming and motion planning
write the acronym UCSAL using ABB and Mitsubishi golems. The for industrial robots. In ISR98, 29th International Symposium on
file transfer of robot programs, at present moment is done by floppy Robotics 1998. ISR Press.
disk.

VI. CONCLUSION AND FUTURE WORKS

The facilities brought by OO Project nature makes possible in
a posterior implementations add sensors and artificial intelligence
techniques updating the software application area.
The system, after some changes, can be centralized in a server
showed in picture 9 and interact with a motion coordinates data
base of a manufacture cell, or facilitate program(task) migration
between different robots. Also is possible develop new protocol
classes allowing work with other machines, that have the same action
principle of robots, for example: a CNC or a five axis machine.
The implementation of motion coordinate inputs, through an
3D simulation and PC to controller communication was not made.

Proceedings of the Joint International Conference on Autonomic and Autonomous Systems

and International Conference on Networking and Services (ICAS/ICNS 2005)
0-7695-2450-8/05 $20.00 © 2005 IEEE