Home

Document

Contents

1. Interface Interface z B SHM Simulator z B SHM o Wett Iniialsierungsdatei Abbildung 3 2 Konzeption des Simulationssystems Quelle Eigene Darstellung Das Simulationssystem besteht im Kern aus dem Simulator mit dem die virtuelle Welt also die Umgebung des Roboters erstellt und simuliert wird Aufbau und Eingriff in die virtuelle Welt erfolgt ber die HSimL API auf die im Kapitel 3 4 noch n her eingegangen wird Das Konzept sieht weiter vor die Visualisierung der virtuellen Welt au erhalb des Simulators stattfinden zu lassen und so die Simulation unabh ngig vom visuellen Aspekt durchzuf hren Wie schon in der Aufgabenstellung erw hnt wird ViToSA zur Visualisierung eingesetzt Eine Schnittstelle erm glicht die Kommunikation zwischen Simulator und Visualisierung Den Anforderungen entsprechend wird eine weitere Schnittstelle f r die Manipulation der Simulation von au en bereitgestellt Dies soll einen interaktiven Zugriff auf die virtuelle Welt erm glichen Entwicklung eines Software Simulationssystems 49 Welche Schnittstellen f r Visualisierung und Manipulation verwendet werden und wie die Kommunikation zwischen den einzelnen Komponenten abl uft wird in dem folgenden Kapi tel n her beschrieben 3 3 2 Schnittstellen Design F r die Interprozess Kommunikation IPC zwischen dem Simulator und der Visualisierung bzw zwischen dem Simulator und Programmen welche die virtue
2. 1 HSimL Fasst alle Definitionsdateien zu einer Bibliothek zusammen 2 HWorld Definiert die Funktionen zur Erstellung der Dynamik Welt 3 HBody Definiert die Funktionen zur Erstellung eines K rpers 4 HJoint Definiert die Funktionen zur Erstellung von Verbindungen Gelenken 5 HGeom Definiert die Funktionen zur Erstellung von Geometrieobjekten 6 HSpace Definiert die Funktionen zur Erstellung von Kollisionsr umen 7 HRotation Definiert zus tzliche Funktionen zur Rotation 8 HContact Definiert Strukturen f r die Kontakte 9 HMass Definiert die Struktur der Masse 10 SharedDataManipulation Datenstruktur f r die Manipulation 11 SharedDataVisualisation Datenstruktur f r die Visualisierung Die Abbildung 3 8 zeigt die Struktur der Bibliothek mittels eines UML Diagramms Die Welt hat hier eine Kollisionswelt einen Untergrund und eine Kontaktgruppe bereits integriert Sie kann aber noch in weitere Kollisionswelten aufgeteilt werden Den Kollisionswelten wiederum Entwicklung eines Software Simulationssystems 56 sind die Kollisionsobjekte zugeordnet Die Welt besteht weiterhin aus K rpern und Gelenken Die K rper haben eine eigene Masse und ein Kollisionsobjekt integriert e Welt Kollisionswelt Untergrund Kontaktgruppe K 0 CE a Kollisionswelt Korper Gelenk Masse Kollisionsobjekt Kg Kollisionsobjekt Abbildung 3 8 UM
3. Vgl Gross Hauger Schnell 1998 S 104 ff Theoretische Grundlagen 19 Allgemeine Bewegung Die allgemeine Bewegung eines starren K rpers setzt sich aus einer Translation und einer Drehung des Gesamtsystems zusammen Theorem von Chasles Es reicht aus drei Punkte innerhalb eines starren K rpers zu betrachten um dieses Theorem zu verdeutlichen Alle drei Punkte sind von einer Startposition in eine Endposition berf hr bar indem sie parallel verschoben und anschlie end um die entsprechende Achse gedreht werden Die Abbildung 2 4 stellt die allgemeine Bewegung grafisch dar Abbildung 2 4 Darstellung einer allgemeinen Bewegung Quelle Eigene Darstellung 2 2 3 Dynamik Kr fte und Drehmomente Das erste Bewegungsgesetz von Newton besagt dass ein K rper sich in Ruhe befindet oder seine Geschwindigkeit konstant ist solange keine u ere Kraft wirkt Demzufolge setzt sich ein K rper in Bewegung oder in Drehbewegung wenn an ihm eine Kraft oder ein Drehmo ment wirkt Das Drehmoment M spielt f r die Rotation die gleiche Rolle wie die Kraft f r die Translation Die Translationsbewegung eines starren K rpers kann durch den Impuls charakterisiert wer den F r Rotationsbewegungen ist eine weitere physikalische Gr e der so genannte Dreh 8 Vgl hierzu und im Folgenden Dreizler L dde 2003 S 316 Vgl hierzu und im Folgenden Baraff 1997 S 13 ff Theoretische Grundlagen 20 impuls zu definieren
4. 0222000020000020000000nnnnannnnenennnnn nennen nnnnnen nn 54 Abbildung 3 7 Simulationsbibliothek HSIML nennen 55 Abbildung 3 8 UML Diagramm der HSimL Bibliothek 00222000020000 nenne nnnnnn ne 56 Abbildung 3 9 Programmablaufplan des Simulators nennen nnnnne en 56 Abbildung 3 10 Programmablauf der Initialisierungsphase nennen 57 Abbildung 3 11 Programmablauf der Simulationsschleife 22220 58 Abbildung 3 12 Programmablauf des Einleseprozesses nenne nennenennn nennen 60 Abbildung 3 13 Kommunikationsablauf zwischen SHM und ViTOSA a nnaannnannoannnannnnnnnnnnnna 61 Abbildung 3 14 Screenshot einer Beispiel Simulationsumgebung mit ViToS A 62 Abbildung 3 15 Darstellung des Test Regelkreises Close loop 63 Abk rzungsverzeichnis Abk rzungsverzeichnis 3D AABB API ASIMO BSD BSP DDD GCC gcc GNU GPL HRI HSimL ID IPC K DOP MUTEX OBB ODE OPCODE OpenGL POSIX Qt RTBOS SHM SVN UI ViToSA Dreidimensional Axis Aligned Bounding Box Application Programming Interface Advanced Step in Innovative Mobility Berkeley Software Distribution Binary Space Partitioning Data Display Debugger GNU Compiler Collection GNU C Compiler GNU s Not Unix General Public License Honda Research Institute HRI Simulation Library Identifikationsnummer Interprozesskommunikation K Discrete Oriented Polytop Mutual Exclusion Oriented Bounding Box Open Dynamics Engine Optimized Collisi
5. Ar lt 0 005 Durch ODE be kommt der Anwender ein m chtiges Werkzeug f r die Konstruktion und einfache Handha bung komplexer Systeme in die Hand gelegt Durch den ERP und CFM Parameter k nnen auf einfache Weise Feinabstimmungen in der virtuellen Welt gemacht werden Wie bereits erw hnt hat sich erst gegen Ende des Projekts rausgestellt dass ODE nicht threadsicher ist d h dass eine fehlerfreie Ausf hrung von mehreren parallelen Simulatoren ber Threads nicht garantiert werden kann Nur die Ausf hrung von parallelen Simulatoren ber getrennte Prozesse ist m glich Dies ist insofern ein Problem da das beim HRI einge Zusammenfassung und Ausblick 66 setzte Betriebssystem RTBOS Real Time Brain Operating System auf die Ausf hrung von Threads ausgelegt ist Eine M glichkeit dieses Problem zu l sen w re die HSimL Bibliothek dazu benutzen um ODE threadsicher zu machen Daf r m ssten alle Daten auf die ein glo baler Zugriff m glich ist durch einen bestimmten Sperrmechanismus gesch tzt werden A ber alleine das Ausfindig machen der entsprechenden Daten ist sehr schwer und zeitauf wendig zumal der gesamte Prozess f r jede neue Version von ODE wiederholt werden m sste Daher wurde darauf verzichtet und der Simulator jetzt nur noch als ein auszuf hren des Programm implementiert Ein Ziel das mit der Erstellung der eigenen Simulations Bibliothek HSimL verfolgt wurde war es den eigentlichen ODE Code vor dem Anwe
6. internen Grafikprogramm ViToSA ist problemlos m glich Die Simulations API ist den Anfor derungen entsprechend umgesetzt worden Mit ihr k nnen nun virtuelle Welten aufgebaut und die Umgebung des Roboters nachgebildet werden Im Laufe des Projekts mussten aufgrund ver nderter Bedingungen allerdings nderungen bei der Umsetzung des Simulationssystems durchgef hrt werden Hier ist vor allem der Si mulator anzuf hren der jetzt als eine auszuf hrende Einheit also als ein Programm reali siert wurde und nicht wie am Anfang vorgesehen als eine Komponente des HRI Modells Es hat sich erst im Laufe des Projekts herausgestellt dass ODE nicht threadsicher ist und somit der einwandfreie Einsatz im threadbasierten Betriebssystem des Unternehmens nicht garan tiert werden konnte Daraus ergaben sich wiederum weitere nderungen an das gesamte Simulationssystem So konnte der Zugriff auf den Simulator nicht mehr direkt durch die Si mulations API erfolgen sondern musste ber entsprechende Schnittstellen Shared Memo ry realisiert werden Anstatt der Simulator Komponente wurde eine Ersatzkomponente imp lementiert die als Input die Soll Position eines K rpers erh lt und als Output die Ist Position des Objektes wieder ausgibt Die brigen Anforderungen an den Simulator wurden entsprechend umgesetzt Virtuelle Wel ten in der die Dynamik starrer K rper simuliert wird sind auf einfache Art und Weise zu erstellen Vor allem durch die Konzeption
7. m ssen diese K rper eine bestimmte Position und Orientierung relativ zueinander haben Dennoch ist es f r die beiden K rper m glich sich in einer Position zu befinden in der die Gelenkbedingungen nicht bereinstimmen Dieser Feh ler kann auf zwei Arten entstehen Zum einen k nnen w hrend der Simulation Fehler auftre ten so dass die K rper von der gew nschten Position abweichen Zum anderen ergeben sich Fehler wenn der Anwender die Position und Orientierung eines K rpers nicht richtig setzt Es gibt einen Mechanismus diesen Gelenkfehler zu verringern W hrend jedem Simulations schritt wendet jedes Gelenk eine spezielle Kraft an um die K rper zur ck an ihre richtige Position zu bringen Diese Kraft wird durch den ERP Error Reduction Parameter kontrol Iert Der Parameter kann einen Wert zwischen 0 und 1 annehmen Der ERP Wert spezifiziert inwieweit der Gelenkfehler behoben wird Bei einem Wert von O wird keine Berichtigungskraft angewandt und die K rper k nnten eventuell auseinander drif ten Bei einem Wert von 1 wird versucht alle Gelenkfehler auszubessern Dennoch ist es nicht ratsam einen ERP Wert von 1 zu benutzen da der Fehler nicht vollst ndig behoben wird Daher wird ein Wert zwischen 0 1 und 0 8 empfohlen Der ERP Wert kann global f r eine Welt gesetzt werden Es ist aber auch m glich jedem Gelenk einen spezifischen Wert zuzuweisen Theoretische Grundlagen 34 Gelenk Kr fte K rper 2 Abbildu
8. C_ RW Abbildung 2 11 Struktur einer virtuellen Welt in ODE Quelle Eigene Darstellung 2 5 2 Die Welt Das Welt Objekt symbolisiert die virtuelle Umgebung f r die Simulation der K rperdynamik Es stellt eine Art Beh lter dar in dem die K rper die Verbindungen zwischen den K rpern Gelenke die Kollisionsr ume und die Geometrie Objekte gespeichert werden Es ist m glich mehrere virtuelle Welten zu erzeugen die voneinander unabh ngig sind So k nnen z B K rper Objekte aus zwei verschiedenen Welten nicht miteinander kollidieren In den meisten Anwendungen reicht es aus nur eine Welt zu erzeugen sofern keine Simulatio nen zu unterschiedlichen Zeitpunkten stattfinden m ssen In diesem Fall ist eine weitere Welt pro Zeitpunkt erforderlich da alle Objekte die sich in derselben Welt befinden immer nur zur gleichen Zeit existieren k nnen ber das Welt Objekt wird ein Simulationsschritt durchgef hrt und es lassen sich verschie dene Einstellungen in der virtuellen Umgebung vornehmen die sich auf jedes Objekte in der Welt beziehen So kann z B eine Gravitationskraft hinzugef gt werden die sich auf alle Ob jekte in gleicher Weise auswirkt Zur Durchf hrung eines Simulationsschritts in ODE stehen zwei verschiedene M glichkeiten zur Verf gung Die erste Methode Step f hrt einen Simulationsschritt aus und ist die genau ere aber auch langsamere der beiden Methoden
9. Er charakterisiert die Drehbewegung in hnlicher Weise wie der Impuls die Translationsbewegung Der Drehimpuls L eines um eine feste Achse rotierenden K rpers ist das Produkt aus sei nem Tr gheitsmoment 7 bez glich dieser Achse und seiner Winkelgeschwindigkeit L Jo hnlich wie die Kraft als zeitliche nderung des Impulses angesehen werden kann L F 2 gibt es einen Zusammenhang zwischen Drehimpuls und Drehmoment M T t t 2 3 Kollisionserkennung Die Kollisionserkennung ist verantwortlich f r die berpr fung ob sich Objekte in einem Kol lisionsraum ber hren oder berschneiden Dadurch soll das gegenseitige Durchdringen von K rpern verhindert werden Die allgemeine sehr aufwendige Variante um Kollisionen zu er kennen ist die Brute Force Methode bei der jedes einzelne Objekt mit jedem anderen Objekt auf Kollisionen berpr ft wird Dies ist ziemlich zeit und rechenaufwendig vor allem weil Kollisionen in der Regel verh ltnism ig selten auftreten Um diesen Aufwand zu verkleinern ist die Kollisionserkennung sehr h ufig in zwei Phasen unterteilt In der ersten Phase wird versucht alle Objektpaare auszuschlie en die nicht kolli dieren k nnen um somit die schnelle Auffindung von Kollisionsbereichen zu erm glichen Daf r werden ganz spezielle Algorithmen f r eine Raumaufteilung eingesetzt In der zweiten Phase wird mit Hilfe komplexerer Algorithmen zwischen den brig gebliebenen Objekten eine Kol
10. Sprache C und anhand der bei HRI geltenden Programmier Konventionen Die bersetzung der entwickelten Programme erfolgt mit gcc GNU C Compiler und dem HRI internen Makefile System Zur Fehlersuche wird der Linux Debugger DDD Data Display Debugger eingesetzt Die Dokumentation der Software bzw des Quellcodes erfolgt mit Doxygen einem Open Source Software Dokumentationswerkzeug Es steht als freie Software unter der GPL zur Verf gung Die Ver sionskontrolle bernimmt die ebenfalls Open Source Software SVN Subversion Entwicklung eines Software Simulationssystems 45 T tigkeit Projektvorbereitungen 01 05 02 06 Einweisung in das Thema Projektplanung Einarbeitung in ODE Vortrag Projektumsetzung 05 06 31 08 Konzept f r Simulationssystem Implementierung des Simulators Implementierung der Visualisierung Implementierung der Benutzerschnittstelle Testszenarios Projektabschluss 01 09 29 09 Dokumentation Puffer Abschlussvortrag Dauer Insgesamt Tage 110 01 05 29 09 Abbildung 3 1 Projektplan 3 2 Anforderungen 3 2 1 Anforderungen an das Simulationssystem Es ist eine Software zu entwickeln die in der Lage ist eine virtuelle dynamische Welt zu erstellen und zu simulieren Diese Welt soll die Umgebung eines Roboters nachbilden ohne den Roboter aber selbst zu simulieren da ein Roboter Simulator bereits existiert Damit die virtuelle Umgebung so real wie m glich wirkt m ssen die physikalischen Gesetze
11. Vorgehensweise bei der Kollisions erkennung 1 Vor jedem Simulationsschritt wird durch eine spezielle Funktion berpr ft welche K rper sich ber hren und eine Liste mit den entsprechenden Kontaktpunkten zur ckgeliefert 2 F r jeden Kontaktpunkt wird eine spezielle Kontaktverbindung erstellt die Informationen zur Reibung und weitere Eigenschaften enth lt 3 Alle erstellten Kontakte werden in einer speziellen Gruppe gespeichert um sie nach dem Simulationsschritt auf schnellen Weg wieder zu l schen 4 Ausf hren des Simulationsschritts 5 Alle Kontakte werden gel scht ODE stellt f r die Kollisionserkennung drei verschiedene Funktionen bereit die eine unter schiedliche Behandlung der Kollisionserkennung erm glichen Im Folgenden sollen diese beschrieben werden Theoretische Grundlagen 38 1 Collide Die Funktion Collide bekommt zwei sich m glicherweise berschneidende Geometrie Objekte bergeben und generiert bei einer berschneidung Kontaktpunkte zwischen den Objekten Wenn sich die Objekte nicht ber hren wird der Wert Null zur ckgeliefert andern falls die Anzahl der Kontakte Diese Funktion macht keinen Unterschied ob es sich bei den bergebenden Objekten um Kollisionsr ume handelt oder einzelne Geometrien Wenn eines oder beide der bergebenden Objekte ein Kollisionsraum ist werden alle Objekte des einen Kollisionsraumes mit allen Objekten des anderen Kollisionsraums verglichen sowie alle Kon t
12. auf Somit h lt sich die Struktur weitestge hend an den Aufbau von ODE siehe Abbildung 3 7 Die Bibliothek ist aufgeteilt in First Level API Second Level API und Third Level API Dabei bilden alle Funktionen aus HWorld und HBody die First und Second Level API Die First Level API ist f r Anwender gedacht die ohne gro en Aufwand eine virtuelle Welt aufbauen m chten Die Second Level API dagegen beinhaltet Zusatzfunktionen wie z B das automa tische Deaktivieren von K rpern siehe Kapitel 2 5 3 Diese Funktionen werden nicht unbe dingt ben tigt sie sind aber in bestimmten F llen sehr n tzlich Die restlichen Funktionen Entwicklung eines Software Simulationssystems 55 aus HJoint HSpace HGeom HRotation HContact HMass bilden die Third Level API und sind f r fortgeschrittene Anwender gedacht die komplexere Welten erstellen m chten Hier zu geh rt z B die Verwendung von Gelenken Diese Aufteilung ist auch aufgrund des Um fangs der API sehr hilfreich da es die f r den Anwender wichtigen Funktionen zu einer Ein heit gruppiert Funktionen die nicht so h ufig oder sehr selten genutzt werden bilden wieder um eine Gruppe f r sich HSimL HWorld HBody HyJoint HSpace HGeom HRotation HContact HMass SharedDataManipulation SharedDataVisualisation Abbildung 3 7 Simulationsbibliothek HSimL Quelle Eigene Darstellung
13. betrachten Eine externe Anwendung kann ber die Schnittstelle Shared Memory oder Sockets in die Simulation eingreifen Der Simulator liest vor jedem Simulationsschritt die Schnittstelle aus und aktualisiert anhand der eingelesenen Daten die Simulation Anschlie end schreibt er die Simulationsdaten in die Schnittstelle f r die Visualisierung Dieser Vorgang l uft sequentiell ab und wird in einer Schleife st ndig wiederholt Die Visualisierung ViToSA liest in be stimmten Abst nden den Shared Memory aus und stellt die eingelesenen Daten grafisch dar Entwicklung eines Software Simulationssystems 53 Vaia x Sim ID 1 Obj ID 4 newDataFlag 1 exitFlag 0 positionFlag 1 forceFlag 0 setForceFlag 0 position 123 force 0 SHM Sockets hreib Manipulation E Shared Data o Z B User Interface Manipulation Ba Simulator SHM Sockets m Shared Data esen Visualisierung Visualisation 1 vr ViToSA a Data Visualisation n Valid x Sim ID 1 Model CUBE Model ID 3 Size 1 1 1 Position 1 2 3 Orientation 100 010 001 Abbildung 3 5 Ablauf der Kommunikation Quelle Eigene Darstellung 3 4 Simulator Der Fokus der Masterarbeit liegt auf der Simulation der Dynamik starrer K rper Der hier beschriebene Simulator ist der Kern des gesamten Simulationssystems Dieses Kapitel gibt einen berblick ber dessen Struktur und Funktionsweise Im Anhang 2 ist ein Beispielcod
14. der Anforderungen aber durch die Kombination der bei den Varianten ergaben sich gewisse Vorteile Zum einen kann die Simulation Visualisierung und Manipulation jetzt von verteilten Rechnern im Netzwerk stattfinden zum anderen ber ragt die Shared Memory Variante durch ihre Schnelligkeit Durch die Umsetzung beider Kon zepte bekommt der Anwender auch einen gr eren Handlungsspielraum F r die Implemen tierung des Shared Memory wurde zun chst die unternehmenseigene IOStream Bibliothek verwendet Aufgrund eines neuen Release dieser Bibliothek bei der keine Zugriffssteuerung mehr wegen der Gefahr von Deadlocks unterst tzt wird musste auf die jetzige SHM Zusammenfassung und Ausblick 67 Bibliothek zur ckgegriffen werden die auf den POSIX Standard aufbaut Die Implementie rung der Socket Schnittstelle erfolgte mit der unternenmenseigenen Socket Bibliothek Die Entwicklung und Verwendung der beiden Datenstrukturen SharedDataVisualisation und SharedDataManipulation f r die Visualisierung bzw f r die Manipulation erweitern das Kon zept der Unabh ngigkeit und der Erweiterbarkeit des Simulationssystems da die beiden Da tenkonzepte jederzeit mit neuen zus tzlichen Informationen erweitert werden k nnen Die Visualisierung der Simulation konnte problemlos mit Hilfe eines Konverters in ViToSA verwirklicht werden Es steht jeweils ein Konverter f r das Shared Memory Modell und ein Konverter f r das Netzwerk Modell zur Verf gung E
15. eigene Datenstruktur ObjectData mit der es die Objekte visualisiert ber den in ViTo SA eingesetzten Sourcehandler ist es m glich mehrere Konverter gleichzeitig zu laden wo bei die Daten der entsprechenden Anwendung alle in derselben Szene visualisiert werden Der Konverter ist f r jede Anwendung neu zu implementieren Die Abbildung 2 21 veran schaulicht das Prinzip in einer Grafik Theoretische Grundlagen 43 E C Benutzer a aan DIENEN 1 Nase n lt SR SS SS Konverter 1 Visualisierungs Sourcehandler Konverter 2 9 Daten Konverter n Abbildung 2 21 Konzeption von ViToSA Quelle HRI Internal Report M M hlig 2006 Der Ablauf der Visualisierung sieht nun folgenderma en aus Zun chst m ssen dem Konver ter die anwendungsspezifischen Daten bermittelt werden Wie diese bertragung der Daten an den Konverter erfolgt ist in ViToSA nicht festgelegt und Aufgabe des Benutzers Der Konverter muss nun die erhaltenen Informationen in ViToSA konforme Nachrichten umwan deln und sie an den Sourcehandler bermitteln Der Sourcehandler stellt sicher dass die umgewandelten Daten an die Szene gesendet und dort dargestellt werden Dies ist auch f r mehrere Konverter parallel m glich wobei die Anzahl an Konvertern nicht beschr nkt ist Der Benutzer kann nun ber den so genannten Viewer die Szene Betrachten ViToSA bietet hier auch die Funktion mehrer
16. eines Textparsers k nnen nun mittels einer norma len Textdatei virtuelle Welten auf einfache Weise aufgebaut werden Eine Bespielkonfigurati on ist im Anhang 1 beigef gt Allerdings k nnen ber diese Textdatei noch keine Verbindun gen Gelenke zwischen den K rpern erstellt werden Diese Funktionalit t w re in einer sp teren Version zu realisieren Es sei hier noch angemerkt dass der Textparser nicht Teil der Anforderungen war sondern aufgrund der ver nderten Bedingungen erst im Laufe des Pro jekts noch zus tzlich spezifiziert wurde Zusammenfassung und Ausblick 65 Die Simulation von virtuellen Welten unter Verwendung der Socket Schnittstelle hat bisher noch den Nachteil dass bei der Initialisierung des Simulators solange gewartet werden muss bis sich die beiden Clients f r die Visualisierung und Manipulation mit dem Netzwerk server verbinden Dieses Problem ist durch einen Multithread Ansatz zu l sen indem der Simulator in mehrere Threads aufgeteilt wird Der Hauptthread simuliert die virtuelle Welt w hrend nebenher ein anderer Thread auf die Clients Visualisierung und Manipulation war tet und sobald sich ein Client anmeldet die Verbindung zu ihm erstellt Die Multithread Erweiterung konnte leider nicht mehr im Zeitrahmen der Masterarbeit realisiert werden und ist daher in einer sp teren Version zu erg nzen Es sei hier noch angemerkt dass diese Er weiterung allerdings nicht zu den Anforderungen geh rte Urspr
17. starrer K per Dieses Kapitel stellt die Grundlagen f r die Bewegung von K rpern Objekten vor die als Basis f r die nachfolgenden Kapitel dienen Die klassische Mechanik besch ftigt sich mit der Beschreibung und Berechnung der Bewe gung von Teilchen Massepunkten und K rpern Es geht also um das Aufstellen und L sen von Bewegungsgleichungen Die Mechanik kann in Kinematik und Dynamik unterteilt wer den Die Kinematik beschreibt die Bewegung von K rpern ohne die Ber cksichtigung der einwirkenden Kr fte also nur den zeitlichen Verlauf Die Bewegung wird durch die Gr en Ort Weg Geschwindigkeit und Beschleunigung beschrieben Die Dynamik besch ftigt sich im Gegensatz zur Kinematik mit der durch Kr fte hervorgerufenen Bewegung also mit der Ursache und Wirkung der Bewegung Sie beschreibt somit die nderung der Bewegungs gr en Weg Geschwindigkeit und Beschleunigung unter der Einwirkung von Kr ften und Momenten 2 2 1 Der starre K rper Honerkamp und R mer beschreiben in ihrem Werk Klassische Theoretische Physik einen starren K rper wie folgt Ein K rper wird als starr bezeichnet wenn er als unverformbar an gesehen werden kann d h wenn in guter N herung die Abst nde zwischen allen seinen Teilen unver ndert bleiben D h ein starrer K rper ist ein System von Massenpunkten mit konstanten Abst nden zueinander In der Realit t ist ein K rper sicherlich nie v llig starr sondern unterliegt V
18. 2 Abbildung 2 7 Beliebig orientierter COuacder nennen nennen nenne nnennne nennen 23 Abbildung 2 8 Simulation von zwei miteinander verbundenen K rpern een 27 Abbildung 2 9 Schematische Darstellung der Objektstruktur in ODE ssennnnannnsennnnnnrnenenne 27 Abbildung 2 10 Verbindung von K rpern mit Gelenken nennen nennen 28 Abbildung 2 11 Struktur einer virtuellen Welt in OUDE 29 Abbildung 2 12 Kugel Gelenk 31 Abbildung 2 13 Gcharmer Gelenk no nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnneennenn 31 Abbildung 2 14 Gchebe Gelenk rnia a aa 32 Abbildung 2 15 Universal Schanier Typ2 und kontakt Gelenk n nnnannnannnnnnonnnnennnnnnnnnnnna 32 Abbildung 2 16 Funktionsweise des Error Reduction Parameters nenne 34 Abbildung 2 17 Die verschiedenen Geometrien in ODE u0022222000220nnnennnennnennennnnnnnn 36 Abbildung 2 18 K rper in ODE mit mehreren Kollisionsobjekten no 36 Abbildung 2 19 Aufbau und Ablauf einer Simulation mODE 40 Abbildung 2 20 Screenshot von VITOSA siisii sriti iaaa ardada 42 Abbildung 2 21 Konzeption von ViToA nennen nnnnnenn 43 ABBIAUNG S T Ge te E WEE 45 Abbildung 3 2 Konzeption des SimulationssystemS nenne nenne nennen 48 Abbildung 3 3 Datenstruktur GharedatevVeualeaton nennen 51 Abbildungsverzeichnis VIII Abbildung 3 4 Datenstruktur GharedataManoulaton nennen 52 Abbildung 3 5 Ablauf der Kommunikation nennen nnnnnnnnnn nennen 53 Abbildung 3 6 Architektur des SimulatorsS 2
19. Basis f r die dar auf folgenden Kapitel geben 2 1 1 Simulation Simulation ist die Bezeichnung f r die Nachbildung und Analyse eines Systems oder Pro zesses durch ein vereinfachtes Modell Durch eine Simulation kann auf einfache und zeitspa rende Weise das Verhalten von Objekten nachgebildet werden anstatt komplizierte Verfah ren zur Untersuchung anzuwenden F r die Simulation von bewegten Objekten wird das vereinfachte Modell von starren K rpern angewendet die in der Realit t so nicht vorkommen Dies vereinfacht die Simulation erheb lich 2 1 2 Simulationsprogramm Ein Simulationsprogramm bildet das Verhalten eines Systems oder Prozesses durch ein Mo dell auf einem Rechner ab Die Verhaltensregeln sind durch mathematische Gleichungen beschrieben und mit Hilfe des Computers werden alle L sungsm glichkeiten durchgesspielt 2 1 3 Simulator Ein Simulator ist ein Ger t System oder Computer mit dem bestimmte Eigenschaften eines Systems bzw Prozesses nachgebildet werden k nnen 2 1 4 Regelung Regelkreis Die Regelung ist ein Vorgang bei dem eine bestimmte Gr e X kontinuierlich erfasst und mit einem vorgegebenen Sollwert abgeglichen wird Im Gegensatz zur Steuerung ist die Rege lung ein geschlossener Wirkungskreis Vgl hierzu und im Folgenden Myers Enzyklop disches Lexikon 1977 Band 21 S 746 Vgl Myers Enzyklop disches Lexikon 1977 Band 19 S 710 Theoretische Grundlagen 15 2 2 Mechanik
20. Die Steuerung erfolgt indem die Komponente Robot Control die Koordinaten der Hand an die Komponente Manipulate Object schickt Die Position der Hand wird an den Simulator bergeben Die Entwicklung eines Software Simulationssystems 63 Kommunikation erfolgt dabei ber Shared Memory Die neue Ist Position wird der Kompo nente vom Simulator zur ckgegeben Diese wird sogleich an die Komponente Robot Control bertragen Position i Position Robot Control Manipulate Object Objekt Nr Objekt Nr Simulator Visualisierung ViToSA pi Stand Alone Server Abbildung 3 15 Darstellung des Test Regelkreises Closed Loop Quelle Eigene Darstellung Zusammenfassung und Ausblick 64 4 Zusammenfassung und Ausblick In der vorliegenden Arbeit wurde ein Simulationssystem konzipiert und entwickelt das die Dynamik starrer K rper simuliert visualisiert und aktive Simulationen von au en manipulie ren kann Das System integriert au erdem eine Kollisionserkennung Die in der Aufgabenstellung und Zielsetzung genannten Anforderungen an das zu entwi ckelnde System wurden alle umgesetzt Aktive Simulationen k nnen nun ber eine Schnitt stelle von au en manipuliert werden Die Manipulation der virtuellen Welt kann ber eine externe Anwendung erfolgen die ber die beiden Schnittstellen Shared Memory oder So ckets auf die virtuelle Welt zugreift Auch die Visualisierung der virtuellen Welt mit dem HRI
21. Diese Methode verwendet ein System ei ne gro e Matrix von linearen Un Gleichungen die zu l sen sind Dies hat einen Zeitfaktor der Ordnung m und eine Speicherfaktor der Ordnung m wobei m die Anzahl der Bedingungen ist F r gro e Simulationen kann das eine gro e Speicherbelastung bedeuten Theoretische Grundlagen 30 gungen ist F r gro e Simulationen kann das eine gro e Speicherbelastung bedeuten und die Berechnungen k nnen betr chtlich lange dauern Die Funktion QuickStep f hrt einen Simulationsschritt mit Hilfe einer iterativen Methode durch Diese Funktion hat einen Zeitfaktor der Ordnung m N und einen Speicherfaktor von m wobei m die Anzahl der Bedingungen ist und N die Anzahl von Iterationen F r gro e Simulationen ist dies die weitaus schnellere aber auch die ungenauere Methode 2 5 3 Der K rper Das K rper Objekt symbolisiert einen starren K rper in der Simulation Jeder K rper hat ei nen Referenzpunkt der mit dem Massenschwerpunkt bereinstimmt siehe Kapitel 2 2 1 ber einen Positionsvektor x y z wird die Position des Referenzpunktes bestimmt dem auch eine lineare Geschwindigkeit vx vy vz zugewiesen werden kann Die Orientierung eines K rpers ist durch eine 3 3 Matrix oder ein Quaternion gegeben Ein Winkelgeschwin digkeitsvektor wx wy wz beschreibt dabei die Orientierung des K rpers ber die Zeit hin weg Weiterhin besitzt ein K rper die zeitkonstanten Eigenschaften Masse und eine
22. Fachbereich Informatik und Ingenieurwissenschaften der Fachhochschule Frankfurt Main University of Applied Sciences Prof Dr Peter Nauth Koreferent Prof Dr Andreas Pech Masterthesis Simulation von bewegten Objekten in einem closed loop Visionsystem von Dipl Ing Mirko Radowitz Die Arbeit wurde erstellt in Kooperation mit dem Honda Research Institute Europe GmbH FS Betreuer Dipl Ing Mark Dunn Dr Ing Michael Gienger September 2006 Erkl rung Ich versichere dass ich meine Masterarbeit ohne Hilfe Dritter und ohne Benutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt und die den benutzten Quellen w rt lich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe Diese Arbeit hat in gleicher oder hnlicher Form noch keiner Pr fungsbeh rde vorgelegen Frankfurt 5 Oktober 2006 Mirko Radowitz Danksagung Ich m chte mich an dieser Stelle ganz besonders bei meinen Betreuern Herrn Dipl Ing Mark Dunn und Herrn Dr Ing Michael Gienger f r die sehr gute Betreuung und Hilfestellung w hrend der Arbeit bedanken Ihre fachlich kompetente und menschlich nette Betreuung war mir eine gro e Hilfe Auch bedanken m chte ich mich bei Herrn Dr Ing Christian Goerick f r die Erm glichung dieser Masterarbeit und bei allen anderen Kollegen vom Honda Research Institute Weiterer Dank geht an meinen betreuenden Dozenten von der Fachhochschule Frankfurt am Main H
23. Gumulatonssvstems nennen 44 31 Projektplanung und Vorbereitung Eege 44 32 Anforder ngeN else einen 45 3 2 1 Anforderungen an das Gimulaionsesvsiem nennen nennen 45 3 2 2 Anforderung an den Simulator nennen nennen nennen 46 3 2 3 Anforderung an die Manipulation nennen nennen 47 3 2 4 Anforderung an die Visualisierung nenn nenn nenne nennen 47 3 3 SlMUlAallonssySsiem eege 48 3 3 1 Konzeption des Gmulatonssvstems nenne nnnnnenennn nennen 48 932 Schnittstellen Desionsnseereee a 49 3 3 3 Ablauf der Kommuhlkalioh eek 52 934 GMAO EE 53 3 4 1 KONZERTE een ee ee 53 342 ImplEmenleiing aan 54 3423 nn E ele er E E 56 344 TESISZENAN0Ss soseen en ADE AEE a AEA EREE 59 SS DNR alle le AE 59 3 6 VISUAISIErUNG Keen ee ee er 60 GE Ee E de GE 62 4 Zusammenfassung und AUSDICK a aan 64 Beete een TEE LXVII Abbildungsverzeichnis VII Abbildungsverzeichnis Abbildung 1 1 Darstellung des ersten Heoelkreses nennen 12 Abbildung 1 2 Darstellung des zweiten Hegelkreses nenne anne 12 Abbildung 2 1 Starrer K rper mit lokalem Koordinatensystem nn 16 Abbildung 2 2 Darstellung einer Translationsbewegung anne 17 Abbildung 2 3 Darstellung einer Hotaionsbewegunmg nenne nennen 18 Abbildung 2 4 Darstellung einer allgemeinen Bewegung 19 Abbildung 2 5 Kugel als H llk rper 000000 nennen nnnnennnnnn nennen nnnnne nenne nnennnnnn 21 Abbildung 2 6 Achsenorientierter Quader als H llk rper 44404444440 Rn en ne nn ernennen 2
24. L Diagramm der HSimL Bibliothek Quelle Eigene Darstellung 3 4 3 Simulationsablauf An dieser Stelle soll nun der Programmablauf des Simulators beschrieben werden Die Ab bildung 3 9 stellt diesen Prozess grafisch dar Die Erl uterungen beziehen sich dabei auf die Verwendung der SHM Schnittstelle Es kann analog dazu auch die Socket Schnittstelle ein gesetzt werden en Parameter 2 Konfig Datei Simulator starten Parameter 3 SHM Manipul Parameter 4 SHM Visual Schnittstelle f r Manipulation erzeugen Schnittstelle f r Visualisierung erzeugen Simulations Welt erzeugen a d Dynamik Welt erzeugen f A Kollisions Welt erzeugen Simulations Welt initialisieren 8 Untergrund erzeugen statische Umgebung Simulationsschleife aufrufen V y fi f d Bereitstellung einer Kontakt Gelenk Gruppe Simulations Welt l schen Abbildung 3 9 Programmablaufplan des Simulators Quelle Eigene Darstellung Entwicklung eines Software Simulationssystems 57 Dem Simulator muss beim Programmsstart die Anzahl der zu simulierenden Objekte bekannt sein Daher ist die Objektanzahl als Parameter mit zu bergeben Die brigen drei Parameter sind optional Sie sind daf r vorgesehen die Konfigurationsdatei und die Visualisierungs bzw die Manipulationsschnittstelle zu spezifizieren Ohne die Angabe der Parameter wird der Standardname und Pfad verwendet Im n chsten Schritt
25. Tr g heitsmatrix welche die Massenverteilung um den Massenschwerpunkt beschreibt K rper werden wie schon erw hnt ber Gelenke miteinander verbunden Eine Gruppe von K rpern in der jeder K rper in irgendeiner Weise mit jedem anderen K rper aus einer Grup pe verbunden ist wird als so genannte Insel bezeichnet Jede Insel in der Welt wird bei einem Simulationsschritt separat als eine Einheit behandelt Es besteht die M glichkeit K rper zu deaktivieren und wieder zu aktivieren Deaktivierte K r per werden bei einem Simulationsschritt nicht aktualisiert und sparen dadurch Berechnungs zeit Wenn also von einem K rper bekannt ist dass er bewegungslos oder f r die Simulation nicht relevant ist sollte er deaktiviert werden Bei einer gro en Anzahl von K rpern ist es aber so gut wie unm glich jeden K rper manuell zu berpr fen ob er sich bewegt oder nicht Daher bietet ODE eine Funktion an bei der automatisch ein K rper deaktiviert wird wenn er sich in mehreren Simulationsschritten oder in einer bestimmten Zeitspanne nicht bewegt hat Ein K rper wird als unbeweglich betrachtet sobald der Betrag der linearen Geschwindigkeit und der Winkelgeschwindigkeit unter einem bestimmten Grenzwert liegen Wird ein deakti vierter K rper mit einem aktiven K rper ber ein Gelenk verbunden so wird er automatisch beim n chsten Simulationsschritt reaktiviert Theoretische Grundlagen 31 2 5 4 Das Gelenk Ein Gelenk dient der V
26. aktpunkte zur ckgegeben Da bei dieser Funktion kein Unterschied zwischen Kollisionsr u men und Geometrie Objekten gemacht wird ist es besser die Funktionen SpaceCollide und SpaceOollide2 zu verwenden die solch eine Kontrolle erm glichen 2 SpaceCollide Die Funktion SpaceCollide erzeugt die Kontaktpunkte nicht direkt sondern bestimmt zu n chst einmal alle Geometrie Objekte innerhalb eines Kollisionsraums die sich m glicher weise berschneiden In einer Callback Funktion welches die beiden sich m glicherweise berschneidenden Objekte bergeben bekommt kann nun f r jedes Objektpaar genau be stimmt werden ob die Funktion Collide zur Kontakt Generierung aufgerufen wird In dieser Callback Funktion ist es zus tzlich m glich die genauen Kontakt Parameter f r jeden Kon takt einzustellen 3 SpaceCollide2 Die Funktion SpaceCollide2 ist der Funktion SpaceCollide hnlich nur mit der Ausnahme dass sie Geometrie Objekte aus einem Kollisionsraum mit Geometrie Objekten aus einem anderen Kollisionsraum nach m glichen berschneidungen berpr ft Das genaue Verhalten der Funktion ist abh ngig vom Typ der bergebenen Geometrien 1 Wenn eines der Argumente ein Kollisionsraum spezifiziert und das andere nur ein Geometrie Objekt wird die R ckruffunktion f r alle m glichen berschneidungen zwischen dem Geometrie Objekt und den Objekten in dem bergebenem Kollisions raum aufgerufen 2 Wenn beide bergebene Argument
27. alisation Quelle Eigene Darstellung Valid ist eine spezielle Identifikationsnummer die jeder richtig erzeugten Instanz der Daten struktur zugewiesen wird Die Sim ID ist eine eindeutige Identifikationsnummer die be stimmt welcher Simulationswelt dieses Datenobjekt angeh rt Der Parameter Model legt fest um was f r ein Objektprimitiv es sich handelt wie z B W rfel Kugel oder Zylinder Die Model ID ist eine eindeutige Identifikationsnummer die jedem Objekt zugewiesen wird und es genau spezifiziert Der Parameter Size enth lt die Gr e der Objekte Bei einem Quader sind das die drei Seitenl ngen und bei einer Kugel der Radius Position gibt die genaue Lage des Objekts in Weltkoordinaten an Dabei ist immer die Position des Massenschwer punkts gemeint siehe Kapitel 2 2 1 und 2 5 3 Orientation beinhaltet dementsprechend die Orientierung des Objekts Datenstruktur f r die Manipulation Die Datenstruktur SharedDataManipulation ist speziell f r die externe Manipulation der virtu ellen Welt gedacht Sie definiert alle Informationen um ein Objekt in der virtuellen Welt von au en zu steuern und zu modifizieren wie z B die Position des K rpers zu ver ndern oder einem K rper eine Kraft hinzuzuf gen Die Anwendung die sp ter f r die Manipulation der virtuellen Welt verantwortlich ist muss lediglich eine Instanz dieser Datenstruktur bilden und die entsprechenden Daten in dem Objekt eintragen Anschlie end bergibt sie das Date
28. ard und Software zu gew hrleisten Gerade aber bei den Testdurchl ufen wird die empfindliche und teure Hardware sehr belastet und es besteht die Gefahr einer Be sch digung Dazu kommt der Aufbau von komplizierten Testumgebungen die n tig sind um das entwickelte Verhalten zu berpr fen und zu testen Ein weiteres Problem ergibt sich bei der Nutzung der Hardware von mehreren Wissenschaft lern da sie immer nur f r einen Versuch genutzt werden kann und es somit automatisch zu Engp ssen kommt Die Entwicklung einer Software Simulationsumgebung f r den Roboter gibt die M glichkeit diesen Problemen entgegenzuwirken und den Entwicklungsprozess zu beschleunigen Siehe Honda Research Institute Europe GmbH www honda ri de 2006 Einleitung 11 1 3 Aufgabenstellung und Zielsetzung Es ist ein Software Simulationssystem zu entwickeln welches erm glicht die Dynamik und Kinematik von Objekten starren K rpern zu simulieren visualisieren und zu manipulieren F r die Simulation der Dynamik und Kinematik starrer K rper ist eine Bibliothek zu konzipie ren und zu implementieren mit deren Hilfe es m glich wird eine virtuelle Welt zu erstellen In dieser virtuellen Welt ist die Umgebung des Roboters nachzubilden Die Bibliothek soll flexibel und erweiterbar sein Die Basis daf r ist die frei erh ltliche ODE Bibliothek Open Dynamics Engine Die virtuelle Welt soll ber eine externe Manipulations Schnittstelle konfiguri
29. atenstruktur definiert alle n tigen Informationen die f r die Manipulation eines Objekts erforderlich sind Die Abbildung 3 5 im Kapitel 3 3 3 macht den Prozess der interaktiven Manipulation grafisch deutlich Entwicklung eines Software Simulationssystems 60 Bei dem interaktiven Eingriff in die Simulation ber den Shared Memory wird f r den zu ma nipulierenden K rper eine Instanz dieser Datenstruktur mit den entsprechenden Soll Objektwerten erzeugt und an den Simulator ber die Schnittstelle bergeben Der Simulator liest die Schnittstelle aus und f hrt die nderungen durch Die folgende Abbildung 3 12 macht den Einleseprozess des Simulators aus der SHM Schnittstelle anhand eines Programmablaufplans deutlich SHM auslesen Manipulation Simulator beenden Objekt ID auslesen und berpr fen ED Datenobjekt mit E SE zur ckgesetzten Flag in Daten ndern SHM schreiben Abbildung 3 12 Programmablauf des Einleseprozesses Quelle Eigene Darstellung Nach dem Einlesen der Daten wird zun chst gepr ft ob das newDatarlag gesetzt ist Wenn das der Fall ist wei der Simulator dass sich die Daten ge ndert haben und liest die Simu lations ID aus Wenn die ID mit der ID der Simulationswelt bereinstimmt wird der Einleseprozess weitergef hrt und berpr ft ob das exitFlag gesetzt ist Ist auch das der Fall wird der Simulator dementsprechend beendet Ansonsten ist zu b
30. bjekten K rper sind nun indirekt durch die Zuweisung zu einem Geometrie Objekt einem bestimmten Kollisionsraum zugeordnet Allerdings ist es nicht zwin gend erforderlich die Welt in solche R ume aufzuteilen dies erspart jedoch einen erhebli chen Rechenaufwand Kollisionsr ume sind auf jeden Fall in der Simulation einzusetzen sobald mehrere K rper zu einem komplexen Kollisions Objekt wie z B zu einem Automobil verbunden werden In der Abbildung 2 10 wird die Verbindung von mehreren K rpern mit Gelenken zu einem zusammenh ngenden Objekt anschaulich dargestellt Dadurch ist es m glich komplexere Strukturen aufzubauen Hierf r stehen verschiedene Gelenktypen wie z B ein Scharnier zur Verf gung die an sp terer Stelle noch n her erl utert werden K rper 1 Gelenk K rper 2 cke Gelenk pe ae Pr 22 2 K rper 4 Gelenk K rper 3 Abbildung 2 10 Verbindung von K rpern mit Gelenken Quelle Eigene Darstellung In der Abbildung 2 11 wird die Struktur einer virtuellen Welt auf Basis von ODE illustriert Diesmal wird die Trennung von Welt und Kollisionsraum deutlich und die Beziehung zwi schen K rpern und Geometrien veranschaulicht Einem K rper k nnen mehrere Geometrien zugeordnet werden Dadurch lassen sich komplexere Kollisionsobjekte erstellen Theoretische Grundlagen 29 a N an gi K rper 1 Geometrie 1 SS D y K rper 2 Geometrie 2 VW gt D A A K rper 3 Geometrie 3
31. chtet und nochmals getestet ansonsten wird die berpr fung gestoppt 1 gt Vgl Eckstein 1998 S 28 ff Theoretische Grundlagen 24 F r den Aufbau der B ume stehen viele verschieden Varianten zur Verf gung die entweder eine top down oder bottom up Strategie verwenden Die B ume bestehen dabei entweder aus Kugel H llk rper achsenorientierten Quadern beliebig orientierten Quadern K DOPS oder aus B umen mit verschiedenen H llk rpern 2 3 3 Raumaufteilungen Die Behandlung von gro en Mengen an Objekten ist wie bereits erw hnt ein weiteres Prob lem der Kollisionserkennung Mit der Raumpartitionierung kann die Anzahl der zu testenden Objektpaare f r die Kollisionserkennung wesentlich reduziert werden Die Idee dahinter ist den Raum in einzelne Zellen aufzuteilen und nur noch Objekte in derselben Zelle auf Kollisi onen zu untersuchen Zu den klassischen Verfahren geh ren die uniforme Raumuntertei lung Quadtrees Oktrees BSP Trees Binary Space Partitioning und noch weitere Verfah ren Uniforme Raumauteilung Bei dieser Methode wird ein gleichm iges Gitter im Kollisionsraum aufgespannt Jedes Ob jekt wird mindestens einer Zelle zugeordnet Die Kollisionserkennung muss nur noch zwi schen Objekten durchgef hrt werden die sich in der gleichen Zelle befinden Oktree Quadtree Bei diesem Verfahren wird der gesamte Raum in eine Hierarchie aus achsenorientierten Quadern aufgeteilt Die Wurzel besteht aus e
32. den Kontaktpunkte liefern Die Bibliothek unter st tzt zurzeit die oben angegebenen Kollisions Objekttypen Die Bibliothek f r die Kollisionserkennung gibt im Gegensatz zur Dynamik Bibliothek Infor mationen ber die Form Gestalt und Geometrie der K rper Vor jedem Simulationsschritt wird untersucht welche K rper sich ber hren um anschlie end die entsprechenden Kon taktpunkte zu bergeben An diesen Kontaktpunkten werden dann Verbindungen Kontakt Gelenke erstellt Ein Kontaktpunkt hat dabei eine ganz spezielle Struktur Diese Struktur besteht aus einem Positionsvektor einem Normalenvektor der Durchdringungstiefe und den zwei beteiligten Geometrie Objekten Dies kann auch die statische Umgebung sein Bevor die Kollisionserkennung genutzt werden kann ist zun chst eine Kollisionswelt hnlich der Simulationswelt zu erzeugen in der die Kollisionserkennung stattfindet Anschlie end sind dann alle f r die Simulation ben tigten Geometrie Objekte zu erstellen und der Kollisi onswelt hinzuzuf gen Vor dem Start der Kollisionserkennung ist noch ein Beh lter f r die Kontaktverbindungen bereitzustellen Dieser wird in ODE als joint group bezeichnet und speichert alle w hrend der Kollisionserkennung erstellten Kontaktverbindungen in einer Gruppe damit sie nach dem Simulationsschritt auf einer einfacher Weise wieder gel scht werden k nnen Ablauf der Kollisionserkennung Unten stehende Ausf hrungen beschreiben die genaue
33. der realen Welt also die Modelle von Massentr gheit Reibung und K rperkollisionen be r cksichtigt simuliert werden Die Dynamik einzelner Objekte in der virtuellen Welt muss abschaltbar sein um sie durch eine kinematische Steuerung von au en zu ersetzen Dadurch soll der Eingriff durch den simulierten Roboter in die virtuelle Umgebung erm glicht werden Eine weitere Anforderung an das System ist die M glichkeit in die Simulation interaktiv ein zugreifen d h neben der direkten Manipulation der virtuellen Welt durch den Simulator selbst also durch die API muss auch die M glichkeit bestehen von au en die aktuelle Si mulation zu beeinflussen Die Manipulation der virtuellen Welt durch eine externe Anwen Entwicklung eines Software Simulationssystems 46 dung kann dabei entweder ber eine Space Mouse oder durch eine einfache Tastaturein gabe erfolgen Das System muss zudem eine Visualisierung bereitstellen mit der die symbolischen Daten des Simulators dargestellt werden k nnen F r die Kommunikation zwischen Simulator Visualisierung und Manipulation sind die n tigen Schnittstellen bereitzustellen 3 2 2 Anforderung an den Simulator Der zu entwickelnde Simulator muss ganz bestimmte Anforderungen erf llen damit er f r den Einsatz im sp teren Simulations System geeignet ist Diese sind hier in funktionale und qualitative Anforderungen gegliedert Funktionale Anforderungen Zun chst muss gener
34. des Objekt schnell mit den umliegen den Objekten berpr ft werden kann Voraussetzung ist dass die Objekte nicht zu dicht an einander angeordnet sind 3 QuadTree Space Hier wird ein hierarchischer rasterbasierter AABB Baum Axis Aligned Bounding Box ver wendet um die Kollisionserkennung zu optimieren siehe Kapitel 2 3 2 Es ist au ergew hn lich schnell f r Simulationen mit gro er Anzahl an Objekten im offenen Gel nde 2 5 12 Simulation Integration Der Prozess ein System von starren K rpern ber die Zeit hinweg zu simulieren wird Integ ration genannt Jeder Integrationsschritt erh ht die aktuelle Zeit durch eine vorgegebene Schrittgr e und passt den Status von allen K rpern der neuen Zeit an Es wird ein Integra tor erster Ordnung eingesetzt Das Landau Symbol O N wird in der Informatik dazu verwendet um die Komplexit t von Algorithmen zu spezi fizieren Vgl Myers Enzyklop disches Lexikon 1977 Band 14 S 584 Theoretische Grundlagen 40 Der Integrator den ODE verwendet ist sehr stabil aber nicht besonders genau au er bei einer kleinen Schrittgr e Es ist geplant in einer sp teren Version von ODE einen Integrator h herer Ordnung einzusetzen mit dem genauere Simulationen durchgef hrt werden k nnen Zwischen jedem Integrationsschritt kann der Benutzer Funktionen aufrufen um Kr fte an den K rpern anzuwenden Diese Kr fte werden einem Kr ftespeicher in einem K rper zuge f gt Wen
35. e f r einen Simulator beigef gt 3 4 1 Konzept Der Aufbau des Simulators wird durch die Abbildung 3 6 widergespiegelt Basis f r den Si mulator ist wie schon erw hnt die Open Dynamics Engine ODE gilt als sehr stabil und ist im Vergleich zu anderen physikalischen Simulationsumgebungen verh ltnism ig schnell und genau Zudem ist es eine Open Source Software und somit frei erh ltlich ODE wird dabei f r die physikalische Umgebung der virtuellen Welt eingesetzt Die Einbindung der Physik Engine in den Simulator erfolgt ber die selbst erstellte Simulations Bibliothek HSimL Diese Bibliothek ist ein Wrapper um ODE und umschlie t den Code um ihn in die unternehmensin terne Systemstruktur zu integrieren Dadurch wird zus tzlich ein kontrollierter Zugriff auf die ODE Funktionen gew hrleistet Mit Hilfe dieser Bibliothek lassen sich nun virtuelle Welten bestehend aus starren K rpern und Geometrie Objekten erstellen und simulieren Auch die ODE basierte Kollisionserkennung wird unterst tzt Der Simulator ist mit Hilfe einer gew hn lichen Textdatei konfigurierbar Die Textdatei spezifiziert f r jeden K rper den Typ Kugel Quader Zylinder usw die Gr e die Position und Orientierung Je nach belieben kann f r jeden K rper auch noch ein zus tzliches Geometrie Objekt angelegt werden Komplexere Entwicklung eines Software Simulationssystems 54 Gebilde sind bisher noch nicht ber die Konfigurationsdatei zu erstellen Dies er
36. e Kollisionsr ume sind wird die R ckruffunktion f r alle sich m glich berschneidenden Objektpaare aufgerufen wobei eines der Ob jekte dem ersten Kollisionsraum angeh ren muss und das andere Objekt dem zwei ten Kollisionsraum Theoretische Grundlagen 39 ODE stellt zurzeit drei verschiedene Arten von Kollisionsr umen zur Verf gung Den Simple Space den Multiresolution Hash Table Space und den QuadTree Space siehe hierzu Kapi tel 2 3 3 Alle drei Kollisionsr ume verwenden unterschiedliche Strukturen f r die Speiche rung der Geometrie Objekte und benutzen unterschiedliche Algorithmen zur Kollisionserken nung 1 Simple Space Hier wird keine optimierte Kollisionserkennung angewendet Es werden alle m glichen Ob jektpaare auf berschneidungen berpr ft siehe Kapitel 2 3 4 Die Zeit die f r die ber schneidungstests f r n Objekte ben tigt wird ist O n Daher ist es f r Simulationen mit einer gro en Anzahl an Objekten nicht so gut geeignet Allerdings ist es f r kleinere Simula tionen mit wenigen Objekten die bevorzugte Variante 2 Multiresolution Hash Table Space Hier wird eine interne Datenstruktur benutzt die den Kollisionsraum in ein dreidimensionales Raster aufteilt siehe Kapitel 2 3 3 Jede Zellen berlappung wird protokolliert wobei eine Zelle die Form eines W rfels mit der Seitenl nge 2 hat Die Zeit die f r berschneidungs tests f r n Objekte ben tigt wird betr gt O n da je
37. e Positionen des Tisches und der Objekte an die Robot Control Komponente bergeben Diese kann nun in die Simulation eingreifen und die Positionen der Objekte in der virtuellen Welt ver ndern wie z B ein Objekt greifen und neben dem Tisch wieder loslassen Das Objekt w rde dann aufgrund der Schwerkraft auf den Boden herunter fallen Einleitung Der zweite Regelkreis siehe Abbildung 1 2 basiert auf dem ersten Regelkreis jedoch mit dem Unterschied dass die symbolischen Informationen zun chst visualisiert werden Aus Simulator Symbolisch Informationen Robot Control Abbildung 1 1 Darstellung des ersten Regelkreises Quelle Eigene Darstellung 12 den visuellen Daten werden anschlie end Bild Sequenzen generiert und einem Vision system bergeben Das Visionsystem extrahiert aus den visuellen Informationen wiederum Kommandos zur Steuerung des Roboters die der Robot Control Komponente bergeben werden Diese kann nun wieder aufgrund der Informationen in die virtuelle Welt eingreifen und sie manipulieren Symbolische Informationen Simulator Visualisierung Visuelle Informationen Robot Control Visionsystem Symbolische Informationen Abbildung 1 2 Darstellung des zweiten Regelkreises Quelle Eigene Darstellung Einleitung 13 Das Ziel der Arbeit ist es mit dem erstellten Software Simulationssystem eine virtu
38. e Viewer zu benutzen Entwicklung eines Software Simulationssystems 44 3 Entwicklung eines Software Simulationssystems Dieses Kapitel umfasst den gesamten Entwicklungsprozess von der Planung des Simulati onssystems bis zur Implementierung und Testen der Bibliotheken und der Test Anwendungen Es gliedert sich in die folgenden Unterkapitel zech Projektplanung 2 Anforderungen an das System 3 Simulationssystem 4 Simulator 5 Visualisierung 6 Manipulation 7 _ Testszenario 3 1 Projektplanung und Vorbereitung Das Projekt ist in drei Phasen eingeteilt In der ersten Phase findet die Einarbeitung und Vorbereitung statt Die zweite Phase besch ftigt sich mit der Umsetzung des Projekts die im Wesentlichen durch die Kapitel Simulationssystem Simulator Visualisierung und Manipula tion beschrieben werden In der letzten Phase findet die Dokumentation mit einem abschlie Benden Vortrag ber das Ergebnis statt Am Anfang des Projekts wird der genaue zeitliche Ablauf des gesamten Vorhabens nach einer kurzen Einarbeitung in das Thema in einem Projektplan siehe Abbildung 3 1 fest gehalten Nachdem sich ein gewisser berblick verschafft wurde soll in dieser Zeit auch ein Vortrag ber das zu entwickelnde Simulationssystem stattfinden Dies hat den Zweck Un Klarheiten schon zu Beginn des Projekts ausfindig zu machen und Anregungen f r die Reali sierung zu geben Die Programmierung des gesamten Quellcodes erfolgt in der
39. e assoziiert werden ODE unterst tzt sechs verschie dene Typen von Geometrie Objekten wie in der Abbildung 2 17 dargestellt Dazu geh ren Kugel Quader Zylinder Strahl Dreieck Maschen und benutzerdefinierte Geometrien Theoretische Grundlagen 36 Abbildung 2 17 Die verschiedenen Geometrien in ODE Quelle HRI Wie die Abbildung 2 18 veranschaulicht k nnen einem K rper mehrere Geometrien zuge wiesen werden Dies erlaubt die Konstruktion von wesentlich komplexeren Objekten Die Trennung von K rper und Geometrie Objekte hat dabei einige Vorteile So ist die Erstellung von unsichtbaren Objekten m glich die einem anderen Objekt wiederum als zus tzliches Gewicht hinzugef gt werden k nnen Es wird lediglich ein K rper erzeugt ohne diesem eine Geometrie zuzuweisen Umgekehrt erm glicht die Erstellung von Geometrien ohne sie ei nem K rper zuzuweisen die Erzeugung von unbeweglichen Objekten Abbildung 2 18 K rper in ODE mit mehreren Kollisionsobjekten Quelle HRI 2 5 11 Kollisionserkennung ODE besteht wie bereits erw hnt aus zwei Hauptkomponenten Zum einen aus der Biblio thek f r die Simulation der Dynamik starrer K rper und zum anderen aus der Bibliothek f r die Kollisionserkennung Die in ODE integrierte Kollisionserkennung muss nicht zwingend verwendet werden Es ist auch m glich andere Bibliotheken zu benutzen so lange sie die Theoretische Grundlagen 37 richtigen Informationen f r die zu generieren
40. ei Kugeln sehr schnell ist da lediglich die Abst nde ihrer Mittelpunkte berechnet werden m ssen Allerdings haben die meisten Objekte eine orthogonale Struktur wie z B ein W rfel so dass eine An n herung an diese Strukturen mit Kugeln bzw die H lleffizienz nicht sehr gut et Abbildung 2 5 Kugel als H llk rper Quelle Eigene Darstellung 11 Vgl Warken 2004 S 5 bzw Eckstein 1998 S 19 12 Mit H lleffizienz ist gemeint wie genau ein Objekt von einer H lle umgeben wird 13 Vgl hierzu und im Folgenden Eckstein 1998 S 27 ff Theoretische Grundlagen 22 Achsenorientierte Quader AABB Bei dem achsenorientierten Quader wird um den geometrischen K rper ein achsenparalleler Quader gelegt wie in der Abbildung 2 6 zu erkennen ist Die Quader sind dabei an den Ach sen des Koordinatensystems ausgerichtet berlappungstests k nnen auf diese Weise sehr schnell ausgef hrt werden Allerdings ist auch hier die H lleffizienz bei nicht orthogonalen Strukturen oder bei orthogonalen Strukturen die nicht an den Koordinatenachsen ausgerich tet sind nicht besonders gut Abbildung 2 6 Achsenorientierter Quader als H llk rper Quelle Eigene Darstellung Beliebig orientierte Quader OBB Dieses Verfahren funktioniert hnlich wie der Ansatz des achsenorientierten Quaders Je doch werden die Quader nicht an den Achsen des Koordinatensystems ausgerichtet son dern an den geometrischen K rper selbst siehe Abb
41. ell die M glichkeit gegeben sein eine virtuelle Welt zu konstruieren welche zun chst nur aus symbolischen Informationen besteht Dies beinhaltet die Bereit stellung von primitiven Objekten wie z B Quader Kugel oder Zylinder aus denen sich wiederum durch entsprechende Funktionalit t Gelenke komplexere Strukturen erzeugen lassen An den Objekten m ssen Kr fte angesetzt werden k nnen die bei den Objekten zu einer Bewegung bzw Beschleunigung f hren Eine Kollisionserkennung und antwort ist notwendig damit sich Objekte nicht durchdrin gen k nnen sondern aneinander abprallen bzw ansto en Es ist eine dynamische und kinematische Simulation der Objekte zu erm glichen Es muss die M glichkeit bestehen einzelne Objekte von der Simulation auszuschlie en zu deaktivieren d h dass an diesen Objekten keine Kr fte wirken Sie m ssen aber trotzdem mit den anderen Objekten interagieren k nnen Wenn z B ein an der Simulation teilhabendes Objekt auf ein nicht teilnehmendes Objekt trifft darf es dieses nicht durch dringen sondern muss auf dieses Objekt reagieren k nnen Die Manipulation von bestimmten Objekten wie z B das ndern von Position Kr ften Geschwindigkeit usw ist von au en durch geeignete Schnittstellen bereitzustellen Der Status einzelner Objekte in der Simulation wie z B Position angreifende Kr fte Geschwindigkeit usw muss abfragbar sein Entwicklung eines Software Simula
42. elle Um gebung f r den simulierten Roboter zu erzeugen und diese beiden Komponenten miteinan der zu koppeln 1 4 Aufbau der Arbeit Das 2 Kapitel geht auf die theoretischen Grundlagen der in dieser Arbeit angewandten Kon zepte ein Zun chst werden wesentliche Definitionen aufgef hrt die im Zusammenhang mit dieser Arbeit stehen Danach wird die Mechanik starrer K rper erl utert und die g ngigsten Verfahren zur Kollisionserkennung beschrieben Der n chste Abschnitt stellt anschlie end die zur Verf gung stehenden Physik Engines vor und beschreibt die letztendlich eingesetzte ODE Bibliothek zur Simulation der Dynamik Der letzte Abschnitt dieses Kapitels befasst sich mit dem Visualisierungsprogramm ViToSA In Kapitel 3 wird schlie lich die Umsetzung der Masterarbeit beschrieben Nach der Planung des Projekts folgen die Anforderungen an das Gesamtsystem bzw an die einzelnen Kompo nenten Daraufhin wird das Simulationssystem als Ganzes beschrieben und im Anschluss daran die einzelnen Module Simulator Benutzerschnittstelle und Visualisierung genauer be trachtet Am Ende des Kapitels folgt die Beschreibung des Testszenarios Im abschlie enden 4 Kapitel werden die Ergebnisse zusammengefasst entstandene Prob leme besprochen und ein Ausblick f r die weitere Entwicklung gegeben Theoretische Grundlagen 14 2 Theoretische Grundlagen 2 1 Definitionen Dieses Kapitel soll grundlegende Begriffe kurz beschreiben und somit eine
43. en Zum Schluss ist die Kolli sionswelt mit den entsprechenden Geometrien f r die einzelnen K rper zu erzeugen Diese sind noch den K rpern zuzuweisen Bevor nun die Simulationsschleife aufgerufen wird muss noch eine Gelenkgruppe f r die Kontakt Gelenke spezifiziert werden Auf der rechten Seite der Abbildung wird der Ablauf der Simulationsschleife dargestellt Hier k nnen z B Kr fte auf die K rper addiert werden Im n chsten Schritt findet die Kollisions Theoretische Grundlagen 41 erkennung statt Auf Basis der Kollisionserkennung werden zwischen den K rpern die sich ber hren oder zwischen K rpern und der statischen Umgebung Kontakte erstellt so dass sie sich nicht durchdringen k nnen Anschlie end wird der eigentliche Simulationsschritt ausgef hrt und die Dynamik der K rper berechnet Am Ende m ssen alle Kontaktverbindun gen wieder gel scht werden 2 5 13 Simulationsprogramm Dieser Abschnitt soll kurz den generellen Aufbau eines Simulationsprogramms in ODE do kumentieren Zun chst wird in der Main Funktion die virtuelle Welt mit allen darin enthalte nen Objekten erzeugt Dazu geh rt die Erstellung einer Kollisionswelt mit den entsprechen den Kollisionsobjekten und die Verbindung der K rper mit Gelenken An dieser Stelle k nnen auch verschieden Einstellungen vorgenommen werden wie z B das Einstellen einer allge meinen Gravitationskraft die in der Welt auf alle Objekte wirken soll Nach der Konstrukt
44. er nderungen und Deformationen wenn er bspw rotiert Deformationen wiederum verteilen die Masse eines K rpers neu und w rden die Bewegung nur noch weiter verkomplizieren Daher wird der starre K rper als ein Ersatz f r die Realit t benutzt der so zusagen nur ein idealisiertes Modell der theoretischen Physik ist Ein starrer K rper besitzt 6 Freiheitsgrade Diese geben an wie viele von einander unab h ngige Bewegungen ein starrer K rper durchf hren kann Dazu geh ren die drei Freiheits grade der Translation also die Bewegung in den drei r umlichen Dimensionen L nge Breite und H he sowie die drei Freiheitsgrade der Rotation also die Drehung um die x y und z Achse Die Lage des K rpers ist festgelegt durch Angabe von drei Punkten Um die Hand Vgl Gross Hauger Schnell 1998 S 1 f Vgl Honerkamp R mer 1989 S 81 Theoretische Grundlagen 16 habung der Bewegungen eines starren K rpers zu vereinfachen wird die Translations und Rotationsbewegung jeweils einzeln behandelt F r die Bewegung eines starren K rpers ist ein geeignetes Koordinatensystem n tig Dieses ist fest und kann weder verschoben noch rotiert werden Inertialsystem Es symbolisiert so mit den Welt Raum Um die Bewegungen eines K rpers einfacher zu beschreiben wird ein zus tzliches k rperfestes Koordinatensystem mit dem K rper assoziiert wie in der Abbil dung 2 1 grafisch dargestellt Dieses Koordinatensystem hat seinen Ursprung i
45. erbar bzw manipulierbar sein Das hei t es muss m gliche sein ber ein entsprechendes Eingabeger t wie z B eine Space Maus oder einfach ber die Tastatur mit der virtuellen Welt zu inter agieren indem Objektpositionen und andere Objekteigenschaften ver ndert werden k nnen Die Visualisierung der virtuellen Welt soll mit dem vom HRI entwickelten Grafikprogramm ViToSA Visualisation Tool for Simulation Applications erfolgen Um dies zu erm glichen ist ein Plug In zu konzipieren und zu implementieren F r das Testen des Simulationssystems sind zwei unterschiedliche Regelkreise Closed Loops mit dem vom HRI verwendeten Komponenten Integrationsmodell vorgesehen Der erste einfachere Regelkreis siehe Abbildung 1 1 besteht aus den zwei Komponenten Simu lator und Robot Control Die bereits bestehende Komponente Robot Control simuliert den Roboter Die Simulator Komponente ist im Rahmen dieser Arbeit zu implementieren und soll die virtuelle Welt also die Umgebung des Roboters simulieren Sie generiert symbolische Informationen von der virtuellen Umgebung und bergibt diese an die Robot Control Kompo nente Symbolische Informationen k nnen z B die Koordinaten des Massenschwerpunktes eines starren K rpers sein Die Robot Control Komponente kann auf Basis dieser Daten wiederum nderungen in der virtuellen Welt vornehmen So k nnte z B die Simulator Kom ponente ein Tisch auf dem sich mehrere Objekte befinden simulieren und di
46. erbindung von K rper Objekten Es ist eine Beziehung bzw Bedin gung die zwischen zwei K rpern aufgestellt wird Dadurch k nnen diese zwei K rper nur bestimmte Positionen und Orientierungen zueinander haben Die folgenden Gelenktypen werden von ODE bereitgestellt Kugel Gelenk Scharnier Gelenk Schiebe Gelenk Univer sal Gelenk Scharnier Typ2 Gelenk Kontakt Gelenk Es gibt noch zwei weitere Gelenktypen das Fixier Gelenk und das Motor Gelenk die aber nur in Spezialf llen zum Einsatz kommen Im Folgenden sind die wichtigsten dieser Gelenke beschrieben Kugel Gelenk Die Abbildung 2 12 zeigt die Verbindung von zwei K rpern durch ein Kugelgelenk Die bei den K rper k nnen jegliche Position zueinander einnehmen solange die Kugel des ersten K rpers sich in der Fassung des zweiten K rpers befindet Abbildung 2 12 Kugel Gelenk Quelle ODE User Guide Scharnier Gelenk Die Abbildung 2 13 zeigt die Verbindung von zwei K rpern ber ein Scharniergelenk Dieses Gelenk bedingt dass sich beide K rper in derselben Position zueinander befinden und sich nur entlang der Scharnierachse bewegen k nnen Body 1 Anchor Body 2 Abbildung 2 13 Scharnier Gelenk Quelle ODE User Guide Theoretische Grundlagen 32 Schiebe Gelenk Die Abbildung 2 14 zeigt die Verbindung von zwei K rpern durch ein Schiebegelenk Dieses Gelenk bedingt dass die beiden Objekte sich nur entlang einer Achse bewegen und die glei che Orientierung zue
47. ere Registerkarten die jede f r sich verschiedene Einstellungsm g lichkeiten bietet ber die erste Registerkarte Converters lassen sich alle zur Verf gung stehenden Konverter in das Programm laden entfernen und konfigurieren Die n chste Re gisterkarte Viewer stellt Funktionen f r das Betrachtungsfenster bereit wie z B die Anzeige von Schatten Achsen Raster usw Der Abschnitt Camera bietet Funktionen f r die Kamera einstellung wie z B die Ansicht der Szene aus vordefinierten Positionen wie Top Front 3D usw Der Szene k nnen hier auch weitere Kameras an selbst definierten Positionen hinzu gef gt werden Filter ist die Registerkarte die in der Abbildung 2 20 angezeigt wird In die ser Ansicht werden alle Objekte der Szene in einer Baum Struktur mit Angabe der Position aufgef hrt Der Bereich Measurements bietet eine Funktion mit der Abst nde zwischen ausgew hlten Objekten aus der Szene gemessen werden k nnen ber das letzte Fenster k nnen einzelne Bilder oder Bildsequenzen von der Szene generiert werden Robot is standing Heel frame is converged Time 372 06 Abbildung 2 20 Screenshot von ViToSA Quelle HRI Internal Report M M hlig 2006 Die Anbindung von externen Programmen an ViToSA wird durch das Konzept eines Konver ters erm glicht Ein Konverter ist ein in QT erstelltes Plug In der die anwendungsspezifi schen Daten in entsprechende Nachrichten f r ViToSA umwandelt ViToSA verwendet intern eine
48. erpr fen dass die spezifizierte Objekt ID auch wirklich einen existierenden K rper in der Simulation zugeordnet werden kann Wenn auch das zutrifft werden die Daten entsprechend den nderungs Flags mit den angegebenen Daten modifiziert 3 6 Visualisierung Die Visualisierung der Simulation erfolgt mit dem im Kapitel 2 6 beschriebenen Programm ViToSA Auch hier wird die Kommunikation zwischen dem Visualisierungsprogramm und dem Simulator anhand der SHM Schnittstelle beschrieben Die Kommunikation ist aber auch ber die Socket Schnittstelle m glich Entwicklung eines Software Simulationssystems 61 Der Informationsaustausch erfolgt mittels einer speziell daf r entworfenen Datenstruktur SharedDataVisualisation siehe Kapitel 3 3 4 hnlich wie bei der Manipulation Diese Da tenstruktur definiert alle n tigen Informationen die f r die Visualisierung eines Objekts erfor derlich sind ber diese Struktur findet auch die angeforderte Statusabfrage von K rpern in der virtuellen Welt statt wie z B die aktuelle Position oder Geschwindigkeit eines Objekts Die Abbildung 3 5 im Kapitel 3 3 3 macht den Prozess der Kommunikation grafisch deutlich Der Ablauf der Visualisierung kann nun wie folgt beschrieben werden F r jeden an der Si mulation teilnehmenden K rper wird eine Instanz also ein Datenobjekt der Datenstruktur SharedDataVisualisation erzeugt und in einem Daten Array gespeichert Nach jedem Simu lationsschritt werden vom Sim
49. errn Prof Dr Peter Nauth Auf diesem Wege m chte ich mich auch bei Frau Dipl Kff Swenja Kaschel f r Ihre Unter st tzung bedanken Mirko Radowitz Inhaltsverzeichnis V Inhaltsverzeichnis ETKIALUNO EE 1 1 INHIAISVELZEICHNI Sa a ae Eee ae V leie elle een VI ADKUFZUNGSVETZEIEHN IS na ee ne era ehe ee IX d ENGNG era Eege ere 10 1 1 Das Honda Research Institute Europe 10 12 Movatn EEN 10 1 3 Aufgabenstellung und Zielsetzung nennen nennen nennen 11 E WR te Ree EN 13 2 Theoretische Grundlagen ara 14 NIR gie len EE 14 2 1 1 ln e Serena ee nie 14 CN SimUulallonsprogramm ensure 14 Zell SSL TOR E 14 214 Regelung Regelkreis anne ia 14 2 2 Mechanik SIArer Kopel EE 15 2 2 1 Der stare ee 15 2 2 2 Kinematik des stamrenbkorpers 16 2 2 3 Dynamik Kr fte und Drehmmomente Axe 19 23 KOLISIORSETKENNUNdG EE 20 2 3 1 EE 21 2 32 HUIKOTBEFNIEFAECHIER a s Eee 23 293 E EI ee E BE 24 2 3 4 Basisk llisionserkennung a 25 2 SENYSIGENGNES une een eek 25 20 Open Dynamics Engine een re 26 2 5 1 SPUK Ur VON ODE ser ee ee 27 e E E 29 2 98 DOEK ODO Eee ee 30 2 5 4 RE 31 VI e De ONE een TEE 33 29 6 NVEICHE BEUINAUNgEN tee ed 34 25 7 Einsatz Von GCFM nd ERP rennen 34 2 9 8 REDIN E 35 2 5 9 KOlISIONSIAUMEr EE 35 2 5 10 DIEGeometrie Objekten ei 35 2 5 11 KOlllSIONSEIKENNUNG aan 36 25 12 Sim lation Bee e e EE 39 2 5 13 SImUulallonsprogfammeuseke ee 41 26 VOSA nee se ee 41 3 Entwicklung eines Gotbware
50. es Flag gesetzt kann dem K rper noch ein Kollisionsobjekt hinzugef gt wer den wodurch sich auch etwas komplexere Objekte erstellen lassen Wenn das Flag gesetzt ist muss Typ Offset Position und Gr e des zus tzlichen Kollisionsobjekts angegeben wer den OBJEKT_START Model CUBE Position 111 Size 0 5 0 5 0 5 Force 000 Torque 000 AddGeom 0 OBJEKT_END OBJEKT_START Model CUBE Position 222 Size 0 5 0 5 0 5 Force 000 Torque 000 AddGeom 1 Geom OffsetType CUBE Geom OffsetPos 0 200 GeomOffsetSize 0 2 0 2 0 2 OBJEKT END OBJEKT_START Model CYLINDER Position 1 1 1 Size 0 500 Force 000 Torque 000 AddGeom 0 OBJEKT_END OBJEKT_START Model SPHERE Position 1 1 1 Size 0 500 Force 000 AddGeom 0 OBJEKT END Anhang LXX Anhang 2 Simulator Code Der nachfolgende Code zeigt ein Beispiel f r einen ganz einfachen Simulator Daf r wird eine Welt und ein K rper erstellt Die Welt hat bei der Initialisierung standardm ig eine Gra vitationskraft von 0 0 9 81 Als K rper wird ein Quader mit einer Seitenl nge 1 1 1 der Position 0 0 0 und der Masse 1 erzeugt Als Motion mode wird hier eine 0 bergeben d h der K rper wird im dynamischen Modus gestartet anstatt im Kinematik Modus Anschlie Bend wird die Simulationsschleife aufgerufen Hier wird zu dem K rper in jedem Durchgang eine Kraft addiert und danach ein Simulationsschritt durchgef hrt Anschlie end erfolgt die Visualisierun
51. fordert zur zeit noch die direkte Programmierung im Simulatorcode Im Anhang 1 befindet sich eine Bei spiel Konfigurationsdatei F r die Umsetzung der Textdatei ist ein Parser im Simulator zu st ndig Dieser wandelt die in der Datei spezifizierten Objekte in die entsprechenden K rper und Geometrien um Mit Hilfe der Schnittstellen Shared Memory oder Sockets kann der Si mulator nun mit externen Anwendungen wie z B einer HRI Komponente oder einer einfa chen Anwendung kommunizieren gt Virtuelle Welt l Dynamik Welt Kollisions Welt l I d D 1 Yen l l Ausgabe Eingabe Schnittstelle l Schnittstelle SHM Sockets EEN SHM Sockets API Simulations Bibliothek HSimL i KS I 1 l 1 t Parser Simulator l l a I 1 V 1 d Q a d Konfig Datei Abbildung 3 6 Architektur des Simulators Quelle Eigene Darstellung 3 4 2 Implementierung Die Implementierung der Simulations Bibliothek HSimL HRI Simulation Library erfolgt nach den HRI Richtlinien Wie bereits an anderer Stelle erw hnt ist die Simulations Bibliothek ein Wrapper um die ODE Bibliothek An dieser Stelle soll nur der generelle Aufbau der API auf gezeigt werden Eine vollst ndige Dokumentation aller Funktionen wurde mit Doxygen er stellt und kann aufgrund des gro en Umfangs hier nicht angegeben werden Die API teilt sich in mehrere verschiedene Definitionsdateien
52. g der virtuellen Welt Nach beenden der Simulationsschleife ist die Welt noch zu bereinigen include lt HS5imL hr int mainlint argc char argwo i HWorld simWlor ld HEody hbodY double size 3 f double position gt s double force gt LE Ar i D k H Ug H 43 i 0 2 0 H Z Create virtual world simWorld HWorld neut j HWorld initi simWorld Z create and init body body HBody_newi HBody init Body World Mass Type Size Position Hotion mode Hbody jiniti body Simllorld 1 CUBE size position DI Z Simulation loop whilel 1 i HEody addForce body force j HWorld stepi simWorld visualisationl f eleaning the world HBody_cleari body HEody deletei body HWorld clear simWorld Hor IO deiere simWorld j return O
53. ildung 2 7 Dadurch wird die H lleffi zienz stark verst rkt Allerdings sind die Kollisionstests wesentlich aufwendiger als bei den Kugeln und achsenorientierten Quadern 14 Vgl Eckstein 1998 S 27 ff Theoretische Grundlagen 23 Abbildung 2 7 Beliebig orientierter Quader Quelle Eigene Darstellung Konvexe Polyeder beschr nkter Richtung K DOP Dieses Verfahren hnelt dem Ansatz der achsenorientierten Quadern jedoch mit dem Un terschied dass es mehrere Beschr nkungsfl chen gibt Somit hat dieses Verfahren eine wesentlich bessere H lleffizienz Bei Bewegungen ist die Berechnung der Endlage allerdings wesentlich aufwendiger 2 3 2 H llk rperhierarchien Durch die Verwendung von H llk rpern k nnen berlappungstests schon wesentlich be schleunigt werden Eine weitere M glichkeit die Kollisionserkennung zu verbessern ist die Verwendung von H llk rperhierarchien d h ein geometrisches Objekt in einen Baum von immer kleiner werdenden H llk rpern aufzugliedern Dabei wird das gesamte Objekt zu n chst durch einen H llk rper umgeben Anschlie end wird der H llk rper in zwei weitere kleinere H llk rper aufgeteilt Dieser Vorgang kann immer weiter gef hrt werden Somit k n nen gro e Teile schon ziemlich fr h von einer Kollision ausgeschlossen werden Die ber pr fung auf Kollisionen beginnt bei der Wurzel Wenn eine Kollision erkannt wurde wird die n chst tiefere Stufe in der Hierarchie betra
54. in kleiner Nachteil der Visualisierung mit ViToSA ist dass es versucht alle K rper im Sichtfeld des Benutzers zu behalten Die Folge davon ist dass ViToSA den Sichtbereich immer weiter vergr ert falls sich ein K rper z B von Zentrum weg bewegt F r die interaktive Manipulation der Simulation wurde eine kleine Anwendung Benutzer schnittstelle implementiert ber die eine textbasierte Eingabe mittels der Tastatur die virtu elle Welt manipuliert werden kann In einem weiteren Schritt w re die Benutzerschnittstelle um die Interaktion mit einer Space Mouse noch zu erweitern Die Entwicklung und Dokumentation des Projekts hat aus Zeitgr nden parallel stattgefunden Literaturverzeichnis LXVIII Literaturverzeichnis Brause R 2004 Betriebssysteme Grundlagen und Konzepte 3 berarbeitete Auflage Berlin 2004 Baraff D 1997 An Introduction to Physically Based Modeling Rigid Body Simulation I Unconstrained Rigid Body Dynamics online verf gbar unter www cs edu baraff pbm pbm html 2006 Dreizler R M L dde C S 2003 Theoretische Physik 1 Theoretische Mechanik Ber lin Heidelberg 2003 Eckstein J 1998 Echtzeitf hige Kollisionserkennung f r Virtual Reality Anwendungen Dissertation Technische Fakult t der Universit t des Saarlandes 1998 Gross D Hauger W Schnell W 1998 Technische Mechanik 1 Statik 6 Auflage Berlin 1998 Honda Research Institute Eu
55. inander haben Abbildung 2 14 Schiebe Gelenk Quelle ODE User Guide Die Abbildung 2 15 veranschaulicht die drei Gelenktypen Universal Gelenk Scharnier Typ2 Gelenk und ein Kontakt Gelenk Normal Contact point Abbildung 2 15 Universal Schanier Typ2 und Kontakt Gelenk Quelle ODE User Guide Bei jedem Simulationsschritt ist es den Gelenken m glich Kr fte auf die mit ihnen verbun denen K rper zu bertragen So k nnen bei einer Bewegung des K rpers die Gelenkbedin gungen eingehalten werden Die Abbildung 2 16 macht dieses Prinzip deutlich Dort sind zwei K rper mit einem Gelenk verbunden Falls sich die K rper w hrend eines Simulations schritts auseinander bewegen ist es dem Gelenk durch eine Kraft m glich dagegen zu wir ken Jedes Gelenk besitzt mehrere Parameter um z B die Position des Gelenks zu bestimmen Die Parameter beziehen sich auf globale und nicht k rperbezogene Koordinaten Daher m ssen die K rper bevor sie mit einem Gelenk verbunden werden zuerst in die richtige Posi tion gebracht werden Theoretische Grundlagen 33 F r die leichtere Handhabung von Kontakt Gelenken die bei der Kollisionserkennung immer wieder neu entstehen gibt es eine spezielle Gelenkgruppe Dieser Gruppe werden alle Kon takt Gelenke zugeordnet damit sie nach jedem Simulationsschritt mit nur einem Funktions aufruf wieder gel scht werden k nnen 2 5 5 Gelenkfehler Wenn ein Gelenk zwei K rper verbindet
56. inem Quader der den gesamten Raum enth lt In der n chsten Stufe wird der Quader weiter aufgeteilt Dabei ist die Aufteilung von dem verwendeten Verfahren abh ngig Der Oktree z B teilt in jeder n chsten Stufe den Quader in acht kleinere Quader auf Beim Quadtree entsprechend in vier kleinere Quader Es m s sen jetzt nur die Quader untersucht werden in denen sich Objekte befinden Der Vorteil zu der uniformen Raumaufteilung ist dass die Zellengr e der Quader an die Gr e der Objek te angepasst ist Allerdings erh ht sich der Aufwand die Struktur zu aktualisieren wenn sich Objekte bewegen 16 Vgl Eckstein 1998 S 25 ff 1 Vgl hierzu und im Folgenden Eckstein 1998 S 129 ff 18 Vgl Eckstein 1998 S 130 ff Theoretische Grundlagen 25 BSP Trees Bei diesem Verfahren wird der Raum durch Fl chen von Polygonen aufgeteilt Die Fl chen werden in einem bin ren Baum eingeordnet Jeder Knoten des Baums speichert die Ebene einer Fl che die den Raum weiter aufteilt 2 3 4 Basiskollisionserkennung Wie in den vorherigen Kapiteln schon beschrieben kann durch die Verwendung von be stimmten Algorithmen die Anzahl der zu untersuchenden Objektpaare verkleinert werden Kommt es aber tats chlich zu Kollisionen zwischen Objekten m ssen diese mit den Basis kollisionsalgorithmen getestet werden Hierbei wird berpr ft ob sich zwei Fl chenmengen schneiden Dies ist genau dann der Fall wenn es eine Kante oder Ecke de
57. ion der virtuellen Welt wird der Grafikroutine die Simulationsroutine als Funktionszeiger bergeben Die Grafik Bibliothek ist nun daf r verantwortlich dass in be stimmten Intervallen die Simulationsberechnung immer wieder aufgerufen wird Innerhalb dieser Simulationsroutine erfolgt auch die Abfrage ob es in der Simulation zu Kollisionen gekommen ist Im Fall einer m glichen Kollision wird die Callback Funktion aufgerufen in der die eigentliche Kollisionsbehandlung stattfindet Nach der Behandlung von Kollisionen wird nun der eigentliche Simulationsschritt ausgef hrt in der die Berechnung der Dynamik erfolgt Die Simulation wird solange durchgef hrt bis der Benutzer sie durch ein bestimmtes Abbruchkriterium beendet 2 6 ViToSA Die Simulation der Dynamik von starren K rpern soll durch eine unabh ngige Anwendung visualisiert werden Dies erfolgt mit dem Programm ViToSA Visualisation Tool for Simulati on Applications ein Werkzeug f r die Visualisierung von 3D Informationen Das Programm ist eine von HRI entwickelte Anwendung die in Qt erstellt wurde und als allgemeines 3D Visualisierungswerkzeug dient Ein wesentliches Merkmal von ViToSA ist die Erweiterbarkeit des Programms Qt ist eine Softwarebibliothek von Trolltech f r die Erstellung von grafischen Benutzeroberfl chen unter C Theoretische Grundlagen 42 Die Abbildung 2 20 zeigt einen Screenshot des Programms Im unteren Bereich der Abbil dung befinden sich mehr
58. leife mit SHM SHM Manipulation auslesen Simulator beenden Simulationsdaten modifizieren Kollisionserkennung durchf hren Simulationsschritt durchf hren Visualisierungsdaten in SHM Visualisierung schreiben Abbildung 3 11 Programmablauf der Simulationsschleife Quelle Eigene Darstellung Nach Beendigung der Kollisionserkennung wird der eigentliche Simulationsschritt ausgef hrt und anschlie end die symbolischen Informationen an die Visualisierung bergeben indem sie in den Shared Memory der Visualisierungs Schnittstelle geschrieben werden Entwicklung eines Software Simulationssystems 59 3 4 4 Testszenarios Die hier beschriebenen Testszenarios haben den Zweck die implementierte API zu testen Dabei wird berpr ft ob die Funktionen in der Simulation das richtige Verhalten aufzeigen und die richtigen R ckgabewerte liefern Die Verifizierung der API HSimL Bibliothek erfolgt durch die Erstellung von Testprogram men die sich an die Struktur der ODE Simulationsprogramme anlehnen siehe Kapitel 2 5 13 Auch die Visualisierung der Tests erfolgt der Einfachheit halber mit der in ODE ent haltenen Grafik Bibliothek Drawstuff Erst in einem sp teren Schritt wird f r die Visualisie rung das Grafikprogramm von HRI eingesetzt In den generierten Testszenarios sollen die einzelnen Funktionen der API auf ihre richtige Funktionsf higkeit berpr ft werden Daf r werden aufgrund des gro en Umfang
59. lisionserkennung durchgef hrt Zwei spezielle Umst nde stellen die Kollisionserkennung vor eine besondere Herausforde rung Eine Gro e Anzahl an Objekten und geometrisch komplexe Objekte Hier kann die Anwendung von r umlichen Datenstrukturen die Kollisionserkennung beschleunigen Zum einen ist es m glich bei einer gro en Anzahl an Objekten eine Raumpartitionierung anzu wenden Zum anderen kann die besonders schwierige Handhabung von geometrisch kom plexen Objekten durch H llk rper bzw H llk rper Hierarchien optimiert werden Die Kollisionserkennung kann in eine statische und in eine dynamische Kollisionserkennung eingeteilt werden Die statische Kollisionserkennung entscheidet ob sich nicht bewegende 1 vgl Eckstein 1998 S 95 Theoretische Grundlagen 21 Objekte berschneiden w hrend bei der dynamischen Kollisionserkennung berpr ft wird ob sich bewegende Objekte schneiden 2 3 1 H llk rper Die Verwendung von H llk rpern vereinfachen komplexe geometrische Strukturen Dadurch lassen sich die Anwendungen von komplizierten Algorithmen wesentlich beschr nken Hier f r stehen mehrere verschiedene Ans tze die wiederum verschieden H llk rper verwenden zur Verf gung Im Folgenden sollen die wichtigsten von ihnen aufgef hrt werden Kugel Der geometrische K rper wird durch eine Kugel umgeben wie in der Abbildung 2 5 darge stellt Kugeln haben den Vorteil dass der Test auf Kollisionen zwischen zw
60. lisionsraum ist ein spezielles Geometrie Objekt Es kann als ein Beh lter angesehen werden indem sich weitere Geometrie Objekte befinden Somit hnelt es sehr dem Welt Objekt bei der Simulation der Dynamik nur mit dem Unterschied das hier keine Dynamik sondern Kollisionen simuliert werden Die Kollisionsr ume wurden eingef hrt um die Kollisi onserkennung zu beschleunigen siehe Kapitel 2 3 Ohne diese R ume m ssten alle Ob jektpaare die in der Welt bestehen berpr ft werden ob sie sich gegenseitig ber hren Da mit ist bei einer hohen Anzahl von Objekten ein sehr gro er Rechenaufwand verbunden Eine bessere Vorgehensweise ist jede Geometrie einem Kollisionsraum hinzuzuf gen und dann eine Kollisionserkennung davon abh ngig zu machen in welchem Kollisionsraum es sich befindet 2 5 10 Die Geometrie Objekte Die Kollisionserkennung basiert vor allem auf den Geometrie Objekten Sie bestimmen die Form und Gestalt eines K rpers und haben im Gegensatz zu starren K rpern keine dynami schen Eigenschaften wie z B Masse oder Geschwindigkeit sondern geometrische Werte wie Gr e Position Form usw Es gibt zwei verschiedene Arten von Geometrie Objekten Diejenigen die Ihre Orientierung und Position w hrend der Simulation ver ndern k nnen und solche die das nicht k nnen wie z B die statische Umgebung Um die Kollisionserkennung in der Dynamik Simulation zu verwenden muss das Geometrie Objekt mit einem starren K per Objekt
61. lle Welt von au en mani pulieren muss eine geeignete Schnittstelle bereitgestellt werden damit ein Informationsaus tausch zwischen den entsprechenden Prozessen stattfinden kann Generell stehen mehrere Alternativen zur Verf gung wie Shared Memory SHM Sockets Pipes Queues FiFo usw SHM bietet dabei die wohl schnellste bertragung von gr eren Datenmengen wohingegen Sockets die Kommunikation auf mehreren verteilten Rechnern erm glicht Aufgrund der Vor teile die SHM und Sockets bieten wurden beide Varianten parallel implementiert um somit den Anwendern einen gr eren Handlungsspielraum zu geben Die ben tigten Informationen die zwischen der Visualisierung und Simulation bzw zwischen Manipulation und Simulation ausgetauscht werden m ssen sind daf r in zwei speziellen Datenstrukturen festgehalten Nur ber diese Datenstrukturen ist die Interprozess Kommunikation zwischen den einzelnen Komponenten m glich Die Datenstrukturen m s sen allen beteiligten Kommunikationspartnern bekannt sein Im Folgenden wird zun chst auf die beiden Schnittstellen SHM und Sockets n her einge gangen und danach werden die beiden implementierten Datenstrukturen beschrieben Shared Memory SHM Schnittstelle Shared Memory ist ein vom Betriebssystem verwalteter Speicherbereich der von mehreren Prozessen gelesen und beschrieben werden kann Die Prozesse m ssen sich aber unter einander abgleichen also synchronisieren damit nicht mehr al
62. lliertere Beschreibung der Funktionsweise von ODE l sst sich dort nachlesen 21 Siehe Smith 2006 http www q12 org Siehe ODE Homepage http www ode org 2006 3 Siehe ODE User Guide http www ode org 2006 Theoretische Grundlagen 27 Abbildung 2 8 Simulation von zwei miteinander verbundenen K rpern Quelle HRI 2 5 1 Struktur von ODE ODE definiert f r die Simulation starrer K rper und f r die Kollisionserkennung f nf verschie dene Objekte die in der Abbildung 2 9 schematisch dargestellt sind Gelenke K rper Kollisions Raum Geometrie Abbildung 2 9 Schematische Darstellung der Objektstruktur in ODE Quelle Eigene Darstellung Das Objekt Welt ist die u ere H lle die alle anderen Objekte einschlie t In der Welt befin den sich die K rper die ber Gelenke miteinander verbunden werden k nnen Ein K rper definiert in ODE nur die dynamischen Eigenschaften wie z B Geschwindigkeit Masse usw eines physikalischen Objekts Es werden keine Aussagen ber die Form und das Aus Theoretische Grundlagen 28 sehen gemacht Daf r wird jedem K rper eine Geometrie zugewiesen was zum einen die u ere Form des K rpers definiert und zum anderen f r die Kollisionserkennung n tig ist Es ist m glich die Welt in mehrere Kollisionsr ume aufzugliedern siehe Kapitel 2 3 3 um eine Optimierung der Kollisionserkennung zu erreichen Ein Kollisionsraum besteht dabei aus mehreren Geometrie O
63. m Zentrum des K rpers R Schwerpunkt 2 d K Mir R Ort des Massenmittelpunktes M gt m m Massenelement r Radius des Massenelements Dieser k rperbezogene fixe Schwerpunkt R vereinfacht den Umgang mit der Bewegung eines starren K rpers Inertialsystem Abbildung 2 1 Starrer K rper mit lokalem Koordinatensystem Quelle Eigene Darstellung 2 2 2 Kinematik des starren K rpers Translationsbewegung Translation nennt man eine Bewegung bei der die Verbindungsstrecke zwischen zwei be liebigen Punkten A und B eines K rpers ihre Richtung nicht ndert Alle Punkte erfahren Theoretische Grundlagen 17 dann in der Zeit dr die gleiche Verschiebung dr Damit sind auch die Geschwindigkeiten v und die Beschleunigungen a f r alle Punkte des K rpers gleich dr dv d r y SE d dt dt dt Die Bahnkurven die von verschiedenen K rperpunkten durchlaufen werden haben alle die gleiche Form Bei der Translation ist demnach die Bewegung eines beliebigen K rperpunk tes repr sentativ f r die Bewegung des ganzen K rpers Die Abbildung 2 2 macht die Translation anhand einer Grafischen Darstellung deutlich Abbildung 2 2 Darstellung einer Translationsbewegung Quelle Eigene Darstellung Rotationsbewegung Bei einer Rotation bewegen sich alle Punkte des K rpers um eine gemeinsame Drehachse Ist die Lage dieser Achse im Raum unver nderlich so spricht man von einer Ro
64. n der n chste Integrationsschritt erfolgt wird die Summe aller Kr fte auf den K r per angewendet Anschlie end wird der Kr ftespeicher wieder gel scht Die Abbildung 2 19 zeigt den generellen Aufbau einer Simulations und Kollisionswelt sowie den genauen Ablauf der Dynamik Simulation Aufbau der virtuellen Welt Ablauf der Simulationsschleife Welt erstellen und Parameter konfigurieren Kr fte auf K rper K rper erstellen und anwenden im Raum positionieren Gelenke erstellen und Se K rper verbinden Kollisionserkennung Masse Massenverteil erstellen und K rper Erstellen von zuweisen Kontakten Kollisionswelt erstellen und der Welt zuordnen Simulations schritt Geometrien erstellen und den K rpern zuordnen Kontakte l schen Kontaktgruppe erstellen und Simulationsschleife aufrufen 3 Abbildung 2 19 Aufbau und Ablauf einer Simulation in ODE Quelle Eigene Darstellung Auf der linken Seite der Abbildung 2 19 wird der Aufbau der virtuellen Welt dargestellt Am Anfang werden zun chst die Welt und danach die einzelnen K rper erstellt In der Welt las sen sich nun Parameter wie z B die ERP und CFM Werte einstellen und eine allgemeine Gravitationskraft spezifizieren F r die K rper muss eine Masse und eine Massenverteilung sowie die Position im Raum angegeben werden Anschlie end k nnen die Gelenke zur Ver bindung der K rper angelegt und entsprechend eingestellt werd
65. nder zu verbergen Bei der Einbindung der Kollisionserkennung gab es hier aber erhebliche Probleme Diese erfolgt bei ODE n m lich ber eine Callback Funktion die erst im Anwendungsprogramm Simulator spezifiziert und als Funktionszeiger bergeben wird Diese Funktion erwartet ODE spezifische Parame ter die nicht durch ein Casting umzuwandeln sind Daher wurde hier zun chst direkt auf den ODE Code zur ckgegriffen Gewiss w re es m glich den frei zug nglichen ODE Code zu modifizieren und somit auch diese Callback Funktion abzu ndern Nachteilig w re aber dass f r jedes neue Release von ODE diese nderungen wiederholt werden m ssten Das Problem wurde im Endeffekt gel st indem die Kollisionserkennung einfach fest in die Biblio thek implementiert wurde Dadurch kann die Kollisionserkennung zwar nicht mehr ohne eine Neu bersetzung der Bibliothek konfiguriert werden aber der Anwender braucht sich daf r auch nicht mehr um die Kollisionserkennung zu k mmern Die Visualisierung und Manipulation sind wie gefordert unabh ngig von der eigentlichen Si mulation mittels eines geeigneten Interface realisiert Tats chlich wurden zwei verschiedene Schnittstellen f r die Kommunikation zwischen den einzelnen Komponenten ViToSA Mani pulation und Simulator implementiert Der Informationsaustausch kann entweder ber Sha red Memory oder aber mit Hilfe von Sockets erfolgen Die Umsetzung von zwei unterschied lichen Modellen war zwar nicht Teil
66. ng 2 16 Funktionsweise des Error Reduction Parameters Quelle Eigene Darstellung 2 5 6 Weiche Bedingungen Die Bedingungen die durch ein Gelenk zwischen zwei K rpern aufgestellt werden sind fest und d rfen nicht gebrochen werden Es ist aber in manchen F llen n tig dass die Gelenke nicht vollkommen starr sind sondern einen elastischen Charakter aufweisen Dies ist z B bei Kontakt Gelenken von Vorteil bei denen die Kollisionsfl che nachgeben soll um etwa weiches Material zu simulieren Daf r gibt es neben dem ERP den CFM Parameter Constraint Force Mixing durch den die Starrheit des Gelenks bestimmt wird Ein Wert von 0 bedeutet dass die Bedingung hart ist Ein positiver Wert erm glicht dass die Bedingung bertreten werden darf 2 5 7 Einsatz von CFM und ERP Die Kombinationen des CFM und ERP Parameters macht es m glich verschiedene Effekte zu erreichen So kann z B jede gew nschte Feder D mpfungs Bedingung in einem Gelenk nach den folgenden Formeln berechnet werden h k ERP h k k 1 CFM h k k k Federkonstante k D mpfungskonstante h Schrittgr e Theoretische Grundlagen 35 2 5 8 Reibung ODE unterst tzt die Modellierung von Reibung an Kontaktpunkten Daf r verwendet es das einfache Reibungsmodell von Coulomb Die Regel lautet E lt u lE Wobei F die Tangentialkraft und F die Normalkraft ist u ist der Reibungskoeffizient 2 5 9 Kollisionsr ume Ein Kol
67. nglich war es beabsichtigt sich nicht nur auf eine Simulationsbibliothek zu beschr n ken sondern es sollte die M glichkeit geben mehrere Bibliotheken zu benutzen Dies w rde zum einen eine gewisse Unabh ngigkeit gew hrleisten aber zum anderen auch die M glich keit bieten verschiedene mehr oder weniger komplexe Implementierungen einer Funktion zu nutzen Ferner sollte z B auch eine eigene einfach gehaltene Bibliothek f r die Simulation der Dynamik entwickelt werden um komplexe Funktionen z B aus ODE durch einfachere weniger rechenintensive Funktionen zu ersetzen Um diese Anforderung zu erm glichen wurde ein entsprechendes Konzept f r ein Framework entwickelt Dieses Framework sollte eine API bereitstellen die wiederum verschiedene Funktionen mit unterschiedlicher Imple mentierung aus mehreren Bibliotheken unterst tzt Eine intensive Erprobung der ODE Bibliothek machte aber immer mehr deutlich dass die frei erh ltliche Physik Engine allen gestellten Anforderungen an den Simulator bereits entspricht und somit eine Eigenentwick lung keinen h heren Nutzen hervorbringen w rde Daraufhin wurde auch auf die Entwicklung des Frameworks verzichtet und ODE als alleinige Simulations Bibliothek eingesetzt Die Open Dynamics Engine als Basis des Simulators hat sich in den Testdurchl ufen und w hrend der Erprobung des Simulators als sehr stabil und wenig fehleranf llig hervorgeho ben solange die Simulationsschritte klein gehalten wurden
68. nob jekt dem Simulator ber eine der beiden Schnittstellen entweder Shared Memory oder So ckets Der Simulator selbst pr ft vor jedem Simulationsschritt ob neue Daten f r die Manipu lation vorliegen und ndert dementsprechend die Simulationseinstellungen Die Abbildung 3 4 zeigt den Aufbau dieser Datenstruktur Entwicklung eines Software Simulationssystems 52 E SharedDataManipulation A Valid Sim ID Obj ID newDataFlag exitFlag positionFlag forceFlag setForceFlag position force orientation Abbildung 3 4 Datenstruktur SharedDataManipulation Quelle Eigene Darstellung Valid und Sim ID sind entsprechend den Parametern der Datenstruktur f r die Visualisie rung zu verstehen Obj ID spezifiziert das zu ver ndernde Objekt und newDataFlag gibt an ob neue Daten vorliegen ber das ExitFlag ist es m glich die Simulation zu beenden Die Flags positionFlag forceFlag und setForceFlag bestimmen welche Eigenschaften des K rpers ge ndert werden sollen Die weiteren Parameter position und force und orienta tion spezifizieren die neue Position Kraft oder Orientierung 3 3 3 Ablauf der Kommunikation Die Abbildung 3 5 zeigt den generellen Ablauf der Kommunikation zwischen Simulator Visu alisierung ViToSA und Manipulation Die drei verschiedenen Anwendungen laufen unab h ngig voneinander ab und sind daher getrennt zu
69. nutzerschnittstelle m glich sein Dadurch wird der Anwender in die Lage gebracht manuell in die Simulation einzugreifen Dies kann z B durch eine Space Mouse oder textbasiert durch die Tastatur erfolgen 3 2 4 Anforderung an die Visualisierung F r die Betrachtung der virtuellen Welt und der Abl ufe die in der virtuellen Umgebung statt finden wird eine Visualisierung ben tigt die eine dreidimensionale Darstellung von Roboter und Umgebung erm glicht sowie virtuelle Kommandos anzeigen kann Die Visualisierung soll unabh ngig von der Simulation der Dynamik sein und erfolgt daher extern au erhalb des Simulators Entwicklung eines Software Simulationssystems 48 3 3 Simulationssystem Dieses Kapitel beschreibt das zu entwickelnde Simulationssystem Es soll den generellen Aufbau und die Struktur des Systems wiedergeben Dabei wird auf die Konzeption und die Schnittstellen zwischen den einzelnen Komponenten eingegangen 3 3 1 Konzeption des Simulationssystems Gem den im vorigen Kapitel gestellten Anforderungen wird ein entsprechendes Konzept f r das Simulationssystems entwickelt Die Abbildung 3 2 stellt den generellen Aufbau dieses Systems grafisch dar Die gestrichelten Pfeile symbolisieren den logischen und die ausgef ll ten Pfeile den tats chlichen Datenfluss N Virtuelle Welt Objekt 1 U I Visualisierung i Manipulation ViToSA Ge i z B User Interface I 1 e l I i Objekt n l l
70. ody ID 1 0 3084 1 0038 0 4985 0 0000 0 0000 0 0000 Abbildung 3 14 Screenshot einer Beispiel Simulationsumgebung mit ViToSA Quelle HRI 3 7 Testszenarios Das Simulationssystem soll wie schon in der Aufgabenstellung beschrieben durch einen geschlossenen Regelkreis Closed Loop mit Hilfe des bei HRI verwendeten Komponenten Integrationsmodell getestet werden Das Testszenario umfasst allerdings nur den einfachen Regelkreis aus der Aufgabenstellung siehe Kapitel 1 3 sowie Abbildung 1 1 Der zweite Regelkreis wurde nicht realisiert Die Abbildung 3 15 zeigt den Aufbau des Testszenarios Im oberen Bereich sind die beiden Komponenten Robot Control und Manipulate Object abgebildet die zusammen den Re gelkreis bilden Die Robot Control Komponente hat in dieser Darstellung nur eine symboli sche Bedeutung In Realit t ist sie ein System von Komponenten die den Roboter simulie ren Diese Komponente wird von HRI zur Verf gung gestellt Im unteren Bereich ist der Si mulator dargestellt Er wird wie schon erw hnt als Stand Alone Server betrieben Der Ab lauf kann nun wie folgt beschrieben werden Der Roboter der durch die Komponente Robot Control simuliert wird bewegt seine Hand in die N he eines Objekts und greift danach Das zu greifende Objekt wird bei der Ber hrung mit der Roboterhand deaktiviert und somit von der Simulation ausgeschlossen Das Objekt wird jetzt von au en also von der Robot Control Komponente gesteuert
71. on Detection Open Graphics Library Portable Operating System Interface for UniX Quasar toolkit Real Time Brain Operating System Shared Memory Subversion User Interface Visualisation Tool for Simulation Applications Einleitung 10 1 Einleitung 1 1 Das Honda Research Institute Europe Das Honda Research Institute Europe GmbH HRI ist ein Tochterunternehmen des japani schen Automobilherstellers Honda Motor Co Ltd Es wurde zusammen mit den Schwester unternehmen in Japan und den USA im Januar 2003 gegr ndet und ist im Bereich der Grundlagenforschung f r Intelligente Systeme t tig Ein wesentliches Ziel von HRI ist es die Mechanismen und die Entwicklung von Informati onsprozessen in biologischen Systemen zu untersuchen die grundlegenden Prinzipien zu identifizieren und sie anschlie end in technischen Systemen einzuf gen HRI arbeitet mit mehreren nationalen und internationalen Forschungsinstituten und Universi t ten zusammen und verkn pft somit die universit re Wissenschaft mit der praktischen For schung in verschiedenen Disziplinen 1 2 Motivation Die Entwicklung eines humanoiden Roboters sowie das erstellen und testen eines komple xen Visionsystems ist eine sehr komplizierte und anspruchsvolle Aufgabe Dies wird zus tz lich durch den Mangel an Sensoren und Aktoren erschwert da sie nur begrenzt zur Verf gung stehen Ferner sind viele aufwendige Testverfahren notwendig um eine fehlerfreie Funktion der H
72. owohl ber das Netzwerk wie auch zwischen Prozessen auf einem Rechner So kann z B die Simulation auf einen leistungsstarken Rechner erfolgen und die Visualisierung auf mehreren verteilten Clients im Netzwerk stattfinden Es ist aber genauso m glich nur auf einem Rechner die Si mulation und Visualisierung durchzuf hren Datenstruktur f r die Visualisierung Die Datenstruktur f r die Visualisierung SharedDataVisualisation definiert alle Informatio nen die von ViToSA ben tigt werden um eine grafische Ausgabe der Simulation zu erm gli chen In dem Simulator wird f r jedes zu visualisierende Objekt eine Instanz dieser Struktur erzeugt Diese Daten werden dann am Ende jedes Simulationsschritts dem Visualisierungs tool ber eine der genannten Schnittstellen entweder Shared Memory oder Sockets berge ben Die Datenstruktur setzt sich aus elementaren Datentypen zusammen Die Verwendung von Zeigern ist allerdings nicht m glich da ein Zeiger nur innerhalb eines Programmierblocks g ltig ist Daher sind Zeiger f r eine Interprozesskommunikation nicht geeignet Die Abbil dung 3 3 zeigt den Aufbau dieser Datenstruktur 28 Vgl Wolf 2006 S 353 ff Vgl Brause 2004 S 259 Entwicklung eines Software Simulationssystems 51 SharedDataVisualisation Valid Sim ID Model Model ID Size Position Orientation Abbildung 3 3 Datenstruktur SharedDateVisu
73. r einen Fl che gibt die die andere Fl che durchdringt Ein Verfahren um dies zu testen ist z B die tren nende Ebene Zwei K rper ber hren sich genau dann nicht wenn eine trennende Ebene zwischen ihnen aufgespannt werden kann 2 4 Physik Engines Physik Engines sind f r die Simulation physikalischer Abl ufe verantwortlich Es sind einige kommerzielle wie auch nicht kommerzielle Engines verf gbar die f r verschiedenartige Einsatzgebiete konzipiert sind Dazu geh ren die Spielephysikengines und Physikengines f r virtuelle Realit ten Zu den kommerziellen Physik Engines geh ren Havok Physics Ageia PhysX Megon RenderWare Physics und True Axis Physics die alle f r Windows entwi ckelt worden sind Daneben gibt es zum einen die kostenlose Physik Engine Newton Game Dynamics lauff hig f r Windows Linux und Mac OS sowie die beiden Open Source Engines Tokamak f r Windows und die Open Dynamics Engine f r Windows Linux und Mac OS Wie schon in der Aufgabenstellung erw hnt wird ODE als Basis f r die eigene Simulations bibliothek verwendet und im n chsten Kapitel genauer beschrieben 19 Vgl Eckstein 1998 S 131 ff 2 Vgl Eckstein 1998 S 93 ff Theoretische Grundlagen 26 2 5 Open Dynamics Engine Die Open Dynamics Engine ist eine frei erh ltliche plattformunabh ngige Bibliothek f r die Simulation der Dynamik starrer K rper in einer virtuellen Umgebung von Russel Smith Die Physik Engine gilt al
74. rope GmbH 2006 http www honda ri de Honerkamp J R mer H 1989 Klassische Theoretische Physik Eine Einf hrung 2 Auflage Berlin Heidelberg 1989 M hlig M 2006 VITOSA A 3D Visualisation Tool for Simulation Applications HRI inter nal Report 2006 Myers Enzyklop disches Lexikon in 25 B nden 1977 Band 19 9 Auflage Mannheim 1977 Myers Enzyklop disches Lexikon in 25 B nden 1977 Band 21 9 Auflage Mannheim 1977 Open Dynamics Engine 2006 http www ode org Orear J 1982 Physik Band 1 M nchen 1982 Smith R 2006 http www q12 org Warken T 2004 Collision Detection for Curved Rigid Objects in the Context of Dynamics Simulations Dissertation Naturwissenschaftlich Technische Fakult t der Universit t des Saarlandes 2004 Wolf J 2006 Linux Unix Programmierung Das umfassende Handbuch 2 erweiterte Auflage Bonn 2006 Anhang LXIX Anhang Anhang 1 Beispiel f r eine Konfigurationsdatei KonfigSimulation txt Im Folgenden wird eine Beispielkonfiguration f r die Initialisierung des Simulators aufgelistet Ein Datensatz wird dabei immer in die beiden Bezeichner OBJEKT_START und OBJEKT_END eingeschlossen um die Zusammengeh rigkeit der eingeschlossenen Daten zu einem Objekt zu kennzeichnen Nach dem Start Bezeichner wird der Objekttyp angege ben Danach folgt die Position Gr e Kraftvektor Drenmomentvektor und das Flag AddGe om Wird dies
75. s der API zun chst nur die wesentlichen Funktionen getestet Dazu geh rt z B das erzeugen von K rpern Kollisionsobjekten und Gelenken zur Verbindung von K rpern oder das Hinzuf gen von Kr ften auf einen K rper und viele weitere mehr 3 5 Manipulation Die Simulation von starren K rpern soll von au en beeinflussbar sein Dadurch ist es m g lich w hrend einer aktiven Simulation Modifikationen an einzelnen Objekten vorzunehmen Die Simulation an sich darf jedoch nicht beeinflusst werden oder sogar aussetzen sondern muss unabh ngig von potentiellen nderungen weiterlaufen Es soll schlie lich gew hrleistet werden dass die Simulation die Realit t so gut wie m glich nachbildet Generell ist die Manipulation der virtuellen Welt auf zwei verschiedene Arten m glich Zum einen direkt im Simulator selbst durch die Anwendung der API Funktionalit t und zum ande ren durch die interaktive Manipulation mit Hilfe einer geeigneten Schnittstelle Diese interak tive Manipulation soll im Folgenden beschrieben werden Die Kommunikation zwischen der externen Anwendung und dem Simulator erfolgt wie schon im Kapitel 3 3 2 beschrieben entweder durch die Verwendung des Shared Memory oder ber Sockets In diesem Fall soll die Kommunikation anhand der SHM Schnittstelle beschrieben werden Dabei wird der Informationsaustausch mittels einer speziell daf r entworfenen Da tenstruktur SharedDataManipulation realisiert siehe Kapitel 3 3 4 Diese D
76. s ein Prozess lesend und vor allem schreibend auf ein Speichersegment zugreift Zun chst muss ein Prozess den Datenspeicher erzeugen Dieser wird in Linux im Pfad dev shm abgelegt Anschlie end kann jeder beliebige Prozess den Datenspeicher seinem Adressraum hinzuf gen sofern ihm der Speicher bekannt ist Shared Memory ist wohl die schnellste Form der Interprozesskommunikation Nachteilig ist nur dass bei diesem Verfahren keine explizite Synchronisation stattfindet und die Kontrolle selbst durch Sperrmechanismen realisiert werden muss Allerdings stehen auch schon Bib liotheken zur Verf gung die einen Sperrmechanismus implementieren Entwicklung eines Software Simulationssystems 50 Die f r die Kommunikation mit dem Simulator eingesetzte SHM Bibliothek vom Honda Re search Institute basiert auf dem POSIX Standard Portable Operating System Interface for UniX und hat auch bereits eine Zugriffskontrolle implementiert Socket Schnittstelle Ein Socket ist eine Schnittstelle zwischen einem Prozess also einer Applikation und dem vom Betriebssystem verwendetem Netzwerk Protokoll zur Interprozess oder Netzwerk Kommunikation Der Zugriff erfolgt vergleichsweise wie auf Dateien nur das es sich hier nicht um physikalische Dateien handelt sondern um Kommunikationskan le Die Kommunikation ber Sockets in Unix Linux ist Teil des POSIX Standards Der Vorteil von Sockets gegen ber dem Shared Memory ist die Kommunikation s
77. s schnell leistungsstark robust sowie flexibel und steht unter der BSD Lizenz Sie kann daher nach eigenem belieben ver ndert und verbreitet werden ODE wird stetig weiterentwickelt und ist sehr gut dokumentiert Bei der Simulation wird ein h chst stabiler Integrator eingesetzt so dass Simulationsfehler nicht zu einem instabilen System f hren k nnen In ODE findet grunds tzlich eine Unterscheidung zwischen der Simulation der Dynamik star rer K rper und der Kollisionserkennung zwischen den K rpern statt Daf r ist in ODE eine integrierte Kollisionserkennung enthalten die auch Reibung unterst tzt Sie muss allerdings nicht zwingend eingesetzt werden Zudem steht auch eine optimierte Kollisionserkennung namens OPCODE OPtimzed COllision DEtection zur Verf gung Auf diese optimierte Vari ante wird hier hingegen nicht eingegangen Die Bibliothek bietet selbst keine Funktionalit t f r die Darstellung von visuellen Informatio nen an daher wird f r die Visualisierung der Simulation eine zus tzliche Bibliothek ben tigt In dem Software Paket ist aber auch eine kleine Grafikbibliothek namens Drawstuff enthal ten die auf OpenGL basiert und f r eine Darstellung der Simulationen ausreicht Die Abbil dung 2 8 zeigt eine einfache Beispiel Simulation die mit der Drawstuff Bibliothek visualisiert wurde 7 Die Ausf hrungen in diesem Kapitel basieren alle auf dem ODE Benutzerhandbuch auf das hiermit verwiesen wird Eine detai
78. sen Abbildung 3 10 Programma blauf der Initialisierungsphase Quelle Eigene Darstellung Entwicklung eines Software Simulationssystems 58 Die Konfigurationsdatei wird in einer Schleife ausgelesen bis das Ende der Datei erreicht wird F r jeden Datensatz wird ein entsprechender K rper konstruiert Dabei werden zu n chst die Masse und die Massenverteilung entsprechend den Angaben in der Konfigurati onsdatei erstellt Danach wird automatisch ein entsprechendes Kollisionsobjekt generiert und dem K rper zugewiesen Im n chsten Schritt wird berpr ft ob ein Offset Geometrie Objekt erzeugt werden soll Eine Offset Geometrie ist ein zus tzliches Geometrie Objekt das einem K rper zugewiesen werden kann Durch Angabe eines Offsets kann die Geometrie beliebig am K rper positioniert werden Damit ist es m glich auch komplexere Objekte zu entwerfen Nach der Initialisierung wird die Simulationsschleife aufgerufen die in der Abbildung 3 11 dargestellt ist Die Simulationsschleife wird solange durchlaufen bis von au erhalb das Exit Flag gesetzt wird In der Simulationsschleife selbst wird am Anfang der Shared Memory der Manipulations Schnittstelle ausgelesen und eventuell die Simulationsdaten ge ndert falls die entsprechenden Flags gesetzt sind Danach startet der Simulator die Kollisionserken nung und ruft f r jedes eventuell kollidierende Objektpaar eine Callback Funktion siehe Ka pitel Siehe 2 5 11 auf Simulationssch
79. tation um eine feste Achse Geht die Drehachse dagegen nur durch einen raumfesten Punkt Fixpunkt und ver ndert ihre Richtung mit der Zeit so bezeichnet man dies als eine Rotation um einen Fixpunkt Wir betrachten zun chst die Rotation eines K rpers um eine feste Achse In diesem Fall bewegen sich die Punkte auf Kreisbahnen deren Ebenen jeweils senkrecht zur Drehachse Vgl Gross Hauger Schnell 1998 S 103 Theoretische Grundlagen 18 stehen Die Fahrstrahlen zu allen K rperpunkten berstreichen in gleichen Zeiten den glei chen Drehwinkel Demnach sind die Winkelgeschwindigkeit und die Winkelbeschleuni gung a f r alle Punke gleich _ d do _d o D e dt dt dt A d nderung des Drehwinkels dt nderung der Zeit Wir wenden uns nun der Rotation um einen raumfesten Punkt A zu Die momentane Lage der Drehachse sei durch den Einheitsvektor e gekennzeichnet F hrt der K rper in der Zeit dt eine Drehung mit dem Drehwinkel do um die augenblickliche Drehachse aus so bewegen sich alle K rperpunkte momentan auf Kreisbahnen Die Rotation um einen raumfesten Punkt A kann hinsichtlich des Ergebnisses stets auch durch die Rotation um eine durch den festen Punkt gehende Achse erzielt werden Euler sches Theorem Die Abbildung 2 3 verdeutlicht die Rotation in einer grafischen Darstellung Abbildung 2 3 Darstellung einer Rotationsbewegung Quelle Eigene Darstellung
80. tionssystems 47 Der Simulator muss daf r die Dynamik von starren K rpern berechnen k nnen d h die am K rper anliegenden Kr fte m ssen in eine nderung des Weges der Geschwindigkeit und der Beschleunigung umgesetzt werden Die Visualisierung spielt f r den Simulator direkt keine Rolle und sollte m glichst unab h ngig von der Simulation ablaufen Es m ssen aber die entsprechenden Daten f r eine m gliche Veranschaulichung der Simulation bereitgestellt werden Die Initialisierung virtueller Welten soll mit Hilfe einer Konfigurationsdatei Textdatei erfol gen damit eine dynamische Konfiguration des Simulators m glich ist Qualitative Anforderungen Die qualitativen Anforderungen an das System sind zum einen eine schnelle physikalische Simulationsumgebung die sich durch Robustheit und Absturzsicherheit also einen stabilen Integrator auszeichnet und zum anderen sollte die Simulation der Dynamik m glichst genau sein Allerdings ist dies nicht immer zu gew hrleisten da durch den interaktiven Eingriff in die virtuelle Welt es immer wieder zu kleinen Ungenauigkeiten kommen kann 3 2 3 Anforderung an die Manipulation F r die Steuerung bzw Beeinflussung des Simulators ist eine Schnittstelle zu implementie ren mit der es m glich ist interaktiv in die Simulation einzugreifen und somit den Roboter an die Umgebungssimulation zu koppeln Die Manipulation sollte aber auch durch eine externe Anwendung z B eine Be
81. ulator die symbolischen Informationen also Position Orientie rung usw aller beteiligten K rper in dem zugeh rigen Datenobjekt festgehalten Anschlie Bend wird das gesamte Daten Array in den Shared Memory geschrieben Das Visualisie rungsprogramm liest nun in einem bestimmten Intervall das Daten Array aus und generiert aus den symbolischen Informationen visuelle Daten F r die Visualisierung der virtuellen Welt muss ViToSA zun chst durch einen Konverter er weitert werden Es sind jeweils zwei verschiedene Konverter f r die Kommunikation ber Shared Memory oder ber Sockets zu implementieren wie es die Abbildung 3 13 illustriert E Konverter SHM D e D Visualisierung EN ViToSA ObjectData SharedData _SharedData S amp gt S d Abbildung 3 13 Kommunikationsablauf zwischen SHM und ViToSA Quelle Eigene Darstellung Der Konverter liest dabei die Daten ber Shared Memory oder Socket ein konvertiert die Daten in das entsprechende Format ObjectData und bergibt die Informationen an ViToSA Die Abbildungen 3 14 zeigt ein Beispiel f r die Visualisierung einer virtuellen Welt Entwicklung eines Software Simulationssystems 62 Models d Position X Y Z Offset X Y Z l 3 Scene 0 0000 0 0000 0 0000 2 SimConv_1 0 0000 0 0000 0 0000 X Body ID 0 1 6229 1 6052 0 2495 0 0000 0 0000 0 0000 x Geom ID 0 1 8275 1 943373 0 2495 0 0000 0 0000 0 0000 x B
82. wird jeweils ein gemeinsamer Speicherbereich Shared Memory f r die beiden Schnittstellen Visualisierung und Manipulation erzeugt Die Gr e des zu reservie renden Speichers ist dabei abh ngig von der Anzahl der Objekte die simuliert werden sol len Wird die Socket Schnittstelle verwendet m ssen an dieser Stelle jeweils ein Netzwerk server f r die Visualisierung und f r die Manipulation initialisiert werden Anschlie end wird die Simulations Welt erstellt Dies beinhaltet die automatische Generie rung einer Dynamik und Kollisionswelt eines Untergrunds statische Umgebung und einer Gelenkgruppe f r die Kontakt Verbindungen die w hrend der Kollisionserkennung generiert werden Jede virtuelle Welt erh lt eine eindeutige ID mit deren Hilfe die Simulations Welt eindeutig identifiziert werden kann Daraufhin wird die Welt initialisiert Dies erfolgt ber die Konfigurationsdatei in der alle zu simulierenden K rper genau spezifiziert sind Der genaue Aufbau dieser Datei ist im Anhang 1 nachzulesen Abbildung 3 10 macht diesen Prozess anhand eines Ablaufplans deutlich Initialisierung der virtuellen Welt Datensatz aus Konfig Datei auslesen Masse erzeugen Erstellung K rper Massenverteilung erzeugen Quader Kugel Zylinder Offset Geometrie erzeugen Masse und Massenverteilung Nein K rper zuweisen Nein Datei Zeiger erh hen Kollisionsobjekt erzeugen Kollisionsobjekt dem K rper LG zuwei

Download Pdf Manuals

Related Search

Document documents documents folder document editor document holder documents word document360 documentary document editor free documents file document camera document recovery document scanner documents folder this computer documenting reality documents needed for real id documents list document shredding near me document capture pro document viewer document writer document ai document google document sign document intelligence documentos normativos

Related Contents

Milwaukee angle grinder User's Manual  Samsung FG87SUB User Manual  SE 559  manual do proprietário  Deutsch - Schuss Home Electronic  Istruzioni  Trésor de la Langue Française Informatisé (TLFI)  Untitled  Achassis  Simrad CA44  

Copyright © All rights reserved. Failed to retrieve file