S. Hohera, P. Nehera, Alexander Verla
Analysis and evaluation of collision detection libraries for
collision monitoring of multi-channel control applications
Stuttgart, Juni 2013
a
Institute for Control Engineering of Machine Tools and Manufacturing Units, University of Stuttgart
Seidenstr. 36, 70174 Stuttgart
{simon.hoher, alexander.verl}@isw.uni-stuttgart.de
www.isw.uni-stuttgart.de
Abstract
The main objective of this paper is to evaluate collision detection libraries for collision monitoring of
multi-channel control applications. First, the requirements for collision monitoring of multi-channel
control will be presented. On this basis suitable collision detection libraries will be analyzed and
selected considering the required feature range. The assumed libraries are then evaluated in regard to
their runtime characteristics. In particular the time-intensive memory accesses at runtime and the time
deterministic and efficient execution times during different experiments are examined in more detail
on a real-time platform.
Keywords
Collision detection, real-time, multi-channel control
Preprint Series
Stuttgart Research Centre for Simulation Technology (SRC SimTech)
SimTech – Cluster of Excellence
Pfaffenwaldring 5a
70569 Stuttgart
[email protected]
www.simtech.uni-stuttgart.de
22nd International Conference on Production Research
Analysis and evaluation of collision detection libraries for collision monitoring of multichannel control applications
Simon Hoher, Philipp Neher, Alexander Verl
University of Stuttgart, Institute for Control Engineering of Machine Tools and Manufacturing Units,
Seidenstraße 36, 70174 Stuttgart, Germany
The main objective of this paper is to evaluate collision detection libraries for collision monitoring of multichannel control applications. First, the requirements for collision monitoring of multi-channel control will be
presented. On this basis suitable collision detection libraries will be analyzed and selected considering the
required feature range. The assumed libraries are then evaluated in regard to their runtime characteristics. In
particular the time-intensive memory accesses at runtime and the time deterministic and efficient execution
times during different experiments are examined in more detail on a real-time platform.
Keywords:
Collision detection, real-time, multi-channel control
1
INTRODUCTION
What advances e-Manufacturing? The key answer is the
trend towards sustainable Custom Manufacturing. CNC
machining of work piece in the German industry has an
increasing tendency in the past decade towards
manufacturing of individualized or customized work pieces
in small and micro series. On the other hand, the highly
standardized mass production of work pieces is of
diminishing relevance or is shifting to Asian countries [9].
For the manufacturing of these customized work pieces
modern production cells are used. These are CNCcontrolled machines with a high degree of automation for
complete machining of work piece, in which various tools,
handling systems and transport devices deals with a work
piece.
The manufacturing of small and micro series and a high
geometric complexity of the processing sequence do not
only result in a proportionally high setup effort, but also
higher error proneness. The control of the tools, handling
systems and transport devices is usually carried out
autonomously so that in case of command errors collisions
between machine parts may occur and consequently
damages or destructs machine elements and work pieces.
The idea of this paper is to develop a software-based
method for in-process collision monitoring and prevention
in modern production cells. Independent of certain
machine types, this method should be able to prevent
effectively the above mentioned collisions interfering with
the different controls, and thus avoid costly damages and
machine downtimes.
Our approach is based on a geometric real-time simulation
of the production cell with a multi-channel fieldbus
connection on the basis of control signals. A protective
cover will be placed around the machine elements of the
virtual machine so that a time buffer is created. When the
virtual collision occurs, the real machine can be stopped or
affected in a way that the real collision can be avoided.
2
DISTINCTIVE FEATURES OF GEOMETRICAL
COLLISION DETECTION LIBRARIES
Today there are numerous differing collision detection
libraries that could possibly be used for collision
monitoring. Therefore the question is which one is the right
one. The decision is here affected by two decisive factors:
● The range of feature of a collision detection library
and
● The performance characteristics at runtime.
Lin and Gottschalk [1], Jiménez et al. [2] and Ericsson [3]
have defined the feature range of available collision
detection algorithms. Now, the feature range is subdivided
into:
● Geometric model representation,
● Simulation scene manager and
● Simulation system environment.
2.1 Geometric model representation
The feature range of the geometric model representation of
collision detection libraries are described as follows:
Geometric object model [1]: The objects in a collision
scene can be described as simple primitive objects (e.g.
box, sphere, cylinder…), convex bodies, compound convex
bodies, non-convex bodies or simply as an amount of not
closed polygons, so-called polygon soups. In addition, in
representing the geometric object models a distinction can
be made between polygonal object models and nonpolygonal models.
Polygonal bodies approximate objects with dots, edges
and surface. Here convex and not convex polygonal
objects enclose a defined volume via the surface elements,
thus they have an inside and an outside. Polygon soups
are a quantity of any desired polygons that do not enclose
a volume with their total surface.
Non-polygonal geometric object models as Constructive
Solid Geometries, implicit surfaces and parametric surface
like NURBS do not discretize the object and consequently
provide a smooth geometric surface description. Collision
detection for non-polygonal object models is much more
computationally intensive and thus it is basically only
appropriate for non-real-time object arrangements.
Collision detection manifold [1]: Here the information depth
is taken into account in case of collision. In the simplest
case only the information is provided that two objects are
in contact. This is called an intersection. But, in addition,
more detailed information like a common contact point, the
exact contact points, the contact normal on the respective
object surface, the penetration volume and the penetration
depth can be provided.
Distance calculation manifold [1]: This information differ
from the collision detection manifold by providing
information, if 2 objects do not touch each other. The
information ranges from the Euclidian distance of the
object pairs up to the nearest points and the normal on the
respective object surface.
2.2 Simulation scene manager
Further, the implementation of the simulation scene
manager in the collision detection library may have an
effect on the selection:
Broad phase processing [3]: In the broad phase it is
attempted to make a pre-selection for the exact collision
detection of collision pairs. Thus, in the case of many
objects the number of exact pair tests can usually
considerably reduced. But, depending on the broad phase
algorithm, the distance calculation manifold can only be
approximated or will be lost completely. The methods
range from Bounding Volume Hierarchies, Spatial
Partitioning up to binary space-partitioning trees. Often a
special broad phase algorithm can only be applied to
specific geometric object models.
Motion [1]: In case of a dynamic motion the objects will
move over time. Some algorithms here require that the
objects should only move with a maximum speed within a
time step. If this requirement is fulfilled, one talks of a
temporal coherence in the dynamic motion. The
assumption of temporal coherence may increase
calculation efficiency.
Movement [3]: In the real world all objects move
simultaneously. Through a sequential motion with directly
following collision detection the computing performance
can be improved. However, due to the sequential
movement collision situations could arise that do not exist
in the real world.
Deformable models [1]: The object can become deformed
over time. This feature may slow down calculation
efficiency.
Pair processing [1]: If two defined objects are to be
checked for collisions, one talks of a 2-body processing, in
case of n objects of a N-Body processing.
Extrude/swept volume collision detection [2]: If a collision
detection of objects with dynamic motion is only carried out
at discrete times, it may happen that collisions are
overlooked. This is the case when a collision would only
occur between the discrete time steps, and not at the times
of calculation. With extrude or swept volume collision
detection these collisions can be detected. These methods
are more computational intensive than collision detection
at discrete times, see [3].
Adaptive sampling [2]: Ideally, the next calculation time
should be then when a real collision actually takes place. If
the movement trajectory of the objects is known, then the
next calculation date for collision detection can be
determined through adaptive sampling. Adaptive sampling
needs additional computational power, but can reduce the
exact pair test per frame.
Trajectory parameterization [2]: If the motion trajectory of
the objects is known in advance and can be described as a
function over time, the collision time can be determined by
means of the trajectory parameterization.
Prioritization: Depending on the particular application it
may happen that in some areas collision detection is not
necessary. By prioritization this behavior can be
determined and the number of exact pair test can be
reduced.
2.3 Simulation system environment
Finally, also interfaces and requirements of the simulation
system can play a decisive role for using a collision
detection library:
Memory management: The memory management of the
collision detection library manages the used memory and
determines whether memory can be allocated dynamically
at runtime. Further, the Memory Management can support
the transfer of an own memory handler and use copies of
geometric object models without additional memory space.
Target platform: Collision detection libraries can partly use
other target platform libraries like the Standard Template
Library (STL) or special Foundation Classes. Depending
on the target platforms these platform libraries (especially
with real-time systems) might not exist, and the collision
detection library cold not run on the target platform.
Parallelization: Many system platforms provide access to
multi-core CPUs or GPU to run code in parallel. Then, the
collision detection library has to support this parallel code
execution.
License right: Depending on the license type the library
can be free of charge or subject to a fee.
2.4 Performance Characeristics
So far the feature range of collision detection libraries has
been described that allow a theoretical pre-selection for the
collision library due to an application.
Additionally, some runtime feature may be decisive for the
practical application:
Accuracy: The calculated collision detection manifold and
distance calculation manifold are as conform as possible
with the analytical solution.
Robustness: The collision detection library does not get
caught in endless loops or crash at runtime. Reasons
could be faulty descriptions of the numbers in the finite
precision (numerical robustness) or degenerated or faulty
object descriptions and topologies (geometric robustness).
Efficiency [3]: Depending on the number and scaling of the
objects, the computing performance of the polygonal
collision detection may be impaired [3]. Also the position of
the objects can affect the velocity. Efficiency therefore
determines the computation time for a pair of objects.
Time Determinism: In collision detection it can be very
important, for example in case of real-time applications that
in the worst case the calculation step does not take longer
than average. Time determinism describes the
characteristic of the constant calculation time.
In the following, the design factors of collision detection
libraries for the above described multi-channel control
application are examined. Based on these requirements,
collision detection libraries with appropriate characteristics
will be selected and evaluated.
3
SPECIALIZED DESIGN FACTORS OF COLLISION
DETECTION LIBRARIES FOR MULTI-CHANNEL
CONTROL APPLICATIONS
In Figure 1 the problem of a potential collision of machine
components is illustrated. Here, a work piece in a
production cell is machined by two spindles (S1, S2), a tool
chain (TC) and a work piece table (T1). The work piece
feeding is done by a robot (R1). The control of the
spindles, the tool chain and the work piece table is
subdivided into two independent channels (CH1, CH2).
The robot control (RC) is also executed independently.
Due to the independent motion in the individual channels
(CH1, CH2, RC) collisions between machine elements may
occur.
22nd International Conference on Production Research
Production
cell
Toolchain
(TC)
Physical machine
Control
NC1
CH1
T1
S2
RC
CH2
S1
TC
S2
Set point
CH
S1
T1
R1
z
x
y
R1
Figure 1: Simple scenario of a multi-channel control task
As the described collision monitoring should be
independent of a special manufacturer control, only the
actual control signals are available. These signals are
transmitted in the control cycle time via the fieldbus. The
cycle time within common control tasks is 1 ms. Our
collision monitoring approach taps the signals from the
fieldbus and checks within the control cycle time for
collisions. A safety sleeve with enough distance is put
around the machine elements in the simulation. By means
of a collision monitoring simulation, collisions between the
artificially enlarged virtual machine elements are
determined. So the physical machine can still be stopped
(or affected) and a real collision can be prevented. Figure 2
illustrates the design of the collision monitoring simulation.
The distance between the safety sleeve and the machine
component is adapted to the maximum machining speed
during initialization (worst case assumption). At a feed rate
of 60m/min and a cycle time of 1 ms the distance should
be at least 1 mm. Then a reaction in the control is possible
one cycle before the real collision occurs.
Physical machine
In the described collision monitoring for multi-channel
control of production cells there are various problemspecific variables which are decisive for the application of a
special collision detection library.
Control
e.g.:
stop
Set point
1ms
Production
cell
t
Emergency
Field bus
Collision monitoring
Collision Monitoring
Toolchain
(TC)
S1
S2
T1
R1
z
y
x
Safety sleeve
Figure 2: Application of the proposed collision
monitoring system to avoid physical collisions
The related simulation scene manager of the collision
detection library should handle a dynamic motion. Since
the machine elements cannot jump from one section to
another temporal coherence is assumed. Further, all
movements need to be executed simultaneously by the
simulation scene manager, so that no incorrect collision
situations are provoked in the virtual world by sequential
object movements. Since the collision monitoring is equally
important in the whole work space of the production cell, a
prioritization of the simulation scene is not possible. The
single machine elements like machines, axes, tool
changers, tool table, tool or feeding robot are only
minimally deformed during machining and are therefore
assumed to be rigid bodies. Consequently, a rigid body
collision detection is absolutely sufficient for this
application. The only exception is the work piece where the
erosion could be taken into account during the collision
detection.
Since in the presented concept just the current set points
of the control are tapped, the look-ahead data of the CNC
are not known. Therefore, an adaptive sampling in the
collision library does not offer any advantages. The set
points are updated in very short time steps so that it can
also be assumed that there is no tunneling between the
time steps. An extrude volume or swept volume collision
detection is therefore not necessary. Therefore, adaptive
sampling, extrude volume and swept volume collision
detection would only have a negative effect on the
calculation performance. As the kinematics of the
production cell is known, an efficient 2-body pair
processing by manual determination of possible collision
pairs could be implemented easily.
Due to the high dynamic motion of the machine elements
and so the high requirements on performance, the final
decision was to use a collision detection library with
polygonal geometric object models. According to the state
of the art these libraries are characterized by highest
performance.
Ideally, the collision detection should be integrated into the
CAD/CAM chain of the machine operator, in order to keep
the additional effort for the collision monitoring as low as
possible. Since the production cells in the CAD programs
are usually described in great detail, unnecessary details
like boreholes and screws need to be removed or
abstracted by convex hulls. Possibly the triangulation of
the objects must be reduced too, because a very detailed
triangulation may negatively affect the efficiency and the
memory usage of the collision detection library. However,
building convex hulls and reducing triangulation must not
necessarily be taken over by collision library itself, but it
can also be implemented by other pre-switched software
Table 1: Required feature range of collision detection
libraries
Feature range
Geom. model representation
Geometric object model
Collision detection manifold
Distance calculation
manifold
Simulation scene
Broad phase
Motion
Movement
Deformable models
Pair processing
Extrude/swept volume
Collision detection
Adaptive sampling
Trajectory parameterization
Prioritization
Simulation environment
Memory management
Target platform
Parallelization
License right
Requirement
Table 2: Required performance characteristics of collision
detection libraries
Performance
characteristics
Polygonal model, convex
object
At least intersection
Accuracy
Robustness
Depends on collision
monitoring strategy
Velocity
Determinism
Memory
management
Depends on collision
monitoring strategy
Dynamic motion
Simultaneous movement
Rigid body
2-Body
Not required
Not required
Not required
No prioritization
Own memory handler
No system libraries
Not required
Not required
modules. So, this feature will not be taken into further
consideration in this paper.
CAD programs commonly provide the standard export of
polygonal object models, for example with the VRML97
specification. Non-convex objects or polygon soups can be
included in this data. By subdividing non-convex objects
into lower convex bodies, convex collision detection
libraries are more than adequate.
A non-convex
separation into convex lower bodies or the computation of
a convex sleeve can again be done by an upstream
software module which is not a part of the collision
detection library.
An object description with polygon soups is physically not
possible within physical systems, but due to an incorrect
export of machine elements from the CAD program this
occurs frequently in practical applications. This means that
if the exported data are to be used directly, a collision
library for polygon soups is recommended. Alternatively, if
there is need to processed non-convex object models, an
upstream pre-processing step that is not part of the
collision detection library can generate convex bodies from
the polygon soup.
The collision detection manifold and distance calculation
manifold depends strongly on the collision avoidance
strategy to be implemented in the controls. Therefore, it is
difficult to limit the information depth in this case. The
minimum requirement is at least the provision of
information via intersection.
In order to enable a communication between the operating
system and the fieldbus of the system control, in the field
of control engineering often PC-based operating systems
like WinXP or Win7 with special real-time extension and
corresponding fieldbus drivers are used.
Requirement
1mm (1%)
No endless loops,
no crashes
Fast
Constant
No allocations at
runtime
Conventional systems for such PC-based real-time
systems linked as multi-slaves to the control fieldbus are
WinRTX by Intervall Zero or TwinCAT by Beckhoff. These
real-time extensions possess their own memory and
scheduler within the operating system administered by the
real-time extension. Consequently, the collision library
ideally has a memory management for the transfer of a
memory handler to this memory area. In addition, it is
possible that common platform system libraries as the
Standard Template Library (STL) are not supported by the
real-time extension and dynamic memory allocations at
runtime cause the well-known Blue Screen. For example,
this is both the case with TwinCAT. Otherwise, the memory
management and the platform libraries have to be
integrated manually into the code of the collision detection
library. These non-existent features should not lead to a
final exclusion of the library.
Nowadays, the real-time extensions described above only
provide confined parallelization interfaces. Via Affinity
Masks (WinRTX) individual processes can be assigned to
a CPU. Interfaces for a multi-core execution of a process
are partially proprietarily available, but the application of
the interfaces is still difficult to handle. The call for
execution of the collision detection library on its own core
is a requirement on the real-time operating system and not
on the implementation of the collision detection library. A
parallelization of the code of the collision detection library
is therefore not demanded.
The required feature range of the collision detection library
is summarized in Table 1.
Further the performance characteristics of collision
detection libraries have to be defined for a multi-channel
control application. For the described collision monitoring
strategy the collision detection needs to work very
efficiently in the control cycle. The calculation time should
be as constant as possible in this case, so that a
transmission of the results can be guaranteed in the
related control cycle. Also, in exceptional situations the
library should not stop itself. Otherwise the physical
machine has also to be stopped in case of crashes and
endless loops. The requirements on accuracy are rather
low. Smaller deviations of the collision calculation do
hardly affect the monitoring strategy. Therefore,
divergence in accuracy of 1 % referring to the analytical
solution is demanded. Usually only a few 10 MB memory is
available for computation and object model description.
Consequently, the memory management should be very
efficient. In addition, dynamic memory allocations are not
allowed, since they could lead to a crash of the real-time
operating system. The required features at runtime are
summarized in Table 2.
22nd International Conference on Production Research
Table 3: Comparison of geometric model representation features of the assumed collision detection libraries
Geometric model
representation
V-Clip
(V1.0)
Swift++
(V1.2)
Solid
(V3.5.6)
Bullet
(V2.8)
Rapid
(V2.01)
Wild Magic
(V5.7)
Y
Y
Y
Y*
Y*
N
Y
N
Y
Y
N
Y
N
N
N
Y
N
N
Y*
Y
N
N
N
N
N
Y
Y
Geometric object model
Primitives
Convex
Compound convex
Non-convex
Polygon soup
N
Y
Y
N
N
N
Y
Y
Y
Y
Y
Y*
N
N
N
*with additional (plug-in) software
Collision detection
manifold
Intersection
Penetration depth
Contact point
Contact volume
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
N
N
N
N
* Efficiency is higher, if just first contact triangle is asked
Distance calculation
manifild
Euclidian distance
Closest point
Y
Y
Y
Y
Y
Y
Y
Y
Table 4: Comparison of simulation scene manager features of the assumed collision detection libraries
Simulation scene manager
Broad phase processing
Motion
V-Clip
Swift++
Solid
Bullet
Rapid
Wild Magic
N
AABB
AABB
N
N
Dynamic
(TC)
N
2-Body
N
Dynamic
(TC)
N
N-Body
N
Dynamic
AABB /
Dynamic
AABB
Dynamic
Dynamic
(TC)
N
2-Body
N
Dynamic
Deformable models
Y
Y
N
1
1
Pair Processing
2/N* -Body
2/N* -Body
2-Body
2
Extrude/swept
volume
Ray Cast*
Ray Cast /
N
collision detection
Sweep
Prioritization
N
N
N
N
N
N
1
2
* For each collision pair the depth of collisions detection manifold can be set, * Limited to a few geometric models
4
COLLISION DETECTION REVIEW
Over the past years various collision detection algorithms
of polygonal object models have been developed, which
meet the required feature range and performance
characteristics for the problem in Chapter 3. Six collision
libraries have been chosen:
● Swift++ and V-Clip implementing an adaption of the
closest-features algorithm [4, 5],
● Solid and Bullet implementing the GJK and EPA
algorithm [6]
● Rapid [7] implementing Bounding Volumes Trees and
● WildMagic 5 implementing a Linear Constraint Solver
(see [3] for algorithm issues).
For a survey of the libraries’ function description see [8].
Strictly speaking, Bullet is a Physic Engine. But since the
collision detection is clearly enclosed from the Physic
Engine by the developers, this library was also considered.
In case of Wild Magic 5 the collision detection is also only
one subcomponent of the total software suit “Geometric
Tools”. But because this is the only C++ implementation of
a collision detection library with quadratic programming
has been researched, this software suite was applied.
All libraries have a defined API that ensures a simple
application of the libraries. The scale of the model
representation is shown in Table 3.
The feature range of the simulation scene manager is seen
in Table 4. All libraries permit a dynamic motion and can
be controlled by simultaneous movement. V-Clip, Swift++
and Rapid expect a temporal coherence (TC) in
movement.
In Table 5 the feature range of the simulation system
environment are summarized. All collision detection
libraries provide the possibility of copying identical objects.
VClip, Solid and WildMagic also need the system library
STL and optionally other third-party software. Only Bullet
offers an adequate interface for the transfer of an own
memory handler and for parallelization.
Table 5: Comparison of simulation system environment features of the assumed collision detection libraries
Simulation system
environment
Parallelization
License right
5
Swift++
Y
N
STL, (Qhull*,
Inventor*)
Y
N
-
Solid
Bullet
Rapid
Y
Y
Y
N
Y
N
STL,
(Qhull*)
N
N
N
Y
N
Free / With
Free / With
Free / With
Free / Free
Free / With
cost
cost
cost
cost
2
* Optional, needed for full collision framework support, * Memory allocation is centralized
COLLISION DETECTION EVALUATION
In a next step the runtime properties of the collision
detection libraries will be evaluated.
5.1 Experimental setting
Various experiments were performed in order to assess
accuracy, robustness, efficiency, time determinism and
memory management. In the first experiment two cuboidal
blocks are moved abruptly and then they stay in this place
for a defined time span of 1 s. Within this time span the
calculation is repeated every 10 ms. The cube is moved in
that way that adjacent vertexes, edges and faces are
tested. The position is always selected in a way that the
cubes are in a defined distance to each other (Exp. 1.1 –
Exp. 1.6), touch each other exactly (Exp. 1.7 – Exp. 1.13)
and then penetrate each other (Exp. 1.13. – Exp. 1.18).
The temporal coherence is given since no geometric
features are skipped. The test setup can be seen in Figure
3, the respective positions are described in Table 6.
1
y
Wild Magic
Y
2
N*
STL
N
Free / Free
around the z-axis and penetrate each other a bit at the
edges. The test run takes also 18 s and is repeated every
22.5 ms.
1
y
1
Shared objects
Memory handler
Target platform
V-Clip
x
z
0.05
Figure 4: Basic sketch of experiment 2 and 3
Since depending on the library, triangular faces, polygonal
faces or vertexes have to be transferred, the discretization
of the described objects differs as shown in Table 7. At all
experiments, the convex object interface is used.
Table 7: Number of used triangular faces, polygonal
faces or vertexes for the experiments
Exp.
V-Clip, Rapid,
WildMagic
Swift++, Solid
Bullet
1
2
3
12 triangles
160 triangles
1600 triangles
6 polygons
42 polygons
402 polygons
8 vertexes
40 vertexes
400 vertexes
x
z
Figure 3: Basic sketch of experiment 1
As a further experiment 2 discs with a low discretization
(Experiment 2) and with a high discretization (Experiment
3) are positioned next to each other and rotated around
their own axis. During the test the discs rotate completely
For experiment 1 the Euclidian distances can be calculated
analytical and will be later used for comparison with the
numerically calculated data of the collision detection
library.
In all libraries the current C++ implementation was
compared. All presented results were achieved on an Intel
Core i5-2540M 2.60 GHz Dell laptop with a Windows 7 32bit operating system and 3.28 GB main memory. All
experiments were compiled with the Microsoft Visual
Studio 2008 C++ Compiler Version 15.00.30729.01 and
Table 6: Respective position of the second cube during Experiments 1.1 – 1.18
Exp.
Contact
x
y
z
n
1.1 / 1.7 / 1.13
Vertex-Vertex
1.1 / 1.0 / 0.9
1.1 / 1.0 / 0.9
1.1 / 1.0 / 0.9
(0, 0, 1)
0
1.2 / 1.8 / 1.14
Vertex-Edge
0.0
(0, 1, 0)
/4
1.3 / 1.9 / 1.15
1.4 / 1.10 / 1.16
Edge- Edge
Edge-Face
1.3 / √
+ 0.5 / 1.1
1.1 / 1.0 / 0.9
1.0
1.1 / 1.0 / 0.9
0.0
0.0
0.0
(0, 0, 1)
(0, 1, 0)
0
/4
1.5 / 1.11 / 1.17
1.6 / 1.12 / 1.18
Face-Face
Face-Vertex
0.0
0.0
0.0
0.0
(0, 0, 1)
(1, 1, 1)
0
/3
1.3 / √
+ 0.5 / 1.1
1.1 / 1.0 / 0.9
1.4 / √
+ 0.5 / 1.2
22nd International Conference on Production Research
b)
a)
70µs
c)
d)
65µs
60µs
45µs
130µs
e)
f)
300µs
Figure 5: Execution time of experiments 1, 2, and 3 (a, b, c, d, e) and absolute distance errors (f) for the selected collision
detection libraries
the compiler option /O2 (maximize speed). All calculations
were carried out with the real-time extension WinRTX and
a double precision presentation. A latency time
measurement under WinRTX resulted in a maximum
system latency time of 3 µs at an average latency time of 0
µs. In addition, a real-time-capable, time deterministic
memory pool for the memory measurements was installed.
All experiment runs were repeated 10 times and from
these the average was calculated, in order to reduce the
impact of the latency time.
5.2 Simulation results
By means of the simulation runs of experiment 1, 2 and 3
now the runtime properties (efficiency, time determinism,
memory management behavior, accuracy and robustness)
are assessed.
In Table 9 the memory need at the initial phase (Init) and at
the runtime phase (RT) for each experiment is shown. Only
Bullet and Solid do not need dynamic memory at runtime.
Obviously, Swift++, V-Clip and Rapid are also designed in
a way that no or less memory is allocated at runtime. Only
in special situations memory allocations in the range of a
few Kilobytes have become necessary. Whereas V-Clip,
Swift++, Rapid and Solid have a similar memory need at
the runtime phase, Wild Magic needs considerably more
memory space. In experiment 3 the initialization required
more than 4 GB so that a runtime measurement was not
possible due to memory allocation failed.
In Figure 5 the execution times and the calculated
Euclidian distances and penetration depths are depicted.
Wild Magic was not considered anymore for the following
two reasons:
● Each calculation step in experiment 1 and 2 lasted
longer than 1 second and thus stands in no relation to
the other libraries (< 50 µs).
● None of the 3 experiments could be executed
completely with Wild Magic. The collision detection
reported numerous errors and then stopped itself
before the intended end of the simulation experiment.
Table 9: Memory allocation at the initializing phase (Init) and at runtime phase (RT) and occurrence timing
Exp.
Phase
1
2
3
1
Init
Init
Init
RT
2
RT
3
RT
V-Clip
Swift++
Rapid
Wild Magic
Bullet
Solid
1.2 KB
110 KB
1090 KB
1KB
(at 5.0 s)
1KB
(at 0.7 s)
102 KB
512 KB
4259 KB
0.16 KB
(at 14.0 s)
none
61 KB
5.5 MB
4 GB
53KB
(each step)
3.8 MB
(each step)
19 KB
150 KB
1342 KB
none
0.6 KB
208 KB
2181 KB
none
none
none
5.67 KB
(at 0.7 s, 3.5s)
none
21 KB
116 KB
950 KB
0.08 KB
(at 6.0 s)
0.08 KB
(at 0.7 s)
0.08 KB
(at 0.7 s)
failed
none
none
None of the other libraries reported errors during the
experiments. The numerical and geometric robustness was
therefore given as long as the objects were initialized
according to the respective user’s guide.
During the experiments V-Clip, Swift++ and Rapid show
individually high execution time peaks which are well
above a multiple of the usual calculation time. These
always occur in connection with a memory allocation
(comp. Table 9). Since a deterministic memory pool is
used, these execution time peaks are repeatable.
Swift++ and Rapid need similar execution times for
experiment 2 and 3. Consequently, it can be concluded
that these libraries have similar execution times,
independent of the level of detail of discretization. Here the
finer discretization of the objects is only reflected in a
higher memopry need. All other libraries need 2 to 10
times for experiment 3 compared to experiment 2.
Solid is the only tested library that shows especially with
experiment 2 and 3 a constant calculation time. In case of
experiment 1 the calculation time is twice as long for some
poses, but it is still possible to carry out a worst case
assessment.
Even though Bullet is based on the same algorithm as
Solid, the runtime properties are fundamentally different.
The execution time is – depending on the experiment – 2
to 5 times longer, in case of collisions even sometimes 30
times. However, in Bullet the execution time is constant as
long as no collisions occur.
This behavior can also be noted with Rapid. As long as
there are no collisions, Rapid is by far the most efficient
library, but shortly before or during collisions a significant
increase of the execution time can be recorded.
The absolute error in calculating the Euclidian distances
was identical for the libraries V-Clip, Swift++, Solid and
Bullet (see Figure 5). The very minor error is due to double
precision limitations. Only when calculating the penetration
depth, significant errors occurred. But this is of secondary
importance for the simulation-based collision monitoring
system. Rapid could also detect the collisions without
error, but no Euclidian distances and penetration depth.
In summary, the application of geometric collision detection
libraries for collision monitoring for use in a multi-channel
control is based on the following facts:
● Wild Magic is not suitable for the given task due to the
poor robustness, the very high execution time and the
enormous memory need.
● V-Clip has sufficient efficiency. However, there are
dynamic memory allocations at runtime and thus,
computing time peaks. This is especially the case
when two surfaces face each other. Therefore, V-Clip
is also not appropriate for the described application.
●
Bullet has very long execution times. In particular in
case of collisions there are clear increases in
computing time up to 300 µs. This computation would
already need half of the available computing time for
just one collision pair. Bullet can also not be
recommended for the collision monitoring system.
● Swift++ has a short execution time. Although in a test
dynamic storage allocations occurred at runtime at
one experiment. It seems to be an implementation
error. If this memory allocation will be removed by
revisions of the soured code, the usage of Swift++ can
be agreed.
● Solid just offers an average execution time. However,
memory is never allocated at runtime and the
computation is very time-deterministic. Solid is
therefore suitable for collision monitoring and will be a
strong candidate if the target platform supports the
STL library.
● Rapid is a very strong candidate for collision
monitoring. As long as there are no collisions or they
are not close up, Rapid has by far the best execution
time. Also in case of a collision the increase to 20 µs is
still acceptable. A very interesting factor with Rapid is
that polygon soups are allowed as input data. So, if
the memory allocation at runtime can be prevented by
revisions of the source code and just intersections are
needed, Rapid will be the right and best choice.
Note: If the target platform does not support STL library
and does not allow memory allocation during runtime
phase, none of the displayed libraries can solve the
problem of collision monitoring.
6 SUMMARY
Even though there is a multitude of very powerful collision
detection libraries, there was so far no comparison made
for the requirements for collision monitoring of a multichannel control.
The objective of this paper was to present the
requirements of collision monitoring and to select on this
basis suitable libraries considering their feature range.
These libraries were then assessed in regard to their
runtime properties for a collision monitoring. In particular
the time-intensive memory accesses at runtime and a time
deterministic, short computing time during different
experiments were examined in more detail.
By means of experiments two libraries could be identified
for collision monitoring:
● Solid is especially suitable if CAD data are not
degenerated and the Euclidian distance or penetration
depth information between machine elements is
needed.
● Rapid is very interesting in case of degenerated CAD
data, since also polygon soups can be handled by this
22nd International Conference on Production Research
library. On the other hand, there is the drawback that
distance information cannot be calculated and, in case
of a(n) (imminent) collision, a clear increase of the
execution time can be noted. Also, memory allocation
at the runtime phase can be problematically.
It is shown, that none of the evaluated collision detection
libraries can be used in environments without common
platform libraries (like STL) and were dynamic memory
allocatation is prohibited during runtime. While candidates
were found for systems which support these features,
collision monitoring is currently impossible with open
libraries (apart from other libraries, unknown to the autors),
given the described system environment. Further work
should be done in this direction.
7 ACKNOWLEDGMENTS
The authors would like to thank the German Research
Foundation (DFG) for financial support of the project within
the Cluster of Excellence in Simulation Technology (EXC
310/1) at the University of Stuttgart.
8
REFERENCES
[1] Gottschalk, S., Lin, M., 1998, Collision detection
between geometric models: A survey, Proc. of IMA Conf.
on Mathematics of Surfaces.
[2] Jiménez, P., Thomas, F., Torras, C., 2001, 3D collision
detection: a survey, Computers & Graphics, Volume 25,
Issue 2, Elsevier, 269-285.
[3] Ericson, C., Real-Time Collision Detection, Elsevier,
2005.
[4] Ehmann S., Lin, M., 2001, Accurate and Fast Proximity
Queries Between Polyhedra Using Convex Surface
Decomposition, Computer Graphics Forum, Volume 20,
Issure 3, 500-511.
[5] Mirtich, B., 1998, V-Clip: fast and robust polyhedral
collision detection, ACM Transactions on Graphics,
Volume 17 Issue 3, 177 - 208
[6] Van den Bergen, G., 1999, A Fast and Robust GJK
Implementation for Collision Detection of Convex Objects,
Journal of Graphics Tools, Volume 4, Issue 2, 7-25.
[7] Gottschalk, S., Lin, M., Manocha, D., 1996, OBBTree: a
hierarchical structure for rapid interference detection,
SIGGRAPH '96 Proceedings of the 23rd annual
conference on Computer graphics and interactive
techniques, ACM, 171-180.
[8] Reggiani, M., Mazzoli, M, Caselli, S., 2002, An
experimental evaluation of collision detection packages for
robot motion planning, IEEE/RSJ International Conference
on Intelligent Robots and Systems, Volume 3, 2329-2334.
[9] Kai Cheng, Richard J. Bateman, e-Manufacturing:
Characteristics, applications and potentials, Progress in
Natural Science, Volume 18, Issue 11, 10 November 2008,
Pages 1323-1328.