- Email: [email protected]
A robot simulation system for small and medium-sized companies
ELSEVIER
Copyright © IFAC Robot Control, Wroclaw, Poland, 2003
IFAC PUBLICATIONS www.elsevier.comllocale/ifac
A ROBOT SIMULATION SYSTEM FOR SMALL AND MEDIUM-SIZED COMPANIES
H. Roth, M. Ruehl, F. Dueber University ofSiegen, Hoelderlinstr. 3, 57068 Siegen, Germany
Abstract: The simulation of industrial robot systems becomes more and more important. Almost all companies in the automobile industry simulate their robot lines before the real systems are built up. By the usage of simulation systems one can reduce the costs of a robot system, test and optimize the robot programs and ensure the absence of collisions. At the moment there exist several commercial simulation systems, but for small and medium-sized companies there is no really applicable system available. This paper explains a robot simulation and programming tool called ROPSUS++ that is developed especially for those companies. All important parts of this software system are explained. In addition two special features, the collision detection and the path planning system, are described in detail. Copyright © 2003 IFAC
Keywords: robot off-line programming, industry automation, robotic manipulators, obstacle avoidance, path planning, configuration space
I. INTRODUCTION
tuitive. That means the user should be able to guess the functionality behind a button. Because the system is developed for small companies it must be cheap.
The University of Siegen develops a robot simulation system for small and medium-sized companies. It is called ROPSUS++ (Robot Programming System of the University of Siegen). The goal of this project is to offer the smaller industry an alternative to the common simulation tools. There are several simulation systems available. The most common are the IGRIP and the ROBCAD system. These systems are very expensive and therefore not applicable for smaller companies.
The ROPSUS++-System fulfils all these conditions. The next chapter gives an overview of the most important components of this program. The following chapters explain special features of ROPSUS++. Chapter three and four contain details about the data management. Chapter five describes the collision detection and chapter six the path planning system used in ROPSUS++.
Nevertheless the simulation of robot systems is very useful or these smaller companies, because they can reduce the costs of such a robot system, test and optimize the programs and ensure the absence of collisions. Simulation becomes more and more important. So there is the need to develop a system that can be used by smaller companies. This system must contain all important features for robot simulation (e.g. collision detection, omine programming tool, CAD import, path planning system, etc.). On the other hand the system must be easy to use for the customers. For this the user interface should be in-
2. COMPONENTS OF ROPSUS++ This chapter gives an overview of the important components of the ROPSUS++ simulation tool. For building a realistic three-dimensional model the system uses a common CAD-System. The data for kinematics of robots and other devices are managed by an intuitive window. And for programming the robots we developed a graphical programming system.
91
2.1 CAD-System
On the left side of this window there is a tree-structure containing the information of the current simulation model. This tree consists of a few mangers for different types of simulation data. For example there is one manager for the robots, one manager for the motion paths and one manager for other devices. Every manager administers one type of simulation data. The user can directly see all simulation data in the treestructure. A more detailed description of one object can be seen on the underlying layers in the tree. For example the first robot in figure 1 consists of a linkage object and a control object. The linkage of the robot consists of six joints.
To be able to develop a realistic simulation of robots in their environment one must build up a three dimensional model of the robots and all other objects around them. For this the simulation program must be able to either import CAD-data from other programs or to offer a CAD-tool on its own. ROPSUS++ is based on an existing CAD-Program. This program is named CADdy++. It is developed by the German company DataSolid GmbH. It is an often used program by small and medium-sized companies. By this the user is able to build up a static three-dimensional model of his device with CADdy++ and after that he can directly use this model for a dynamic simulation in ROPSUS++. The advantage of this approach is that in contrast to the most other robot simulation tools there is no need for importing CAD-data from other programs. In most cases this importation is not error free and the user is forced to correct the data before he can go on in the simulation program. In ROPSUS++ one can directly use the static data for dynamic simulation.
On the right side of the window the user is shown the parameters and settings of one object in detail. In the figure the values of the six joints and the position and orientation of the tool centre point of the first robot can be seen. By this structure it is on the one hand very easy for the user to keep a good overview of the simulation model and on the other hand he can change the parameters of a special object very fast.
2.3 Graphical Programming Interface 2.2 Ropsus-Explorer In addition to the setting of geometric and dynamic .~ properties of the objects in the simulation the user should be able - re '" to program all dynamic devices.
After building the static geometry of the devices the user must set the kinematics data for them. For example the simulation tool must know how many joints belong to a device and which part of the device should be moved with the change of the joint's value. The user must tell the system if the joint is a revolute or linear joint. He must set the acceleration and the maximum velocity etc..
~~i~o~~ co:~:n ~~UI~~~~gtoo: commands in a normal editor. For we the ROPSUS++-System developed a graphical programming interface. The user is offered all possible commands for the current device in a window. In another window he can see a flowchart of his program. Here he can insert additional commands simply by "drag and drop" a corresponding symbol. Figure 2 illustrates such a flowchart of a robot's program. of these The parameters commands can be set after a double click on the corresponding symbol.
All this information is managed in ROPSUS++ by a single window, the so called ROPSUS-Explorer. Figure 1 shows this window for a simulation model that consists of two robots and other simulation data.
=- _.: F~;
~:
3R.obotI!f_1
_.
_ _3
_ _5 _ _6
--.;:
-<_d L'fR_"_2
t::-
;;Devo<"""-
c..t:P~_1
ps.i6iJ·
X:
I'SZIl...
iJ iJ
~iJ·
f:
1-0:0;·92
P:;-iJ·
z:
~iJ·
Y.u
f7.91iJ '.,66.0, iJ
T.Ql!ll:Port_Z
_ _'*-'- I
3 rl--------3...,.
5d_·1
Fig. 2. Flowchart
The simulation of robots within their working environment uses a huge amount of data such as geometric layout, kinematics and others. Though ROPSUS++ is based on CADdy++ which already has its own model ROPSUS++ implements a separate one referring to the logical view of robots, not the geometric view as done in 3D-CAD applications. The two models exist parallel with structural links between them. That is, geometry isn't duplicated for the logical model but linked with the geometric one.
:
__-
fi.1T
3. DATA MODEL
f<.9l±l. """ ps.97iJ P;;-iJ· .... PO:Z;-iJ
~PfacC2
.fJJ'
~
Fig. I. ROPSUS-Explorer
92
Robotics data could become complex depending on the device which is represented. As for example a robot with three joints is quite more complex than a si~ple motion path with four or more target points. This shows the need for a very flexible data model. But a simple structure couldn't fulfil these needs, so ROPSUS++ implements a tree based data structure. The.tree structure implies the advantages of a highly fleXible layout, a fast and easy extensibility and the possibility to design hierarchical dependencies. Each type of data (robots, motion paths, other devices etc.) is represented by one subtree within the globai model tree. As for the representation data of each object type could vary its subtree layout, too. A robot for example could be represented by a subtree existing of four nodes but a motion path by only two nodes. So the layout has to be highly flexible. In case of implementing new or extending existing object types the model has to be modified, too. The simplest way to perform this is by adding a new node to a subtree. Hierarchical dependencies could be useable for grouping different objects. In this case their representing subtrees are reordered within one common node. This action forces the subtrees to 'move down' one step in the trees hierarchy.
Al part tree
BI
Each Part could have its own designation which has to be unique in some local parts of the model tree. To enable the possibility to address a Part by its name the model tree could be treated as a directory structure. To address 'point I' in Figure 3 the directory structure looks like 'root-path I-point I'. Each Part contains the structural information of the tree such as parent node and sub nodes (Figure 4A). Also some administration functionality like traversing the subtrees is located within a Part. In addition to this each Part holds a list of its Properties again with the administration functionality for them. All Parts within the ROPSUS++ model tree have the same structure. There are no different Parts available. In meaning of object oriented programming (OOP): All Parts are instances of one class, there are no derived classes.
In ROPSUS++ these two kinds of information are separated in so called Parts and Properties. Parts contain information about the tree layout and properties contain the model information.
3.2 Property - Model information Properties assign additional functionality and logical properties to a Part. Each Part could hold as much as desired properties (Figure 4B). Properties don't implement administration functionality for the tree. They access the model by using the functions implemented in their container part. In difference to Part each logical property has its own Property, or with OOP: Property is the abstract base class for many different derived classes each representing a logical property in the robotic domain.
3.1 Part - Layout information A Part represents a node within the ROPSUS++ model tree. In this tree there is no difference between node and leaf. At the very beginning of the project the model tree was used to represent robots only, so one node represented a part of the robot device. Until now many other objects are stored as subtree in the global model and the name Part stayed but its meaning has changed from part to node.
3.3 Part Manager - Model tree administration
I
Additional to Parts and Properties ROPSUS++ implements one Part Manager to administrate the whole model tree. Also the trees root node is placed within the Part Manager. As for some restrictions the Part Manager builds the only global access point for the model tree within ROPSUS++. There is no way to address a single Part directly except its name (see Chapter 3. I).
path 1
I ... position + orientation + graphics
I-
point 2
I-
point 3
+ position .. ortentation
+ position ... o6entation
+ graphics
+ graphics
properties of • part
Fig. 4. Structure of part tree A), list of properties assigned to a part B).
The {ree model implemented in ROPSUS++ receives an even more detailed grade of flexibility by separating the model information from its layout information. That is, each node within the tree could have layout and model information. A motion path for example exists of one ore more target points. Each point has information of at least position, orientation and graphical representation. But each point is also a node within the subtree of its path (see Figure3).
point 1
~ ~
1-+
Fig. 3. Layout and model information of motion path 93
4. ROPSUS++ MODEL
Instead of this an Attachment Property is created which represents a bidirectional link between the two related Parts (robot and static device). If the device is released the Attachment Property is destroyed.
After describing the global tree structure (model view) this chapter announces the usage and adaptations in ROPSUS++ (logical view).
All Properties used in the ROPSUS++ model could be divided into two kinds: common Properties used by all types of objects and special Properties only useable for a special type of object. The Geometry Property for example belongs to the first group. Robots, devices and paths need to be displayed graphically. For that all these objects should own at least one Geometry Property. Other Properties like the TDH-Property are useable for robots only.
The goal of ROPSUS++ is the offline simulation of robots within their working environment, so all types of objects in such a working cell have to be considered. At the moment ROPSUS++ implements simulation functionality for robots, static devices like tables, etc. and motion paths. Extensions for sensors, dynamic devices and other object types are under construction. Within the ROPSUS++ model tree each object type has its own subtree which root node is located directly under the model trees root node (Figure 5). To each type's root Part there is a Type Manager attached as a Property. These managers are used to administrate all entities of their specific type. This includes functionality to create, modify, destroy and access one ore more entities. The Property Path Manager for example is attached to a Part called 'Path Manager' which builds the root node for all paths. If a new path should be created a related call to the Path Manager's create function has to be made.
5. COLLISION DETECTION Collision detection is one of the most significant tasks within a simulation system like ROPSUS++. Playing such a central role and being called many times to check for collision the collision detection engine (CollisionEngine) has to be a high performance piece of software. The CollisionEngine implemented in ROPSUS++ uses the geometrical data of the CADdy++ model through the links stored in the ROPSUS++ model (GeometryProperty). The data is stored within structures based on the ACIS geometric modeler designed by Spatial Technologies. It is a boundary representation (b-rep) of the 3D objects geometries. Some of the functionality provided by the ACIS class library doesn't seem to be optimized for collision detection so few modifications of the algorithm are in progress.
This instructs the Path Manager to build a new Part called 'path I', an attached Property belonging to that Part and attach the new Part as subtree to itself. A special kind of Property builds the Attachment Property. In case of a robot grapping a static device the last isn't static anymore - it is now part of the robot. Logically the related Part and its subtree within the ROPSUS++ model have to be moved from the Static Device subtree to the one of the grapping robot and backwards when it is released from the robot. This would last in a lot of moving actions within the tree.
5.1 Four phases filtering The Collision Engine is designed as a multi step system where each computation loop is separated in up to four phases. Within the first phase the relevant geometric objects are approximated by bounding geometries. The advantage of boundaries lies in the reduced time needed for comparing pairs of geometric objects. The complex objects are replaced by their boundaries with a much simpler geometry like spheres or boxes. Practice evaluation has shown that using spheres as an approximation object has other advantages. Rotations of the original geometry haven't to be mapped to the bounding sphere and the distance calculation is reduced to comparing the radii of two spheres. The boundary spheres are stored as an OCtree structure with predefined depth within the ROPSUS++ model. Applying a varying depth (depending on the geometries complexity) of the OCtree structure is one of the next milestones of the Collision Engine's development. Boundaries are computed in the moment a new geometry is added to the ROPSUS++ model. As for some not so well working ACIS internal algorithms this could last some time. That is the reason for another enhancement feature: parallelization of these computations by splitting them into multiple threads
Geo JD Geo JD Geo JD
RM RobotManager PM PathManager SDM StaticOeviceMan
SM SensorManager
Gee GeometryData ...
JD
JointData
Fig. 5. Logical layout of ROPSUS++ model tree
9..+
o
and/or delegating the work to different computers within a network.
no collision test nessessary a) (part1,part1) sen·test b) (pa-t2,part4) = (part4,pa-t2 )
-..
.
.. .. .. ..
N
M
1::
1::
1::
D.
D.
D.
on
1::
1::
D.
D.
I
After generating the boundaries in a pre-computing step in the fIrst phase the main part of the collision detection algorithm could be started. It is build by the next three phases (Figure 6). At the beginning of phase two there will be a defmed amount of geometric objects which have to be compared. They build the so called collision candidates. In phase two these candidates are filtered through a knowledge database - the so called Matrix-Of-Interest (MOl). This is a major feature of ROPSUS++ collision detection framework and will be described later on. After being fIltered by the MOl the amount of candidates will be reduced but is still too much for a time performance collision test. Phase three will reduce the number of candidates further on by comparing their bounding spheres. By comparing the boundaries no statement about collision could be made but a defInite statement about non-collision. If the boundaries don't collide, the original geometries couldn't collide either, because the boundaries are larger than the geometries. These computations can be done much faster than comparing to the complex geometries themselves. The result of phase three is an even more reduced set of collision candidates which couldn't be tighten more at the moment. So the real complex geometries ofthe remaining candidate pairs are compared in phase four. The geometries lasting the end of phase four build the set of colliding objects within the ROPSUS++ model. They are marked as such within the model providing collision information for other subsystems of ROPSUS++. And again the ability of parallelism to increase calculation speed will be used to delegate the collision computations to other threads and/or computers.
part 1 The ma-ked fl8ld represents the candidate
part 2
pa~
part 3
(pa-t2.part4)
I
- ---•
part 4 partS
Fig. 7. Matrix-Of-Interest (MOl) The rows and columns of the two-dimensional matrix represent the geometries one row and column for each (Figure 7). Each fIeld within this matrix represents a candidate pair for a possible collision. The triangular shape has its origin in the equality of the pairings (x 1; y2) and (y2; xl). Information about them are stored only once within the matrix and consider of data about movability, state of last collision test, position and orientation at the last time step (used for fourdimensional collision detection), and much more. All this information is processed by some functions implementing knowledge based candidate fIltering. By this the MOl build a base system for storing all relevant information. The knowledge based functions will be implemented as Plug-Ins which could be added to and removed from the MOl at runtime. These fIlters include: static or non-moving devices couldn't collide by themselves so they don't have to be tested against each other if two parts didn't move within the last timeframe their state didn't change either and is valid without the need of testing again two adjacent parts of the same device connected by a joint collide every time. No check has to be done and they are considered as 'no collision detected' if two parts move with increasing distance and they didn't collide last time they don't do at this timeframe
5.2 Matrix-DJ-Interest -- knowledge basedfiltering One of the most interesting parts of the Collision Engine is the Matrix-Of-Interest (MOl). The MOl could be seen as knowledge based database paired with a two-dimensional matrix with information about the geometry of all objects attached to the ROPSUS++ model.
There is much potential in tuning and enhancing the functionality of the MOl to optimize the process of collision detection by reducing the candidate pairs. Further work is done at this place by developing more Plug-In fIlters and making use of delegating calculations over network.
5.3 Three- and/our-dimensional collision detection There are two different kinds of collision detection algorithms implemented in ROPSUS++. Both of them detect collisions after they appeared not before.
. . Amount of candidate pairs decreases With each step
Fig. 6. Four phases of candidate fIltering The first algorithm detects collisions in three dimensional space at discrete points in time (tn)' That is, after the model is modified by other simulation steps lJ5
within a time slice it is frozen. All geometric objects within this temporary static model are used for input to the collision detection algorithm described in chapter 5.1. After the collision detection ends the next time slice begins and a new simulation step is performed.
1.51
I--+--+--+--t
1.1.1-+--+-1
There is at least one lack within this proceeding. What about collisions appearing between two discrete points of time (t,,:::; t:::; t,,+I)? For detecting the~e collisions a second algorithm was implemented m ROPSUS++. It is based on comparing two swept volumes each build by the bounding geometries of a candidate with its positions in three dimensional space at time t" and t,,+I. By using this data.as input and considering a constant speed of the objects between tn and t,,+1 the time of collision teal with t" :::; teal :::; t,,+1 could be approximated.
·151
.1."
-51
51
1...
1.51
Fig. 9. Motion Planning in the configuration space This is normally done by setting the robot to every possible configuration and checking for collision between the robot and any other object in the environment. For robots with many joints this calculation can last very long. A lot of planning algorithms must know the complete configuration space for the planning. The planning algorithm in the ROPSUS++System does not need to know the complete space.
6. MOTION PLANNING A very useful tool in a robot simulation program is a system for path planning. With such a system the user only needs to tell the system the starting ~d the ending point of a robot motion. Because the sunul~ tion system knows the geometry of the obs~c1es m the environment of the robot, the path plannmg system can calculate a collision-free path between the starting and the ending point.
The planner starts with the direct l.ine pat~ betwe~n the starting and ending configuratIOn. ThIs path IS checked for collision. If a collision exists, the planner calculates the middle point of the colliding path segments and moves this point out of the collision. Then the planning starts again. By this the path is moved step by step out of the collision. In figure 9 one can see a path developed by this algorithm.
There are a lot of path planning algorithms available in the literature. Almost all algorithms do the planning in the so called configuration spac~. In th~s space there exists one point for every pOSSIble POSItion of the corresponding robot. Figure 8 shows a very simple robot with only two joints and the corr~ sponding configuration space. The advantage of thIS space is that the three-dimensional geometry of the robot is mapped to a simple point in the configuration space. Therefore path planning is !educed t~ the search of a collision-free path for a pomt. The dIsadvantage is the bigness of this space. F?r a .robot .with six joints the configuration is a slX-dunenslOnal space.
CONCLUSION In this paper a robot simulation system for small and medium-sized companies is presented. This system is designed as an add-on to a common CAD-program. The user interface is very easy and intuitive. The paper explained the details of the data manageme~t.. In addition two very important features, the collISIOn detection and the path planning system are described.
For using this space for path planning one must calculate the mapping of the obstacles to the configuration space.
REFERENCES T
Cameron, S. (1989). Efficient Intersection Tests for Objects Defined Constructively. In: The International Journal ofRobotics Research. Vol.B, No. I, pp. 3-25. Cameron, S. (1990). Collision Detection by FourDimensional Intersection Testing, In: IEEE Transactions on Robotics and Automation, Vo/.6 No. 3, S. 291-302 Latombe, Jean-Claude (1991). Robot motion planning. Kluwer Academic Publishers
jon2
·125"
:;> .....--- ----.... . -~
)CUt I
75"
Fig. 8. A simple robot and the corresponding configuration space
96
Copyright © IFAC Robot Control, Wroclaw, Poland, 2003
IFAC PUBLICATIONS www.elsevier.comllocale/ifac
A ROBOT SIMULATION SYSTEM FOR SMALL AND MEDIUM-SIZED COMPANIES
H. Roth, M. Ruehl, F. Dueber University ofSiegen, Hoelderlinstr. 3, 57068 Siegen, Germany
Abstract: The simulation of industrial robot systems becomes more and more important. Almost all companies in the automobile industry simulate their robot lines before the real systems are built up. By the usage of simulation systems one can reduce the costs of a robot system, test and optimize the robot programs and ensure the absence of collisions. At the moment there exist several commercial simulation systems, but for small and medium-sized companies there is no really applicable system available. This paper explains a robot simulation and programming tool called ROPSUS++ that is developed especially for those companies. All important parts of this software system are explained. In addition two special features, the collision detection and the path planning system, are described in detail. Copyright © 2003 IFAC
Keywords: robot off-line programming, industry automation, robotic manipulators, obstacle avoidance, path planning, configuration space
I. INTRODUCTION
tuitive. That means the user should be able to guess the functionality behind a button. Because the system is developed for small companies it must be cheap.
The University of Siegen develops a robot simulation system for small and medium-sized companies. It is called ROPSUS++ (Robot Programming System of the University of Siegen). The goal of this project is to offer the smaller industry an alternative to the common simulation tools. There are several simulation systems available. The most common are the IGRIP and the ROBCAD system. These systems are very expensive and therefore not applicable for smaller companies.
The ROPSUS++-System fulfils all these conditions. The next chapter gives an overview of the most important components of this program. The following chapters explain special features of ROPSUS++. Chapter three and four contain details about the data management. Chapter five describes the collision detection and chapter six the path planning system used in ROPSUS++.
Nevertheless the simulation of robot systems is very useful or these smaller companies, because they can reduce the costs of such a robot system, test and optimize the programs and ensure the absence of collisions. Simulation becomes more and more important. So there is the need to develop a system that can be used by smaller companies. This system must contain all important features for robot simulation (e.g. collision detection, omine programming tool, CAD import, path planning system, etc.). On the other hand the system must be easy to use for the customers. For this the user interface should be in-
2. COMPONENTS OF ROPSUS++ This chapter gives an overview of the important components of the ROPSUS++ simulation tool. For building a realistic three-dimensional model the system uses a common CAD-System. The data for kinematics of robots and other devices are managed by an intuitive window. And for programming the robots we developed a graphical programming system.
91
2.1 CAD-System
On the left side of this window there is a tree-structure containing the information of the current simulation model. This tree consists of a few mangers for different types of simulation data. For example there is one manager for the robots, one manager for the motion paths and one manager for other devices. Every manager administers one type of simulation data. The user can directly see all simulation data in the treestructure. A more detailed description of one object can be seen on the underlying layers in the tree. For example the first robot in figure 1 consists of a linkage object and a control object. The linkage of the robot consists of six joints.
To be able to develop a realistic simulation of robots in their environment one must build up a three dimensional model of the robots and all other objects around them. For this the simulation program must be able to either import CAD-data from other programs or to offer a CAD-tool on its own. ROPSUS++ is based on an existing CAD-Program. This program is named CADdy++. It is developed by the German company DataSolid GmbH. It is an often used program by small and medium-sized companies. By this the user is able to build up a static three-dimensional model of his device with CADdy++ and after that he can directly use this model for a dynamic simulation in ROPSUS++. The advantage of this approach is that in contrast to the most other robot simulation tools there is no need for importing CAD-data from other programs. In most cases this importation is not error free and the user is forced to correct the data before he can go on in the simulation program. In ROPSUS++ one can directly use the static data for dynamic simulation.
On the right side of the window the user is shown the parameters and settings of one object in detail. In the figure the values of the six joints and the position and orientation of the tool centre point of the first robot can be seen. By this structure it is on the one hand very easy for the user to keep a good overview of the simulation model and on the other hand he can change the parameters of a special object very fast.
2.3 Graphical Programming Interface 2.2 Ropsus-Explorer In addition to the setting of geometric and dynamic .~ properties of the objects in the simulation the user should be able - re '" to program all dynamic devices.
After building the static geometry of the devices the user must set the kinematics data for them. For example the simulation tool must know how many joints belong to a device and which part of the device should be moved with the change of the joint's value. The user must tell the system if the joint is a revolute or linear joint. He must set the acceleration and the maximum velocity etc..
~~i~o~~ co:~:n ~~UI~~~~gtoo: commands in a normal editor. For we the ROPSUS++-System developed a graphical programming interface. The user is offered all possible commands for the current device in a window. In another window he can see a flowchart of his program. Here he can insert additional commands simply by "drag and drop" a corresponding symbol. Figure 2 illustrates such a flowchart of a robot's program. of these The parameters commands can be set after a double click on the corresponding symbol.
All this information is managed in ROPSUS++ by a single window, the so called ROPSUS-Explorer. Figure 1 shows this window for a simulation model that consists of two robots and other simulation data.
=- _.: F~;
~:
3R.obotI!f_1
_.
_ _3
_ _5 _ _6
--.;:
-<_d L'fR_"_2
t::-
;;Devo<"""-
c..t:P~_1
ps.i6iJ·
X:
I'SZIl...
iJ iJ
~iJ·
f:
1-0:0;·92
P:;-iJ·
z:
~iJ·
Y.u
f7.91iJ '.,66.0, iJ
T.Ql!ll:Port_Z
_ _'*-'- I
3 rl--------3...,.
5d_·1
Fig. 2. Flowchart
The simulation of robots within their working environment uses a huge amount of data such as geometric layout, kinematics and others. Though ROPSUS++ is based on CADdy++ which already has its own model ROPSUS++ implements a separate one referring to the logical view of robots, not the geometric view as done in 3D-CAD applications. The two models exist parallel with structural links between them. That is, geometry isn't duplicated for the logical model but linked with the geometric one.
:
__-
fi.1T
3. DATA MODEL
f<.9l±l. """ ps.97iJ P;;-iJ· .... PO:Z;-iJ
~PfacC2
.fJJ'
~
Fig. I. ROPSUS-Explorer
92
Robotics data could become complex depending on the device which is represented. As for example a robot with three joints is quite more complex than a si~ple motion path with four or more target points. This shows the need for a very flexible data model. But a simple structure couldn't fulfil these needs, so ROPSUS++ implements a tree based data structure. The.tree structure implies the advantages of a highly fleXible layout, a fast and easy extensibility and the possibility to design hierarchical dependencies. Each type of data (robots, motion paths, other devices etc.) is represented by one subtree within the globai model tree. As for the representation data of each object type could vary its subtree layout, too. A robot for example could be represented by a subtree existing of four nodes but a motion path by only two nodes. So the layout has to be highly flexible. In case of implementing new or extending existing object types the model has to be modified, too. The simplest way to perform this is by adding a new node to a subtree. Hierarchical dependencies could be useable for grouping different objects. In this case their representing subtrees are reordered within one common node. This action forces the subtrees to 'move down' one step in the trees hierarchy.
Al part tree
BI
Each Part could have its own designation which has to be unique in some local parts of the model tree. To enable the possibility to address a Part by its name the model tree could be treated as a directory structure. To address 'point I' in Figure 3 the directory structure looks like 'root-path I-point I'. Each Part contains the structural information of the tree such as parent node and sub nodes (Figure 4A). Also some administration functionality like traversing the subtrees is located within a Part. In addition to this each Part holds a list of its Properties again with the administration functionality for them. All Parts within the ROPSUS++ model tree have the same structure. There are no different Parts available. In meaning of object oriented programming (OOP): All Parts are instances of one class, there are no derived classes.
In ROPSUS++ these two kinds of information are separated in so called Parts and Properties. Parts contain information about the tree layout and properties contain the model information.
3.2 Property - Model information Properties assign additional functionality and logical properties to a Part. Each Part could hold as much as desired properties (Figure 4B). Properties don't implement administration functionality for the tree. They access the model by using the functions implemented in their container part. In difference to Part each logical property has its own Property, or with OOP: Property is the abstract base class for many different derived classes each representing a logical property in the robotic domain.
3.1 Part - Layout information A Part represents a node within the ROPSUS++ model tree. In this tree there is no difference between node and leaf. At the very beginning of the project the model tree was used to represent robots only, so one node represented a part of the robot device. Until now many other objects are stored as subtree in the global model and the name Part stayed but its meaning has changed from part to node.
3.3 Part Manager - Model tree administration
I
Additional to Parts and Properties ROPSUS++ implements one Part Manager to administrate the whole model tree. Also the trees root node is placed within the Part Manager. As for some restrictions the Part Manager builds the only global access point for the model tree within ROPSUS++. There is no way to address a single Part directly except its name (see Chapter 3. I).
path 1
I ... position + orientation + graphics
I-
point 2
I-
point 3
+ position .. ortentation
+ position ... o6entation
+ graphics
+ graphics
properties of • part
Fig. 4. Structure of part tree A), list of properties assigned to a part B).
The {ree model implemented in ROPSUS++ receives an even more detailed grade of flexibility by separating the model information from its layout information. That is, each node within the tree could have layout and model information. A motion path for example exists of one ore more target points. Each point has information of at least position, orientation and graphical representation. But each point is also a node within the subtree of its path (see Figure3).
point 1
~ ~
1-+
Fig. 3. Layout and model information of motion path 93
4. ROPSUS++ MODEL
Instead of this an Attachment Property is created which represents a bidirectional link between the two related Parts (robot and static device). If the device is released the Attachment Property is destroyed.
After describing the global tree structure (model view) this chapter announces the usage and adaptations in ROPSUS++ (logical view).
All Properties used in the ROPSUS++ model could be divided into two kinds: common Properties used by all types of objects and special Properties only useable for a special type of object. The Geometry Property for example belongs to the first group. Robots, devices and paths need to be displayed graphically. For that all these objects should own at least one Geometry Property. Other Properties like the TDH-Property are useable for robots only.
The goal of ROPSUS++ is the offline simulation of robots within their working environment, so all types of objects in such a working cell have to be considered. At the moment ROPSUS++ implements simulation functionality for robots, static devices like tables, etc. and motion paths. Extensions for sensors, dynamic devices and other object types are under construction. Within the ROPSUS++ model tree each object type has its own subtree which root node is located directly under the model trees root node (Figure 5). To each type's root Part there is a Type Manager attached as a Property. These managers are used to administrate all entities of their specific type. This includes functionality to create, modify, destroy and access one ore more entities. The Property Path Manager for example is attached to a Part called 'Path Manager' which builds the root node for all paths. If a new path should be created a related call to the Path Manager's create function has to be made.
5. COLLISION DETECTION Collision detection is one of the most significant tasks within a simulation system like ROPSUS++. Playing such a central role and being called many times to check for collision the collision detection engine (CollisionEngine) has to be a high performance piece of software. The CollisionEngine implemented in ROPSUS++ uses the geometrical data of the CADdy++ model through the links stored in the ROPSUS++ model (GeometryProperty). The data is stored within structures based on the ACIS geometric modeler designed by Spatial Technologies. It is a boundary representation (b-rep) of the 3D objects geometries. Some of the functionality provided by the ACIS class library doesn't seem to be optimized for collision detection so few modifications of the algorithm are in progress.
This instructs the Path Manager to build a new Part called 'path I', an attached Property belonging to that Part and attach the new Part as subtree to itself. A special kind of Property builds the Attachment Property. In case of a robot grapping a static device the last isn't static anymore - it is now part of the robot. Logically the related Part and its subtree within the ROPSUS++ model have to be moved from the Static Device subtree to the one of the grapping robot and backwards when it is released from the robot. This would last in a lot of moving actions within the tree.
5.1 Four phases filtering The Collision Engine is designed as a multi step system where each computation loop is separated in up to four phases. Within the first phase the relevant geometric objects are approximated by bounding geometries. The advantage of boundaries lies in the reduced time needed for comparing pairs of geometric objects. The complex objects are replaced by their boundaries with a much simpler geometry like spheres or boxes. Practice evaluation has shown that using spheres as an approximation object has other advantages. Rotations of the original geometry haven't to be mapped to the bounding sphere and the distance calculation is reduced to comparing the radii of two spheres. The boundary spheres are stored as an OCtree structure with predefined depth within the ROPSUS++ model. Applying a varying depth (depending on the geometries complexity) of the OCtree structure is one of the next milestones of the Collision Engine's development. Boundaries are computed in the moment a new geometry is added to the ROPSUS++ model. As for some not so well working ACIS internal algorithms this could last some time. That is the reason for another enhancement feature: parallelization of these computations by splitting them into multiple threads
Geo JD Geo JD Geo JD
RM RobotManager PM PathManager SDM StaticOeviceMan
SM SensorManager
Gee GeometryData ...
JD
JointData
Fig. 5. Logical layout of ROPSUS++ model tree
9..+
o
and/or delegating the work to different computers within a network.
no collision test nessessary a) (part1,part1) sen·test b) (pa-t2,part4) = (part4,pa-t2 )
-..
.
.. .. .. ..
N
M
1::
1::
1::
D.
D.
D.
on
1::
1::
D.
D.
I
After generating the boundaries in a pre-computing step in the fIrst phase the main part of the collision detection algorithm could be started. It is build by the next three phases (Figure 6). At the beginning of phase two there will be a defmed amount of geometric objects which have to be compared. They build the so called collision candidates. In phase two these candidates are filtered through a knowledge database - the so called Matrix-Of-Interest (MOl). This is a major feature of ROPSUS++ collision detection framework and will be described later on. After being fIltered by the MOl the amount of candidates will be reduced but is still too much for a time performance collision test. Phase three will reduce the number of candidates further on by comparing their bounding spheres. By comparing the boundaries no statement about collision could be made but a defInite statement about non-collision. If the boundaries don't collide, the original geometries couldn't collide either, because the boundaries are larger than the geometries. These computations can be done much faster than comparing to the complex geometries themselves. The result of phase three is an even more reduced set of collision candidates which couldn't be tighten more at the moment. So the real complex geometries ofthe remaining candidate pairs are compared in phase four. The geometries lasting the end of phase four build the set of colliding objects within the ROPSUS++ model. They are marked as such within the model providing collision information for other subsystems of ROPSUS++. And again the ability of parallelism to increase calculation speed will be used to delegate the collision computations to other threads and/or computers.
part 1 The ma-ked fl8ld represents the candidate
part 2
pa~
part 3
(pa-t2.part4)
I
- ---•
part 4 partS
Fig. 7. Matrix-Of-Interest (MOl) The rows and columns of the two-dimensional matrix represent the geometries one row and column for each (Figure 7). Each fIeld within this matrix represents a candidate pair for a possible collision. The triangular shape has its origin in the equality of the pairings (x 1; y2) and (y2; xl). Information about them are stored only once within the matrix and consider of data about movability, state of last collision test, position and orientation at the last time step (used for fourdimensional collision detection), and much more. All this information is processed by some functions implementing knowledge based candidate fIltering. By this the MOl build a base system for storing all relevant information. The knowledge based functions will be implemented as Plug-Ins which could be added to and removed from the MOl at runtime. These fIlters include: static or non-moving devices couldn't collide by themselves so they don't have to be tested against each other if two parts didn't move within the last timeframe their state didn't change either and is valid without the need of testing again two adjacent parts of the same device connected by a joint collide every time. No check has to be done and they are considered as 'no collision detected' if two parts move with increasing distance and they didn't collide last time they don't do at this timeframe
5.2 Matrix-DJ-Interest -- knowledge basedfiltering One of the most interesting parts of the Collision Engine is the Matrix-Of-Interest (MOl). The MOl could be seen as knowledge based database paired with a two-dimensional matrix with information about the geometry of all objects attached to the ROPSUS++ model.
There is much potential in tuning and enhancing the functionality of the MOl to optimize the process of collision detection by reducing the candidate pairs. Further work is done at this place by developing more Plug-In fIlters and making use of delegating calculations over network.
5.3 Three- and/our-dimensional collision detection There are two different kinds of collision detection algorithms implemented in ROPSUS++. Both of them detect collisions after they appeared not before.
. . Amount of candidate pairs decreases With each step
Fig. 6. Four phases of candidate fIltering The first algorithm detects collisions in three dimensional space at discrete points in time (tn)' That is, after the model is modified by other simulation steps lJ5
within a time slice it is frozen. All geometric objects within this temporary static model are used for input to the collision detection algorithm described in chapter 5.1. After the collision detection ends the next time slice begins and a new simulation step is performed.
1.51
I--+--+--+--t
1.1.1-+--+-1
There is at least one lack within this proceeding. What about collisions appearing between two discrete points of time (t,,:::; t:::; t,,+I)? For detecting the~e collisions a second algorithm was implemented m ROPSUS++. It is based on comparing two swept volumes each build by the bounding geometries of a candidate with its positions in three dimensional space at time t" and t,,+I. By using this data.as input and considering a constant speed of the objects between tn and t,,+1 the time of collision teal with t" :::; teal :::; t,,+1 could be approximated.
·151
.1."
-51
51
1...
1.51
Fig. 9. Motion Planning in the configuration space This is normally done by setting the robot to every possible configuration and checking for collision between the robot and any other object in the environment. For robots with many joints this calculation can last very long. A lot of planning algorithms must know the complete configuration space for the planning. The planning algorithm in the ROPSUS++System does not need to know the complete space.
6. MOTION PLANNING A very useful tool in a robot simulation program is a system for path planning. With such a system the user only needs to tell the system the starting ~d the ending point of a robot motion. Because the sunul~ tion system knows the geometry of the obs~c1es m the environment of the robot, the path plannmg system can calculate a collision-free path between the starting and the ending point.
The planner starts with the direct l.ine pat~ betwe~n the starting and ending configuratIOn. ThIs path IS checked for collision. If a collision exists, the planner calculates the middle point of the colliding path segments and moves this point out of the collision. Then the planning starts again. By this the path is moved step by step out of the collision. In figure 9 one can see a path developed by this algorithm.
There are a lot of path planning algorithms available in the literature. Almost all algorithms do the planning in the so called configuration spac~. In th~s space there exists one point for every pOSSIble POSItion of the corresponding robot. Figure 8 shows a very simple robot with only two joints and the corr~ sponding configuration space. The advantage of thIS space is that the three-dimensional geometry of the robot is mapped to a simple point in the configuration space. Therefore path planning is !educed t~ the search of a collision-free path for a pomt. The dIsadvantage is the bigness of this space. F?r a .robot .with six joints the configuration is a slX-dunenslOnal space.
CONCLUSION In this paper a robot simulation system for small and medium-sized companies is presented. This system is designed as an add-on to a common CAD-program. The user interface is very easy and intuitive. The paper explained the details of the data manageme~t.. In addition two very important features, the collISIOn detection and the path planning system are described.
For using this space for path planning one must calculate the mapping of the obstacles to the configuration space.
REFERENCES T
Cameron, S. (1989). Efficient Intersection Tests for Objects Defined Constructively. In: The International Journal ofRobotics Research. Vol.B, No. I, pp. 3-25. Cameron, S. (1990). Collision Detection by FourDimensional Intersection Testing, In: IEEE Transactions on Robotics and Automation, Vo/.6 No. 3, S. 291-302 Latombe, Jean-Claude (1991). Robot motion planning. Kluwer Academic Publishers
jon2
·125"
:;> .....--- ----.... . -~
)CUt I
75"
Fig. 8. A simple robot and the corresponding configuration space
96