Diplomarbeit (*.pdf - 5,3MB) - Faculty of Computer Science ...

Technische Universität Dresden
Fakultät Informatik
Institut für Software- und Multimediatechnik
Diplomarbeit
Thema:
„Entwicklung einer virtuellen Laserbearbeitungsanlage“
vorgelegt von:
Helmar Behrends
geb. am 15.01.1979 in Lutherstadt- Wittenberg.
Matrikelnummer: 2620640
Eingereicht am 30. Juni 2005.
Betreuender Hochschullehrer : Prof. Dr. M. Wacker
Betreuer des Fraunhofer IWS : Dr. S. Völlmar

Erklärung
Hiermit versichere ich, diese Arbeit selbständig verfasst und nur die
angegebenen Quellen benutzt zu haben.
Helmar Behrends
2

Inhaltsverzeichnis
1 Einleitung ................................................................................................. 8
1.1 Das Fraunhofer „Institut für Werkstoff- und Strahlentechnik“........ 9
1.2 Problemstellung.............................................................................. 10
1.3 Zielstellung..................................................................................... 11
1.4 Gliederung der Arbeit..................................................................... 12
2 Analyse ................................................................................................... 13
2.1 Beschreibung der vorhandenen Situation am IWS ........................ 13
2.1.1 Einführung Laserstrahlschweißen......................................... 13
2.1.2 Beispiel 1: XXL- Anlage...................................................... 14
2.1.3 Einführung Laserstrahl- Auftragschweißen .......................... 15
2.1.4 Beispiel 2: Modulares Pulverdüsensystem zum
Auftragschweißen Lasertechnik (COAXn).......................... 18
2.1.5 Simulationsumgebungen ....................................................... 19
2.2 Anforderungsermittlung................................................................. 23
2.2.1 Vorbetrachtung...................................................................... 23
2.2.2 Konstruktionswerkzeug......................................................... 24
2.2.3 Simulation ............................................................................. 29
2.2.4 Kollisionserkennung.............................................................. 29
2.3 Zusammenfassung.......................................................................... 30
3 Design ..................................................................................................... 32
3.1 Konstruktion / Spiegelung der Kinematik...................................... 32
3.2 Simulation ...................................................................................... 36
3.3 Kollisionskontrolle......................................................................... 40
3.3.1 Vorbetrachtung...................................................................... 40
3.3.2 Analyse vorhandener Verfahren............................................ 41
3.3.3 Broad Phase (Strukturanalyse).............................................. 42
3.3.4 Narrow Phase ........................................................................ 47
3.3.5 Oriented Bounding Box Trees (OBB-Trees) ........................ 51
3.3.6 OBB Überlappungstest.......................................................... 60
3.3.7 Primitivtest ............................................................................ 61
3.3.8 Integration in die Simulation................................................. 64
3.3.9 Kontinuierliche Kollisionserkennung ................................... 66
4 Implementierung ................................................................................... 70
4.1 Konstruktion................................................................................... 70
4.1.1 Berechnung der Transformationen........................................ 75
4.1.2 Wiederverwendung von Komponenten................................. 77
4.2 Simulation ...................................................................................... 79
4.2.1 Ablaufsteuerung .................................................................... 79
3

4.2.2 Konfiguration ........................................................................ 81
4.2.3 Entwicklung eigener CNC-Interpreter .................................. 83
4.3 Kollisionskontrolle......................................................................... 87
4.3.1 Berechnung der OBB- Parameter.......................................... 87
4.3.2 OBB Aktualisierung.............................................................. 88
4.3.3 OBB-Überlappungstest und Traversierung........................... 89
4.3.4 Primitivtest ............................................................................ 95
4.3.5 Konfiguration ........................................................................ 95
4.3.6 Anzeige der Kollisionen........................................................ 96
4.4 Schnittstellen .................................................................................. 97
4.5 Persistenzstrategie .......................................................................... 99
4.6 VR- Darstellung ........................................................................... 101
4.6.1 Chromium............................................................................ 101
4.6.2 XML3D ............................................................................... 103
5 Test, Anwendungsbeispiele................................................................. 105
5.1 Kuka-Roboter und -Komponenten ............................................... 105
5.2 XXL-Anlage................................................................................. 107
5.3 Laserstrahl-Auftragschweißen ..................................................... 110
6 Zusammenfassung............................................................................... 112
6.1 Fazit und Ausblick ....................................................................... 114
4

Abbildungsverzeichnis
Abb. 1-1 Anwendungsgebiete des IWS ............................................................. 9
Abb. 2-1 Modell XXL- Anlage ........................................................................ 14
Abb. 2-2 Achsanordnung zum beidseitigen 3D-Laserstrahlschweißen ........... 15
Abb. 2-3 Laserstrahl- Auftragschweißen [Völlmar04] .................................... 16
Abb. 2-4 Schema des Gesamtvorgangs............................................................ 17
Abb. 2-5 Diodenlaser und Beschichtungskopf, Kombination mit Roboter ... 18
Abb. 2-6 3 Seiten- Cave des IWS, Navigation mit Flystick............................. 19
Abb. 2-7 Fadal- Anlage: reale Maschine und VRML- Simulation .................. 20
Abb. 2-8 Funktionsschema WireGL/ Chromium ............................................. 21
Abb. 2-9 Übersicht Standardverbindungen [Webhofer04] .............................. 25
Abb. 2-10 offene und geschlossene kinematische Ketten................................ 26
Abb. 2-11 Erstellen des kinematischen Modells (Bsp. Kuka KR3)................. 26
Abb. 2-12 Kinematische Kette für KR3 (ohne Kopf) ...................................... 27
Abb. 2-13 Bewegungsrichtungen der XXL- Anlage........................................ 27
Abb. 2-14 Kinematische Ketten der XXL- Anlage (Ausschnitt) .................... 28
Abb. 3-1 Beispiel eines Szenegraphen ............................................................ 32
Abb. 3-2 Erstellen von Baugruppen ................................................................. 33
Abb. 3-3 Szenegraph mit zwei fest angeordneten Baugruppen ....................... 34
Abb. 3-4 Szenegraph mit kinematisch verbundenen Baugruppen ................... 34
Abb. 3-5 Transformationen in einer Hierarchie ............................................... 35
Abb. 3-6 Spezifikation der Bauteiltransformationen und der Achsen ............. 35
Abb. 3-7 Architekturmuster Interpreter im Anwendungskontext .................... 36
Abb. 3-8 Abstrakte Maschine........................................................................... 37
Abb. 3-9 Klassendiagramm CNC- Interpreter ................................................. 38
Abb. 3-10 Zeitliche Diskretisierung der CNC-Programme.............................. 39
Abb. 3-11 Parallelisierung der CNC-Programme (∆ t = 100ms) ..................... 39
Abb. 3-12 Repräsentation von 3D- Modellen nach [Gotttschalk00]................ 41
Abb. 3-13 Kuka-Roboter Kr3........................................................................... 42
Abb. 3-14 Constraints des Kr3......................................................................... 43
Abb. 3-15 Änderung der Parameter einer Gelenkverbindung.......................... 44
Abb. 3-16 Anzahl der Kollisionstests mit/ohne Kohärenz............................... 45
Abb. 3-17 Ermittlung der zu testenden Objektpaare........................................ 46
Abb. 3-18 Kollisionserkennung ....................................................................... 46
Abb. 3-19 Beispiele für Bounding Volumes .................................................... 48
Abb. 3-20 Bounding Volume Hierarchie aus Sphären..................................... 49
Abb. 3-21 Konvergenz einiger Bounding Volume .......................................... 51
Abb. 3-22 vierstufige Hierarchie aus OBBs (S.6)............................................ 51
Abb. 3-23 Binärbaum (l.) u. entsprechender Quadtree (r.) [Mezger01] .......... 52
Abb. 3-24 Kollision zweier Binärbaumblätter (l.), Quadtree (r.) [Mezger01]. 52
Abb. 3-25 Überlappung der Wurzelknoten [Mezger01] .................................. 53
Abb. 3-26 Aufbau einer Bounding Volume Hierarchie ................................... 53
Abb. 3-27 Auswirkung innerer Punkte auf die OBB- Berechnung.................. 55
Abb. 3-28 Auswirkung ungleichmäßiger Sampling- Raten ............................. 55
Abb. 3-29 Integrieren über den Primitiven ...................................................... 56
5

Abb. 3-30 Auswirkungen kleiner Linien/Flächensegmente............................. 56
Abb. 3-31 Verwendung der konvexen Hülle.................................................... 56
Abb. 3-32 L ist separierende Achse für die OBBs A und B ............................. 60
Abb. 3-33 Verfahren von Möller (l.) und Held (r.) .......................................... 62
Abb. 3-34 Geometrische Interpretation für den positiven Fall ........................ 63
Abb. 3-35 Überlappungstest zweier Dreiecke.................................................. 64
Abb. 3-36 Integration der Kollisionskontrolle in die Simulation..................... 65
Abb. 3-37 Schraubenbewegung als allgemeine Starrkörperbewegung............ 66
Abb. 3-38 Kollisionserkennung zwischen zwei Kanten .................................. 68
Abb. 4-1 „Import CAD-Object“-Dialog........................................................... 70
Abb. 4-2 Segmentierung der Baugruppen........................................................ 71
Abb. 4-3 Place-Dialog...................................................................................... 71
Abb. 4-4 Place-Dialog und eingefügtes Bauteil............................................... 72
Abb. 4-5 Szene mit Sockel............................................................................... 72
Abb. 4-6 Zusammenstellen des Rumpfes......................................................... 73
Abb. 4-7 Festlegen der Gelenkparameter......................................................... 73
Abb. 4-8 „Place“-Dialog .................................................................................. 74
Abb. 4-9 Positionierung auf dem Sockel.......................................................... 74
Abb. 4-10 Aufsetzen des Rumpfes auf den Sockel .......................................... 75
Abb. 4-11 Szene mit Sockel und Rumpf.......................................................... 75
Abb. 4-12 Anfügen eines Bauteils im Szenegraphen....................................... 76
Abb. 4-13 Wiederverwendung von modellierten Komponenten ..................... 77
Abb. 4-14 "Import from Project"-Dialog ......................................................... 78
Abb. 4-15 Beeinflussung des Zeitverhaltens.................................................... 79
Abb. 4-16 Thread der Ablaufsteuerung............................................................ 80
Abb. 4-17 Dialog zur Konfiguration der CNC-Simulation.............................. 81
Abb. 4-18 Auswählen der CNC-Interpreter -Klasse ........................................ 81
Abb. 4-19 dynamisches Laden des CNC-Interpreters...................................... 82
Abb. 4-20 Klassendiagramm CNC-Interpreter ................................................ 83
Abb. 4-21 Quellcode des DefaultCNCInterpreter's ......................................... 84
Abb. 4-22 DefaultCNCCommand- Implementierung ...................................... 85
Abb. 4-23 Bestimmung der OBB-Parameter ................................................... 87
Abb. 4-24 Rekursionsbaum für einen BV- Hierarchietest [Mezger01] ........... 89
Abb. 4-25 Algorithmus für Test zweier BVHs ................................................ 90
Abb. 4-26 Implementierung des OBB-Überlappungstests............................... 94
Abb. 4-27 Konfiguration der Kollisionserkennung.......................................... 95
Abb. 4-28 Darstellung der kollidierenden Primitive........................................ 96
Abb. 4-29 Transparente Verwendung der Schnittstellen (Bsp. DCAM) ......... 97
Abb. 4-30 Klassendiagramm der Remote-Control -Schnittstelle..................... 98
Abb. 4-31 XML-Struktur des Datenformats ................................................... 99
Abb. 4-32 Abbildung von Baugruppen auf die verwendete XML-Struktur .. 100
Abb. 4-33 Oberfläche der Anwendung .......................................................... 101
Abb. 4-34 VR-Version (Chromium) der Anwendung.................................... 102
Abb. 4-35 Anzeige de Details der Kollisionen............................................... 102
Abb. 4-36 Verteilung einer Szene auf drei Displays...................................... 102
Abb. 4-37 Architektur des Gesamtsystems nach [Metze].............................. 103
Abb. 4-38 Darstellung einer Szene in XML3D.............................................. 104
6

Abb. 5-1 Kuka-Roboter und -Komponenten.................................................. 106
Abb. 5-2 XXL-Anlage.................................................................................... 107
Abb. 5-3 Laserschweißköpfe.......................................................................... 108
Abb. 5-4 Umsetzung der Faltenbalge als zylindrische Objekte ..................... 109
Abb. 5-5 Reis-Roboter mit Laserkopf............................................................ 110
Abb. 5-6 Reis-Roboter mit Werkstück........................................................... 111
7

1 Einleitung
Aktuelle Veranstaltungen wie die im April stattgefundene Hannover-Messe
und die Ende Juni diesen Jahres stattfindenden IFF- Wissenschaftstage zeigen
einen klaren Trend auf: In zunehmendem Maße sollen »Virtual Reality und
Augmented Reality“ zum Planen, Testen und Betreiben technischer Systeme
eingesetzt werden, um kürzere Innovationszyklen für die Entwicklung von
Produkten, Prozessen und Systemen zu erreichen. Dies erfordert neue
Technologien im CAE-Bereich. Eine aktuelle Lösung ist das Virtual
Engineering:
Virtual Engineering (VE) bietet dabei für die einzelnen Projektphasen:
Planung, Simulation und 3D- Visualisierung spezielle Konzepte an:
Während der Planungsphase sollen untereinander vernetzte - auch
örtlich verteilte - Planungsteams mit gemeinsam erstellten digitale
Modellen in ihrer Entscheidungsfindung und ihrem Agieren unterstützt
werden, um eine konsistente und sichere Planungsbasis zu schaffen.
In der Simulation werden unter Verwendung von CAD-Layoutdaten
und statischen Planungsergebnissen dynamische Sachverhalte in
Simulationsmodellen formuliert. Das System als Simulationsmodell
gestattet die Vorwegnahme der Realität in einer simulierten Virtualität
und erlaubt eine Betrachtung der dynamischen Prozesse über die Zeit.
Die korrekte Dimensionierung der Anlagen, die Überprüfung von
Funktionalitäten sowie die Untersuchung von Steuerungskriterien und
Störfallsituationen werden einfach und kostengünstig realisierbar.
3D-Visualiserung meint die individuelle, auf ihre Aufgabenfelder
abgestimmte dreidimensionale Visualisierung, um somit
unternehmensweite Entscheidungen zu unterstützen. Des Weiteren
bieten Abbildungen, Filme und VR im Bereich Marketing und
Akquisition Einblick in das Potential der entwickelten Technologie.
Diesem Trend folgend beschäftigt sich das Fraunhofer "Institut für Werkstoff
und Strahlentechnik" (IWS) seit geraumer Zeit mit virtuellen Technologien und
entwickelt zusätzlich eigene, speziell an seine Bedürfnisse angepasste,
Softwarekomponenten in den Bereichen CAD,CAM u. CAE.
8

Die vorliegende Arbeit ist ein Bestandteil dieser Entwicklung des VE und
konzentriert sich im wesentlichen auf die Phasen Simulation und 3D-
Visualisierung. Ziel ist es eine virtuelle Simulationsumgebung speziell für den
Anwendungsfall der Lasermaterialbearbeitung zu erstellen.
Im folgenden Abschnitt sollen nun zunächst das Fraunhofer IWS kurz
vorgestellt, anschließend die Problemstellung definiert und abschließend eine
Zusammenfassung der Zielstellungen dargelegt werden.
1.1 Das Fraunhofer „Institut für Werkstoff- und Strahlentechnik“
Das IWS betreibt anwendungsorientierte Forschung und Entwicklung von den
physikalischen und werkstofftechnischen Grundlagen bis hin zur System- und
Anlagenentwicklung. Die Schwerpunkte sind:
Lasertechnik (z.B. Laserschweißen, Laserschneiden, Laserbeschichten,
Laserreinigen)
Oberflächentechnik (z.B. Auftragschweißen, Dünnschichttechnologie).
Diese vielfältigen Technologien (siehe auch Abbildung 1-1) sind für die
verschiedensten Bereiche und Branchen der Wirtschaft interessant.
Insbesondere in den Branchen Automobilindustrie, Luft- und Raumfahrttechnik
und Werkzeug- und Formenbau bietet das IWS Dienstleistungen an.
Abb. 1-1 Anwendungsgebiete des IWS
Der übliche Ablauf sieht vor, dass ein Unternehmen A dem Fraunhofer IWS
ein vorhandenes Werkstück mit zugehörigem CAD-Modell für die weitere
Bearbeitung zur Verfügung stellt.
Das IWS erstellt dann entsprechend der Problemstellung eine Bearbeitungsstrategie
z.B. in Form von Laserschweißverfahren, Laserschweißkomponenten

für Industrieroboter oder auch komplett neu entwickelten Schweißanlagen, die
für die Weiterbearbeitung des Werkstücks nötig sind.
Diese Art der Erforschung und Untersuchung von neuen Technologien bzw.
neuen Anwendungsspektren auf den oben angesprochenen Gebieten erfordern
einen sehr hohen informationstheoretischen Aufwand. Der Kostenfaktor für die
Realisierung eines prototypischen Modells wächst dabei unproportional mit der
Komplexität der zu entwickelnden Technologie.
Zur Auflösung dieser Problemstellungen wird derzeitig die Forschung für
virtuelle Räume als Visualisierungs- und Simulationsumgebung am IWS
vorangetrieben. Virtuelle Räume bieten die individuelle Freiheit für
ergebnisorientiertes Forschen und Experimentieren von technologisch
komplexen Gebilden für die Einhaltung von endlichen wirtschaftlichen
Restriktionen.
1.2 Problemstellung
Aktuell werden am IWS zahlreiche Softwareprodukte aus den Bereichen CAD,
CAM und CAE eingesetzt. Speziell für den Anwendungsfall Simulation und
3D-Visualiserung von Laserbearbeitungsanlagen wurden diese jedoch aus
unterschiedlichen anwendungsbedingten Gründen (z.B. mangelnde oder nur
eingeschränkt nutzbare Funktionalitäten, Möglichkeiten der VR- Darstellung)
als mehr oder minder geeignet eingeschätzt.
Probleme ergeben sich zusätzlich in lizenzrechtlichen Fragestellungen. Hierbei
gilt, dass jede speziell vom IWS gewünschte Erweiterung der Funktionalität
einer vorhandenen extern entwickelten Software mit erheblichen Kosten und
mit hohem Kommunikationsaufwand mit dem Hersteller verbunden ist.
Speziell die Auslieferung von Softwareprodukten, in Form von mit externer
Software erstellten Komponenten, an Kunden des IWS stellt dabei oft ein
lizenzrechtliches Problem dar.
Die Entscheidung eine eigene Simulationsumgebung zu erstellen, die speziell
an die Bedürfnisse des IWS und dessen Kunden angepasst werden kann, ist
damit ersichtlich.
Einen weiteren Vorteil einer Eigenentwicklung stellt die Möglichkeit der freien
Gestaltung der Schnittstellen dar. Diese können so angepasst werden, dass sich
die neu erstellte Software problemlos in den vorhandenen Workflow
integrieren lässt und bereits am IWS entwickelte Komponenten auf diese Art
und Weise weiterverwendet werden können. Die möglichst transparente und
flexible Schnittstellengestaltung ist damit eine wesentliche Anforderung an
diese Arbeit.
Die detaillierten Zielstellungen der vorliegenden Arbeit unter Berücksichtigung
der bisher dargestellten Anforderungen sollen im folgenden Abschnitt
zusammengefasst werden.
10

1.3 Zielstellung
Mit Hilfe dreidimensionaler Simulation sollen die kinematischen
Eigenschaften von Maschinen bzw. Maschinenelementen mit Schwerpunkt der
Anwendung bei der Lasermaterialbearbeitung untersucht werden.
Dazu soll ein Programmsystem erstellt werden, welches es ermöglicht,
ausgehend von technischen Zeichnungen oder vorhandenen CAD- Daten, ein
funktionales Abbild der Maschine zu erstellen und dessen einzelne
Maschinenelemente entsprechend ihren kinematischen Eigenschaften
(Rotationen, Translationen etc.) zu verknüpfen.
Der Bewegungsablauf der Maschine wird für ausgewählte Bauteile und
technischen Zielstellungen (z.B. Härten und Auftragsschweißen) an Hand von
Programmen aus technologischen CAD/CAM in das Maschinentool importiert
und die Technologie an der virtuellen Maschine nachvollzogen.
Parallel dazu soll jederzeit eine detaillierte Kollisionskontrolle erfolgen
können, um so bereits in der Simulationsphase eventuelle Konstruktionsmängel
der Maschinenelemente und Fehler in den Anlagen- Programmen aufdecken zu
können. Zur Aufklärung unübersichtlicher Situationen in der 3D- Szene sollte
der Export in eine virtuelle Anlage ermöglicht werden.
In einem weiteren Bearbeitungsschritt soll, ausgehend von der Analyse durch
Kollisionskontrolle ein programminternes Bearbeiten des Bewegungsablaufs
und der Maschinenelemente ermöglicht werden. Hierzu gehören das Entfernen,
Hinzufügen und Bearbeiten der Maschinenelemente über eine möglichst
intuitive und zugleich leistungsfähige Benutzerschnittstelle.
Zusammenfassend ergeben sich folgende Funktionalitäten:
1) Werkzeug zur Konstruktion einer generischen Maschine (Beispiel:
Roboter und Portalanlage).
2) Spiegelung der Kinematik einer Bearbeitung in einer Simulation.
3) Kollisionskontrolle beim Bewegungsablauf und Identifizierung der
Kollisionspunkte
4) Ermöglichung der intuitiven Modifikation von Maschinenelementen
und Bahndaten.
Die volle Funktionalität der virtuellen Bearbeitungsanlage sollte auf
entsprechend ausgerüstetem PC möglich sein, der Export in eine VR-Anlage
sollte so offen gehalten werden, dass die Rückgabe von Informationen aus der
Anlage in die Simulation später möglich ist. Die Schnittstellen können in der
Arbeit nach den Erfordernissen der Programmentwicklung gestaltet werden.
11

Ihre Beschreibung muss die nachträgliche Gestaltung nach den industriellen
Normen (z.B. RRSII) ermöglichen
1.4 Gliederung der Arbeit
Um einen möglichst systematischen Entscheidungsprozess zu vollziehen,
Handlungsspielräume problemorientiert einzugrenzen und dem Leser der
Arbeit einen möglichst intuitiven Einstieg in die Problematik zu bieten, liegt es
nahe, bei der Planung und Durchführung eines Projektes auf bewährte
Strategien im Entwicklungsprozess zurückzugreifen. In der vorliegenden
Arbeit soll dies der für die Softwareentwicklung klassische Weg nach
[Sommerville] und [Balzert] sein. Dieser besteht aus den Kernprozessen
Analyse, Entwurf, Implementierung und Test, welche sich somit als
Gliederung anbieten.
12

2 Analyse
Im folgenden sollen alle Anforderungen an die zu erstellende Anwendung
ermittelt werden. Typische Fragestellungen sind: „Welches System soll
entwickelt werden?“, „Was sind die Anforderungen des Kunden?“ und „Ist es
möglich, das geforderte System zu realisieren?“.
Die Analysephase beginnt üblicherweise mit der Feststellung des Ist-
Zustandes. Dieser wird im folgenden Abschnitt dargestellt.
2.1 Beschreibung der vorhandenen Situation am IWS
Da die Aufgabenstellung für die Simulation den Anwendungsfall Laserschweißen
im Allgemeinen vorsieht, soll anhand zweier Beispiele die
zugrundeliegende Technologie erläutert werden. Als Einstieg in die Thematik
ist jedem Beispiel eine kurze Erläuterung der Besonderheiten der jeweiligen
Technologie vorangestellt. In Abschnitt 2.1.5 werden dann die zu den
dargestellten Technologien bereits existierenden Simulationsumgebungen
untersucht.
2.1.1 Einführung Laserstrahlschweißen
Das Laserstrahlschweißen stellt ein Fügeverfahren dar, das gekennzeichnet ist
durch:
• tiefe und schlanke Schweißnähte mit Einschweißtiefen bis ca. 20 mm,
• einen geringen Energieeintrag und damit geringen Schweißverzügen,
• hohen Schweißgeschwindigkeiten im Bereich von mehreren m/min
sowie
• einer hohen Flexibilität der zu verschweißenden Geometrien (3D-
Formen).
Mit dem Fügeverfahren Laserstrahlschweißen lassen sich sowohl Eisenmetalle
(z.B. Baustahl) als auch schweißgeeignete Nichteisenmetalle (z.B. Aluminium,
Titan, Magnesium u. Kupfer) verschweißen.
Das Laserstrahlschweißen kommt in fast allen Bereichen des Fahrzeug-,
Maschinen-, Anlagen-, Apparate- und Schiffbaus als hocheffizientes und

flexibles Fügeverfahren zum Einsatz. Die verarbeiteten Stähle reichen von
unlegierten Kohlenstoffstählen, niedriglegierten Einsatzstählen über höher und
hochfeste Feinkornbaustähle bis zu hochlegierten korrosionsbeständigen
Stählen.
2.1.2 Beispiel 1: XXL- Anlage
Zur Technologieentwicklung des Laserstrahlschweißens von sehr großen 3D-
Teilen für die Luft- und Raumfahrt investierte das Fraunhofer Institut für
Werkstoff- und Strahltechnik (IWS) Dresden in eine neuartige XXL-
Laserstrahlschweißanlage (Abb. 2-1).
Abb. 2-1 Modell XXL- Anlage
Diese Anlage erlaubt die Bearbeitung von 3D-Strukturelementen mit den
Abmessungen 10 x 3 x 1 m und wurde vom IWS Dresden und den Firmen
Airbus Deutschland, Schuler Held Lasertechnik Dietzenbach und Ibs-
Automation Chemnitz konzipiert, hergestellt und in Betrieb genommen. Ibs-
Automation entwickelte und lieferte die gesamte Steuerungstechnik
einschließlich Software mit CNC- Betriebssystemerweiterungen und
Postprozessor zur automatisierten NC-Programmgenerierung.
Da aus Gründen der Nahtausbildung, der Belastbarkeit und des Verzuges beim
Schweißen von Aluminiumstrukturen mit T-Naht beidseitig gleichzeitig
geschweißt werden muss, sind im Anlagenkonzept zwei mechanisch
unabhängige Schweißköpfe vorgesehen. Mit Hilfe von zwei CNC-Steuerungen
Sinumerik 840D werden die Bewegungen der beiden Schweißköpfe und einer
mitlaufenden Spanntechnik synchronisiert. Die Orientierung des Laserstrahls
im Raum wird mit drei Rundachsen A, B und C realisiert (Abb. 2-2). Die dritte
Rundachse ist notwendig, weil das qualitätsgerechte Schweißen von
Aluminium die Zuführung von Zusatzwerkstoff bedingt und somit eine
Positionierung des Schweißkopfes um den Tool Centre Point (TCP) notwendig
wird. Der zusätzlich geforderte flache Anstellwinkel des Laserstrahls zur
14

Grundfläche hat eine Umlenkung des fokussierten Laserstrahls mittels HD-
Spiegel nahe dem TCP zur Folge. Außerdem ist im Vorlauf zum TCP für jeden
Schweißkopf ein optischer Nahtführungssensor montiert. Die prinzipielle
Achsanordnung zum sensorgeführten beidseitig gleichzeitigen 3D-
Laserstrahlschweißen zeigt Abbildung 2-2.
Abb. 2-2 Achsanordnung zum beidseitigen 3D-Laserstrahlschweißen
Synchrone 3D- Nahtführung
Eine wesentliche Forderung zur Programmierung der CNC-Steuerung besteht
darin, dass auf Grundlage eines CAD-Datenfiles die Soll-Schweißbahn mit
Hilfe eines Postprozessors zu berechnen ist. Die Geometriedaten im
berechneten NC-Programm sollen dabei im Werkstückkoordinatensystem der
Maschine vorliegen (TCP- Programmierung). Der spezielle Postprozessor
wurde im Rahmen des Projektes durch ibs entwickelt. Aus der in Abbildung 2-
2 dargestellten Anordnung der Rundachsen ist ersichtlich, dass für die TCP-
Programmierung eine kinematische 6-Achs-Transformation erforderlich ist.
Zur Ausführung des beidseitig gleichzeitigen 3D-Laserstrahlschweißen führen
beide Schweißköpfe ein automatisch generiertes NC-Programm mit gleichen
Bahnpunkten aus. Neu entwickelte Strukturen im CNC-Betriebssystem sorgen
dafür, dass die NC-Programme für beide Köpfe synchron abgearbeitet werden
und generieren bei Überschreitung einer vorgegebenen Abweichung eine
Fehlermeldung bzw. stoppen die Laserschweißanlage.
2.1.3 Einführung Laserstrahl- Auftragschweißen
Wie alle Maschinenteile sind auch Rotoren von Turbinen und Flugzeugtriebwerken
den Gesetzen allen Irdischen unterworfen: Vielfältige Einflüsse im
rauen Betrieb setzen ihnen zu. In einer neuen, als »Bladed Disks» (Blisks)
bezeichneten Bauweise werden sie nicht mehr wie früher aus mehreren Teilen
zusammengesetzt, sondern aus Gründen der Festigkeit, Kompaktheit und
Wirtschaftlichkeit in einem Stück gefertigt. Sollten jedoch die Schaufeln
(Blades) zu sehr verschlissen oder etwa durch Vogelschlag beschädigt sein,
lassen sie sich nicht mehr einfach von der Scheibe (Disk) abnehmen und
austauschen. Eine neue Blisk schlägt mit typischerweise 35 000 bis 60 000
15

Euro zu Buche. Sechs- bis siebenmal kostengünstiger ist eine Instandsetzung
durch Direct Metal Deposition, das auf dem Laserstrahl- Präzisions- Auftragschweißen
basiert. In der Luftfahrtindustrie ist dieses Reparaturverfahren im
Kommen – im Fahrzeugbau werden Umformwerkzeuge damit bereits serienmäßig
wieder auf Vordermann gebracht.
Beim Laserstrahl-Auftragschweißen handelt es sich um ein generierendes
Fertigungsverfahren, das gegenüber spanenden Methoden immer dann im
Vorteil ist, wenn Einzelstücke oder kleinere Serien schnell erzeugt oder eben
individuell repariert werden sollen. Zunächst wird das beschädigte Bauteil
dreidimensional gescannt. Ein Computerprogramm (LAVA) berechnet die
physikalischen Eigenschaften der Schweißraupe. Eine am Institut
mitentwickelte Software (DCAM) steuert auch die Bahn des Lasers, der Pulver
aus Titanlegierungen aufschweißt und so die schadhafte Stelle aus vielen
»Schweißraupen« (Abb. 2-3) schichtweise rekonstruiert. Die gesamte
Prozesskette ist geschlossen und läuft von der Datenerfassung über das
Schweißen bis zur Endbearbeitung automatisiert ab (Abb. 2-4).
Abb. 2-3 Laserstrahl- Auftragschweißen
Bevor mit der Erläuterung des zweiten Beispiels begonnen wird, soll zunächst
auf die Vorgehensweise beim Laserstrahl-Auftragschweißen in Hinblick auf
den zu erstellenden Anforderungskatalog eingegangen werden. Dieser Ablauf
ist typisch für zahlreiche Anwendungsgebiete des IWS und soll daher,
unabhängig von konkreten Beispielen, noch etwas detaillierter untersucht
werden.
Die Darstellung der Prozesskette für die Verarbeitung einzelner Werkstücke in
Abb. 2-4 zeigt eine wichtige Problematik auf. Es wird ersichtlich, dass u.U. bis
zu vier unabhängig voneinander agierende Programme (inkl. CAD- u.
Visualisierungssoftware) für die Bearbeitung eines einzelnen Werkstücks
notwendig sind. Diese Situation wird vom IWS als äußerst hinderlich
eingeschätzt. Um diesem Problem zu begegnen, sollte die zu erstellende
Simulationssoftware daher besonders integrative Konzepte berücksichtigen.
Denkbar wäre dazu beispielsweise, dass ein Starten der Simulation aus einer
16

anderen Anwendung heraus und ein Datenaustausch zwischen diesen beiden
Programmen ermöglicht wird. Dieser Vorgang sollte dabei für den Anwender
möglichst transparent ablaufen. Auch die ausschließliche Verwendung von
einzelnen Komponenten der Anwendung (bspw. die Kollisionserkennung) für
andere Anwendungen wäre denkbar. Hier spielen softwaretheoretische
Modelle, speziell komponentenbasierte Systeme und Framework-
Architekturen eine wichtige Rolle für die Entwicklung. Diese Konzepte sollten
also in jedem Fall in den Systementwurf integriert werden.
Korrektur
Anlage
Auftrag /
Bauteil
Geometrieerfassung
Bearbeitungsstrategie
Werkstoffe
Bearbeitungsparameter
Werkzeugbahnberechnung
DCAM
Generierung CNC-Programm
Numerische und VR- Simulation
Aufbau Systemtechnik
Bearbeitung / Prozessüberwachung /
Kontrolle
LAVA
Abb. 2-4 Schema des Gesamtvorgangs nach [Völlmar04]
Korrektur
Bearbeitung
Im folgenden Abschnitt sei nun das zweite Anwendungsbeispiel dargestellt.
17

2.1.4 Beispiel 2: Modulares Pulverdüsensystem zum Auftragschweißen
Lasertechnik (COAXn)
Die präzise Herstellung von Oberflächenschutz- und Funktionsschichten sowie
schnelle Reparaturen von Hochwertbauteilen zählen zu den wichtigsten
Anwendungsgebieten, in denen sich das Laserstrahl- Auftragschweißen heute
industriell etabliert hat. Eine wichtige Voraussetzung für den erfolgreichen
Einsatz des Verfahrens sind robuste Pulverdüsen, die einfach zu handhaben
sind und eine exakte sowie stabile Zufuhr des Schweißpulvers auch an weniger
gut zugänglichen Bearbeitungsstellen sowie beim Beschichten von
Freiformflächen ermöglichen. Mit dem modularen Pulverdüsensystem COAXn
des Fraunhofer IWS steht dem Anwender ein flexibles Werkzeug zur
Verfügung, das zusammen mit der entsprechenden Lasertechnik leicht in
Standard- Werkzeugmaschinen und Bearbeitungssysteme integriert werden
kann.
Abb. 2-5 Diodenlaser und Beschichtungskopf, Kombination mit Roboter
Bei der Konstruktion des Pulverdüsensystems wurde besonderes Augenmerk
auf die leichte Integrierbarkeit in Werkzeug- oder sonstige Bearbeitungsmaschinen
gelegt, die heute üblicherweise bei den Anwendern bereits
vorhanden sind. Einschließlich des Lasers kann somit das komplette
Beschichtungssystem als Nachrüstsatz erworben und in die bestehende
Anlagentechnik eingebaut werden (z.B. Abb. 2-5 links): kompakte Einheit,
bestehend aus 2 kW-Diodenlaser und Beschichtungskopf vom Typ COAX8).
Mit einem Gelenkarmroboter kombiniert, steht eine preiswerte, 3D-fähige
Bearbeitungsanlage zur Verfügung (Abb. 2-5 rechts). Für eine Verfahrenskombination
aus Auftragschweißen und Endbearbeiten (Fräsen) sind Köpfe aus
dem System COAXn und 3- und 5achs-CNC-Fräszentren integriert worden.
Die mit den COAXn- Köpfen hergestellten Strukturen reichen von filigranen
Einzelraupen mit Breiten und Höhen von wenigen zehntel Millimetern über
großflächige Beschichtungen mit Schichtdicken von maximal 2,5 mm bis hin
zu 3D-Geometrieaufbauten. Beispiele für hochpräzise Anwendungen sind
Laseranlagen zur Reparatur von komplex geformten Triebwerkkomponenten
wie Schaufeln (siehe Anwendungsbeispiel Kap. 6), Scheiben und Blisks. Auf
der anderen Seite werden heute auch große Umformwerkzeuge aus dem
Automobilbereich durch lokale Laser-Auftragschweißungen repariert und
schnell im Design geändert.
18

2.1.5 Simulationsumgebungen
Für die vorgestellten und weitere Anlagen existieren am IWS bereits
Simulationsumgebungen. Die Vor- und Nachteile dieser Anwendungen sollen
im folgenden analysiert werden.
Da die Möglichkeit der VR- Darstellung auf der institutseigenen VR- Anlage
ein entscheidendes Analysekriterium darstellt, soll diese zu Beginn vorgestellt
werden.
VR- Anlage
Im IWS steht eine modifizierte 3 Seiten- Cave nach dem Schema in Abb. 2-6
zur Verfügung. In einem Freiraum von zirka 2 m x 2 m x 3 m können virtuelle
Anlagen in einem Besprechungsraum dargestellt werden.
Die Installation besteht aus drei Projektionsflächen und sechs Beamern, in
denen die Bilder für die beiden Augen der Nutzer durch Polarisationseffekte
getrennt erzeugt werden. Jedem Beamer ist im Netzwerk ein separater PC
zugeordnet, so dass eine hohe Performance der Abläufe erreicht werden kann.
Die Anwender lösen durch Verwendung ihrer Polarisationsbrillen die Bilder
auf den Schirmen als räumliche virtuelle Darstellung der Anlage auf.
Die Installation ist mit einem optischen Tracking – System der Firma
Advanced Realtime Tracking GmbH, Herrsching, ausgerüstet. Damit können
sowohl die genaue Position einer Referenzperson als auch die Orientierung von
Steuergeräten ermittelt werden. Die VR-Darstellung wird exakt auf diese
Person bezogen berechnet, weitere Nutzer in deren Umgebung nehmen die
Inhalte mit geringen Qualitätsverlusten wahr. Die Interaktion erfolgt über einen
Flystick und in dem hier behandelten Fall über einen entsprechend
programmierten und frei beweglichen Touch-Screen zur Steuerung.
XXL- Anlage
Abb. 2-6 3 Seiten- Cave des IWS, Navigation mit Flystick
Die Simulation der XXL- Anlage erfolgt bisher mittels der eigens am IWS
entwickelten Software „CNCInspector“. Diese ist in der Lage, die für den
19

Betrieb der Anlage notwendigen drei parallel abzuarbeitenden CNC-
Programme auszuführen und zu visualisieren. Als entscheidender Mangel wird
die Tatsache eingeschätzt, dass die Anwendung zwar in der Lage ist,
Kollisionen zwischen den Baugruppen der Anlage oder der Anlage und dem
Werkstück zu erkennen, dies jedoch aufgrund mangelnder Performance bisher
praktisch nicht einsetzbar ist. Die Simulation der XXL- Anlage in einer
generischen Simulationsanwendung, inklusive schneller Kollisionskontrolle
und CNC- Steuerung, wäre damit ein entscheidender Fortschritt.
Laserstrahl- Auftragschweißen
Die Simulation des Laserstrahl- Auftragschweißens erfolgt derzeit auf
unterschiedlichen Umgebungen. Teilweise wurden komplette Anlagen in
VRML umgesetzt, um somit eine Darstellung auf der institutseigenen CAVE
mit Hilfe des X- Rooms Softwarepakets zu ermöglichen. Als Beispiel sei die
Fadal – Anlage (Abb. 2-7) angeführt. Hierbei haben sich jedoch schnell die
Grenzen einer Umsetzung in VRML aufgezeigt. Grund hierfür ist, dass es sich
bei VRML um eine Beschreibungssprache für 3D- Szenen handelt. Die
Möglichkeiten einer Programmiersprache besitzt diese natürlich nicht. Daher
wird angestrebt, Anwendungen in herkömmlichen Programmiersprachen, z.B.
in der Sprache Java in Verbindung mit Java3D umzusetzen.
Abb. 2-7 Fadal- Anlage: reale Maschine und VRML- Simulation
Für die Robotersimulation existieren am IWS ebenfalls bereits zahlreiche
Anwendungen. Hier wären vor allem die Hersteller eigenen Produkte von Reis
und Kuka zu nennen. Diese zeichnen sich durch eine sehr komfortable
Simulationsumgebung für die jeweils eigenen Produkte aus. Roboter anderer
Hersteller können jedoch nicht (zumindest nicht voll funktionsfähig) in die
Umgebungen importiert werden.
An dieser Stelle sei daher die am Institut vorhandene Software „EasyRob“ zu
nennen. Diese bietet für fast alle gängigen Roboterhersteller Komponentenbibliotheken
an und stellt zugleich eine große Anzahl an Schnittstellen zur
Verfügung. Leider lassen sich mit dieser Anwendung die erstellten Szenen
nicht in der vorhandenen VR- Anlage darstellen. Grund hierfür ist, dass am
20

IWS aktuell die Verwendung der Opensource Komponentensoftware
Chromium zur VR- Darstellung angestrebt wird, welche abschließend im
folgenden kurz vorgestellt werden soll.
Chromium
Diese Verteilungssoftware bietet die Möglichkeit OpenGL- Anwendungen in
verschiedenster Form auf mehrere Rechner zu verteilen Das System fungiert
dabei als OpenGL- Treiber (die Original- Treiber werden durch eigene ersetzt)
und hat somit Zugriff auf die darzustellende Geometrie der aktuell auf dem
System laufenden 3D- Anwendung. Die Geometriedaten können anschließend
über ein Netzwerk auf verschiedene Rechner in unterschiedlichen Konfigurationen
verteilt werden. Eine solche Beispiel- Konfiguration zeigt
Abbildung 2-8.
Abb. 2-8 Funktionsschema WireGL/ Chromium
Chromium ist aktuell in der Version 1.8 für alle gängigen Linux- und
Windowssysteme verfügbar. In einer Studienarbeit am IWS wurden die
Möglichkeiten dieser Technologie detailliert untersucht. Dabei stellte sich
heraus, dass die Nutzung der Software gewissen Einschränkungen unterliegt.
So traten besonders bei Anwendungen die nach den Microsoft MFC SDI/MDI
Komponenten programmiert wurden Probleme auf. Diese konnten nicht
dargestellt werden. Da die Software EasyRob offensichtlich auf diesen
Modellen entwickelt wurde, schlug eine Darstellung in der VR-Anlage fehl. Im
21

Gegensatz dazu lassen sich die am Institut getesteten Java3D Anwendungen
ohne größere Umstände und mit sehr hoher Performance auf dem VR-System
darstellen. Es wurden lediglich einige, sehr unproblematische Implementierungsregeln
für Java3D- Anwendungen aufgestellt. In Absprache mit dem
IWS wird daher für die vorliegende Arbeit eine Implementierung in
Java/Java3D angestrebt.
Weitere Vorgehensweise
Nachdem nun die prinzipiellen Verfahrensweisen des IWS und die aktuelle
Situation in Bezug auf vorhandene Simulationsumgebungen dargestellt wurde,
sollen im folgenden Abschnitt, ausgehend von den in Abschnitt 1.3 gesetzten
Zielstellungen, die Anforderungen an das zu erstellende Projekt zusammengetragen
werden.
22

2.2 Anforderungsermittlung
Die Anforderungsermittlung unterscheidet in der Ermittlung von funktionalen
und nicht-funktionalen Anforderungen. Erstere beschreiben das, was das
System tun soll, letztere formulieren einschränkende Bedingungen, also wie die
funktionalen Anforderungen zu realisieren sind.
Die in Abschnitt 1.3 genannten Zielstellungen unterscheiden im wesentlichen
vier Funktionalitäten. Deren spezielle funktionale und nicht-funktionale
Anforderungen unter Berücksichtigung der dargestellten Beispiele sollen im
Anschluss an eine Vorbetrachtung in den folgenden Abschnitten erörtert
werden.
2.2.1 Vorbetrachtung
Ziel der Arbeit ist das Untersuchen der kinematischen Verhältnisse von
Maschinen bzw. Maschinenelementen. Der Begriff Kinematik ist wie folgt
definiert:
Def. 2-1 Die Kinematik (kinema, griech., Bewegung) ist die Lehre von der
mathematischen Beschreibung der Bewegung von Punkten und Körpern mit
Hilfe der Größen Weg, Geschwindigkeit und Beschleunigung im Raum, ohne
auf die Ursachen einer Bewegung einzugehen. Sie ist neben der Statik und
Dynamik ein Teilgebiet der Mechanik.
Im vorliegenden Anwendungsfall sind also die Bewegungen von Körpern in
Form von Maschinenteilen zu modellieren. In der Mechanik werden diese oft
idealisiert als starre Körper betrachtet (siehe Definition 2).
Def. 2-2 In der klassischen Mechanik ist ein starrer Körper ein System von
Massepunkten, deren Entfernungen voneinander konstant sind.
Da sich die wesentlichen Baugruppen, aus denen die zu simulierenden
Laserschweißanlagen aufgebaut sind, während eines ordnungsgemäßen
Schweißvorganges nicht verformen, kann auch für die Simulation idealisiert
von starren Körpern ausgegangen werden. Sollten sich die Baugruppen, etwa
auf Grund von Kollisionen, trotzdem verformen, so liegt bereits bei Eintritt der
Kollision ein Fehlverhalten vor. Das Auffinden dieser Kollision stellt damit
bereits die Fehlererkennung dar. Die Konsequenz des Fehlverhaltens zu
simulieren, beispielsweise in Form von Verformung oder Zerstörung von
Komponenten, ist nicht Aufgabe der Simulation.
Es sei an dieser Stelle jedoch vermerkt, dass z.B. Schweißroboter mit einer
Reihe von Schläuchen, die den Laserschweißkopf mit den erforderlichen
Ressourcen versorgen, ausgestattet sind. Als Modellierungsmethode für derlei
Anwendungsfälle bietet sich die Verwendung von Finite- Elemente- Methoden
23

an. Dabei wird das Gesamtmodell aus einer Reihe einzelner FE- Teilmodelle
aufgebaut, die durch Gelenke miteinander verbunden sind. Diese
Gelenkverbindungen lassen sich in Form kinematischer Bindungen
mathematisch formulieren und schränken somit die Bewegungsmöglichkeit der
einzelnen Glieder zueinander ein. Unter Minimierung der potentiellen Energie
des Gesamtsystems könnten dann entsprechend Lage und Position der
Elemente bestimmt werden.
Leider hat die Verwendung solcher Algorithmen auch Nachteile. Ein
gravierender Nachteil ist der numerische Aufwand. Auch unter Verwendung
moderner Hardware benötigen diese Verfahren unter Umständen Minuten oder
gar Stunden an Rechenzeit. Da sich die vorliegende Arbeit aus Zeit- und
Kostengründen auf die Simulation der kinematischen Verhältnisse
konzentrieren und damit die dynamischen Gegebenheiten unberücksichtigt
lassen soll, empfiehlt es sich, die Simulation auf die Verwendung starrer
Körper zu beschränken.
2.2.2 Konstruktionswerkzeug
Zunächst gilt es den Begriff Konstruktion im vorliegenden Anwendungskontext
zu definieren. Unter Konstruktion soll hier das Zusammenfügen von
bereits in CAD- Anwendungen modellierten dreidimensionalen Baugruppen
unter Berücksichtigung der kinematischen Verhältnisse des Systems
verstanden werden.
Für die virtuelle Konstruktion einer realen Anlage wird zunächst ein
programminternes Modell benötigt, dass in der Lage ist, alle für die Simulation
wichtigen Informationen abzubilden. Dieses sollte so generisch angelegt sein,
dass es für die heterogenen Anlagentypen des Laserschweißverfahrens einsetzbar
ist. Im folgenden soll daher untersucht werden, ob ein solches Modell
existiert und unter welchem Aufwand es programmtechnisch umgesetzt werden
kann.
Für die Entwicklung dieses Modells empfiehlt sich die Betrachtung der
Gesetze der Mechanik. In der klassischen Mechanik besitzt ein starrer Körper
sechs Freiheitsgrade: drei Ortskoordinaten eines (beliebigen) Referenzpunktes
im Körper sowie drei Drehwinkel. Für seine Bewegung existieren folgende
Möglichkeiten:
reine Translation
reine Rotation und
die Abbildung der Ortskoordinaten und Drehwinkel als Funktionen
der Zeit
Maschinen bestehen in der Regel aus einer Reihe einzelner Teilkörper
(Baugruppen, Bauteile), die durch Lagerungen, Führungen, Verbolzung o.a. so
miteinander gekoppelt sind, dass die zur Erfüllung der Funktion der Maschine
in Verbindung stehenden Bewegungen und Kraftübertragungen bestmöglichst
erreicht werden. Somit können selbst komplexe Bewegungen starrer Körper
durch Kombination von Bindungselementen in sogenannten gelenkgekoppelten
24

Mehrkörpersystemen realisiert werden. Eine Übersicht einiger häufig
verwendeter Bindungselemente findet sich in Abbildung 2-9. Diese gehören
ausschließlich der Gruppe der holonomen Bindungen an. Somit hängen die
Bindungsgleichungen lediglich von den Lagekoordinaten ab. Mathematisch
können holonome Bindungen in fast beliebiger Ausartung beschrieben werden.
In technischer Hinsicht erfüllen jedoch nur wenige Ausprägungen eine
sinnvolle Funktion und sind mit den konventionellen Mitteln der
Produktionstechnik herstellbar. Diese Restriktionen schränken die Anzahl
theoretisch möglicher Bindungselemente stark ein. Aus den verbleibenden
Möglichkeiten lässt sich eine Auswahl von Standardgelenken ableiten, die je
nach Anzahl ihrer Freiheitsgrade klassifiziert werden kann.
Abb. 2-9 Übersicht Standardverbindungen [Webhofer04]
Man spricht in diesem Zusammenhang auch von kinematischen Ketten. Diese
bestehen aus einer endlichen Anzahl von Gliedern, die durch Gelenke
miteinander verbunden sind. Ein Gelenk lässt Bewegungen in bestimmten
Freiheitsgraden oder Relativbewegungen zwischen einzelnen Gliedern zu oder
schränkt sie ein. Kinematische Ketten können als offene oder geschlossene
Strukturen ausgeprägt sein (Abbildung 2-10).
Fasst man nun mehrere hierarchische Ketten in einem Gesamtsystem
zusammen, so ergibt sich ein hierarchisches System, in dem die einzelnen
Objekte (Baugruppen) durch Beziehungen miteinander verknüpft werden. Die
Beziehungen entsprechen den durch den Freiheitsgrad der Bewegung und die
festgelegten Einschränkungen (Constraints) definierten Elementverbindungen.
In dem so modellierten Gesamtsystem können durch Manipulation weniger
Parameter verschiedene Konfigurationen des Modells erzeugt werden und
25

somit die verschiedenen Betriebszustände einer Maschine effizient
nachgebildet werden. Darüber hinaus lässt sich ein solches Modell als Graph
darstellen und bietet daher eine transparente Möglichkeit Maschinensysteme
abzubilden.
Abb. 2-10 offene und geschlossene kinematische Ketten
Ausgehend von den vorangegangen Betrachtungen wird daher als Modell ein
gelenkgekoppeltes Starrkörpersystem verwendet. Die Modellierung geschieht
folgendermaßen: In einem ersten Schritt wird das reale System in Baugruppen
und Bauteile (Substrukturen) zerlegt. Diese stellen im Starrkörpermodell die
beweglichen Glieder einer Starrkörperkette dar. Unter rein kinematischer
Betrachtung werden die Teilkörper in einem zweiten Schritt gemäß den realen
Lagerungen, Führungen, Verbolzungen etc. durch geeignete Bindungselemente
(Scharniergelenk, Linearführung, Schiebehülse etc.) an ihren
Gelenkanschlüssen im Modell miteinander verbunden. Man erhält somit einen
Mechanismus mit den Bewegungsmöglichkeiten der realen Maschine
(Abbildung 2-11).
Baugruppen
Grundgestell
Rumpf
Schwinge
Arm
Konstruktion
Verknüpfen
Constraints
Kinematisches Modell
A1 – A6 Rotationsachsen des
vollständigen Modells
Abb. 2-11 Erstellen des kinematischen Modells (Bsp. Kuka KR3)
26

Der zugehörige Graph des kinematischen Modells ist eine offene kinematische
Kette (Abbildung 2-12).
Schlitten
Rotation
Rotation
Rotation
Y1 Z1
X1
Szene
Abb. 2-12 Kinematische Kette für KR3 (ohne Kopf)
Betrachtet man die Anwendungsbeispiele aus Abschnitt 2.1, so können einige
Rückschlüsse auf die zu erwartende Komplexität der kinematischen Strukturen
gezogen werden. Abbildung 2-13 zeigt ein Modell der XXL- Anlage mit
eingezeichneten Transformationsrichtungen im Koordinatensystem der
Maschine für ausgewählte Bauteile. Es fehlen lediglich die in Abbildung 2-2
dargestellten Schweißkomponenten.
X2
Grundgestell
Rumpf
Schwinge
Arm
Abb. 2-13 Bewegungsrichtungen der XXL- Anlage
x
z
y
27

Überführt man die Hierarchie der Maschine in einen Graphen, so ergibt sich
die in Abbildung 2-14 dargestellte Struktur. Analysiert man diese, so ergeben
sich folgende Sachverhalte:
Zunächst ist ersichtlich, dass im Gegensatz zum oben dargestellten Beispiel
(KR3) das System aus kinematischen Ketten besteht, bei denen ein Objekt
mehrere Kind- Objekte haben kann, daher die Baumstruktur.
Seitenteil 1 Basis
Seitenteil 2
X- Teil 1 Schlitten
X- Teil 2
Y- Teil 1
Z- Teil 1
Szene
Y1- Teil 2
Z1- Teil 2
... ... ...
Y2- Teil 2
Z2- Teil 2
Abb. 2-14 Kinematische Ketten der XXL- Anlage (Ausschnitt)
Translation
feste Bindung
Des weiteren enthalten die dargestellten Graphen keine Zyklen. Dies
vereinfacht die programmtechnische und algorithmische Verfahrensweise. Es
soll daher die Annahme übernommen werden, dass die Graphen azyklisch sind.
Darüber hinaus kommen die Modelle, abgesehen von Fest-Verbindungen,
lediglich mit Bindungselementen aus, die eine reine Translation oder eine reine
Rotation um eine beliebige Achse realisieren. Zunächst sollen daher diese drei
Bindungselemente in den Anforderungskatalog aufgenommen werden.
28

2.2.3 Simulation
Die Simulation soll auf zwei Arten erfolgen können. Zum einen soll der
Benutzer die Maschinen manuell steuern können. Dies dient typischen
Anwendungsfällen in Form von Erreichbarkeitsstudien oder dem generellen
Untersuchen des Potentials der entwickelten Maschine.
Des Weiteren sollte eine Steuerung mittels CNC- Programmen implementiert
werden. Da es sich bei den vorliegenden Anwendungsbeispielen, was die
CNC- Steuerung betrifft, um sehr heterogene Systeme handelt, sollte auch
diese Funktionalität entsprechend generisch ausgelegt sein. Grund hierfür ist,
dass derzeit zwar ein einheitlicher CNC- Standard existiert, gleichzeitig aber
für fast jede Maschine eine Reihe von Sonderbefehlen existiert.
Darüber hinaus tritt speziell bei der XXL- Anlage die Problematik auf, dass
mehrere CNC- Programme parallel abgearbeitet werden müssen. Die gleiche
Problematik ergibt sich in einer Simulationsszene mit mehreren Robotern. Das
zu erstellende System sollte also in der Lage sein, mehrere parallel laufende
CNC- Programme ausführen zu können.
2.2.4 Kollisionserkennung
Die Kollisionserkennung dient der Auflösung von Fehlern in Form von
Konstruktionsmängeln oder Fehlern in den Anlagenprogrammen. Daher sollte
sowohl während der manuellen Steuerung als auch parallel zur CNC-
Simulation eine Erkennung möglich sein.
Dabei gilt, dass bei Eintritt einer Kollision ein Fehlverhalten vorliegt und die
Simulation dies dem Benutzer in geeigneter Form mitteilen muss. Zur späteren
Analyse des Fehlverhaltens ist es notwendig, dass Ort und Zeit der Kollision
bekannt sind und speziell die entsprechenden CNC- Zeilen, in denen
Kollisionen aufgetreten sind, markiert werden.
Darüber hinaus gilt es zu beachten, dass sich mehrere Baugruppen parallel
bewegen können. Dies ist beispielsweise im Falle der XXL- Anlage relevant.
Hier können sich die einzelnen Türme und der Schlitten unabhängig
voneinander bewegen.
29

2.3 Zusammenfassung
Anhand der Anwendungsbeispiele Laserstrahlschweißen und Laserstrahl-
Auftragschweißen inklusive vorhandener Simulationsumgebungen wurden
typische Verfahrensweisen und Problemstellungen des IWS aufgezeigt.
Anschließend wurden die Anforderungen für das Erreichen der gesetzten Ziele
an das zu erstellende System analysiert. Dabei stellte sich heraus, dass auf
Basis eines generischen Modells für die vorgestellten Beispiele eine
Modellierung möglich ist. Es ist davon auszugehen, dass sich damit ein
Großteil der zu erwartenden Anlagentypen in das System integrieren lässt, da
die Einschränkungen lediglich Spezialfälle in der Konstruktion ausschließen.
Der Anspruch, ein System für alle theoretisch denkbaren Anlagenkonstruktionen
zu erstellen, ist im Rahmen der vorliegenden Arbeit sicher nicht
zu erfüllen. Entscheidend ist jedoch, dass die Klasse der modellierbaren
Systeme klar definiert ist und die vorhandenen Problemstellungen gelöst
werden können.
Im folgenden seien als Ausgangpunkt für die nachfolgenden Kapitel noch
einmal alle funktionalen und nicht- funktionalen Anforderungen zusammengefasst.
funktionale Anforderungen
Import von Bauteilgeometrien aus unterschiedlichen CAD- Datenformaten
Konstruktion des Gesamtsystems unter Beachtung der kinematischen
Eigenschaften
Möglichkeit der manuellen Steuerung der Anlage und gleichzeitiger
(möglichst realistischer) visueller Darstellung
flexible CNC-Steuerung, die an die Besonderheiten einer jeden
Maschine (Dialekt, mehrere parallel laufende CNC- Programme)
angepasst werden kann.
Kollisionserkennung
Export in VR-Anlage (Cave des IWS)
30

nicht-funktionale Anforderungen
Implementierung in Java/ Java3D
Plattform: aktueller PC und aktuelle Grafikkarte
Ergonomie
Integrative Konzepte, Portabilität
Nachdem nun alle Anforderungen an das System analysiert sind soll im
folgenden Kapitel die zu erstellende Anwendung modelliert werden. Dazu ist
es notwendig, Lösungen für die geforderten Funktionalitäten und aufgedeckten
Problemstellungen zu entwickeln und in ein Gesamtkonzept zu integrieren.
31

3 Design
Die Software-Architektur (Architekturentwurf) repräsentiert die früheste
Softwaredesign-Entscheidung. Mit ihr werden alle Parameter wie Modifizierbarkeit,
Wartbarkeit, Sicherheit, Performance etc. in gewissen Grenzen
festgelegt und sind nach der in der Literatur vorherrschenden Meinung in
späteren Entwicklungsphasen nur noch mit erheblichen Kosten- und
Zeitaufwendungen abänderbar. Die Entscheidung über das Design einer
Software-Architektur ist somit eine der kritischsten und wichtigsten Punkte
während des Software-Entwicklungsprozesses.
Ziel der Entwurfsplanung ist es, alle projektspezifischen Problemstellungen zu
berücksichtigen und so ein stimmiges und realisierbares Planungskonzept zu
erhalten. Entsprechend den ermittelten Anforderungen ist auch diese Kapitel
gegliedert.
3.1 Konstruktion / Spiegelung der Kinematik
In der Konstruktionsphase sollen die kinematischen Strukturen der virtuellen
Anlage erzeugt und parametrisiert werden können. Die Bauteildaten liegen in
unterschiedlichen CAD- Formaten vor. Zunächst muss also ein Weg gefunden
werden, die Geometrie der Objekte in die Simulationsumgebung zu
importieren.
Abb. 3-1 Beispiel eines Szenegraphen
Hierfür existieren speziell für Java3D entsprechende FileLoader-
Implementierungen für diverse 3D- Formate (VRML, 3DS , STL etc.). Diese
können die genannten Formate lesen und die in den Dateien enthaltenen
32

Objekte in einen Java3D- Szenegraphen umwandeln, der alle Daten des
geladenen Objekts inklusive der Beleuchtung enthält (Abbildung 3-1).
Aus dem so erstellten Szenegraphen sollen nun kinematische Strukturen in dem
Szenegraphen der Simulationsumgebung erstellt werden. Dazu ist es
notwendig die kinematischen Einheiten in Form von Baugruppen zu
segmentieren. Die Idee ist daher, dass der Anwender die Blattknoten des
Szenegraphen (Shape-, Light- oder Fog- Knoten) in beliebiger Kombination zu
Baugruppen zusammenfügen und anschließend diese Baugruppen entsprechend
ihren kinematischen Eigenschaften in einer Hierarchie anordnen kann.
Szenegraph
Abb. 3-2 Erstellen von Baugruppen
Baugruppe
Baugruppe 1
Die erstellten Baugruppen (Abbildung 3-2) bestehen folglich aus mehreren
Shape- Knoten und deren Transformation in das Bauteilkoordinatensystem
(TransformGroup), die unter einer Verzweigungsgruppe (BranchGroup)
angeordnet sind. Die Transformationen für die TransformGroup’s werden aus
der Multiplikation aller Transformationen des Pfades vom Shape- Knoten zum
Wurzelknoten des geladenen Szenegraphen berechnet.
Eine so erstellte Baugruppe wird nun der eigentlichen zu erstellenden Szene
hinzugefügt. Diese besitzt ebenfalls einen Szenegraphen, welcher eine spezielle
Verzweigungsgruppe enthält, an der das gesamte Maschinenmodell angefügt
werden soll. Die Baugruppen auf der obersten Ebene der Hierarchie der
Maschine werden, zusammen mit einer Transformationsgruppe für die
Transformation des Bauteils in das Weltkoordinatensystem der Hauptszene, an
diese Verzweigungsgruppe angefügt (Abbildung 3-3).
Sollen zwei Baugruppen über eine Gelenkverbindung verknüpft werden, so
geschieht dies, indem an die BranchGroup des in der Hierarchie oben
stehenden Bauteils zwei TransformGroup’s angefügt werden, an deren Ende
das zweite Bauteil angebracht ist. Die erste TransformGroup dient der
Transformation des zweiten Bauteils in das Koordinatensystem des Ersten. Die
zweite TransformGroup spiegelt die kinematische Transformation des
verbindenden Gelenks (also Rotation oder Translation um/entlang einer
beliebigen Achse) wieder (Abbildung 3-4).
TG
BG
TG
S S
33

Abb. 3-3 Szenegraph mit zwei fest angeordneten Baugruppen
TG
Baugruppe 1
TG
TG
Baugruppe 3
BG
TG
BG
TG
S S
TG
S S
TG
Baugruppe 1
TG
BG
Szenegraph
TG
S S
BG
TG
Baugruppe 2
Abb. 3-4 Szenegraph mit kinematisch verbundenen Baugruppen
TG
BG
TG
Szenegraph
TG
TG
TG
Baugruppe 4
BG
BG
TG
S S
TG
S S
TG
Baugruppe 2
TG
BG
TG
S S
34

Die hierarchische Anordnung der Baugruppen im Szenegraphen hat den
Vorteil, dass sich Transformationen des übergeordneten Objekts auf alle
untergeordneten auswirken und sich entgegengesetzt Transformationen des
untergeordneten Objekts nicht auf das übergeordnete auswirken (Abb. 3-5).
Abb. 3-5 Transformationen in einer Hierarchie
Die Definition der Koordinatentransformation zwischen zwei Bauteilen sowie
die Spezifikation der Parameter der Gelenkverbindungen soll dabei wie folgt
geschehen (Abbildung 3-6):
1) Definition eines Punktes und zweier orthogonaler Vektoren im
anzufügenden Bauteil. Der Punkt und der erste Vektor (gelb)
entsprechen Lage und Orientierung der Gelenkachse, der zweite Vektor
(magenta) dient der Definition des Nullpunktes der Gelenktransformation
(Rotation o. Translation). Der cyanfarbene Vektor wird
automatisch so ergänzt, dass sich ein Rechtssystem ergibt.
2) Definition der gleichen Elemente im Koordinatensystem des Bauteils
an das angefügt werden soll.
3) Festlegen der Beschränkungen der Gelenkverbindung.
Das roten, grünen und blauen Achsen entsprechen der Basis des Bauteilkoordinatensystems
in der Reihenfolge x-, y- u. z-Achse.
(1) (2) (3)
±180°
Abb. 3-6 Spezifikation der Bauteiltransformationen und der Achsen
35

3.2 Simulation
Nachdem die Konstruktionsphase abgeschlossen ist, steht ein gelenkgekoppeltes
Starrkörpermodell der realen Anlage zur Verfügung. Der Zustand
dieser virtuellen (und der realen) Maschine ist durch die Konfiguration der
Parameter der Gelenkverbindungen definiert.
Während der Simulationsphase soll nun sowohl durch manuelle Ansteuerung
als auch durch das Ausführen von Steuerbefehlen in Form von CNC-
Programmen das Verhalten der Anlage simuliert werden. Speziell für die CNC-
Steuerung müssen also die Maschinenprogramme der realen Anlage in Modellkonfigurationen
der virtuellen Maschine umgesetzt werden. Für diese Aufgabe
eignet sich das aus der Softwaretechnik bekannte Architekturmuster
„Interpreter“ (Abbildung 3-7).
Programm (CNC)
Benutzer
Abstrakte Maschine(Interpreter)
Basissystem (Simulationsumgebung)
Abb. 3-7 Architekturmuster Interpreter im Anwendungskontext
Es handelt sich hierbei um eine Schichtenarchitektur mit Parametrisierung. Auf
einem Basissystem sollen heterogene Programme ausgeführt werden, die ein
Interpreter, als Teil einer abstrakten Maschine, in eine für das Basissystem
ausführbare Form übersetzt.
Im vorliegenden Fall entspricht das Basissystem der Simulationsumgebung.
Die abstrakte Maschine soll in Form einer CNC- Emulationskomponente
umgesetzt werden. Deren Aufgabe ist es, in einem ersten Schritt die CNC-
Quelltexte in eine interne einheitliche Beschreibung umzusetzen und diese
anschließend an eine Ablaufsteuerung zu übergeben. Die Ablaufsteuerung
erstellt dann in einem weiteren Schritt, nach Interaktion mit dem Benutzer, aus
der internen Beschreibung der CNC- Programme eine zeitliche Abfolge von
Modellkonfigurationen der Anlage und visualisiert diese im Basissystem. Die
Verwendung einer internen Beschreibungssprache bietet den Vorteil, dass beim
Ausführen der Simulation die Programme bereits geparst worden sind und nur
noch die interne Struktur abgearbeitet werden muss. Das entwickelte Modell ist
schematisch in Abbildung 3-8 dargestellt.
36

CNC-
Programm
Abstrakte Maschine
CNC-Interpreter
interne
Beschreibung
Basissystem (Simulationsumgebung)
Abb. 3-8 Abstrakte Maschine
Benutzer
Ablaufsteuerung
Modell-
Konfigurationen
Der dargestellte CNC-Interpreter muss in der Lage sein, die heterogenen CNC-
Dialekte zu verarbeiten und in die interne Beschreibungsform umzusetzen. In
Kapitel 2 wurde analysiert, dass diesbezüglich kein vollständig einheitlicher
Standard existiert. Es bietet sich daher an, diesen Interpreter, dem
Gesamtkonzept der zu erstellenden Anwendung folgend, ebenfalls generisch zu
konstruieren.
Da die Umsetzung eines CNC-Befehls in ein Maschinenverhalten unter
Umständen sehr komplex sein kann, bietet es sich an, für diese Konvertierung
die Möglichkeiten einer Programmiersprache zu nutzen. Die Anwender sollten
folglich für ihre speziell verwendeten virtuellen Maschinen eigene Interpreter
schreiben und diese in das Gesamtsystem integrieren können. Die Idee ist
daher, den CNC-Interpreter als ein System von abstrakten Klassen zu
modellieren. Diese bieten die Möglichkeit, erforderliche Schnittstellen zu
definieren und den Zugriff auf andere Objekte zu regeln. Dabei können
einzelne Funktionen vorimplementiert werden und andere durch Schnittstellen
definierte Funktionalitäten erst durch abgeleitete Klassen spezifiziert werden.
Die Definition der zu implementierenden Schnittstellen stellt sicher, dass die
erforderliche Funktionalität durch die hinzugefügten Klassen erbracht wird und
ermöglicht gleichzeitig die Verwendung einer einheitlichen Ablaufsteuerung
für diverse CNC- Systeme.
Mit Hilfe der Java Reflection API können diese zusätzlich implementierten
Klassen anschließend zur Laufzeit in das Programmsystem geladen und
verwendet werden. Somit steht ein dynamisches System zur Verfügung, in dem
das spezielle Maschinenverhalten bei Ansteuerung durch unterschiedlichste
CNC-Programmsysteme modelliert und integriert werden kann.
Abbildung 3-9 zeigt einen ersten Entwurf der abstrakten Maschine in einem
prototypischen Klassendiagramm.
37

Model
-model:Model
>
CNCInterpreter
+parse(source:string):CNCProgram
CNCInterpreterImpl
-model:Model
+run():void
+pause():void
+stop():void
CNCEmulator
erstellt
+run():void
CNCProgram
>
CNCCommand
-model:Model
+execute():void
+getTotalTime():int
CNCCommandImpl
Abb. 3-9 Klassendiagramm CNC- Interpreter
Die Ablaufsteuerung übernimmt die Klasse CNCEmulator. Die abstrakte
Klasse CNCInterpreter repräsentiert die Oberklasse für alle zu entwickelnden
speziellen Interpreter. Deren Aufgabe ist es, aus den CNC- Quelltexten die
interne Beschreibung der CNC-Programme in Form von sogenannten
CNCProgram-Klassen zu erstellen. Diese Programme bestehen wiederum aus,
nach Ausführungsreihenfolge geordneten, abstrakten CNCCommand- Klassen.
Ein CNCCommand repräsentiert einen einzelnen CNC-Befehl und ist für
dessen Ausführung zuständig. Die Ablaufsteuerung muss daher lediglich alle
erstellten CNCProgram-Klassen abarbeiten und für die Ausführung der
einzelnen Befehle (CNCCommand-Klassen) sorgen. Die CNCCommand-
Klassen beschreiben dabei, welche Änderungen der Konfiguration vorgenommen
werden sollen und in welcher Zeit dies geschehen soll.
Da nun der Fall auftreten kann, dass mehrere CNC-Programme parallel
abgearbeitet werden, muss ein Weg gefunden werden, diese zu parallelisieren.
Diese Aufgabe soll die Ablaufsteuerung übernehmen. Dazu wird der Zeitraum
der Programmausführung in diskrete Einheiten unterteilt (Abbildung 3-10). Die
Ablaufsteuerung ruft nun während der Abarbeitung der CNC-Programme die
einzelnen Kommandos nicht vollständig auf, sondern lediglich für eine gewisse
*
*
38

Zeitspanne. Somit können abwechselnd Zeitintervalle der einzelnen aktuell
auszuführenden Kommandos quasiparallel abgearbeitet werden.
Abb. 3-10 Zeitliche Diskretisierung der CNC-Programme
Die Methode execute() der CNC- Kommandos wird daher um zwei Parameter
t0 und t1 erweitert. Diese repräsentieren einen Start- und Endzeitpunkt
innerhalb der Laufzeit des jeweiligen Kommandos. Die Umsetzung der CNC-
Programme in Aufrufe der CNC- Kommandos zeigt Abbildung 3-11.
…
ti-1
ti
ti+1
ti+2
ti+3
ti+4
∆ t
1
2
ti-1
ti
ti+1
ti+2
ti+3
ti+4
CNC
Programm 1
CNC -
Programm 1
3
4
1
2
CNC
Programm 2
CNC -
Programm 2
Command1.execute(0,50)
Command3.execute(50,150)
Command1.execute(50,150)
Command3.execute(150,250)
Command2.execute(0,100)
Command3.execute(250,300)
Command4.execute(0,50)
Abb. 3-11 Parallelisierung der CNC-Programme (∆ t = 100ms)
Der Autor der CNC- Interpreter und damit auch der CNC- Kommando-
Klassen muss daher zeitlich abhängige Konfigurationsänderungen implementieren.
Dies gibt ihm beispielsweise die Möglichkeit, die kinematischen
Größen Geschwindigkeit und Beschleunigung der einzelnen Maschinen-
3
4
. . .
. . .
CNC –
Kommando
39

elemente bei Ausführung von CNC- Programmen abzubilden. Je feiner die
zeitliche Diskretisierung, d.h. je kleiner ∆t gewählt wird, desto genauer werden
diese Effekte dargestellt.
3.3 Kollisionskontrolle
Kollisionserkennung handelt kurz gesprochen davon, herauszufinden ob sich
zwei Objekte berühren oder schneiden. Falls sich die Objekte im Raum
bewegen, ist oft auch noch wichtig, den Zeitpunkt des Zusammentreffens zu
bestimmen. Kollisionserkennung findet daher im Allgemeinen in Raum und
Zeit statt.
Die Problematik besteht im Allgemeinen darin, dass der naive Ansatz, die
Primitive eines jeden Objekts gegen die der anderen auf Überschneidungen zu
testen, in den meisten Anwendungsfällen zu rechenaufwendig ist. Kollisionserkennung
ist daher meist der Flaschenhals in der Simulation. Es sollte daher
besonders an dieser Stelle auf die Effizienz der Rechenverfahren Wert gelegt
werden.
3.3.1 Vorbetrachtung
Für die Erkennung und Behandlung von Kollisionen existiert eine große
Anzahl unterschiedlicher Verfahren. Dabei gilt, dass keines unter optimalen
Kosten universell einsetzbar ist. Die Entscheidung für eines dieser Verfahren
hängt im wesentlichen von den Eigenschaften der Simulationsumgebung ab.
Simulationsumgebungen werden in Hinblick auf die Entscheidung für ein
Kollisionserkennungsverfahren in statische und dynamische Umgebungen
unterteilt:
Statische Umgebung: Objekte bewegen sich nicht
Dynamische Umgebung: Objekte bewegen sich im Raum.
Da sich die Objekte im vorliegenden Anwendungsfall bewegen sollen, handelt
es sich also um eine dynamische Umgebung.
Des Weiteren gilt es zu klären, ob es sich um starre oder deformierbare Körper
handelt und in welcher Objektrepräsentation diese vorliegen. Ersteres wurde
bereits in Kapitel 2 ausführlich erörtert und letzteres wird folgend analysiert.
Objektrepräsentation
Geometrische Modelle, die in der Computergrafik Verwendung finden, lassen
sich nach [Gottschalk00] in zwei Kategorien unterteilen: Polygonale- und
Nichtpolygonale Objekte (Abbildung 3-12).
40

Constructive
solid
geometry
Nichtpolygonale Objekte Polygonale Objekte
Implizite
Flächen
Abb. 3-12 Repräsentation von 3D- Modellen nach [Gotttschalk00]
Im folgenden soll von beliebigen polygonalen Modellen, also speziell auch von
„Polygon soups“ ausgegangen werden. Es wird sich jedoch später noch zeigen
(Abschnitt 3.3.7), dass diese recht allgemeine Annahme noch etwas
eingegrenzt werden kann.
Laufzeitanforderungen
Parametrisierte
Flächen
3D Modelle
Des weiteren ist entscheidend für die Auswahl des Verfahrens, dass möglichst
viele der erforderlichen Berechnungen vor Beginn der eigentlichen Simulation
durchgeführt werden können. Deren Kosten sind weitaus unkritischer zu
bewerten als Berechnungen, die während der eigentlichen Simulation in jedem
Zeitschritt durchgeführt werden müssen. Es ist daher anzustreben, so weit als
möglich Berechnungen vor Beginn der Simulation durchzuführen und die
Ergebnisse in den entsprechenden Objekten zu speichern. Dies erhöht
einerseits die Speicheranforderungen, bedeutet zugleich aber einen
Geschwindigkeitsgewinn.
3.3.2 Analyse vorhandener Verfahren
konvex
Strukturierte
Objekte
nicht konvex
Polygon
soups
Wie bereits erwähnt existieren zahlreiche Kollisionserkennungsverfahren für
unterschiedliche Anwendungsfälle. Die Problematik, dass ein einfacher
gegenseitiger Test aller Primitive auf Überschneidungen meist zu aufwendig
ist, wird dabei gelöst, indem versucht wird die Menge der Primitive auf einer
höheren Abstraktionsebene zu strukturieren und mittels konservativerer Tests
die Anzahl der notwendigen Primitivtests zu reduzieren.
Dabei wird meist in zwei Phasen vorgegangen. In der ersten Phase (Broad
Phase) der Kollisionserkennung wird versucht, alle Paare von Objekten
auszuschließen, die nicht kollidieren können. Räumliche und zeitliche
Kohärenzen können genutzt werden, um diese Erkennung zu beschleunigen.
41

In der zweiten Phase (Narrow Phase) werden die Kollisionen zwischen
Objektpaaren exakt bestimmt. Räumliche, hierarchische Datenstrukturen, wie
beispielsweise AABB- , OBB- oder k-dop- Bäume werden genutzt, um
möglichst schnell in Bereiche zu leiten, in denen Kollisionen auftreten. Auf
den entsprechenden (kleineren) Teilmengen von geometrischen Figuren kann
anschließend ein exakter Schnittest (Primitivtest) durchgeführt werden.
Darüber hinaus existieren beispielsweise noch sogenannte Raumaufteilungsverfahren
(Gittermethode, Quad/Oktonärbäume o. BSP- Bäume). Diese
sortieren grob die Objekte aus, die nicht kollidieren können und nutzen somit
räumliche Kohärenz aus. Probleme bereiten diese Verfahren jedoch bei
dynamischen Szenen, da sie nur schlecht aktualisiert werden können.
Generell gilt, dass soweit als möglich a priori- Wissen über die vorhandene
Szene und deren Strukturen für die Kollisionserkennung verwendet werden
sollte, um somit die Kosten für die Erkennung zu senken. Es soll daher
zunächst damit begonnen werden, die Struktur der zu simulierenden Objekte
im Hinblick auf die Entwicklung einer Kollisionserkennungsstrategie zu
untersuchen.
3.3.3 Broad Phase (Strukturanalyse)
In Kapitel 2 wurde ein Modell entwickelt, mit dem die kinematischen
Eigenschaften der realen Maschinen abgebildet werden. Dieses besteht aus
gelenkgekoppelten Starrkörpern in Form von Baugruppen. Ziel der
Kollisionserkennung soll sein, die Kollision von Baugruppen zu erkennen und
zu visualisieren. Die Baugruppen (und damit deren Primitive) entsprechen
somit den zu testenden Objekten.
Diese Objekte sind in einer Baumstruktur angeordnet. Eine Vater-Kind-
Beziehung dieses Graphen entspricht dabei einer Kopplung der Baugruppen
über eine Gelenkverbindung. Diese wird durch den Nutzer parametrisiert.
Festzulegen sind zum einen die Koordinatentransformation und damit die
Positionierung der Baugruppen zueinander und zum anderen die Constraints
(Beschränkungen) eines jeden Gelenks, die üblicherweise durch min/max-
Drehwinkel etc angegeben werden (Abbildung 3-13 und 3-14).
Abb. 3-13 Kuka-Roboter Kr3
42

Abb. 3-14 Constraints des Kr3
Da letzteres die Bewegungsfreiheit eines Gelenks gemäß der Auslegung der
realen Maschine einschränkt, kann davon ausgegangen werden, dass somit
Kollisionen zwischen direkt gekoppelten Baugruppen ausgeschlossen werden
können.
Für die gesamte Anlage heißt dies jedoch nicht, dass keine Kollisionen
auftreten können, da diese Einschränkungen jeweils nur Kollisionen zwischen
zwei gekoppelten Baugruppen ausschließen. Es ist davon auszugehen, dass
auch unter Einhaltung aller Constraints der Gelenkverbindungen Konfigurationen
der Anlage auftreten können, in denen Kollisionen zwischen nicht
direkt verbundenen Baugruppen auftreten können.
Folglich sollen zunächst von der Kollisionskontrolle alle diejenigen
Objektpaare ausgeschlossen werden, die in einer direkten Vater- Kind-
Beziehung im zugehörigen Modellgraphen stehen.
Weiterhin ist über die Struktur der Szene bekannt, dass die enthaltenen Objekte
in einer Hierarchie angeordnet sind. Auch dieses Wissen soll im folgenden für
die Reduzierung der notwendigen Kollisionstests verwendet werden.
In Kapitel 2.1 stellte sich heraus, dass diese hierarchische Anordnung den
Vorteil besitzt, dass sich Transformationen des übergeordneten Objekts auf alle
untergeordneten auswirken und sich entgegengesetzt Transformationen des
untergeordneten Objekts nicht auf das übergeordnete auswirken. Dies bedeutet,
dass bei Änderung der Parameter einer Gelenkverbindung sich lediglich die
unterhalb dieser Kante im Graphen angeordneten Knoten bewegen. Alle
übrigen verändern ihre Position und Lage nicht. Darüber hinaus gilt, dass die
sich bewegenden Objekte ihre relative Position und Lage zueinander ebenfalls
nicht verändern.
Abbildung 3-15 zeigt schematisch diesen Fakt. Ändert sich beispielsweise die
Translation Tr1 , so werden alle farblich markierten Knoten bewegt. Alle
anderen Knoten bleiben unverändert. Somit entstehen zwei Mengen
(orangefarbene und weiße Knoten), deren Elemente gegeneinander auf
Kollisionen getestet werden müssen. Dies reduziert die Anzahl der zu
testenden Paare.
43

Seitenteil 1 Basis
Seitenteil 2
X- Teil 1 Schlitten
X- Teil 2
Y- Teil 1
Z- Teil 1
Tr3
Szene
Y1- Teil 2
Z1- Teil 2
... ... ...
Abb. 3-15 Änderung der Parameter einer Gelenkverbindung
Es darf jedoch nicht unbeachtet bleiben, dass sich durch die Ermittlung der zu
testenden Paare ein Mehraufwand in jedem Zeitschritt ergibt. Betrachtet man
unabhängig von der Baumstruktur, und damit den Vater-Kind-Ausschluss
unbeachtet lassend, das Resultat dieser Verfahrensweise, so ergibt sich
folgende Rechnung:
Bisher war die Anzahl der zu testenden Paare in jedem Zeitschritt konstant
gegeben durch:
a
1
n(
n −1)
=
2
Durch die Separierung ergeben sich zwei aus unterschiedlichen Objekten
bestehenden Mengen M1 und M2, für die gilt:
M
M
1
2
= n
Die Anzahl der erforderlichen Tests errechnet sich somit aus
1
= n
a =
n ⋅ n
2
1
2
2
Tr2
.
Tr1
a... Anzahl der Paare
n... Anzahl der Objekte
n n = n
1 + 2
Y2- Teil 2
Z2- Teil 2
Translation
feste Bindung
44

Deren Maximum wird erreicht, wenn gilt
und beträgt somit
n
n 1 = n2
=
2
2
⎛ ⎞
max ( 2 ) = ⎜ ⎟
⎝ 2 ⎠
n
n a
Berechnet man nun die Differenz d aus der ursprünglich und der nun maximal
erforderlichen Anzahl an zu testenden Objektpaaren, so ergibt sich:
. 1 2 1
d =
n −
4 2
n
Diese Differenz ist für alle n > 2 positiv und steigt exponentiell (quadratisch)
mit wachsendem n (Abbildung 3-16). Es kann also davon ausgegangen werden,
dass der Mehraufwand durch die Ermittlung der zu testenden Paare besonders
bei großen n durch die Reduzierung der Anzahl der Tests kompensiert wird.
Abb. 3-16 Anzahl der Kollisionstests mit/ohne Kohärenz
Die bisher aufgestellten Rechnungen gelten jedoch nur für den Fall, dass sich
pro Zeitintervall jeweils nur eine Transformation ändert. Es ist aber nach
Kapitel 2 auch zulässig, dass sich mehrere Transformationen gleichzeitig
ändern können. In diesem Fall (Abbildung 3-17) entstehen für jede geänderte
Transformation (T1 u. T2) jeweils zwei Mengen von Objekten (bewegte -
unbewegte), die gegeneinander auf Kollisionen getestet werden müssen (M1
und M2). Jedes Paar definiert dabei eine Liste von Objektpaaren, die auf
Kollisionen getestet werden müssen (P1 und P2). Die Vereinigung aller dieser
Objektpaare ( P1 ∪ P2
) ergibt dann die Menge der zu testenden Paare.
.
.
45

1
2 3
T2
4 5 . . .
. . . . . .
Konfigurationsänderung
T1
. . .
Abb. 3-17 Ermittlung der zu testenden Objektpaare
Darüber hinaus gilt zu beachten, dass die Kollisionserkennung als
Zustandsmaschine zu implementieren ist, die alle aufgetretenen Kollisionen
speichern muss, wenn diese im neuen Zeitschritt nicht neu berechnet werden.
Dieser Fall tritt auf, wenn Kollisionen zwischen Objekten auftraten, deren
gegenseitige Lage sich im aktuellen Zeitschritt nicht ändert und die somit
folglich auch nicht erneut auf Kollisionen untersucht werden. Abbildung 3-18
zeigt schematisch die Vorgehensweise.
Kollisionserkennung
Kollisionspaare
ermitteln
Kollisionen
berechnen
Simulation
Neu zu
berechnende
Paare
Neuer Zustand
Neu zu
berechnende
Paare entfernen
Kollidierende
Paare
hinzufügen
Kollisionen
visualisieren
Abb. 3-18 Kollisionserkennung
T1: M1 = { orange }
M2 = { weiß, grün }
P1 = { 3-1, 3-2, 3-4, 3-5 }
T2: M1 = { grün }
M2 = { weiß, orange }
P2 = { 5-1, 5-2, 5-3, 5-4 }
P1 ∪ P2 = { 3-1, 3-2, 3-4, 3-5,
5-1, 5-2, 5-4 }
Kollisionen
Zusammengefasst betrachtet, nutzt die beschriebene Verfahrensweise die
zeitliche und räumliche Kohärenz des Systems für die Reduzierung der Anzahl
der zu testenden Objekte aus. Der Ausschluss von Objekten, die in einer
46

direkten Vater- Kind- Beziehung stehen, beruht hingegen auf der
Verwendungen von a priori - Wissen über die zu simulierende Szene.
Nachdem nun in der Strukturanalyse die Anzahl der notwendigen Tests
zwischen einzelnen Objekten reduziert wurde, soll im folgenden Abschnitt
geklärt werden, wie diese verbleibenden Objekttests möglichst effizient
durchgeführt werden können.
3.3.4 Narrow Phase
Für den Überschneidungstest zweier Baugruppen eignet sich die Verwendung
von Bounding Volumes (BV) und Bounding Volume Hierarchien (BVH),
welche daher im folgenden kurz vorgestellt werden.
3.3.4.1 Bounding Volumes
Bounding Volumes (BV, Hüllkörper) werden häufig in Kollisionserkennungsverfahren
verwendet. Die Idee ist, den aufwendigen Schnittest zwischen zwei
aus Polygonen bestehenden Objekten, durch einen weniger „teuren“,
konservativeren Test zu ersetzen. Dazu wird an Stelle der Originalgeometrie
der Objekte eine einfachere Geometrie um das Objekt gelegt und somit der
Schnittest vereinfacht. Anschließend wird bei Erkennen einer Kollision
zwischen den Hüllkörpern eine detailliertere Untersuchung durchgeführt. Da in
der Regel davon auszugehen ist, dass eine Kollision zweier Objekte ein
Spezialfall ist, bedeutet dieses Verfahren einen Geschwindigkeitsgewinn.
Um beim BV- Überlappungstest möglichst nur dann Überlappungen
festzustellen, wenn die Objekte tatsächlich kollidieren, sollten sie durch ihre
Bounding Volumes so gut wie möglich approximiert werden. Allerdings sind
für eine bessere Approximation auch komplexere Bounding Volumes nötig, so
dass dann der Überlappungstest selbst wieder aufwendiger wird. Bei bewegten
Objekten muss außerdem Wert darauf gelegt werden, dass die Aktualisierung
der Bounding Volumes effizient durchgeführt werden kann. Hinzu kommt,
dass die Bounding Volumes dazu geeignet sein müssen, den Aufbau und die
Aktualisierung einer BV- Hierarchie (Abschnitt 3.3.4.2) zu unterstützen. Ein
weiteres Kriterium für die Eignung zu Hierarchiebildung ist die Konvergenzgeschwindigkeit,
mit der sich die Bounding Volumes bei weitergehender
Verfeinerung der Hierarchie an ein Objekt anpassen.
Für die Bewertung der Bounding Volumes ist ein Gütekriterium erforderlich.
In der Literatur existiert dazu ein einheitlicher Ansatz einer Kostenfunktion der
folgenden Form:
T = N u ⋅C
u + N v ⋅C
v + N p ⋅C
. p
Dabei ist
Nu
Cu
Nv
Anzahl der aktualisierten Bounding- Volumes
Kosten für die Aktualisierung eines einzelnen BVs
Anzahl der BV- Überlappungstests
47

Cv
Np
Cp
Kosten für einen BV- Überlappungstest
Anzahl der Primitivtests
Kosten für einen Primitivtest.
Ein gutes Verfahren zur Kollisionserkennung mit Bounding Volumes hat die
Aufgabe, T zu minimieren. Abbildung 3-19 zeigt einige der gebräuchlichsten
Bounding Volumes und ihre Eigenschaften bezüglich der Anzahl und
Geschwindigkeit der Überlappungstests.
Sphäre AABB OBB 6-dop Konvexe
Hülle
Erhöhung der Passgenauigkeit
Abnahme der Anzahl der Überlappungstests
Abnahme der Kosten für (Überlappungstest + BV- Aktualisierung)
Abb. 3-19 Beispiele für Bounding Volumes
Sphären. Für Sphären müssen lediglich Kugelmittelpunkt und –radius
gespeichert werden, da sie rotationsinvariant sind. Sowohl Überlappung als
auch Abstand zweier Kugeln lassen sich wesentlich schneller als mit jeder
anderen Art von Bounding Volume bestimmen. Weil die Konvergenz noch
schlechter als bei AABBs ist, existiert eine Vielzahl von Methoden, um je nach
Art der Objekte möglichst geeignete Hierarchien über Kugeln aufzubauen.
Axis-aligned Bounding Boxes (AABB). Dies ist die einfachste Form eines
Bounding Volumes, sie entspricht einem Quader, der senkrecht zu den
Koordinatenachsen ausgerichtet ist. Die Speicheranforderung für AABBs ist
sehr gering und Überlappungstest und Aktualisierung lassen sich mit wenigen
Koordinatenvergleichen durchführen. Durch einfaches Aufspalten in mehrere
kleinere Quader eignen sie sich für den automatischen Top-Down-Aufbau
einer Hierarchie. Diesen Vorgang kann man solange Fortsetzten, bis die
AABBs auf der untersten Ebene nur noch eine Facette enthalten.
Oriented Bounding Boxes (OBB). OBBs sind einer Erweiterung von AABBs
und können in beliebige Richtungen rotiert werden. Aus diesem Grund
konvergieren sie wesentlich schneller (quadratisch) gegen das approximierte
Objekt. Die optimale Anpassung einer OBB an eine Punktmenge ist allerdings
48

nicht trivial, es muss zumindest die konvexe Hülle der Punkte bestimmt
werden, deren Kovarianzmatrix dann die Ausrichtung der OBB über ihre
Eigenvektoren bestimmt.
Discret Oriented Polytopes (k- Dop). Ein k-Dop [Klosowski98] ist ein durch
k Hyperebenen begrenzter Polyeder. Die Normalen der Hyperebenen werden
aus einer kleinen Menge von Vektoren gebildet. Im allgemeinen wählt man die
Einträge der Normalenvektoren aus der Menge {-1,0,1}. Zu jeder Normalen
wird auch die Normale in die Gegenrichtung gebraucht, so dass
gegenüberliegende Facetten des Polyeders parallel zueinander sind.
Lässt man beispielsweise im R³ für jeden Normalenvektor nur jeweils einen
Eintrag ungleich 0 zu, ergeben sich die sechs Normalenvektoren einer AABB
(6-Dop), dagegen erhält man mit Einträgen aus {-1,1} einen Oktaeder (8-
Dop). Durch Hinzunahme weiterer Vektoren werden weitere k-Dop’s (z.B. 14-
,18- oder 26 Dop) gebildet.
3.3.4.2 Bounding Volume Hierarchien
Bounding Volume Hierarchien (BVHs) sind einfache und häufig verwendete
Datenstrukturen für die Kollisionserkennung zwischen komplexen Objekten.
Sie lassen sich unabhängig von den topologischen Eigenschaften des Modells
erstellen und sind somit auch für Polygon soups einsetzbar.
Ein BVH ist eine Baumstruktur aus unterschiedlichen Bounding Volumes,
deren Blattknoten zusammen die gesamte Objektgeometrie enthalten und in der
jeder Vater-Knoten, die Geometrie aller seiner Kind- Knoten umhüllt. Im
Allgemeinen ist jedes BV in der Hierarchie in Bezug auf Volumen, Oberfläche,
Durchmesser o.a. Gütekriterien so optimal wie möglich zu gestalten.
Abbildung 3-20 zeigt ein Beispiel einer BVH mit Sphären.
Abb. 3-20 Bounding Volume Hierarchie aus Sphären
Die Kollisionserkennung mittels BVHs wird durch rekursives Testen auf
Überschneidungen der im Baum enthaltenen BV durchgeführt. Wurde eine
Überlappung entdeckt, so werden anschließend die Kind- Knoten der
beteiligten BVs getestet. Falls keine Kollision festgestellt werden konnte, wird
die Rekursion für diesen Zweig des Baumes abgebrochen. Setzt sich die
49

Rekursion bis zu den Blattknoten fort, so wird anschließend ein Primitivtest der
in den Knoten enthaltenen Geometrie durchgeführt.
Im Allgemeinen gilt, dass Komplexere BVs die Objektgeometrie besser
approximieren und damit die Anzahl der notwendigen Überlappungstests
reduzieren. Zugleich sind diese Tests jedoch gewöhnlich aufwendiger als bei
einfacheren BVs. Es muss also gemäß der Kostenfunktion u.a. ein Kompromiss
zwischen der Anzahl und der Kosten der durchzuführenden Tests sowie den
Aktualisierungskosten gefunden werden. Im folgenden Abschnitt soll dies
näher analysiert werden.
3.3.4.3 Entscheidung für ein Bounding Volume
Auch hier gilt wieder, dass kein Bounding Volume unter optimalen Kosten für
alle Anwendungsfälle einsetzbar ist. Die Entscheidung für ein BV muss daher
die speziellen Anforderungen der Simulationsumgebung und die Eigenschaften
der unterschiedlichen BVs berücksichtigen. Denkbar sind darüber hinaus auch
Kombinationen unterschiedlicher BVs. Prinzipiell gilt, dass alle vorgestellten
BVs im vorliegenden Anwendungsfall eingesetzt werden könnten.
Die beste Approximation der Objekte wird mit k-Dops erreicht. Problematisch
ist jedoch, dass bei Rotation des Objekts, diese, auf Grund ihrer
Achsparallelität, neu erzeugt werden müssten. Gleiches gilt für die (an sich in
der Gruppe der k-dops enthaltenen) AABBs. Speziell im Hinblick auf die
Verwendung einer Hierarchie von BVs stellt dieser Fakt ein erhebliches
Problem dar, da dann zu Laufzeit der Simulation in jedem Zeitschritt die BV-
Hierarchien eines jeden Objekts (bei Rotation) neu erzeugt werden müssten.
Um diesem Problem zu begegnen, existieren Verfahren, die entweder nur
wirklich bewegte Objekte neu erzeugen oder bereits vor Ausführung der
Simulation verschiedene quantisierte Orientierungen der BVs berechnen und
abspeichern (QuOSPOs).
Prinzipiell geht aus der Literatur- Recherche hervor, dass sich für dynamische
Umgebungen mit Starrkörpern OBBs am besten eignen. Der Grund hierfür ist,
dass die Gesamte OBB- Hierarchie offline erzeugt werden kann und dass bei
Rotation eines Objekts, diese nicht neu erzeugt werden muss, sondern einfach
mitrotiert werden kann. Alle Hüllkörper können somit vor Beginn der
eigentlichen Simulation berechnet werden.
Sphären haben den Vorteil, dass der Überlappungstest im Vergleich zu allen
anderen BVs sehr schnell durchzuführen ist. Problematisch ist hier, dass die
Konvergenz der Approximation an das zu umhüllende Objekt meist sehr gering
ist. Im vorliegenden Fall ist dies ebenso anzunehmen, da sich
offensichtlicherweise Maschinenteile oder speziell Roboterarme nur sehr
schlecht mit Sphären approximieren lassen (Abbildung 3-21). Dies hat dann
die Konsequenz, dass sich Bounding Boxen in zunehmenden Maße überlappen,
obwohl keine Kollision eingetreten ist und somit die Anzahl der
Überlappungstests steigt.
50

Abb. 3-21 Konvergenz einiger Bounding Volume
Es sollen daher für den Schnitttest der Baugruppen Orientierte Bounding Boxe
Hierarchien (OBB- Trees) verwendet werden, welche im folgenden näher
erläutert werden.
3.3.5 Oriented Bounding Box Trees (OBB-Trees)
Eine orientierte Bounding Box (OBB) ist ein beliebig orientierter Quader. Eine
OBB Repräsentation besteht folglich aus einem Mittelpunkt, der Orientierung
der Box und der Ausdehnung in die sich aus der Orientierung ergebenden drei
Richtungen. Abbildung 3-22 zeigt eine zweidimensionale schematische
Repräsentation einer vierstufigen OBB- Hierarchie.
Abb. 3-22 vierstufige Hierarchie aus OBBs (S.6)
Im folgenden soll nun zum einen gezeigt werden, wie diese Hierarchien erstellt
werden können und zum anderen, welche Möglichkeiten es gibt, die Parameter
der OBBs für eine gegebene Polygonmenge zu berechnen.
3.3.5.1 Erstellen der Bounding Volume Hierarchie
Bounding Volume Hierarchien können auf drei Arten erstellt werden: Top-
Down, Bottom Up oder durch Inkrementelles Einfügen. OBB- Hierarchien
51

werden auf Grund der einfachen Implementierung meist Top-Down in einer
sogenannten „split and fit“ - Strategie erstellt. Das bedeutet, dass zunächst das
gesamte Objekt umhüllt wird und anschließend das so erstellte Volumen in
eine feste Anzahl kleinerer Volumen zerlegt wird. Für die in jedem dieser
Teilvolumen enthaltene Objektgeometrie wird dann ein neues Hüllvolumen
berechnet. Dies wird so lange durchgeführt, bis die Volumen auf der untersten
Ebene nur noch ein Primitiv der Objektgeometrie enthalten.
Die Anzahl der Unterteilungen eines jeden Volumens bestimmt den
Verzweigungsgrad der so erstellten Bäume. Denkbar sind daher beispielsweise
Binär-, Quad- oder Oktonärbäume (Abbildung 3-23).
Abb. 3-23 Binärbaum (l.) u. entsprechender Quadtree (r.) [Mezger01]
Höhergradige Bäume haben dabei den Vorteil, dass sie mit weniger Knoten
auskommen. Somit benötigen sie in der Regel weniger Speicherplatz.
Abbildung 3-24 zeigt die Rekursionsbäume für einen Binär- und Quadtree für
den Fall, dass zwei Blätter kollidieren. Es zeigt sich, dass die Anzahl der
notwendigen Überlappungstests gleich ist, der Binärbaum jedoch doppelt so
tief ist. Dadurch erhöhen sich beim Binärbaum die Traversierungskosten.
Abb. 3-24 Kollision zweier Binärbaumblätter (l.), Quadtree (r.) [Mezger01]
Falls sich nun allerdings nur die Wurzeln der beiden Hierarchien überlappen,
aber keine Kollision stattfindet (Abbildung 3-25), sind bei der Quadtree-
Implementierung fast doppelt so viele Überlappungstests (Nv) nötig.
52

Abb. 3-25 Überlappung der Wurzelknoten [Mezger01]
Aufgrund dessen, dass im vorliegenden Fall die Kosten für einen
Überlappungstest (Cv) relativ hoch sind, sollte daher jeder unnötige Schnitttest
(Nv) vermieden werden. Die größeren Speicheranforderungen durch
Binärbäume und die erhöhte Traversierungsdauer werden dafür in Kauf
genommen. Es werden folglich Binärbäume verwendet.
Das Teilen der OBBs erfolgt, indem zunächst eine Trennebene orthogonal zur
längsten Achse der Box aufgespannt wird. Diese wird so konstruiert, dass sie
den Scherpunkt der Objektgeometrie enthält. Anschließend wird jedes Primitiv
entsprechend der Lage seines Schwerpunkts einem der beiden durch die
Trennebene definierten Halbräume zugeordnet. Sind beiden Halbräumen
Primitive zugeordnet worden, so werden aus diesen neue Boxen erzeugt
(Abbildung 3-26).
Abb. 3-26 Aufbau einer Bounding Volume Hierarchie
Konnte keine Separierung vorgenommen werden, so wird die Trennebene
orthogonal zur zweitlängsten Achse gewählt. Wurden auch hier wieder alle
Primitive einem Halbraum zugeordnet so wird die kürzeste Achse als Normale
der Trennebene verwendet. Dieser Vorgang wird so lange wiederholt, bis die
OBBs auf der untersten Ebene jeweils nur noch ein Primitiv enthalten.
53

3.3.5.2 Berechnung der OBB-Parameter
Soll ein beliebiges Objekt durch eine OBB umhüllt werden, so müssen deren
optimale Parameter (Mittelpunkt, Orientierung und Ausdehnung) bestimmt
werden. Besonders problematisch ist hierbei, die Orientierung der Box zu
berechnen. Ist diese bekannt, so lassen sich die übrigen Parameter einfach
bestimmen, was im folgenden gezeigt werden soll:
Unter der Annahme, dass die Orientierung der Box bereits berechnet ist, lassen
sich die Ausdehnungen entlang der Flächennormalen v1, v2 und v3
folgendermaßen bestimmen:
u1 = max k ( v1
⋅ pk
)
u = ( v ⋅ p )
2 max k 2 k
3 = max k ( v3
pk
u ⋅
l1 = min k ( v1
⋅ pk
)
l = ( v ⋅ p )
2 min k 2 k
3 = min k ( v3
pk
l ⋅
)
Die Punkte pk entsprechen dabei den Vertices der zu umhüllenden Geometrie.
Die Ausdehnung entlang einer Achse vi berechnet sich aus der Differenz ui - li.
Der Mittelpunkt c wird anschließend bestimmt:
1
1 1
c = ( l1
+ u1)
v1
+ ( l2
+ u2
) + ( l3
+ u3
) v3
2
2 2
Nun gilt es zu klären, wie die Orientierung der OBB berechnet werden kann.
Ziel ist es, die OBB nach dem zu umhüllenden Objekt auszurichten. Ist dieses
beispielsweise lang und dünn, wie z.B. ein Stift, so sollte eine Achse der
berechneten Box nach dessen längster Seite ausgerichtet sein. Ist das Objekt
hingegen besonders dünn entlang einer Richtung, wie dies beispielsweise bei
einem Blech der Fall ist, so sollte eine Achse der OBB möglichst an dessen
Normale ausgerichtet sein. Dies wird nach [Gottschalk00] erreicht, indem die
statistische Verteilung der Geometrie des zu umhüllenden Objekts untersucht
wird, was im folgenden näher erläutert werden soll.
3.3.5.3 Kovarianzbasierte Methoden
Die Form und Gestalt einer Puntkwolke lässt sich approximativ mit einer
Kovarianzmatrix C und ihrem Mittelpunkt m beschreiben. Für Punkte im n-
dimensionalen Raum ergeben sich entsprechend eine reelle, symmetrische
nxn–Matrix und ein n-dimensionaler Vektor. Diese Größen beschreiben die
Punktmenge genau auf die gleiche Art und Weise, wie eine Gaußkurve die
Verteilung einer Menge von Punkten auf einer reellen Achse beschreibt. Die
Kovarianzmatrix und der Mittelpunkt sind lediglich Verallgemeinerungen auf
höhere Dimensionen der üblichen Glockenkurve.
)
54

Die statistische Verteilung in eine spezielle Richtung v ist gegeben durch
v T Cv. Dies entspricht der Streuung der Achs-Projektionen der Punkte auf v. Die
Richtung, die diesen Wert maximiert oder minimiert entspricht den
Eigenvektoren von C, welche zueinander orthogonal sind, da C reell und
symmetrisch ist.
Zur Bestimmung der Orientierung der OBBs wird daher zunächst die
Kovarianzmatrix und deren Eigenvektoren berechnet. Anschließend werden,
wie oben beschrieben, alle Punkte auf diese projiziert und so der Mittelpunkt
und die Ausdehnung der Box bestimmt.
Berechnet man nun die Kovarianz aus den Vertices des zu umhüllenden
Objekts, so treten unter Umständen Probleme dahingehend auf, dass die
berechnete Box nicht optimal ist. Innen liegende Punkte können beispielsweise
die Ausrichtung der OBB verfälschen (Abbildung 3-27).
Abb. 3-27 Auswirkung innerer Punkte auf die OBB- Berechnung
Es ist daher zu empfehlen nur aus den äußeren Punkten die Kovarianzmatrix zu
bestimmen. [Gottschalk00] zeigt jedoch, dass auch damit noch nicht optimale
Boxen erzeugt werden können, falls die extremalen Punkte ungleichmäßig über
den Rand des Objekts verteilt sind (Abbildung 3-28).
Abb. 3-28 Auswirkung ungleichmäßiger Sampling- Raten
Aus den bisher gezeigten Problemen folgt, dass eine Berechnung der
statistischen Verteilung der Vertices allein offenbar nicht ausreichend ist. Die
Idee nach Gottschalk ist daher, über den Flächen/Linien der Primitive zu
55

integrieren und aus diesen Ergebnissen die Kovarianz zu bestimmen
(Abbildung 3-29).
Abb. 3-29 Integrieren über den Primitiven
Das Problem daran ist nun, dass die Ausrichtung von der Länge/Größe der
Linien/Flächen abhängig ist und dass das zu umhüllende Objekt unter
Umständen aus sehr kleinen Linen-/Flächensegmenten bestehen kann, die
keinen großen Einfluss auf die Orientierung der Box haben, diese aber in ihrer
Größe sehr ausdehnen (Abbildung 3-30).
Abb. 3-30 Auswirkungen kleiner Linien/Flächensegmente
Die Idee ist daher, die konvexe Hülle des Objekts zu bilden, und aus deren
Oberfläche die Kovarianz zu berechnen (Abbildung 3-31).
Abb. 3-31 Verwendung der konvexen Hülle
56

Für die Berechnung der Kovarianzmatrix auf der konvexen Hülle, muss diese
zuvor trianguliert werden. Anschließend wird die Kovarianzmatrix
folgendermaßen aufgestellt:
Die Kovarianzmatrix ist bestimmt durch:
Cij = E[
xi
x j ] − E[
xi
] E[
x j ]
die Erwartungswerte E [ xi
] und [ i j ] x x E sind definiert durch:
E [ xi
] =
[ i j ] x x E =
∫
M
x dA
∫
M
i
dA
1
= M ∑ A k
∫
M
x x
i
∫
M
1
A
j
dA
dA
xi
A
... i-te Koordinate eines beliebigen Punktes der Dreiecke
M ... Fläche aller Dreiecke
A k ... Fläche des k-ten Dreiecks
mi k mi
... i-te Koordinate des Mittelpunkts des k-ten Dreiecks
M pi
... i-te Koordinate des Mittelpunkts des gesamten Modells
k ,qi k ,ri k ... i-te Koordinaten der Eckpunkte des k-ten Dreiecks
s,t ... Parameter der Dreiecksparametrisierung:
k
k
x ( s,
t)
= p
k k
k k
+ s ⋅ ( q − p ) + t ⋅ ( r − p ) = f ( s,
t)
A
k
m
k
i
1 1−s
k
= ∑ 2A
M ∫ ∫
k
0
0
f ( s,
t)
dtds
k
1 2A
k k k k k k k k
= ∑ [ 9mi
m j + pi
p j + qi
q j + ri
rj
]
M
A
k
24
und somit ergibt sich für die Kovarianzmatrix:
k
k k k k k k k k M M
[ m m + p p + q q + r r ] m m
1 1
Cij = M ∑ 9 i j i j i j i j −
A 24
i
j
.
.
57

Für die Identifikation der OBB- Parameter müssen abschließend die
Eigenvektoren der Kovarianzmatrix berechnet werden. Dies soll im folgenden
Abschnitt erläutert werden.
3.3.5.4 Bestimmung der Eigenvektoren
Die Berechnung der Eigenvektoren erfordert zunächst die Bestimmung der
Eigenwerte. Diese lassen sich durch die Lösung der folgenden Gleichung
bestimmen, wobei det(M) die Determinante einer nxn-Matrix M und E die nxn-
Einheitsmatrix bezeichnet:
det( A − λ E)
= 0 .
Die Auflösung der Determinante liefert ein Polynom n-ten Grades. Da dessen
Auflösung sehr ineffizient ist, werden die Eigenvektoren großer Matrizen in
der Regel durch spezielle numerische Verfahren bestimmt. Eines dieser
Standardverfahren ist die QR- Zerlegung.
QR- Zerlegung
Es gibt wiederum drei Verfahren, mit denen sich eine QR- Zerlegung
berechnen lässt:
1) Das Verfahren von Gram-Schmidt, das auf dem Verfahren beruht, aus n
linear unabhängigen Vektoren n orthonormale Vektoren zu machen.
Diese Verfahren ist numerisch instabil, wenn man keine Modifikation
vornimmt.
2) Das Householder-Verfahren, das man sich über Spiegelungen an
Hyperflächen veranschaulichen könnte.
3) Das Givens-Verfahren, das mit Rotation von Vektoren in einem
Koordinatensystem begründet werden kann. Im Vergleich zum
Householder Verfahren ist der Aufwand des Givens- Verfahrens
größer, weil nicht spaltenweise sondern elementweise Nullen erzeugt
werden.
Aus den beschriebenen Eigenschaften geht hervor, dass zur Berechnung der
QR- Zerlegung die Verwendung des Householder Verfahrens anzustreben ist.
Eine detaillierte Beschreibung des Householder- Verfahrens soll an dieser
Stelle ausgelassen werden, da es sich hierbei um ein Standardverfahren der
Numerik handelt.
Die Eigenwerte berechnen sich anschließend nach folgendem Algorithmus:
Iteriere bis zur Konvergenz:
Berechne QR- Zerlegung A = Q ⋅ R
T
Setze A = R ⋅Q
(Ähnlichkeitstransformation A → Q ⋅ A ⋅Q
)
58

Das Verfahren konvergiert zu einer Matrix in oberer Dreiecksform, deren
Hauptdiagonale die Eigenwerte enthält.
Berechnung der Eigenvektoren
Aus den Eigenwerten lassen sich die Eigenvektoren aus der Gleichung:
( A − λ E)
⋅ x = 0
bestimmen. Es muss somit lediglich ein lineares Gleichungssystem mit drei
Gleichungen gelöst werden.
Nachdem nun alle Parameter der OBBs bestimmt sind, soll im folgenden soll
geklärt werden, wie der Überlappungstest zwischen OBBs möglichst effizient
durchgeführt werden kann.
59

3.3.6 OBB Überlappungstest
Ein trivialer Test auf Nichtüberschneidung stellt die Projektion der Boxen auf
eine beliebige Achse dar. Jede Box würde so ein Intervall auf dieser Achse
aufspannen. Überlappen sich diese Intervalle nicht, so wird diese Achse als
separierende Achse für die Boxen bezeichnet und die Boxen überlappen sich
folglich ebenfalls nicht. Überlappen sich die Intervalle jedoch, so kann keine
Aussage über eine Kollision getroffen werden, die Boxen könnten sich
schneiden, müssen es aber nicht. In diesem Fall wären weitere Tests
erforderlich.
Nach [Gottschalk00] kann gezeigt werden, dass zwei nichtüberlappende
konvexe Polytope im R 3 immer von einer Ebene separiert werden können, die
parallel zu einer Fläche des Polytops oder parallel zu einer Kante von jedem
Polytop ist [Gottschalk, Lin, Manocha96].
Da jede Box drei unterschiedliche Flächenorientierungen und drei unterschiedliche
Kantenrichtungen besitzt, sind folglich für den OBB- Schnitttest maximal
15 potentielle separierende Achsen zu testen (3 Flächen der einen Box, 3
Flächen der anderen Box und 9 paarweise Kombinationen der Kanten).
Überlappen sich die beiden Boxen nicht, so existiert unter diesen keine
separierende Achse. Somit ist ein Test der 15 Achsen hinreichend für die
Aussage, ob sich die Boxen überlappen oder nicht.
Um diesen Test durchzuführen, müssen also die Mittelpunkte und die
aufgespannten Radien der Boxen auf einer der zu testenden Achsen projiziert
werden (Abbildung 3-32). Ist die Entfernung der Boxmittelpunkte größer als
die Summe der Radien, so überlappen sich die Intervalle und damit die Boxen
nicht. Die gewählte Achse wird somit zu einer separierenden Achse und der
Test kann abgebrochen werden.
Abb. 3-32 L ist separierende Achse für die OBBs A und B
60

Folglich ergibt sich für die Berechnung einer separierenden Achse folgender
Ausdruck:
r r
T ⋅ L
>
∑
i
r
i
a A ⋅ L +
i
∑
i
r
b B
i
i
⋅ L .
Ist dieser erfüllt, so separiert L die beiden getesteten Boxen und diese
überlappen sich folglich nicht.
3.3.7 Primitivtest
Bisher wurden lediglich Überschneidungstests zwischen Hüllvolumen betrachtet.
Handelt es sich hierbei im Falle einer Überlappung um Blattknoten in der
entsprechenden Hierarchie, so muss für eine exakte Kollisionserkennung eine
Untersuchung der von den Volumen eingeschlossenen Geometrie durchgeführt
werden.
Zunächst soll analysiert werden, welche geometrischen Primitive zu erwarten
sind und welche Möglichkeiten für einen gegenseitigen Überlappungstest
bekannt sind.
3.3.7.1 Geometrie
Die Java3D – Geometrie eines Shapes besteht aus Punkten, Linien, Dreiecken
oder Vierecken. Prinzipiell müssten also für alle diese Primitive Überlappungstests
implementiert werden. In der vorliegenden Arbeit soll sich der
Primitivtest jedoch auf Dreiecke beschränken. Grund hierfür ist, dass es sich
bei den durch die FileLoader geladenen Bauteile in der Regel um
dreidimensionale Objekte handelt, deren äußere Hülle durch Flächen (Dreiecke
oder Vierecke) approximiert wird. Sollte es sich bei diesen Flächenstücken um
Vierecke handeln, so können diese leicht trianguliert werden.
Für den Schnittest zweier Dreiecke existieren eine Reihe von Verfahren. Die
Literaturrecherche ergab, dass die am häufigsten Verwendung findenden
Algorithmen diejenigen von [Möller97], [Held97] und [Devillers02] sind,
welche im folgenden vorgestellt werden sollen.
3.3.7.2 Möller
[Möller97] beginnt mit der gegenseitigen Lageuntersuchung jedes Dreiecks in
Bezug auf die durch das andere Dreieck aufgespannte Ebene. Liegen alle
Eckpunkte jeweils im gleichen Halbraum und keiner auf der Ebene, so
überlappen sich die Dreiecke nicht und der Test kann abgebrochen werden.
Andernfalls schneiden die Dreiecke die Schnittgerade L der durch sie
aufgespannten Ebenen (Abbildung 3-33). Ein Test der Intervalle [t3,t4]und
[t1,t2] auf Überschneidungen liefert schlussendlich ein Ergebnis.
61

3.3.7.3 Held
[Held97] untersucht in ähnlicher Art und Weise zunächst die gegenseitigen
Lagebeziehungen der Eckpunkte p2, q2 u. r2 des zweiten Dreiecks T2 in Bezug
auf die durch das erste aufgespannte Ebene Π1. Liegen diese nicht alle im
selben Halbraum, so wird in einem zweiten Schritt direkt das Liniensegment s
= T2 ∩ Π1 bestimmt (Abbildung 3-33).
Abb. 3-33 Verfahren von Möller (l.) und Held (r.)
Anschließend wird in einem zweidimensionalen Linie/Dreieck- Schnitttest
untersucht, ob dieses Segment T1 schneidet.
3.3.7.4 Devillers
Die Verfahren von Möller und Held berechnen den Schnitt der Dreiecke in
mehreren Stufen und haben nach [Devillers02] daher zwei Nachteile.
Zum einen muss die Ausnahmebehandlung für jeden Schritt der Verfahren
exklusiv durchgeführt werden. Weiterhin hat die Abarbeitung von mehreren
Schritten zur Folge, dass sich die Verwendung von Zwischenergebnissen
nachteilig auf die Rechengenauigkeit auswirkt. Das Verfahren nach
[Devillers02] kommt ohne die Verwendung von Zwischenergebnissen aus, ist
damit numerisch robuster und zusätzlich auch effizienter.
Das Verfahren nach [Devillers02] basiert lediglich auf der Auswertung von
Prädikaten der folgenden Form:
Def. 3-1 Gegeben seien vier Punkte in R 3 : a = (ax; ay; az), b = (bx; by; bz), c =
(cx; cy; cz) and d = (dx; dy; dz), so definieren wir die Determinante
62

Das Vorzeichen dieses Prädikats besitzt zweierlei geometrische Interpretationen
(Abbildung 3-34). Zum einen liefert es eine Aussage darüber, ob der
Punkt d über, unter oder auf der durch a,b u. c aufgespannten Ebene liegt,
wobei oben durch die Rechte- Hand- Regel definiert ist. Äquivalent dazu lässt
sich mit Hilfe des Vorzeichens bestimmen, ob sich eine rechtsdrehende
Schraubenbewegung um ab in Richtung cd drehen würde.
Abb. 3-34 Geometrische Interpretation für den positiven Fall
Unter ausschließlicher Verwendung dieser Prädikate ergibt sich zusammengefasst
folgende Verfahrensweise.
In einem ersten Schritt wird wie bei Möller die relative Position des ersten
Dreiecks T1 zu der durch das zweite Dreieck aufgespannten Ebene Π2 ermittelt.
Dazu werden die Vorzeichen der Prädikate [p2,q2,r2,p1] , [p2,q2,r2,q1] und
[p2,q2,r2,r1] untersucht. Drei unterschiedliche Fälle sind denkbar:
a) alle haben das gleiche Vorzeichen und keines ist Null
b) alle sind Null
c) unterschiedliche Vorzeichen
Im Fall a) liegen alle Punkte aus T1 im selben durch Π2 aufgespannten
Halbraum. Die Dreiecke überschneiden sich daher nicht und der Test wird
abgebrochen. Im Fall b) sind die Dreiecke koplanar, folglich wird ein
zweidimensionaler Schnittest durchgeführt, der dann ein Ergebnis liefert. Auf
diesen Test soll an dieser Stelle nicht gesondert eingegangen werden. Es ist
lediglich wichtig zu wissen, dass auch dieser mit der Auswertung von, auf den
zweidimensionalen Fall spezialisierten, Prädikaten der oben beschriebenen
Form auskommt.
Im Fall c) schneidet das Dreieck T1 die Ebene Π2. In einem anschließenden
Schritt wird daher nun in gleicher Art und Weise die Lage der Eckpunkte aus
T2 in Bezug auf Π1 ermittelt. Sollte auch dieser erneute Test keine
63

Entscheidung liefern, so wird in einem dritten Schritt wird eine geeignete
Permutation der Vertices beider Dreiecke gesucht, so dass jeweils p1
(respektive p2) auf der einen Seite von Π2 (respektive Π1) und alle anderen
Punkte des Dreiecks auf der gegenüberliegenden Seite liegen. Die Auswertung
zweier weiterer Prädikate:
[p1,q1,p2,q2] ≤ 0 ∧ [p1,r1,r2,p2] ≤ 0
liefert somit eine Entscheidung für den Überlappungstest. Anhand von
Abbildung 3-35 und den oben beschriebenen geometrischen Interpretationen
der verwendeten Prädikate lässt sich dies leicht nachvollziehen:
Abb. 3-35 Überlappungstest zweier Dreiecke
Eine Überlappung tritt folglich auf, wenn sich die Intervalle [i,j] und [k,l]
überschneiden, also folglich die Bedingungen k ≤ j und i ≤ l erfüllt sind. Genau
dies prüfen die beiden Prädikate.
Auf Grund der Robustheit und der Effizienz soll daher das Verfahren von
[Devillers02] für den Dreieck-Dreieck-Schnitttest verwendet werden.
Im folgenden Abschnitt soll nun gezeigt werden, wie die Kollisionskontrolle in
die vorhandene Simulationsumgebung integriert werden kann.
3.3.8 Integration in die Simulation
Die Ablaufsteuerung unterteilt den Ausführungszeitraum der CNC-Programme
in diskrete Zeitintervalle gleicher Länge. Um parallel laufende Programme
ausführen zu können, werden daher zwischen jedem Zeitschritt nur die, für das
aktuelle Zeitintervall in den CNC-Kommandos vorgesehenen Konfigurationsänderungen,
ausgeführt.
64

Die Kollisionserkennung wird daher, der zeitlichen Diskretisierung der
Simulation folgend, nach Ausführung aller Konfigurationsänderungen eines
Zeitschritts, also an dessen Ende durchgeführt (Abbildung 3-36).
…
ti-1
ti
ti+1
ti+2
ti+3
ti+4
CNC
Programm 1
∆ t
1
2
CNC
Programm 2
3
4
Command1.exceute(0,50)
Command3.exceute(50,150)
Command1.exceute(50,150)
Command3.exceute(150,250)
Command2.exceute(0,100)
Command3.exceute(250,300)
Command4.exceute(0,50)
Abb. 3-36 Integration der Kollisionskontrolle in die Simulation
Folglich wird diese lediglich zu diskreten Zeitpunkten berechnet. Hier zeigt
sich ein typisches Problem der Diskretisierung von kontinuierlichen Prozessen.
Die Problematik besteht darin, dass Kollisionen, die zwischen zwei
Zeitschritten aufgetreten sind und am Ende des Zeitschritts, also zum Zeitpunkt
der Kollisionserkennung nicht mehr existent sind, vom System somit nicht
erkannt werden können. Um diesem Fakt entgegenzuwirken wird derzeit die
Erforschung von kontinuierlichen Kollisionserkennungsverfahren vorangetrieben.
Diese wirken sich jedoch bislang noch sehr negativ auf die
Performance des Gesamtsystems aus und sind nur relativ aufwendig zu
implementieren.
Da die angesprochene Problematik in durchgeführten Tests mit entsprechend
kleiner zeitlicher Auflösung (bspw. 100ms) für die dargestellten Anwendungsbeispiele
auf Grund der relativ langsamen Bewegung der Objekte kein akutes
Problem darstellte, wurde unter Abschätzung von Kosten und Nutzen von der
Implementierung einer kontinuierlichen Kollisionserkennung zunächst abgesehen.
Da Software jedoch immer auch an ihrer Erweiterbarkeit gemessen
wird, soll ein Ansatz für eine kontinuierliche Kollisionserkennung unter
Verwendung der bisher verwendeten Strukturen (OBBs) vorgestellt werden,
um somit bei Bedarf eine Implementierung für erweiterte Versionen der
aktuellen Software zu vereinfachen und vorzubereiten.
. . .
CollisionDetection()
CollisionDetection()
CollisionDetection()
65

3.3.9 Kontinuierliche Kollisionserkennung
Vorgestellt werden soll ein Ansatz nach [Redon00-04], der sich besonders
durch Geschwindigkeit und Robustheit auszeichnet. Das Verfahren erkennt
Kollisionen zwischen mehreren sich bewegenden, starren Objekten, auch wenn
diese besonders dünn sind oder sich schnell bewegen. Seine Effektivität beruht
auf der Kombination aus Intervall-Arithmetik und OBBs.
Zusammengefasst beruht das Verfahren auf folgender Vorgehensweise: In
einem ersten Schritt wird die Bewegung der Objekte durch eine einfache
Zwischenbewegung interpoliert. Anschließend wird eine kontinuierliche
Version des Separierenden-Achsen-Theorems aufgestellt, um somit OBBs über
einen ganzen Zeitraum auf Überlappungen testen zu können. Zusätzlich enthält
das Verfahren einen kontinuierlichen Kollisionstest für sich bewegende
Primitive.
Interpolierende Zwischenbewegung
Für kleine Zeitintervalle soll zur Vereinfachung der Berechnungen die
Bewegung der Objekte interpoliert werden. Nach dem Theorem von Chasles
lässt sich für zwei beliebige Zustände eines starren Körpers (Position und
Orientierung) eine Schraubenbewegung definieren [Selig03], die diesen
unabhängig von der Originalbewegung vom Start- in den Endzustand überführt
(Abbildung 3-37).
Abb. 3-37 Schraubenbewegung als allgemeine Starrkörperbewegung
Folglich wird eine einfache Schraubenbewegung mit konstanter Winkel- und
Translationsgeschwindigkeit als Zwischenbewegung verwendet. Die entsprechende
Transformationsmatrix für eine Schraubenbewegung um/entlang
der z-Achse ist im folgenden dargestellt:
mit
−1
S ( t)
= P V ( t)
P
P ...Transformation der
Schraubachse auf die
z-Achse
66

⎛cos( ω.
t)
− sin( ω.
t)
⎜
⎜ sin( ω.
t)
cos( ω.
t)
V ( t)
=
⎜ 0 0
⎜
⎝ 0 0
0
0
1
0
0 ⎞
⎟
0 ⎟
⎟
.
s.
t
⎟
1
⎟
⎠
Für die sich bewegenden Objekte werden für das aktuell betrachtete
Zeitintervall folglich Schraubenbewegungen berechnet, so dass sich die
Parameter der Objekte (Lage und Orientierung) als einfache Funktionen der
Zeit darstellen lassen:
x
−1
( t)
= P(
t)
x0
= P V ( t)
PP0
x0
wobei x0 einem beliebigen Punkt, P(t) der Originalbewegung und P0 der
Objektpositionsmatrix zum Zeitpunkt t0 entspricht. Diese Funktion ist die
Grundlage für den kontinuierlichen Überlappungstest der OBBs, welcher im
folgenden vorgestellt werden soll.
Kontinuierlicher Überlappungstest für OBBs
Grundlage des Verfahrens ist nun, dass der diskrete Überlappungstest zweier
OBBs:
⋅ ATB
3
> ∑ ai
a⋅
ei
3
+ ∑
i=
1
i=
1
a T b a⋅
f
i
i
durch eine kontinuierliche Variante ersetzt wird. Für den kontinuierlichen Fall
ergeben sich auf der linken und rechten Seite der Gleichung folglich
kontinuierliche Funktionen der Zeit. Beide Funktionen können in ihrem
Wertebereich eingegrenzt werden, in dem Intervall- Arithmetik [Snyder92]
verwendet wird. Sind nun [l1,l2] die Grenzen der linken Seite und [r1,r2] die der
rechten Seite, so ist a eine separierende Achse über dem gesamten
Zeitintervall, wenn gilt: l1 > r2.
Da nun dieser Test lediglich herausfinden kann, ob eine Achse a die Boxen
über dem gesamten Zeitintervall separiert, soll das Intervall bei Fehlschlagen
der 15 Tests geteilt werden. Als Kriterium für eine weitere Unterteilung eines
getesteten Intervalls wird das Verhältnis von Geschwindigkeit und Größe der
Objekte verwendet. Demnach soll ein Intervall geteilt werden, wenn folgender
Ausdruck erfüllt ist:
3
⎛
⎞
vr
⋅ ei
( t0
) + ( t1
− t0
) vr
> k⎜∑
bi
vr
⋅ f ( t0
) ⎟
⎝ i=
1
⎠
3
∑ ai i
i=
1
wobei vr der Relativgeschwindigkeit der beiden Objekte:
ei, fi ... Orientierungen der Boxen
ai, bi ... Ausdehnungen der Boxen
a
TA, TB
... zu testende Achse
... Mittelpunkte der Boxen
67

vr = v(
TA
) − v(
TB
)
und v(TA) der Geschwindigkeit der Box A entspricht:
v ) P T
1
( TA
) = PA
V ′ A ( t0
−
Der Parameter k wurde experimentell ermittelt. Die besten Ergebnisse wurde
nach [Redon02] für k = 0.2 erreicht.
Kontinuierliche Kollisionserkennung zwischen Primitiven
Für die kontinuierliche Kollisionserkennung zwischen aus Flächen bestehenden
Objekten gilt es lediglich folgende Kontaktarten zu berücksichtigen:
Eckpunkt/Fläche, Fläche/Eckpunkt, und Kante/Kante. Zudem kann nach
[Redon02] jeder dieser Kollisionstests so formuliert werden, dass der erste
Kontaktzeitpunkt der Nullstelle einer zeitabhängigen Funktion entspricht:
Sei a(t)b(t) die erste und c(t)d(t) die zweite Gerade der Kanten, so tritt eine
Kollision (der Geraden) ein, sobald gilt (Abbildung 3-38):
a ( t)
c(
t)
⋅ ( a(
t)
b(
t)
× c(
t)
d(
t))
= 0 .
Diese Gleichung wird nun mittels eines intervallbasierten Nullstellenverfahrens
gelöst. Ist eine Lösung im Intervall gefunden, so wird nur dann einen Kollision
angezeigt, wenn der ermittelte Punkt auf beiden Kanten liegt.
Abb. 3-38 Kollisionserkennung zwischen zwei Kanten
Für den Eckpunkt/Fläche- bzw. Fläche/Eckpunkt- Fall wird zuerst eine
Kollision zwischen dem Eckpunkt und der durch die Fläche aufgespannten
Ebene gesucht. Sei a(t) ein Eckpunkt und b(t)c(t)d(t) ein Dreieck, dann tritt
eine Kollision ein, wenn gilt:
a ( t)
b(
t)
⋅ ( b(
t)
c(
t)
× b(
t)
d(
t))
= 0 .
Eine Lösung tr der Gleichung wird folglich nur akzeptiert, wenn a(tr) innerhalb
des Dreiecks b(tr)c(tr)d(tr) liegt.
A
A
.
68

Für die rekursive Nullstellensuche gilt es dabei folgendes zu beachten: Wenn
ein Zeitintervall [tl,tr] in zwei Teilintervalle [tl,tm] und [tm,tr] zerlegt wird, so
müssen die Lösungen zuerst in [tl,tm] gesucht werden. Erst wenn dort keine
Lösung gefunden wurde, wird das zweite Intervall rekursiv durchsucht.
69

4 Implementierung
Im folgenden soll zum einen die entwickelte Anwendung vorgestellt und
gleichzeitig detailliert auf einige Problemstellungen und Lösungen der
Implementierungsphase eingegangen werden.
Der Struktur der bisherigen Arbeit folgend ist auch dieses Kapitel zu Beginn in
die Abschnitte Konstruktion, Simulation und Kollisionskontrolle gegliedert.
Anschließend werden die Schnittstellengestaltung, die verwendete Persistenzstrategie
und die für die VR- Darstellung erforderlichen Implementierungen
erläutert.
4.1 Konstruktion
Zur Erläuterung der Konstruktion soll im folgenden beispielhaft gezeigt
werden, wie die Komponenten Rumpf und Sockel des bereits vorgestellten
Kuka-Roboters „Kr3“ mit der entwickelten Anwendung modelliert werden
können, um somit ein Abbild der realen Kinematik zu erhalten.
Die Konstruktion der Maschinen erfolgt mit Hilfe des „Import CAD-Object-
Dialogs (Abbildung 4-1).
Abb. 4-1 „Import CAD-Object“-Dialog
In diesem können die Daten in den Formaten VRML, 3DS und STL geladen
werden. Wurde eine Baugruppe oder eine komplette Maschine geladen, so wird
70

der gesamte enthaltene Szenegraph im linken oberen Bereich angezeigt. Im
unteren Bereich sind alle enthaltenen Shape3D-Instanzen und Lichtquellen
aufgelistet, die im Modell enthalten sind 1 . Die gesamte Geometrie wird in dem
linken der beiden 3D-Fenster graphisch dargestellt.
Anschließend kann der Benutzer die Baugruppen segmentieren, indem er die
zu verwendenden Shapes selektiert. Die so ausgewählte Geometrie wird im
rechten 3D-Fenster angezeigt (Abbildung 4-2).
Abb. 4-2 Segmentierung der Baugruppen
Ist die Baugruppe vollständig segmentiert, so muss diese benannt und
anschließend in der eigentlichen Szene platziert werden. Letzteres geschieht
mit Hilfe des „Place“-Dialogs (Abbildung 4-3).
Abb. 4-3 Place-Dialog
1 Da der verwendete VRML-Loader zunächst nur die Lichtquellen lädt, muss für die Anzeige
der Shapes der Button „add shapes“ betätigt werden, so dass auch alle Shapes mit in die Liste
im linken unteren Bereich aufgenommen werden.
71

Da im gezeigten Beispiel der Sockel ohne Rotation oder Translation in der
Szene platziert werden soll, werden die Standard-Einstellungen für die
Positionierung (Punkt: (0,0,0), Direction: (1,0,0) und Up: (0,1,0)) verwendet
und durch betätigen des „place“-Buttons direkt der „Place“-Dialog aufgerufen
(Abbildung 4-3). Dieser enthält auf der linken Seite einen Baum, der die
Struktur der modellierten Szene darstellt. Da diese bisher noch leer ist, enthält
der Baum nur den Knoten „Scene“, welcher dem Wurzelknoten der Gesamtszene
entspricht.
Mit Hilfe des „add“-Buttons wird das Bauteil der Szene unter Verwendung der
Standard-Positionierung hinzugefügt (Abbildung 4-4).
Abb. 4-4 Place-Dialog und eingefügtes Bauteil
Wird dieser Vorgang mit „Ok“ bestätigt, so ist der Sockel der Szene
hinzugefügt (Abbildung 4-5).
Abb. 4-5 Szene mit Sockel
Anschließend soll nun der Rumpf des Roboters auf den soeben platzierten
Sockel aufgesetzt werden. Dazu wird dieser im „Import CAD-Object“-Dialog
zunächst aus den entsprechenden Shapes zusammengestellt (Abbildung 4-6).
72

Abb. 4-6 Zusammenstellen des Rumpfes
Da sich dieser nun auf dem Sockel drehen soll, muss die Rotationsachse nach
der in Abschnitt 3.1 beschriebenen Art und Weise festgelegt werden.
Abbildung 4-7 zeigt diesen Vorgang.
Abb. 4-7 Festlegen der Gelenkparameter
Der Vektor „Direction“ entspricht wie bereits erwähnt der Achse, um die sich
das Objekt drehen soll, der „Up“-Vektor dient der eindeutigen Positionierung
(der Button „show“ dient dem Anzeigen der Vektoren). Insgesamt definieren
diese Komponenten folglich die Anschlussstelle am anzufügenden Bauteil.
Nun muss auch dieses Bauteil in der Szene platziert werden. Nach Betätigen
des „place“-Buttons wird erneut der „Place“-Dialog geöffnet (Abbildung 4-8).
73

Abb. 4-8 „Place“-Dialog
Hier wird nun zunächst das Bauteil der Szene ausgewählt, an welches der
Rumpf angefügt werden soll. Da dies der Sockel ist, wird dieser selektiert und
erscheint daraufhin in seinem Bauteilkoordinatensystem.
Anschließend wird auch hier die Positionierung in der oben beschriebenen
Form festgelegt und damit die Anschlussstelle am Bauteil, an das angefügt
werden soll, definiert (Abbildung 4-9).
Abb. 4-9 Positionierung auf dem Sockel
Zusätzlich wird als Transformation der Gelenkverbindung die Rotation
gewählt. Der Rumpf wird daraufhin mittels „add“ an der definierten Position
eingefügt (Abbildung 4-10).
74

Abb. 4-10 Aufsetzen des Rumpfes auf den Sockel
Durch bestätigen mit „Ok“ ist die Szene nun vollständig modelliert. Abbildung
4-11 zeigt das erstellte Objekt. Mit Hilfe des Reglers im rechten unteren
Bereich lässt sich nun der Rumpf auf dem Sockel drehen.
Abb. 4-11 Szene mit Sockel und Rumpf
Im folgenden soll nun gezeigt werden, wie die für die Konstruktion
erforderlichen Transformationen berechnet werden.
4.1.1 Berechnung der Transformationen
Für die Aufstellung der Gleichungen soll nun wieder vom allgemeinen Fall
ausgegangen werden, dass eine Baugruppe A an eine Baugruppe B angefügt
werden soll (Abbildung 4-12).
75

Abb. 4-12 Anfügen eines Bauteils im Szenegraphen
Für beide Baugruppen A und B werden folgende Transformationen aufgestellt:
R =
A
r A r A r A
vdir
vup
v3
0
0
0
r
0
T A
TB
1
r A
v3 und
R =
B
r B r B r B
vdir
vup
v3
Die Vektoren
entsprechenden „Direction“- und „Up“-Vektoren berechnet. Die Transformationen
T A und TB entsprechen der Translation zu dem im Bauteilkoordinatensystem
von A und B definierten Punkt.
0
0
r B
v3 wurden jeweils aus dem Kreuzprodukt der
Somit ergibt sich als Transformation für TG1 folgender Ausdruck:
−1 −1
M AB = TB
⋅ RB
⋅ ( RA
) ⋅ ( TA
) .
Die Gelenktransformation TG2 berechnet sich folglich aus:
bzw.
M
TG
TG1
TG2
Baugruppe A
BG
TG
S S
Baugruppe B
TG
−1 −1
Gelenk = TA
⋅ RA
⋅ rot x ⋅ ( RA
) ⋅ ( TA
)
BG
−1 −1
M Gelenk = TA
⋅ RA
⋅ transl x ⋅ ( RA
) ⋅ ( TA
) ,
TG
S S
Schnittstelle Baugruppe A Schnittstelle Baugruppe B
0
r
0
1
76

wobei rotx einer Rotation um die x-Achse und translx einer Translation entlang
dieser um einen bestimmten Wert entspricht. Dieser Wert entspricht dem
Zustand der Gelenkverbindung, also beispielsweise dem aktuellen Drehwinkel
eines Roboterarms.
Um die Berechnung dieser Transformationen zu beschleunigen werden die
−1 −1
Transformationen ( R A ) ⋅ ( TA
) und TA ⋅ RA
zusammengefasst und in den
Gelenkverbindungen gespeichert.
4.1.2 Wiederverwendung von Komponenten
Da der Prozess der Konstruktion recht aufwendig ist, wurde zusätzlich die
Möglichkeit geschaffen, einmal konstruierte Maschinenelemente wiederverwenden
zu können. Dies bedeutet, dass beispielsweise ein bereits
modellierter Roboter mehrfach in eine neue (oder auch die gleiche Szene)
importiert werden kann, ohne dass dieser neu konstruiert werden muss
(Abbildung 4-13).
Komponenten Kombinationen
Abb. 4-13 Wiederverwendung von modellierten Komponenten
Die kinematischen Eigenschaften der Maschine werden beim Importieren mit
übernommen. Somit lassen sich verschiedene Konfigurationen komplexer
77

Szenen relativ einfach konstruieren, da lediglich die bereits zuvor modellierten
Objekte neu zusammengefügt werden müssen. Dies ergibt im Resultat eine Art
Baukastensystem mit dem die Wiederverwendung von einmal erstellten
Komponenten ermöglicht wird.
Abbildung 4-14 zeigt den zugehörigen Dialog. Nachdem eine Szene geladen
wurde, wird auf der linken Seite deren Struktur angezeigt. Anschließend
können einzelne Teile der Hierarchie für den Import in die aktuelle Szene
ausgewählt werden.
Abb. 4-14 "Import from Project"-Dialog
Die Positionierung der Objekte erfolgt analog zu dem in der Konstruktion
verwendeten Verfahren.
78

4.2 Simulation
Im folgenden sollen detailliert die Konfiguration der CNC- Simulation und die
Entwicklung von anlagenspezifischen CNC-Interpretern erläutert werden.
Zuvor wird vorbereitend die erweiterte Funktionsweise der Ablaufsteuerung
und deren Konfiguration dargestellt.
4.2.1 Ablaufsteuerung
Da die Ablaufsteuerung einerseits ein möglichst realistisches Abbild des CNC-
Steuerungsprozesses darstellen, andererseits jedoch auch parametrisierbar sein
soll, muss deren Zeitverhalten noch näher spezifiziert werden.
Wünschenswert wäre es, wenn sich das Zeitverhalten der Simulation so
beeinflussen ließe, dass der eigentliche Prozess durch Konfiguration
beschleunigt oder verlangsamt werden kann. Um dies zu realisieren wird am
Ende eines jeden Zeitschritts eine Verzögerung (delay_time) eingefügt
(Abbildung 4-15).
…
ti-1
ti
ti+1
ti+2
ti+3
ti+4
CNC
Programm 1
∆ t
1
2
CNC
Programm 2
3
4
. . .
Command1.exceute(0,50)
Command3.exceute(50,150)
CollisionDetection()
sleep(delay_time)
Command1.exceute(50,150)
Command3.exceute(150,250)
CollisionDetection()
sleep(delay_time)
Command2.exceute(0,100)
Command3.exceute(250,300)
Command4.exceute(0,50)
CollisionDetection()
sleep(delay_time)
. . .
Abb. 4-15 Beeinflussung des Zeitverhaltens
79

Da die Ausführung der CNC- Kommandos in der Simulation und die
Kollisionserkennung, abgesehen von der benötigten Rechenzeit, keine Zeit in
Anspruch nehmen, wird die Simulation für den Fall delay_time = ∆t nahezu in
Echtzeit ausgeführt. Wird delay_time größer bzw. kleiner gewählt, so
verlangsamt bzw. beschleunigt sich die Ausführung der CNC- Simulation.
Abbildung 4-16 zeigt einen Ausschnitt der Implementierung der Ablaufsteuerung.
Die CNC-Programme und die Kollisionskontrolle werden dabei in
einem eigenen Prozess (Thread) ausgeführt.
Thread thread = new Thread() {
}
public void run() {
}
...
// main loop
while (!allProgramsDone()) {
}
...
...
// CNC- Programme schrittweise ausführen
for (int i = 0; i < cncPrograms.length; i++)
cncPrograms[i].step(emulation_resoultion);
// Kollisionserkennung
if (collisionDetectionEnabled)
checkCollisions();
// Verzögerungszeit
sleep(delay_time);
...
Abb. 4-16 Thread der Ablaufsteuerung
Es sei an dieser Stelle darauf hingewiesen, dass selbstverständlich auch der Fall
eintreten kann, dass ein CNC-Kommando eine Laufzeit kleiner ∆t hat. Dies
wird von der Ablaufsteuerung berücksichtigt.
80

4.2.2 Konfiguration
In der folgenden Abbildung ist der Dialog für die Konfiguration der CNC-
Steuerung dargestellt.
Abb. 4-17 Dialog zur Konfiguration der CNC-Simulation
Hier können die zeitliche Auflösung der Simulation (∆t) und die
Verzögerungszeit am Ende eines Zeitschritts (delay_time) eingestellt werden.
Darüber hinaus lässt sich festlegen, welche CNC- Interpreter- Klasse
verwendet werden soll. Diese kann entweder aus einer Liste aller im Projekt
bekannten Klassen ausgewählt (Abbildung 4-18) oder direkt durch Eingabe des
vollständigen Namens spezifiziert werden.
Abb. 4-18 Auswählen der CNC-Interpreter -Klasse
81

Das Laden der ausgewählten Klasse und deren Instanziierung zeigt Abbildung
4-19.
public void createDynCNCInterpreterClass(String name)
throws ClassNotFoundException, NoSuchMethodException,
IllegalAccessException, InstantiationException,
InvocationTargetException
{
}
// Klasse laden
Class dynCNCInterpreter = Class.forName(name);
// Parametertyp des zu ermittelnden Konstruktors
Class[] paramTypes = new Class[] { Joints.class };
Object[] paramValues;
// Konstruktor ermitteln
Constructor cncInterpreterConstructor = dynCNCInterpreter
.getConstructor(paramTypes);
// Konstruktor-Parameter erstellen
paramValues = new Object[] {
new Joints(elementConnections,cncEmulator)
};
// Instanz erzeugen
cncInterpreter = (CNCInterpreter) cncInterpreterConstructor
.newInstance(paramValues);
// Interpreter der Ablaufsteuerung zuweisen
cncEmulator.setInterpreter(cncInterpreter);
Abb. 4-19 dynamisches Laden des CNC-Interpreters
Zusätzlich können im Konfigurationsdialog der CNC-Simulation die Anzahl
der parallel auszuführenden CNC-Programme festgelegt und diese benannt
werden. Folglich können beliebig viele parallel laufende Prozesse simuliert
werden.
Zur Auswertung der CNC-Simulationen können die wichtigsten angefallenen
Daten in einer Log-Datei gespeichert werden. Diese enthält Informationen über
den zeitlichen Verlauf der Simulation und eventuell aufgetretene Kollisionen
(auf Wunsch inklusive der kollidierenden Primitive). Letztere werden dabei der
aktuellen CNC-Zeile und dem aktuellen Zeitschritt zugeordnet. Somit lassen
sich in einer nachträglichen Auswertung Rückschlüsse auf die Ursache der
Kollision ziehen.
Es soll an dieser Stelle nicht unerwähnt bleiben, dass bei Eintritt einer
Kollision selbstverständlich auch eine Ermittlung des ersten Kontaktzeitpunkts
zwischen zwei Zeitschritten möglich wäre. Da hier jedoch lediglich die
betroffene CNC-Zeile von Interesse ist, wurde von einer Implementierung
abgesehen. Darüber hinaus wäre es sicherlich lohnender, die in Abschnitt 3.3.9
angesprochene kontinuierliche Kollisionserkennung anstelle dessen zu implementieren,
da diese die Ermittlung des ersten Kontaktzeitpunkts bereits implizit
mitbestimmt.
82

4.2.3 Entwicklung eigener CNC-Interpreter
Im folgenden soll das Entwickeln eigener spezifischer CNC- Interpreter näher
erläutert werden. Dazu sei im folgenden das nun etwas modifizierte Klassendiagramm
dargestellt.
Joints
CNCSource
+getLine(line:int):void
+getLineCount():int
CNCSourceLine
-model:Joints
>
CNCInterpreter
CNCInterpreterImpl
-model:Joints
+run():void
+pause():void
+stop():void
+parse(source:CNCSource[]):CNCProgram
CNCEmulator
erstellt
CNCProgram
+step(stepTime:int):void
-model:Joints
Abb. 4-20 Klassendiagramm CNC-Interpreter
>
CNCCommand
+create(soureLine:CNCSourceLine):void
+getTotalTime():int
+execute(t0:int,t1:int):void
CNCCommandImpl
Im Vergleich zu Abschnitt 3.2 ergeben sich folgende Änderungen: Das Modell
(Model) wird durch die Klasse Joints repräsentiert, welche der Menge der
Gelenkverbindungen entspricht. Die CNC-Quellen sind zeilenweise strukturiert
und werden während des Parsens als CNCSourceLine-Objekt an die abstrakte
Methode create der CNCCommand-Klasse übergeben. Deren abstrakte
Methode execute wurde entsprechend den Ausführungen in Abschnitt 3.2 um
zwei Parameter (t0 und t1 erweitert).
Für die Entwicklung eines eigenen CNC-Interpreters muss nun die abstrakte
Klasse CNCInterpreter überschrieben werden. Abbildung 4-21 zeigt die
Implementierung des DefaultCNCInterpreter, welcher standardmäßig als
Interpreter ausgewählt ist.
Dieser überschreibt lediglich die abstrakte Methode parse und erstellt aus den
CNC-Quelltexten CNCProgram- Objekte, welche wiederum eine Liste von
*
*
83

CNCCommand- Instanzen enthalten, die durch die Klasse DefaultCNC-
Command implementiert sind.
public class DefaultCNCInterpreter extends CNCInterpreter {
...
public CNCProgram[] parse(CNCSource[] sourceCode)
throws CNCException {
}
...
// Anzahl der CNCProgramme ist gleich der Anzahl der
// übergebenen CNC-Quelltexte
int cncCount = sourceCode.length;
// Anlegen des Arrays für die einzelnen Programme
CNCProgram[] programs = new CNCProgram[cncCount];
// erstelle aus jedem CNC-Quelltext ein CNCProgramm
for (int c = 0; c < cncCount; c++) {
// erstelle Programm
programs[c] = new CNCProgram();
// verarbeite jede Zeile eines Programms
for (int l = 0; l < sourceCode[c].getLineCount(); l++) {
}
// hole aktuelle Zeile
CNCSourceLine line = sourceCode[c].getLine(l);
// wenn Zeile (min.) ein Zeichen enthält...
if (line.getText().length() > 0) {
}
}
return programs;
// ...,dann erstelle daraus ein CNCCommand
CNCCommand command = new DefaultCNCCommand(
componentJunctions);
command.create(line);
command.setSourceLocation(new
CNCSourceLocation(c, line
.getStartOffset(),
line.getEndOffset(),line.getText()));
// füge das CNC-Kommando dem Programm hinzu
programs[c].addCNCCommand(command);
Abb. 4-21 Quellcode des DefaultCNCInterpreter's
Das eigentliche Auswerten der CNC-Zeilen übernimmt dann die
CNCCommand- Implementierung. Der CNC-Interpreter ist lediglich für die
Grobstrukturierung der CNC-Programme und Kommandos zuständig.
Abbildung 4-22 zeigt schematisch die Implementierung der DefaultCNC-
Command-Klasse. Diese überschreibt zunächst die Methode create. Hier
werden die CNC-Zeilen geparst und alle gewonnen Informationen (betroffene
Baugruppe(n), zu verändernde Parameter der Gelenkverbindung(en) u.
Laufzeit des Kommandos) werden in der Klasse gespeichert. Der CNC-
84

Interpreter ruft diese Methode vor Beginn der Simulation auf, so dass bei
Ausführung der Simulation bereits alle CNC- Quelltexte geparst sind.
Die DefaultCNCCommand- Implementierung geht davon aus, dass die CNC-
Programme in der Struktur:
„Gelenkbezeichnung Neuer_Wert benötigte_Zeit_in_ms“
,also bspw. in der Form „Arm1 +45 3000“ vorliegen.
public class DefaultCNCCommand extends CNCCommand {
}
// Gelenkverbindung
Joint joint;
// neuer Absolutwert
double value;
// Gesamtlaufzeit
int totalTime;
// parst die CNC-Quelle
public void create(CNCSourceLine line) throws CNCException {
}
// Zeilentext holen
String lineText = line.getText();
// Gelenkname, Neuer Wert und Zeit identifizieren
String gelenkName = ...
value = ...
totalTime = ...
// betroffenes Gelenk holen
joint= joints.getJointByName(gelenkName);
// führt das Kommando aus
public void execute(int t0, int t1) {
}
// Interpolation bestimmen
double anteil = (t1 - t0) / totalTime;
// delta = Sollwert – IstWert_zu_Kommandobeginn
double delta = value - getState(joint);
// neuen Wert setzen
joint.setValue(delta * anteil + joint.getValue());
// liefert die Gesamtlaufzeit des Kommandos
public int getTotalTime() {
return totalTime;
}
...
Abb. 4-22 DefaultCNCCommand- Implementierung
Die Methode execute berechnet folglich den Interpolationswert (anteil) und
anschließend die Differenz zwischen Sollwert und Istwert. Der Istwert
entspricht hier dem Wert unmittelbar vor der Ausführung des Kommandos und
85

kann über die Methode getState für jedes Gelenk abgefragt werden. Der Aufruf
joint.getValue() liefert hingegen den aktuellen Zustand der Gelenkverbindung.
Diese CNCCommand- Implementierung ist eine sehr einfache und soll hier
lediglich als Beispiel dienen. Denkbar wäre beispielsweise auch, dass ein
CNC-Interpreter mehrere verschiedene CNCCommand- Implementierungen
verwendet oder dass zwischen einer Absolut- oder Relativbewegung
unterschieden wird etc. Weiterhin kann ein CNCCommand auch mehrere
Gelenkverbindungen (Joint’s) parallel bewegen müssen, was kein Problem
darstellt, da jedes CNCCommand Zugriff auf die gesamte Struktur der
Maschine hat.
Darüber hinaus soll an dieser Stelle nicht unerwähnt bleiben, dass die
Entwicklung eines eigenen CNC-Interpreters auch eine Möglichkeit zur
Datenerfassung während der Simulation darstellt. Da der Interpreter Zugriff auf
alle Daten der Maschine hat, können diese ausgewertet und beispielsweise
exportiert werden. Somit ergeben sich sicherlich zahlreiche Anwendungsmöglichkeiten,
diese Schnittstelle zu nutzen.
86

4.3 Kollisionskontrolle
Die Implementierung der Kollisionskontrolle soll im aktuellen Abschnitt näher
erläutert werden. In Kapitel 2 wurde analysiert, dass es sich hierbei meist um
den Flaschenhals in der Simulation handelt und daher besonders auf eine
effiziente Implementierung Wert gelegt werden sollte. In Kapitel 3 wurde
bereits ein Großteil der erforderlichen Funktionalitäten behandelt. Die
folgenden Abschnitte sollen nun noch einmal einige spezielle Problemstellungen
behandeln.
4.3.1 Berechnung der OBB- Parameter
In Abschnitt 3.3.5 wurde analysiert, dass für die Berechnung der OBB-
Parameter folgende Schritte erforderlich sind:
Ermitteln der konvexen Hülle
Triangulieren der konvexen Hülle
Aufstellen der Kovarianzmatrix
Berechnen der Eigenvektoren
Bestimmung der OBB-Parameter
Abb. 4-23 Bestimmung der OBB-Parameter
Da bisher noch nicht spezifiziert wurde, wie die konvexe Hülle aus den
Objekten ermittelt werden kann, soll dies näher untersucht werden:
Für die Berechnung der konvexen Hülle existieren zahlreiche Verfahren. Eine
Recherche ergab, dass diesbezüglich auch zahlreiche frei verfügbare
Implementierungen existieren. Da die Wiederverwendung von Komponenten
in der Softwaretechnik als erstrebenswertes Ziel anzusehen ist, wurden
insgesamt acht dieser Bibliotheken auf ihre Eignung getestet. Hierbei stellte
sich heraus, dass Robustheit in numerischen Verfahren eine entscheidende
Rolle spielt. Grund hierfür ist, dass die vorliegenden Bauteilgeometrien
offensichtlich teilweise aus Dreiecken bestehen, deren Punkte kollinear sind
87

oder deren gegenseitiger Abstand teilweise nur sehr gering ist und die meisten
Implementierungen auf Grund dessen versagten.
Als herausragend, was Geschwindigkeit und Robustheit angeht, stellte sich die
Implementierung von [Lloyd] heraus, welche auf dem Verfahren nach [Barber,
Dopkin u. Huhdanpaa] beruht. Hier wurden von den Autoren für Testzwecke
zufällige Punktmengen im R³ generiert und die gleichen Punkte anschließend
mit einer geringen Streuung versehen noch mehrmals hinzugefügt. Somit
entstanden Punktmengen, in denen mehrere Punkte sehr dicht beieinander
liegen. Anschließend wurde der Algorithmus auf diesen Punktmengen getestet
und unter dieser Prämisse entwickelt.
Ein weiterer Vorteil dieser Implementierung ist, dass sich die konvexe Hülle
auch trianguliert ausgeben lässt. Auf Grund dieser entscheidenden Vorteile
wurde die Implementierung von [Lloyd], die mit „QuickHull3D“ bezeichnet
wird, folglich für die Generierung und Triangulierung der konvexen Hülle
verwendet.
4.3.2 OBB Aktualisierung
Da die Erzeugung der OBBs relativ viel Rechenzeit beansprucht, werden diese
im Bauteilkoordinatensystem erstellt und nach deren Erstellung in den
zugehörigen virtuellen Baugruppen gespeichert. Sollen nun zwei OBB-
Hierarchien auf Überschneidung getestet werden, so müssen diese in ein
gemeinsames Koordinatensystem transformiert werden.
Hierfür gibt es zwei Möglichkeiten: Entweder werden beide Objekte in das
sogenannte Weltkoordinatensystem oder eines in das Koordinatensystem des
jeweils anderen transformiert. Letzteres hat den Vorteil, dass nur ein OBB
transformiert werden muss. Gleichzeitig müsste ein und dasselbe OBB bei Test
mit unterschiedlichen anderen OBBs dafür aber jedesmal erneut transformiert
werden. Folglich bietet es sich an, die OBBs in das Weltkoordinatensystem zu
transformieren, da sich einerseits diese Transformation in Java3D schnell
bestimmen lässt:
Node.getLocalToVWorld(Transform3D transform)
und sich andererseits die Transformationen somit wiederverwenden lassen:
Da während einer vollständigen Kollisionskontrolle ein OBB unter Umständen
mehrfach mit anderen auf Überlappungen getestet wird, sollte diese
Transformation nicht bei jedem Test neu durchgeführt werden müssen. Die
Idee ist daher, die transformierten Parameter mit im Original-OBB zu
speichern. Es stellt sich nun jedoch die Frage, wann und wie diese aktualisiert
werden sollten?
Unter Verwendung der in Abschnitt 3.3.3 dargestellten Kohärenz, wäre ein
erster Ansatz, in jedem Zeitschritt nur die OBBs von bewegten Objekten zu
aktualisieren. Das Problem hierbei ist, dass alle OBBs, die in den Hierarchien
88

der bewegten Objekte enthalten sind, unabhängig davon, ob sie an einem
Kollisionstest beteiligt sind, in jedem Zeitschritt transformiert werden müssten.
Dies sollte sich sehr nachteilig auf die Performance auswirken.
Eine andere Idee ist, die transformierten Parameter inklusive einem Flag,
welches den aktuellen Zeitschritt repräsentiert, im OBB zu speichern. Folglich
müssten alle an Kollisionstests beteiligten OBBs in jedem Zeitschritt nur ein
einziges mal aktualisiert werden. Dieses Flag sollte nun so gestaltet sein, dass
zum einen ein Vergleichstest sehr schnell durchgeführt werden kann und
andererseits der Wertebereich groß genug für die zahlreichen
Simulationsschritte ist. Hier bietet sich die Verwendung eines Parameters vom
Typ long an. Dieser Datentyp umfasst 64 bit, so dass der Wertebereich in
jedem Fall hinreichend ist.
4.3.3 OBB-Überlappungstest und Traversierung
Sollen zwei OBB-Hierachien auf Überlappung getestet werden, so werden
diese mittels Tiefensuche von oben nach unten durchlaufen. Die dabei
durchgeführten Überlappungstests ergeben einen Rekursionsbaum (Abbildung
4-24).
Abb. 4-24 Rekursionsbaum für einen BV- Hierarchietest [Mezger01]
Überlappen sich die Bounding Volumes zweier Knoten, werden die Kinder
desjenigen Knotens mit dem größten Bounding Volume gegen den Knoten mit
dem kleineren Bounding Volume getestet. Falls keine Überlappung detektiert
wird, kann die Traversierung abgebrochen werden, da dann auch die Kinder
nicht überlappen können.
Die Idee, immer den Teilbaum mit dem größten Bounding Volume als erstes
zu traversieren, wird auch von [Gottschalk00] verfolgt, da dadurch die Größe
und folglich die Überlappungswahrscheinlichkeit der getesteten Knoten am
schnellsten abnimmt. Das Volumen einer OBB wird bereits bei deren
Erzeugung berechnet und in dieser gespeichert. Abbildung 4.25 zeigt den
Algorithmus für den gegenseitigen Test zweier Bounding Volume Hierarchien
BVA und BVB.
89

oolean findCollisions(BVA, BVB) {
}
A B
( T − T ) ⋅ n / n
Abb. 4-25 Algorithmus für Test zweier BVHs
Die Methode BVCollide testet zwei OBBs auf Überschneidungen nach der in
Abschnitt 3.3.6 aufgeführten Gleichung. Im folgenden soll nun gezeigt werden,
wie sich die Berechnung dieser Gleichung nach [Gottschalk00] optimieren
lässt und wie Spezialfälle behandelt werden können.
Optimierung: Struktur des zu testenden Vektors
Angenommen der Mittelpunkt einer Box A befindet sich an der Stelle T A . Die
A A A
Einheitsvektoren R0 , R1
, R2
entsprechen den drei Achsen der Box und a0, a1,
a2 den Halblängen entlang der entsprechenden Achsen. Selbiges sei äquivalent
für eine Box B definiert.
Die auf Separierung zu testende Achse sei eine Gerade durch den
Koordinatenursprung, deren Richtung mit einem Vektor n bezeichnet wird, der
nicht zwingend ein Einheitsvektor sein muss.
Somit ergibt sich als Separierender- Achsen- Test folgender Ausdruck:
A
A
A
( a1
R1
⋅ n + a2
R2
⋅ n + a3
R3
⋅ n ) / n
B
B
B
( b1
R1
⋅ n + b2
R2
⋅ n + b3
R3
⋅ n ) / n
(Gleichung 4-1)
Da die zu testende Achse entweder der Normale auf einer Fläche der Boxen
oder der Kombination ihrer Kanten entspricht, ergeben sich für n drei Fälle:
n = R , n = R und n = R × R , mit i , j ∈{
1,
2,
3}
.
A
i
if (!BVCollide(BVA,BVB) ) return false;
if (isLeaf(BVA) and isLeaf(BVB))
return PrimitiveCollide(BVA,BVB);
if ((size(BVA)>size(BVB)) or isLeaf(BVB)){
for all children BVC of BVA do
findCollisions(BVC, BVB)
}
else {
for all children BVC of BVB do
findCollisions(BVA, BVC)
}
B
i
>
A
i
B
j
+
90

[Gottschalk00] zeigt nun, dass sich durch Unterscheidung dieser drei Fälle, die
Berechnung in einem ersten Schritt vereinfachen lässt. Es ergeben sich
folgende vereinfachte Gleichungen für den Schnitttest:
Fall 1:
Bsp.: i=2,
A B A
B A
B A
B A
( − T ) ⋅ R > a + b R ⋅ R + b R ⋅ R + b R ⋅ R )
T 2
Fall 2:
Bsp.: i=2
Fall 3:
A
n R2
= :
B
n = R2
2
( 1 1 2 2 2 2 3 3 2
A B B
A B
A B
A B
( T − T ) ⋅ R2
> ( a1
R1
⋅ R2
+ a 2 R2
⋅ R2
+ a3
R3
⋅ R2
) + b2
Bsp.:
A B
n R1
R2
× =
A B ( R × R ) >
A B
( T − T ) ⋅ 1 2
B A
B A
A B
A
( a 2 R2
⋅ R3
+ a3
R2
⋅ R2
) + ( b1
R1
⋅ R3
+ b´
3 R1
⋅ R1
Weiterhin kann die Berechnung optimiert werden, indem das gemeinsame
Koordinatensystem so gewählt wird, dass sich die Box A im Koordinatenursprung
befindet und deren Orientierungen den Koordinatenachsen
entsprechen.
Optimierung: Wahl des Koordinatensystems
Dazu muss die Box B in das Koordinatensystem der Box A transformiert
werden. Interpretiert man R A als Rotationsmatrix, so ergibt sich deren Inverse
A −1
A T
durch ( R ) = ( R ) . In Box B ersetzt man nun R B A T B B
durch ( R ) R und T
A T B
durch ( R ) ( T
A
− T ) . Somit befindet sich Box B in dem durch Box A
definierten Koordinatensystem. Die Berechnungen für die Beispiele
vereinfachen sich wie folgt:
Fall 1:
T > a +
+
B
2
2
B
B
B
( b1
R12
+ b2
R22
b3
R32
)
B
)
.
91

Fall 2:
Fall 3:
T
B
⋅ R
B
2
> ( a R + a R + a R ) + b
1
B
21
B B B B
B
B
B
B
R 22T3
− R23T2
> ( a2
R23
+ a3
R22
) + ( b1
R31
+ b3
R11
)
[Gottschalk00] zeigt, dass sich das in kauf nehmen des Mehraufwands durch
Transformation der Box B in das Koordinatensystem der Box A, insgesamt
betrachtet, positiv auf die Anzahl der durchzuführenden Operationen auswirkt.
Im folgenden sollen einige Spezialfälle, die bei der Berechnung des
Schnitttests auftreten können, betrachtet werden.
OBB der Dicke Null
Ein OBB hat in bestimmten Fällen die Dicke Null. Dies tritt auf, wenn
lediglich ein einziges Dreieck oder generell eine Menge von koplanaren
Polygonen umhüllt wird. [Gottschalk00] zeigt, dass auch für diesen Fall die
Berechnung des Schnitttests vereinfacht werden kann. Da hier jedoch lediglich
eine Addition, eine Multiplikation und eine Betragbildung eingespart werden,
wurde dies (auch in der Implementierung nach [Gottschalk00]) nicht
berücksichtigt.
n = Nullvektor
Sind zwei Kanten der beiden zu testenden Boxen parallel, so ergibt sich für
einen der zu testenden Vektoren n durch Bildung des Kreuzprodukts dieser
Kanten der Nullvektor. Diese Problematik soll nachfolgend unersucht werden.
Gleichung 4-1 wurde in [Gottschalk00] vereinfacht, indem beide Seiten mit |n|
multipliziert worden sind. Dies ist selbstverständlich nur zulässig für den Fall,
dass |n| > 0 ist. Die Auswertung der Gleichung
( T
A
B
− T ) ⋅ n
>
2
B
22
A
A
A
( a1
R1
⋅ n + a2
R2
⋅ n + a3
R3
B
B
B
( b1
R1
⋅ n + b2
R2
⋅ n + b3
R3
für den Fall, dass |n| = 0 ist, liefert somit
0 > 0 .
3
B
23
⋅ n )
⋅ n )
2
+
92

Die optimierten Gleichungen der oben beschriebenen drei Fälle liefen das
gleiche Ergebnis. Die Ungleichung ist somit nicht erfüllt, das heißt der
Nullvektor separiert die beiden Boxen nicht. Dies ist an sich wünschenswert
und stellt im Grunde damit kein Problem dar.
Nun ist es aber so, dass durch Rechenungenauigkeiten das Ergebnis verfälscht
werden kann. [Gottschalk] zeigt, dass beispielsweise für den folgenden Fall:
T
B
⎛− 0.
147256⎞
⎟
= 1.
76777
⎜
⎜
⎜
⎝
B
R
1.
80947
⎟
⎟
⎠
⎛ − 0.
0641566
⎜
= ⎜1.
54303⋅10
⎜
⎝
− 0.
99794
−17
unter Verwendung der Berechnung
ein Vergleich
⎛3.
53553⎞
⎜ ⎟
a = ⎜1.
76777⎟
⎜ ⎟
⎝ 0 ⎠
− 5.
54743⋅10
1
6.
41346 ⋅10
−16
−20
⎛ 2.
33155 ⎞
⎜ ⎟
b = ⎜0.
565685⎟
⎜ ⎟
⎝ 0.
56452 ⎠
− 0.
99794
− 2.
22883⋅10
0.
0641566
B B B B
B
B
B
B
T1 R32
− T3
R12
> a1
R32
+ a3
R12
+ b1
R23
+ b3
R21
1.
00378137201⋅10
−15
> 5.
28600321408⋅10
entsteht, der somit als wahr ausgewertet werden würde (IEEE 64-bit double
precision floating point). Das hieße, dass der Nullvektor die beiden Boxen
separiert, obwohl sich diese offensichtlich überlappen.
Die rechte Seite der Ungleichung sollte in diesem Falle also größer sein, wenn
sich die Boxen überlappen. [Gottschalk] zeigt, dass durch aufaddieren einer
kleinen Zahl auf die Werte der Rotationsmatrix R B der rechten Seite der
Ungleichung, der Effekt erreicht wird, dass bei nahezu parallelen Kanten der
Test extrem konservativ wird und somit das Nullvektorproblem behoben
werden kann. Grund hierfür ist, dass eine Aufaddierung einer sehr kleinen Zahl
(Gottschalk wählt 0.000001) speziell für Werte nahe Null eine enorme
Erhöhung darstellt und somit bei Ungleichungen, deren linke und rechte Seite
Werte nahe Null besitzen, die rechte Seite entsprechend vergrößert wird. Auf
alle anderen Ungleichungen ist der Einfluss dagegen eher gering.
Da es sich bei den Elementen der Rotationsmatrix um Werte zwischen -1 und 1
handelt, ist die Aufaddierung der Konstanten somit unabhängig von den
Ausmaßen der Objekte, also folglich skalierungsinvariant.
−16
−16
⎞
⎟
⎟
⎟
⎠
93

Darüber hinaus gilt es beim Überlappungstest zu beachten, dass möglichst
immer zuerst die Hauptachsen zu testen sind, da sich diese wie gezeigt
einfacher bestimmen lassen. Abbildung 4-26 zeigt die Implementierung des
Überlappungstests.
public class OBBOverlap {
}
final double eps = 1e-6;
double[][] Bf = new double[3][3];
public boolean obb_overlap(double[][] B, double[] T, double[] a,
double[] b) {
Bf[0][0]= Math.abs(B[0][0])+eps;
Bf[0][1]= Math.abs(B[0][1])+eps;
Bf[0][2]= Math.abs(B[0][2])+eps;
Bf[1][0]= Math.abs(B[1][0])+eps;
Bf[1][1]= Math.abs(B[1][1])+eps;
Bf[1][2]= Math.abs(B[1][2])+eps;
Bf[2][0]= Math.abs(B[2][0])+eps;
Bf[2][1]= Math.abs(B[2][1])+eps;
Bf[2][2]= Math.abs(B[2][2])+eps;
}
// Fall 1:
if (TestCase1(0,T,a,b)) return false;
if (TestCase1(1,T,a,b)) return false;
if (TestCase1(2,T,a,b)) return false;
// Fall 2:
if (TestCase2(0,T,a,b,B)) return false;
if (TestCase2(1,T,a,b,B)) return false;
if (TestCase2(2,T,a,b,B)) return false;
// Fall 3:
if (TestCase3(0,0,T,a,b,B)) return false;
if (TestCase3(1,0,T,a,b,B)) return false;
if (TestCase3(2,0,T,a,b,B)) return false;
if (TestCase3(0,1,T,a,b,B)) return false;
if (TestCase3(1,1,T,a,b,B)) return false;
if (TestCase3(2,1,T,a,b,B)) return false;
if (TestCase3(0,2,T,a,b,B)) return false;
if (TestCase3(1,2,T,a,b,B)) return false;
if (TestCase3(2,2,T,a,b,B)) return false;
// sonst Überlappung!!
return true;
private boolean TestCase1(int x, double[] T, double[] a, double[] b)
{
return Math.abs(T[x]) > (a[x] + b[0] * Bf[0][x] + b[1] *
Bf[1][x] + b[2]* Bf[2][x]);
}
private boolean TestCase2(int x, double[] T, double[] a, double[] b,
double[][] B) {
return Math.abs(T[0] * B[0][x] + T[1] * B[1][x] + T[2] *
B[2][x]) > (b[x]+ a[0] * Bf[0][x] + a[1] * Bf[1][x] +
a[2] * Bf[2][x]);
}
private boolean TestCase3(int i, int j, double[] T, double[] a,
double[] b,double[][] B) {
return Math.abs(T[(i + 2) % 3] * B[(i + 1) % 3][j]
- T[(i + 1) % 3] * B[(i + 2) % 3][j]) > (a[(i + 1) %
3] * Bf[(i + 2) % 3][j] + a[(i + 2) % 3] * Bf[(i + 1)
% 3][j] + b[(j + 1) % 3] * Bf[i][(j + 2) % 3] + b[(j
+ 2) % 3] * Bf[i][(j + 1) % 3]);
}
Abb. 4-26 Implementierung des OBB-Überlappungstests
94

4.3.4 Primitivtest
In Abschnitt 3.3.7 wurde der Algorithmus nach [Devillers02] vorgestellt.
Dieser wurde von den Autoren in C++ implementiert. Die Quellen sind frei
verfügbar und wurden daher in die Java-Programmiersprache übersetzt.
Die Autoren weisen jedoch darauf hin, dass diese Implementierung die
Ausnahme, dass alle Punkte eines Dreiecks auf einer Linie oder gar einem
einzigen Punkt liegen, nicht korrekt behandelt. Da der implementierte Test für
solche Ausnahmefälle ein positives Ergebnis liefert, d.h. eine Überlappung der
Primitive angezeigt wird, muss diese Ausnahme gesondert behandelt werden.
Dazu soll die Fläche der Dreiecke bestimmt werden. Ist diese Null, so liegen
die Punkte auf einer Geraden oder sind identisch. Da diese Dreiecke der Fläche
Null keine räumliche Präsenz haben, sollen sie von der Kollisionserkennung
ausgeschlossen werden.
4.3.5 Konfiguration
In Abschnitt 3.3 wurde analysiert, dass für eine optimale Kollisionskontrolle so
weit als möglich die Nutzung von a-priori-Wissen anzustreben ist. Dieses kann
in der einfachsten Form genutzt werden, indem der Anwender in einem
vorbereitenden Schritt alle Objektpaare oder einzelne Objekte von der
Kollisionserkennung ausschließt, von denen er entweder weiß, dass diese nicht
kollidieren können oder deren Kollisionen nicht von Interesse sind.
Abbildung 4-27 zeigt den Konfigurationsdialog der Kollisionserkennung. Hier
können Objektpaare ausgeschlossen werden, die nicht auf Kollisionen getestet
werden sollen. Standardmäßig sind nach Abschnitt 3.3.3 alle Objektpaare
ausgeschlossen, die in einer direkten Vater-Kind-Beziehung stehen.
Abb. 4-27 Konfiguration der Kollisionserkennung
Zusätzlich können hier die zur Markierung von an Kollisionen beteiligten
Baugruppen verwendeten Farben festgelegt werden.
95

4.3.6 Anzeige der Kollisionen
Tritt zwischen zwei Baugruppen eine Kollision auf, so werden diese farblich
markiert. Anschließend können die Details der Kollision angezeigt werden.
Hierfür wurden im unteren Bereich der Anwendung ein Textfeld und ein 3D-
Fenster angelegt (Abbildung 4-28).
Abb. 4-28 Darstellung der kollidierenden Primitive
Im Textfeld werden die Namen der kollidierenden Baugruppen angezeigt. Auf
Kommando (show) können zusätzlich die Gittermodelle der kollidierenden
Baugruppen inklusive der farblich markierten kollidierenden Primitive im
unteren 3D-Fenster dargestellt werden.
96

4.4 Schnittstellen
In Kapitel 2 wurde analysiert, dass bei der Entwicklung der Software besonders
auch integrative Konzepte berücksichtigt werden sollten, um somit einerseits
die Integration der erstellten Anwendung in andere Softwareprodukte zu
ermöglichen und gleichzeitig die Funktionalität spezieller Komponenten der
Anwendung (CNC-Simulation, Kollisionskontrolle) für andere Anwendungsfälle
verfügbar zu machen.
Ein spezieller Anwendungsfall ergab sich für die Software DCAM. Diese
berechnet die Schweißbahnen in Form von CNC-Programmen für vorgegebene
Maschinen und Werkstücke. Die Maschinendaten liegen innerhalb des Systems
jedoch lediglich in Form einer mathematischen Beschreibung vor. Die
konkreten Bauteilgeometrien sind darin nicht enthalten. Somit ist das
Programmsystem nicht in der Lage, eine Kollisionserkennung durchzuführen.
Das IWS sah es somit als wünschenswert an, die CNC-Simulation und die
Kollisionserkennung der vorliegenden Arbeit zu nutzen. Da dies für den
Anwender möglichst transparent geschehen sollte, wurden alle Funktionalitäten
der Anwendung als Schnittstellen offengelegt, so dass diese aus anderen
Programmsystemen heraus transparent verwendet werden können (Abbildung
4-29).
Hauptanwendung (DCAM) Hintergrundanwendung
Benutzer
Abb. 4-29 Transparente Verwendung der Schnittstellen (Bsp. DCAM)
Die eigentliche Anwendung (DCAM) läuft damit beispielsweise im
Vordergrund, während die hier erstellte Applikation unsichtbar im Hintergrund
agiert.
Schnittstellen
97

Das folgende Klassendiagramm zeigt den Entwurf einer Remote-Control-
Komponente. Diese besitzt als Methoden die wichtigsten Funktionalitäten der
Anwendung, welche somit die nach außen offenen Schnittstellen darstellen.
Abb. 4-30 Klassendiagramm der Remote-Control -Schnittstelle
Darüber hinaus ist ein Monitoring-Konzept integriert, mit dem der Programmierer
der Hauptanwendung in der Lage ist, die Vorgänge in der Hintergrundanwendung
zu überwachen und beispielsweise Informationen über den Stand
der CNC-Ausführung (z.B. aktuell ausgeführte CNC- Zeile) oder bisher
aufgetretene Kollisionen (Ort und Zeit) zu ermitteln.
Diese Monitore sind als Interface-Klassen erstellt worden und können vom
Programmierer der Hauptanwendung seinen Vorstellungen entsprechend
implementiert werden. Die orange markierten Klassen entsprechen beispielhaft
diesen Implementierungen.
Die Klasse MainFrame entspricht der Hauptklasse der hier entwickelten
Anwendung.
98

4.5 Persistenzstrategie
Damit die modellierten Szenen vom Anwender gespeichert und somit wiederverwendet
werden können, wurde ein Datenformat entwickelt, dass in der Lage
ist, alle erforderlichen Informationen einer Szene abzubilden. Aus Gründen der
Transparenz und der Erweiterbarkeit des Gesamtsystems wurde hierfür eine
Struktur im XML-Format gewählt (Abbildung 4-31).
...
...
...
...
...
Abb. 4-31 XML-Struktur des Datenformats
Die dargestellte Struktur besteht aus fünf Elementen, welche im folgenden kurz
erläutert werden sollen:
Unter dem Knoten Scene wird der Szenegraph abgebildet. Alle Knoten des
Szenegraphen werden auf gleichnamige Knoten in der XML-Struktur
abgebildet. Eine detaillierte Beschreibung aller Knoten soll an dieser Stelle
ausgelassen werden. Wichtig ist lediglich zu wissen, dass alle BranchGroup’s,
die Baugruppen entsprechen (Abbildung 4-32), neben den üblichen
Eigenschaften die Attribute name und id besitzen, welche den Namen der
Baugruppe und eine dokumentweit eindeutige Nummer repräsentieren.
Letzteres wird für die eindeutige Referenzierung in den folgenden Elementen
benötigt.
99

Baugruppe A
TG
S
BG
TG
S
...
Abb. 4-32 Abbildung von Baugruppen auf die verwendete XML-Struktur
Der Knoten ElementConnections speichert die Parameter der Gelenkverbindungen.
Die an einer Verbindung beteiligten Baugruppen werden über
die oben angesprochene id referenziert.
Das Element Views enthält alle für eine Szene gespeicherten Sichten. Diese
können im Menü unter View add current View angelegt werden.
Unter CollisionObjectPairs sind die Konfigurationen der Kollisionserkennung
gespeichert, also welche Paare auf Kollisionen getestet werden sollen und
welche nicht. Dieser Knoten wird erst angelegt, wenn manuelle Änderungen
vorgenommen werden. Ist dieser nicht vorhanden, so werden die
Standardeinstellungen (Vater-Kind-Ausschluss) ermittelt und verwendet.
Am Ende des Dokuments werden schließlich die Parameter aller verwendeten
OBBs in einer entsprechenden Hierarchie gespeichert. Dies ist vorteilhaft, da
das Laden der berechneten OBBs sehr viel schneller ist, als diese jedesmal neu
zu erzeugen. Nachteil ist sicherlich der erhöhte Speicherbedarf. Dieser bleibt
jedoch in einem akzeptablen Rahmen und wird daher als unproblematisch
eingeschätzt. Die Zuordnung OBB- Hierachie und Baugruppe erfolgt ebenfalls
über das oben angesprochene id-Attribut.
Um die Dateien schnell und ohne große Speicheranforderungen laden zu
können, wurde für das Parsen der XML-Strukturen ein SAX-Parser verwendet,
welcher im Gegensatz zu komfortableren DOM-Parsern das Dokument
sequentiell bearbeitet und für bestimmte Inhalte registrierte Ereignisse erzeugt.
...
100

4.6 VR- Darstellung
Eine besonders wünschenswerte Funktionalität der vorliegenden Arbeit stellt
die Möglichkeit zur VR-Darstellung dar. Hierfür wurden zwei Ansätze
verfolgt. Zum einen wurde die Verwendung des bereits angesprochenen
Chromium-Systems und zum anderen die des XML3D-Datenformats
angestrebt. Die speziell erforderlichen Implementierungen sollen im folgenden
vorgestellt werden.
4.6.1 Chromium
Um die vorliegende Anwendung mittels des Chromium-Systems visualisieren
zu können, wurden in einer aktuell am IWS abgeschlossenen Studienarbeit
[Bretschneider05] Implementierungsregeln definiert. Diese besagen unter
anderem, dass das 3D-Fenster (javax.media.j3d.Canvas3D), in dem die Szene
dargestellt wird, allein, also ohne weitere Oberflächenkomponenten (abgesehen
von einem Menü) auf dem Anwendungsfenster (java.awt.Window) platziert
werden muss. Da die Anwendung bisher jedoch eine recht komplexe
Oberflächenstruktur hat (Abbildung 4-33) und diese für die Bedienung auch
benötigt wird, bietet es sich an, eine für die VR-Darstellung modifizierte
Version der eigentlichen Anwendung zu erstellen.
Abb. 4-33 Oberfläche der Anwendung
Diese wurde so gestaltet, dass sich das zentrale 3D-Fenster auf einem
eigenständigen Frame (JFrame) befindet. Das untere 3D-Fenster für die
Darstellung der Details der Kollisionen musste entfernt werden, da die
verwendete Chromium-Konfiguration immer nur ein 3D-Fenster darstellen
101

kann. Die übrigen Oberflächenkomponenten blieben unverändert. Abbildung
4-34 zeigt die modifizierte Anwendung.
Abb. 4-34 VR-Version (Chromium) der Anwendung
Treten Kollisionen auf, so können die Gittermodelle der kollidierenden
Baugruppen inklusive der farblich markierten Primitive, die bisher im unteren
3D-Fenster angezeigt wurden, nun anstelle der Original-Szene dargestellt
werden (Abbildung 4-35).
Abb. 4-35 Anzeige de Details der Kollisionen
Dabei kann abwechselnd zwischen der Originalszene und der detaillierten
Kollisionsdarstellung umgeschalten werden. Abbildung 4-36 zeigt die noch
verzerrte Darstellung einer auf drei Displays verteilten Szene.
Abb. 4-36 Verteilung einer Szene auf drei Displays
102

4.6.2 XML3D
Derzeit wird am Lehrstuhl für Computergrafik ein Framework für die VR-
Darstellung entwickelt (Abbildung 4-37). Dieses verwendet für den Datenaustausch
ein eigens entwickeltes 3D-Format, welches mit XML3D bezeichnet
wird.
XML3D
Abb. 4-37 Architektur des Gesamtsystems nach [Metze]
Da die Verwendung dieses Frameworks eine weitere Möglichkeit für die
Darstellung in einer VR-Anlage bietet, sollte die zu erstellende Anwendung
über eine Exportfunktion in das XML3D-Format verfügen.
Das Format ist dabei so ausgelegt, dass es neben statischen Szenen auch
Animationen abbilden kann. Da sich letzteres jedoch momentan noch in der
Entwicklung befindet, wurde lediglich der Export statischer Szenen
implementiert. Dafür wurde der Szenengraph der modellierten Szene auf die
XML3D-Struktur abgebildet.
Dazu werden zunächst alle Knoten des Szenegraphen, die Instanzen der
Klassen TransformGroup oder BranchGroup sind, hierarchisch auf Knoten
vom Typ transform der XML3D-Struktur abgebildet. Enthalten diese Gruppen-
Knoten in der Menge ihrer Kind-Knoten Shape3D-Instanzen, so wird eine Id
generiert und unter dem Attribut shape dem XML3D-Knoten hinzugefügt. Die
103

Zuordnung zwischen Id und Shape3D-Instanz wird in einer Liste zwischengespeichert.
Anschließend werden alle Shape3D-Instanzen inklusive der enthaltenen
Geometrie als Knoten vom Typ poly dem XML3D-Dokument angefügt. Die
Materialeigenschaften der Shape3D-Objekte werden abschließend als Shader-
Knoten vom Typ phong angefügt. Abbildung 4-38 zeigt eine in das XML3D-
Format exportierte Szene.
Abb. 4-38 Darstellung einer Szene in XML3D
Da die für den Export in die VR-Anlage notwendigen Implementierungen
damit zunächst abgeschlossen sind und auch alle übrigen geforderten
Funktionalitäten behandelt worden sind, soll im folgenden in die Testphase
übergegangen werden.
104

5 Test, Anwendungsbeispiele
Als Software-Test bezeichnet man in der Informatik ein mögliches Verfahren
zur teilweisen Verifikation bzw. Validierung eines Programms. Dieser dient
der Qualitätssicherung eines neu erstellten oder geänderten Softwareprogramms.
Dabei geht es prinzipiell darum, das tatsächliche Verhalten mittels
Testfällen zu untersuchen und die Ergebnisse mit den erwarteten Ergebnissen
(Anforderungskatalog, Normen usw.) zu vergleichen und zu dokumentieren.
Es handelt sich folglich um eine Aktivität der Softwareentwicklung, in der die
erstellte Anwendung auf ihre Funktionalitäten hin getestet wird. Der Test kann
verschiedene Ausprägungen haben: Im vorliegenden Fall soll der Test derart
erfolgen, dass versucht werden soll, unterschiedlichste Szenarien und
Anwendungsfälle zu modellieren und die nach Kapitel 2 geforderten Funktionalitäten
an diesen zu testen.
Neben den in Kapitel 2 angeführten Anwendungsbeispielen sollen zusätzlich
Roboter und Komponenten der Firma Kuka in den Test einbezogen werden.
5.1 Kuka-Roboter und -Komponenten
Am IWS werden derzeit unter anderem Roboter des Herstellers Kuka
verwendet. Daher wurden während der Entwicklung der Software zum Testen
des Konstruktionswerkzeugs und der Kollisonserkennung unterschiedlichste
Kuka-Roboter und -Kompo-nenten modelliert und somit zur weiteren
Verwendung verfügbar gemacht. Die erforderlichen CAD-Daten entstammen
der Homepage des Hersteller und können dort in den unterschiedlichsten
Formaten abgerufen werden. Im vorliegenden Fall wurden diese im VRML-
Format importiert.
Abbildung 5-1 zeigt einige der erstellten Roboter und Komponenten. Es zeigte
sich, dass sich die Baugruppen mit der hier erstellten Anwendung ohne
Einschränkungen modellieren und deren kinematische Eigenschaften abbilden
lassen.
Zusätzlich konnten die einzelnen Baugruppen mit Hilfe des in Abschnitt 4.1.2
angesprochenen Werkzeugs zur Wiederverwendung von Komponenten in
beliebiger Art und Weise kombiniert werden, wodurch sich die Modellierung
von komplexen Szenen deutlich vereinfachte.
105

Kr3 Kr125
Kr60 Kl1500
Abb. 5-1 Kuka-Roboter und -Komponenten
Darüber hinaus wurde die Kollisionserkennung an den Objekten getestet und
ohne erkennbaren Fehler und in akzeptabler Performance durchgeführt. Tests
ergaben, dass besonders die Nutzung der räumlichen und zeitlichen Kohärenz
die Kollisionserkennung beschleunigen. Dies gilt ganz besonders für den Fall,
dass Kollisionen zwischen zwei Baugruppen auftraten und diese anschließend
gemeinsam gleichartig bewegt wurden. Diese Kollision musste daher im
folgenden Zeitschritt nicht neu berechnet, sondern lediglich angezeigt werden.
106

5.2 XXL-Anlage
In Abschnitt 2.1.2 wurde als Anwendungsbeispiel für das Laserstrahlschweißen
die XXL-Anlage vorgestellt. Um die Möglichkeiten und Funktionalitäten der
vorliegenden Arbeit zu testen, wurde diese prototypisch mit der erstellten
Software modelliert (Abbildung 5-2).
Abb. 5-2 XXL-Anlage
Die Bauteilgeometrien liegen im 3DS-Format vor und wurden über einen
entsprechenden FileLoader in das Programmsystem importiert. Anschließend
ist die Anlage nach dem Modell der „CNCInspector“-Software konstruiert
worden. Abbildung 5-3 zeigt beispielhaft die Umsetzung der Laserschweiß-
Köpfe.
Dabei entstand, bis auf die CNC-Steuerung, ein voll funktionsfähiges Abbild
der realen Maschine 1 . Die CNC-Steuerung in Form eines CNC-Interpreters
konnte leider bis zum Abschluss der vorliegenden Arbeit nicht mehr
implementiert werden, da derzeit noch das Verhalten der Sinumerik-
Steuerungsanlagen der realen Maschine analysiert wird. Unter Verwendung
des Standard-Interpreters können aber bereits zu Testzwecken Programme
abgearbeitet werden.
1 Der exakte Aufbau der realen Anlage darf in der vorliegenden Arbeit nicht veröffentlicht
werden. Aus diesem Grunde ist das hier gezeigte Modell modifiziert worden und entspricht
somit nur teilweise der realen Anlage.
107

Sollte in naher Zukunft die CNC-Steuerung analysiert sein, so kann ein eigener
Interpeter implementiert und in die Anwendung integriert werden. Hier zeigt
sich ein Vorteil der Erweiterbarkeit der erstellten Software.
Neben der Simulation durch CNC-Programme kann die virtuelle Anlage selbstverständlich
auch manuell gesteuert werden.. Für jedes kinematische Gelenk
existiert ein Regler, mit dem die Parameter der Verbindung geändert werden
können. Somit lassen sich verschieden Konfigurationen der Anlage erzeugen
und unter Verwendung der Kollisionskontrolle typische Anwendungsfälle, z.B.
in Form von z.B. Erreichbarkeitsstudien etc., durchführen.
Abb. 5-3 Laserschweißköpfe
Zusätzlich lassen sich jederzeit Werkstücke in die virtuelle Anlage importieren
und sich somit die Möglichkeiten der Bearbeitung durch die XXL-Anlage
analysieren. Sollten Mängel in der Anlagenkonstruktion entdeckt werden, lässt
sich das kinematische Modell der virtuellen Anlage auch jederzeit bearbeiten.
Es können Baugruppen hinzugefügt, entfernt oder deren Gelenkverbindungen
neu konfiguriert werden.
Die Kollisionskontrolle lieferte hier zunächst Kollisionen zwischen Bauteilen,
die aufgrund der geometrischen Nachempfindung für die Darstellung in der
virtuellen Anlage zustande kamen. So traten beispielsweise Kollisionen
zwischen den zylindrischen Objekten, die den Faltenbalgen der realen Anlage
entsprechen, und den Maschinenteilen für die y-Achse auf. Diese Probleme
wurden gelöst, indem durch manuelle Konfiguration Kollisionen zwischen den
betroffenen Baugruppen ausgeschlossen wurden. Hierdurch können keine
Kollisionen übersehen werden, da die zulässige Translation der Faltenberge
entlang der z-Richtung über Constraints reguliert ist. Abbildung 4-5 zeigt die
geometrische Form der Faltenbalge im Modell.
108

Abb. 5-4 Umsetzung der Faltenbalge als zylindrische Objekte
Darüber hinaus zeigte sich auch hier wieder, dass besonders bei Szenen mit
einer großen Anzahl von Baugruppen die Nutzung von Kohärenz und aprior-
Wissen entscheidend zur Beschleunigung der Kollisionserkennung beitragen.
109

5.3 Laserstrahl-Auftragschweißen
Als weiteres Anwendungsbeispiel wurde in Kapitel 2 das Laserstrahl-Auftragschweißen
angeführt. Da sich ein Anwendungsfall ergab, bei dem das
modulare Pulverdüsensystem mit einem Roboter der Firma Reis kombiniert
werden sollte, wurde dieses im Test aus Daten im STL-Format modelliert.
Abbildung 5-4 zeigt den erstellten Roboter mit angefügtem Laser.
Abb. 5-5 Reis-Roboter mit Laserkopf
Damit die Simulation die CNC-Programme der realen Maschine ausführen
kann wurde anschließend von einem Studenten aus dem Maschinenwesen ein
CNC-Interpreter nach der in Abschnitt 4.2 beschriebenen Vorgehensweise
implementiert und in die Anwendung über die vorgesehenen Schnittstellen
integriert. Somit ist die Software nun in der Lage, die Programme der realen
Anlage zu simulieren.
Abschießend wurden verschiedene Werkstücke importiert und die durch die
Software DCAM berechneten Programme an diesen getestet. Ein Beispiel zeigt
Abbildung 5-5.
Da ein direktes Ausführen der Simulation aus der Software DCAM heraus
erwünscht war, wurde die Anwendung, unter Verwendung der in Abschnitt 4.4
beschriebenen Schnittstellen, in das DCAM-System integriert. Hier zeigen sich
die Vorteile der integrativen Konzepte der Anwendung.
110

Abb. 5-6 Reis-Roboter mit Werkstück
Da die Anlagenbetreiber davon ausgehen, dass keine Selbstkollisionen des
Roboters aufgrund der Auslegung der Roboter-Steuerung auftreten können,
bietet es sich an, die Kollisionserkennung entsprechend manuell zu
konfigurieren. Folglich müssten lediglich Kollisionen zwischen dem
Werkstück und den Roboterkomponenten untersucht werden.
111

6 Zusammenfassung
Ziel der vorliegenden Arbeit war die Erstellung einer virtuellen
Laserbearbeitungsanlage. Diese recht allgemein gestellte Aufgabe wurde in
Abschnitt 1.3 durch klar definierte Zielstellungen eingegrenzt:
1) Werkzeug zur Konstruktion einer generischen Maschine
2) Spiegelung der Kinematik einer Bearbeitung in einer Simulation
3) Kollisionskontrolle beim Bewegungsablauf und Identifizierung der
Kollisionspunkte
4) Ermöglichung der intuitiven Modifikation von Maschinenelementen
und Bahndaten
5) Möglichkeit des Exports in eine VR-Anlage,
Das Ergebnis der Arbeit sollte somit ein Softwareprodukt sein, welches über
die genannten Funktionalitäten verfügt. Daher wurde anschließend ein
Projektplan aufgestellt, welcher aus den in der Softwaretechnik üblichen
Phasen: Analyse, Design, Implementierung und Test besteht. Diese bildeten
gleichzeitig die Gliederung der vorliegenden Ausarbeitung.
In Kapitel 2 wurden zunächst die Ist-Situation und typische Anwendungsgebiete
des IWS dargestellt. Anschließend wurden aus den Problem- und
gesetzten Zielstellungen alle Anforderungen an die zu entwickelnde Software
zusammengetragen. Hierbei stellte sich bereits heraus, dass unter Verwendung
eines einfachen internen Modells die Mehrheit der zu erwartenden
kinematischen Modelle abgebildet werden kann. Unter Abschätzung des
Kosten-/Nutzenfaktors wurde dieses Modell als Basis für die weitere
Entwicklung verwendet.
Die ermittelten Anforderungen und die vorbereitend getroffenen Designentscheidungen
wurden anschließend in Kapitel 3 konkretisiert. Es wurde
gezeigt, wie Baugruppen in eine kinematische Struktur integriert und auf dieser
unterschiedliche Konfigurationen der virtuellen Maschine erzeugt werden
können.
Darüber hinaus ist ein Konzept für die CNC-Steuerung der virtuellen Anlage
erarbeitet worden. Hier bestand die Schwierigkeit darin, dass deren Verhalten
zur Entwicklungszeit nicht bekannt ist und somit ein dynamisches System
112

geschaffen werden musste, mit dem noch zur Laufzeit ein Steuerungsverhalten
integriert werden kann. Dazu wurde die Java Reflection API verwendet, welche
es ermöglicht, dynamisch Klassen zu laden und diese anschließend sofort zu
verwenden. Die zu ladenden Klassen sind Teil einer abstrakten Maschine und
erbringen speziell festgelegte Funktionalitäten. Die Implementierung dieser
Klassen erfolgt durch den Anwender selbst.
Als Hauptbestandteil des Kapitels wurde ein Konzept für die Kollisionserkennung
erarbeitet. Dazu wurde zunächst die Szene strukturiert und in, auf
Kollisionen zu testende, Objekte zerlegt. Diese Objekte entsprechen jeweils
den Baugruppen, welche sich abhängig von ihrer kinematischen Struktur
relativ zueinander bewegen Die anschließend entwickelte Vorgehensweise
entspricht einem zweiphasigen Verfahren, bei dem in einer ersten Phase unter
Nutzung von a priori-Wissen sowie zeitlicher und räumlicher Kohärenz
untersucht wird, welche Objekte während eines Zeitschritts überhaupt auf
Kollisionen getestet werden müssen. Anschließend werden die zu testenden
Objekte unter Nutzung von OBB-Hierarchien und Primitivtests auf Kollisionen
untersucht. Die Erzeugung der OBBs erfolgte dabei durch Untersuchen der
statistischen Verteilung der Punkte und Flächen der Primitive des zu
umhüllenden Objekts.
Anschließend wurde gezeigt, dass aufgrund der Diskretisierung des
kontinuierlichen Prozesses während der Simulation, Probleme bei der
Kollisionserkennung auftreten können. Hierfür wurde eine Lösung in Form
eines kontinuierlichen Kollisionserkennungsverfahrens vorgestellt. Da diese
Problematik bisher jedoch als nicht akut eingeschätzt wird und die Einhaltung
der Projektlaufzeit gewährleistet sein muss, ist eine Implementierung in das
Programmsystem bisher nicht erfolgt. Sollte dies zukünftig erwünscht sein, so
wurde auch gezeigt, wie unter Verwendung der bereits vorhandenen Strukturen
(OBBs) eine Implementierung möglich ist.
In Kapitel 4 wurden anschließend spezielle Problemstellungen erläutert und die
implementierte Anwendung vorgestellt. So wurde beispielsweise gezeigt, wie
die Konstruktion von Baugruppen erfolgt und dass diese einmal modellierten
Komponenten mit dem vorhandenen Programmsystem leicht wiederverwendet
werden können. Somit lassen sich selbst komplexe Szenen in unterschiedlichen
Konfigurationen mit geringem Aufwand modellieren.
Darüber hinaus wurde gezeigt, wie sich die CNC-Steuerung parametrieren lässt
und wie eigene CNC-Interpreter entwickelt und integriert werden können.
Anschließend wurden erneut spezielle Problemstellungen und Strategien der
Kollisionserkennung, die Gestaltung der Schnittstellen und die implementierten
Funktionalitäten für die VR-Darstellung erläutert.
Schlussendlich ist die erstellte Anwendung in Kapitel 5 an praktisch relevanten
Szenarien getestet worden. Es zeigte sich, dass die heteregonen Anlagentypen
in Form von Robotern, Laserschweißanlagen oder Lineareinheiten mit der
erstellten Anwendung modellierbar sind und sich deren kinematische Vorgänge
simulieren lassen.
113

6.1 Fazit und Ausblick
Rückblickend betrachtet sind die gesetzten Zielstellungen erfüllt worden. Die
erstellte Anwendung ist in der Lage die kinematischen Eigenschaften
unterschiedlichster Anlagensysteme abzubilden, Simulationen durchzuführen
und Kollisionen zu erkennen. Speziell die Möglichkeiten zur VR-Darstellung
der modellierten Anlagen stellen einen Vorteil gegenüber herkömmlichen
Produkten anderer Hersteller dar.
Darüber hinaus zeichnet sich die Software aufgrund der Implementierung in
Java/Java3D durch Plattformunabhängigkeit und der wahlweisen Nutzung von
DirectX- oder OpenGL- Treibern für die dreidimensionale Darstellung aus. Die
definierten Schnittstellen können unter Verwendung freier Software (Java) und
Entwicklungsumgebungen (z.B. Eclipse) komfortabel genutzt werden.
Allerdings mussten aufgrund der begrenzten Laufzeit und des Umfangs des
Projektes Kompromisse im implementierten Funktionsumfang eingegangen
werden. Da dies bereits zu Beginn abzusehen war, wurde besonders auf die
Erweiterbarkeit der Software und die transparente Gestaltung der Schnittstellen
großen Wert gelegt.
Der aktuelle Stand ist folglich als Prototyp zu bezeichnen. Um die Anwendung
an Kunden des IWS ausliefern zu können, sind daher beispielsweise noch
ergonomische Untersuchungen in Form von Usability-Tests erforderlich. Diese
sollen am IWS in weiterführenden Arbeiten durchgeführt werden.
Darüber hinaus sind zahlreiche Erweiterungsmöglichkeiten denkbar. Zum
einen sei hier die kontinuierliche Kollisionserkennung zu nennen. Weiterhin ist
in Zukunft sicherlich wünschenswert, die eigentliche Lasermaterialbearbeitung
simulieren zu können. Denkbar wäre somit beispielsweise, die vom Laserstrahl
abgefahrenen Bahnen auf dem Werkstück aufzutragen. Hierfür können
ebenfalls die vorhandenen Strukturen (OBBs) für die Berechnung des
Schnittpunkts zwischen Laserstrahl und Werkstück verwendet werden. Auch
hierzu laufen am IWS bereits weiterführende Arbeiten.
114

Quellen
[Balzert]
H.Balzert: Lehrbuch der Software-Technik. Akademischer Verlag, 2000.
[Barber, Dopkin u. Huhdanpaa]
C. B. Barber, D. P. Dobkin, and H. Huhdanpaa. The Quickhull algorithm for
convex hull. Technical Report GCG53, Geometry Center, Univ. of Minnesota,
July 1993.
[Bretschneider05]
K.Bretschneider. Threoretische Grundlagen zur Entwicklung einer virtuellen
Technologie. Studienarbeit. Staatliche Studienakademie Dresden. März 2005.
[Devillers02]
O.Devillers and P.Guige.Faster Triangle-Triangle Intersection Tests.Institut
National de Recherche en Informatique en Automatique. Juni 2002
[Erleben]
K.Erleben. Module Based Design for Rigid Body Simulators. Technical Report
DIKU-TR-02/06, Department of Computer Science, University of
Copenhagen. July 2002.
[Gottschalk, Lin, Manocha96]
S.Gottschalk, M.C.Lin, and D.Manocha. OBBTree: A Hierarchical Structure
for Rapid Interference Detection. In SIGGRAPH 96 Conference Proceedings,
Annual Conference Series. ACM SIGGRAPH, Addison Wesley, August 1996.
[Gottschalk96]
S.Gottschalk. Separating axis theorem. Technical Report TR96-024,
Department of Computer Science, UNC Chapel Hill, 1996
115

[Gottschalk00]
S.Gottschalk. Collision queries using oriented bounding boxes. PhD Thesis
2000.
[Held97]
Martin Held. ERIT – A collection of efficient and reliable intersection tests.
Technical Report, Univesity at Stony Brook, 1997.
[Klosowski98]
J.T.Klosowski. Efficient Collision Detection for Interactive 3D Graphics and
Virtual Environments. PhD thesis, State University of New York, Stony
Brook,1998.
[Lloyd]
John E. Lloyd.Research Associate, Computer Science Dept.University of
British Columbia.
Homepage: http://www.cs.ubc.ca/~lloyd/
[Metze]
J.Metze. Entwicklung eines Visualisierungssystems für Virtual - Reality
Simulationen. Großer Beleg, Institut für Computergrafik, TU-Dresden. März
2005.
[Mezger01]
J.Mezger. Effiziente Kollisionsdetektion in der Simulation von Textilien.
Diplomarbeit. Graphisch-Interaktive Systeme, Universität Tübingen. Dezember
2001.
[Möller97]
Tomas Möller. A fast triangle-triangle intersection test. Journal of graphics
tools. 1997.
116

[Redon00]
S.Redon, A.Kheddar und S.Coquillart. An algebraic Solution to the Problem of
Collision Detection for Rigid Polyhedral Objects. In Proceedings of
International Conference on Robotics and Automation, April 2000.
[Redon01]
S.Redon, A.Kheddar und S.Coquillart. CONTACT: arbitrary in-between
motions for continuous collision detection. In Proceedings of IEEE
ROMAN’2001, Sep. 2001.
[Redon02]
S. Redon, A.Kheddar and S.Coquillart. Fast Continuous Collision Detection
between rigid bodies. Proc. Of Eurographics (Computer Graphics Forum).
2002.
[Redon04]
S. Redon, J.Kim and D.Manocha. Fast Continuous Collision Detection for
Articulated Models. ACM Symposium on Solid Modeling and Applications.
2004.
[Selig03]
J.M.Selig. Lie Groups and Lie Algebras in Robotics. South Bank University,
London.2003
[Snyder92]
J.Snyder. Interval analysis for Computer Graphics. Computer Graphics,26(2),
pages 121-130, July 1992.
[Sommerville]
I.Sommerville: Software Engineering, 6th edition, Addison-Wesley 2000
[Völlmar04]
Dr.S.Völlmar, Dr.D.Lepski, S.Scharek, Dr.H.Eichler, R.Ludewig. Optimierung
einer hybriden Fertigung durch Einsatz von Methoden der virtuellen Realität.
Kompetenzzentrum Neue Materialien, Tagung, Bayreuth. 2./3.11.2004
117

[Webhofer04]
M.Webhofer.Dissertation: Abbildung von Finite-Elemente-Modellen als kinematische
Strukturen. Lehrstuhl für Fördertechnik Materialfluss Logistik.TU-
München. 2004.
118