Framework zur Untersuchung und Simulation autonomer Robotiksysteme

Framework zur Untersuchung und Simulation autonomer Robotiksysteme

Thomas D. Lepich

Bergische Universität Wuppertal

Lehrstuhl für Automatisierungstechnik / Informatik (Thomas@Lepich.de)

Abstract. Diese Arbeit befasst sich mit der Erstellung eines Frameworks zur Untersuchung und Simulation autonomer Robotiksysteme. Hierbei ist das Hauptziel, ein sehr flexibles Fra- mework zu implementieren, welches eine schnelle und mit geringem Einarbeitungsaufwand verbundene Erzeugung grafischer Simulationen von Robotern und ähnlicher Maschinen er- möglicht. Diese sollen sich bezüglich des dynamischen Verhaltens möglichst gering von realen Maschinen unterscheiden. Auf diese Weise soll es ermöglicht werden, autonome Robotiksy- steme und dazugehörige Algorithmen testen zu können, ohne sich direkt realer Prototypen bedienen zu müssen. Der Bau solcher Systeme kann somit hinausgezögert oder sogar vermie- den werden, um damit anfallende Entwicklungskosten zu reduzieren.

1 Einleitung

In der Automatisierungstechnik oder der Neuroinformatik, speziell in der Forschung bezüglich au- tonomer Robotik, müssen oft teure Prototypen von Robotern beschafft oder eigens gebaut werden, an welchen neue Algorithmen zur Steuerung und Umgebungserkennung getestet werden können.

Ebenso werden auch kleine Roboter für Versuche oder die Ausbildung von Studenten genutzt, wie beispielsweise der Khepera der Firma K-Team Corporation.

Bild 1 zeigt zwei Exemplare solcher Roboter, den Cooperative Robotic Assistant, kurz CoRA, des Lehrstuhls für Neuroinformatik an der Ruhr-Universität Bochum [1], sowie ein Modell des Khepera.

Vereinzelt werden bereits jetzt grafische Simulationen genutzt, um Bildmaterial für Tests von Bil- derkennungsalgorithmen durchführen zu können, oder um einfache Steuerungsalgorithmen zu vi- sualisieren. Diese Simulationen sind in der Regel sehr einfacher Natur und sehr spezialisiert auf ein ganz bestimmtes Problem. Eine Anpassung für eine neue Versuchsanordnung erfordert in der Regel eine Neuimplementierung von Großteilen der Software.

Die grafischen Modelle werden in der Regel aus einfachen Primitiven, wie Würfeln und Kugeln zu- sammengesteckt. Die gesamte Grafik wird auf sehr hardwarenaher Ebene mittels direkter OpenGL Aufrufe implementiert, ohne sich eines Szenengraphen oder ähnlicher Optimierungsansätze zu bedienen.

Auf die Implementierung von realistischem dynamischen Verhalten der Avatare und insbesondere der Interaktion mit deren Umgebung wird aus Gründen der Komplexität und des Einarbeitungs- aufwands oft verzichtet.

Hingegen zeigt Bild 2 einen, mit der ersten Version des Robotics Frameworks implementierten Avatar. Die Erstellung eines solchen Avatars beinhaltet lediglich die Positionierung der Bauteile

(a) CoRA (Cooperative Robotic Assistant), Ruhr-Universität Bochum

(b) Robot Khepera II, K-Team Cor- poration

Bild 1:Beispiele realer Roboter

und ihre Verknüpfung durch Aktoren, wie etwa Servomotoren. Der so erstellte Avatar ist anschlie- ßend sofort einsatzbereit. Seine dynamischen Eigenschaften, sowie unterschiedliches Verhalten seiner Sensoren oder Aktoren werden ebenfalls ohne weiteren Aufwand simuliert.

Bild 2:Der AvatarRobot PeTor 3aus der Beispielapplikation des hier vorgestellten Robotics Frameworks

Ein solches Vorgehen erlaubt es, schnell und effizient einfache grafisch simulierte Maschinen zu entwickeln, an denen unterschiedliche Steuerungsalgorithmen getestet werden können.

Zusammenfassend hat das Framework die Aufgabe, eine einfach zu bedienende Schnittstelle für den Aufbau von Avataren zu bieten. Simulierte Maschinen sollen intuitiv aus Einzelteilen, wie etwa Gelenken, diversen Aktoren und Sensoren zusammengebaut werden können. Ebenfalls sollen die so erstellten Avatare mit künstlicher Intelligenz oder einfachen Steuerungen versehen werden können, indem ihnen vom Benutzer implementierte Plugins zugewiesen werden.

Autonome Robotiksysteme und dazugehörige Algorithmen sollen auf diese Weise effizient getestet werden können.

Die Implementierung dieses Konzepts basiert auf zwei wichtigen Datenstrukturen, demRigid Pri- mitiveals atomares dynamisches Grafikelement und derKomponente, welche für die Konstruktion von Avataren benötigt wird. Diese beiden Klassen bilden unter anderem die Grundlage zur Lösung der genannten Anforderungen.

2 Architektur

Die Architektur des Frameworks teilt sich in mehrere Schichten. (Siehe Bild 3.) Die Grundlage bilden hier die beiden BibliothekenObject-oriented Rendering Engine (Ogre 3D), sowie dieOpen Dynamics Engine (ODE).

Graphics Engine Dynamics Engine

Physical/Graphical Layer: Rigid Primitives / Actuators / Sensors ...

Graphics Scene Management Dynamics Collision

Logical Layer: Components / Control ...

Bild 3:Architektur des Frameworks

Ogre 3Dist verantwortlich für eine effiziente Verwaltung, sowie für das Zeichnen der 3D-Inhalte.

Es werden Datenstrukturen und Szenengraphen bereitgestellt, welche für die entsprechenden Auf- gaben zuständig sind. Diese Bibliothek stammt ursprünglich aus der Spieleentwicklung, wird in- zwischen jedoch auf weitaus mehr Gebieten verwendet, wie etwa Simulation, Bildungssoftware, interaktiver Kunst, oder wissenschaftlicher Visualisierung. [4]

Dynamisches Verhalten von Elementen der Simulation wird vonODEberechnet. Bei dieser Biblio- thek handelt es sich um ein für hohe Leistung optimiertes Werkzeug zur Simulation dynamischer Eigenschaften starrer Objekte (Rigid Body Dynamics¹). Es sind darin diverse Arten sogenannter Constraints enthalten, mit welchen sich Freiheitsgrade der dynamischen Körper entziehen lassen, um unterschiedliche Arten von Gelenken oder Scharnieren erstellen zu können. Mithilfe der Cons- traints lassen sich verschiedene Arten von Aktoren realisieren. Die Bibliothek besteht ihrerseits aus zwei Unterbibliotheken für die Kollisionserkennung, sowie für die Dynamikberechnung. Für Kollisionsberechnung werden Kollisionsproxies genutzt. Es handelt sich hierbei um Hüllkörper, die um ein grafisches Element gelegt werden, um dessen Form anzunähern. Die genutzte Daten- struktur eines solchen Höllkörpers ist ein sogenanntesGeom. (Siehe Bild 4b.) Berechnungen der Bewegung einzelner Elemente werden mittels dynamischer Körper berechnet. Der genutzte Da- tentyp eines solchen Körpers wird einfachBodygenannt. (Siehe Bild 4c.) [2, 3]

Das Rigid Primitive

Die Basis des Frameworks, welche die grafische mit der dynamischen Schicht verbindet, ist das Rigid Primitive. Diese Datenstruktur dient als Schnittstelle für eine einfache Nutzung der zugrunde liegenden Bibliotheken.

Bild 4 demonstriert die einzelnen Teilaufgaben, aus denen sich eine grafische Simulation zusam- mensetzt, sowie die Zusammenführung zur Datenstruktur Rigid Primitve. Die Abbildungen 4a, 4b und 4c entsprechen hier den ModulenGraphics,CollisionundDynamicsder untersten Schicht aus Bild 3.

1„Rigid Body Dynamics“ bedeutet, dass die atomaren Objekte innerhalb der Simulation nicht verformt werden können. Möchte man Objekte simulieren, die deformiert werden können, müssen diese aus den atomaren Objekten zusammengesetzt werden.

Das Rigid Primitive dient als atomares „Bauteil“ eines Avatars oder eines beliebeigen Gegen- stands innerhalb der Simulation. Es handelt sich hierbei um ein einfaches starres Element mit dynamischen Eigenschaften, wie Masse und Oberflächenbeschaffenheit, wie Reibung oder Härte.

(a) Die grafische Darstellung der Welt wird durch das Zeichnen von Gittern aus Dreiecken realisiert. Ogre 3D bietet hierzu entsprechende Datenstrukturen. Diese optimieren die Struktur der 3D-Daten in Bezug auf effizientes Zeichnen.

Dazu werden, je nach Komplexität der Formen der Objekte, riesige Mengen von Dreiecken be- nötigt. Für eine effiziente Kollisionsberechnung können diese nicht genutzt werden.

(b) Der Kollisionsraum dient der Berechnung von Überschneidungen zwischen den Elemen- ten der Simulation. Kollisionsproxies dienen hier als Annäherung an die Form der grafischen Elemente. Für die Kollisionserkennung werden in der Regel nur diese genutzt, um Rechenzeit zu sparen. Mehrere dieser Proxies lassen sich ef- fizienter für die Kollisionserkennung nutzen, als ein einzelnes Gitter aus Dreiecken. Die Kollisi- onserkennung ist Aufgabe der Kollisionsbiblio- thek von ODE. Ein einzelnes Proxy wird hier vom DatentypGeombeschrieben.

(c) Dynamische Körper dienen der Berech- nung des kinetischen Verhaltens der Simulati- onselemente. Sie sind ebenfalls Teil von ODE.

Ihre Beschreibung erfolgt durch ihre kineti- schen Eigenschaften und ihre Masse. Über eine räumliche Ausdehnung verfügen sie nicht. Ih- re Bewegungsfreiheit wird eingeschränkt durch Constraints aus der Kollisionserkennung, sowie Joints, die einzelne Körper aneinander heften und so ihre Bewegung relativ zu einander fest- legen.

(d) Die hier vorgestellte Datenstruktur Rigid Primitivekombiniert alle diese Teilaufgaben der Simulation zu einfach einsetzbaren Objekten.

Sie regelt alle entstehenden Abhängigkeiten und die notwendige Kommunikation. (Siehe auch Bilder 5 und 6.)

Bild 4:Unterschiedliche Teilaufgaben der Simulation und ihre Zusammenführung zu einer gemeinsamen, auch für Laien intuitiv einzusetzenden Einheit.

Die Erzeugung und Beschreibung eines Rigid Primitives findet mittels XML statt. Diese Objekte können dann einfach über den Aufruf einer Methode geladen werden. Sie brauchen anschließend nur noch positioniert zu werden und sind sofort einsatzbereit.

Im Hintergrund, versteckt vor dem Benutzer, erledigt ein Rigid Primitive eine Menge Arbeit. Es stellt die notwendigen Datenelemente innerhalb der verschiedenen Module der Simulation her, verwaltet diese und kümmert sich um deren Kommunikation untereinander.

In Bild 5 ist der schematische Aufbau eines Rigid Primitives zu sehen und ein Teil der Kommunika- tion zwischen den Modulen. Das Rigid Primitive stellt die Verbindung der grafischen, dynamischen und der Kollisionsebene dar. Es verfügt über ein grafisches Element, über einen dynamischen Kör- per, sowie über beliebig viele Kollisionsproxies. Alle Proxies werden in einem einzelnen Kollisi- onsraum zusammengefasst. Ein Proxy setzt sich aus einem Geom, welches seine Form beschreibt, und einem Transformationsgeom zusammen. Das Transformationsgeom ist eine Datenstruktur, die es erlaubt ein einfaches Geom aus seinem Ursprung zu verschieben und zu rotieren.

Dynamics Body

Rigid Primitive

Dynamics Characteristics (surface properties, mass...) Graphics

Scene Node

Mesh Data

Collision Space

...

...

Transform 1

Geom 1 Proxy 1

Transform 2

Geom 2 Proxy 2

Transform N

Geom N Proxy N informs

moves

moves

Bild 5:Aufbau und Kommunikation eines Rigid Primitive

Die einzelnen Datenelemente, die hier verbunden werden müssen, sind Teile unterschiedlicher Sze- nengraphen. Die gesamte grafische Darstellung wird durch den Ogre 3D Szenengraphen realisiert, Kollisionserkennung geschieht innerhalb eines ebenfalls hierarchisch geordneten Kollisionsraums und die Berechnung der Dynamik erfolgt in der„dynamischen Welt“unter Verwendung globaler Koordinaten.

Die Simulation erfolgt, indem zunächst alle Kollisionen oder Berührungen² berechnet werden. Zu den gefundenen Überschneidungen der Elemente werden Verbindungen (Constraints) innerhalb der dynamischen Welt erstellt. Anschließend wird die Bewegung in Abhängigkeit aller solcher

2In der Regel handelt es sich um Überschneidungen der Objekte. Echte Berührungen mit einer Eindringtiefe von null sind eine seltene Ausnahme.

Verbindungen berechnet. ODE bietet hier die Möglichkeit die Kollisionsproxies eines dynami- schen Körpers direkt mit dem Körper zu bewegen. Die Bewegung der grafischen Darstellung muss hier vom Rigid Primitive durchgeführt werden. Hierzu wird das Rigid Primitive bei jeder Bewe- gung seines dynamischen Körpers benachrichtigt um entsprechende Schritte einleiten zu können.

Die Verbindung der unterschiedlichen Graphen wird nochmals genauer in Bild 6 dargestellt.

Root Scene Node (Ogre::SceneNode)

Scene Node C (Ogre::SceneNode) Scene Node B

(Ogre::SceneNode) Scene Node A

(Ogre::SceneNode)

Mesh Data A (Ogre::Entity)

Mesh Data B (Ogre::Entity)

Mesh Data C (Ogre::Entity)

Global Collision Space (dxSpace)

Space A (dxSpace)

Transform A1 (dxGeom)

Transform A2 (dxGeom)

Transform B1 (dxGeom)

Transform B2 (dxGeom)

Dynamics World (dxWorld)

Body A (dxBody)

Body B (dxBody)

Space B (dxSpace)

Transform C1 (dxGeom)

Transform C2 (dxGeom) Space C (dxSpace)

Body C (dxBody) Rigid Primitive A

Geom A1 (dxGeom)

Geom A2 (dxGeom)

Geom B1 (dxGeom)

Geom B1 (dxGeom)

Geom B1 (dxGeom)

Geom B1 (dxGeom) (1)

(2)

(3)

Bild 6: Eine Instanz der Klasse RigidPrimitive hat Verbindungen zu drei unter- schiedlichen Graphen. Sie hat eine grafische Darstellung (1), einen dynamischen Körper (2) und verfügt über einen untergeordneten Kollisionsraum (3), der wieder- um beliebig viele Kollisionsproxies (Geoms) beinhalten kann.

Aktoren und Sensoren

Zu einer Simulation von Maschinen gehören neben Bauteilen wie dem Rigid Primitive allerdings noch weitere Elemente. Es werden Aktoren benötigt, die etwa Servomotoren oder pneumatische Zylinder simulieren können, und diverse Sensoren, wie Kameras, Entfernungsmesser oder GPS.

Aktoren werden in der Regel³mittels Constraints simuliert. Hierzu werden unterschiedliche Joints verwendet, um Rigid Primitives zu verbinden und relativ zu einander zu bewegen. [2] Bild 7 zeigt Beispiele zweier Motoren. Zu sehen sind hier jeweils zwei Rigid Primitives, die durch einen Motor

3Einige Aktoren, wie etwa ein Düsenantrieb, können auch durch Anwendung einfacher Kräfte auf ein Rigid Pri- mitive realisiert werden.

an einander gebunden sind. Der Motor selbst verfügt innerhalb der Simulation über keine visuelle Darstellung. Sichtbar sind nur die Rigid Primitives, welche durch den Motor verbunden sind und von ihm bewegt werden. Die grünen Pfeile dienen im Bild nur der Veranschaulichung. Der Ge- rade Pfeil stellt hier die Achse des Motors dar, um welche sich die beiden verbundenen Objekte bewegen. Der gebogene Pfeil zeigt die Drehrichtung an.

(a) (b) (c) (d)

Bild 7:Unterschiedlich zusammengesetzte Motoren und ihre Drehrichtungen

Um Sensoren zu realisieren, werden unterschiedliche Techniken angewendet. Bei Abstandsmes- sung werden Kollisionstests durchgeführt, bei Positionsbestimmung einfache Anfragen an den Szenengraphen gestellt und bei der Simulation von Kameras werden ganze Renderdurchgänge vorgenommen.

Ganz egal, wie die Elemente intern funktionieren, werden sie nach Außen hin mit einfachen, den Elementen entsprechenden Schnittstellen versehen, um eine Intuitive Verwendung zu erlauben.

Alle Bauteile können einfach an Rigid Primitives montiert werden.

Zusammenfassung zu Komponenten

Maschinen bestehen in der Regel aus einzelnen Elementen, welche ihrerseits aus weiteren Elemen- ten zusammengesetzt sein können. Ein Roboter kann aus einem Fahrwerk bestehen, eventuell zwei Armen und einem Kopf. Die Arme ihrerseits können aus mehreren Gelenken, Motoren und diver- sen Sensoren zusammengesetzt sein. Der Kopf kann ebenfalls eine Montage aus einem Gehäuse, einer Steuerungseinheit und verschiedenen Sensoren sein, wie etwa Kameras oder Mikrofonen.

All diese Elemente lassen sich als Gruppen von Bauteilen beschreiben, die wiederum aus wei- teren Bauteilen oder Bauteilegruppen bestehen. Es ergibt sich somit eine Datenstruktur, welche einzelne Bestandteile einer Maschine oder eines Avatars zu logischen, hierarchisch angeordneten Gruppen zusammenfassen kann. Dieser Zusammenhang wird im Robotics Framework durch die DatenstrukturKomponenterealisiert. (Siehe Bild 8.)

Steuerung von Komponenten

Prinzipiell dienen Komponenten der Gliederung von Avataren. Ein weiterer Vorteil ist jedoch die Möglichkeit der Steuerung solcher Komponenten. Es können Steuerungsplugins installiert werden, welche jeweils einen Komponentenbaum kontrollieren können. Diese Plugins können vom Nutzer erzeugt werden, um etwa dynamische Systeme zur Hindernisvermeidung und Zielverfolgung zu implementieren. Es können Avatare zudem mittels übergeordneter Komponenten zu Kollektiven autonomer Individuen zusammengefasst werden, welche Anweisungen von einer übergeordneten Steuerungsinstanz erhalten. (Siehe Bild 9.)

1 1

* 1

* 1

1

Component

Sensor

RigidPrimitive ControlPlugin

Actuator

*

* 1

Bild 8:Aufbau einer Komponente

Component A

Component B Component C Component D

Component E Component F

Control A

Control B

Component G Component H Component I Component J

Control C Control D

Bild 9: Beispiel der Struktur und Steuerung eines Kollektivs autonomer Avatare.

Die gestrichelten Pfeile deuten hier an, welche Komponenten von welchen Steue- rungsplugins gesteuert werden. Im Fall des Steuerungsplugins Control A werden nicht Komponenten, sondern andere Plugins gesteuert.

Ein Steuerungsplugin kann generell in jede einzelne Komponente installiert werden. Durch die In- stallation erhält es Zugang zu allen angeschlossenen Bauteilen, wie Motoren und Sensoren. Diese kann es jederzeit abfragen und bedienen.

3 Anwendung

Die einfache und intuitive Anwendung ist ein zentraler Schwerpunkt des hier vorgestellten Fra- meworks. Im Folgenden soll die Nutzung anhand eines einfachen Bespiels vorgeführt werden. Zu diesem Zweck wurde eine simple Applikation erstellt, welche einen einfachen Roboter simuliert, bestehend aus einigen Gelenken, Sensoren, Motoren und starren Bauteilen. Die simulierte Um- gebung des Roboters beinhaltet zudem einige herumliegende Objekte, mit denen dieser Avatar interagieren kann. Die Steuerung erfolgt über ein Plugin, welches über ein Kontrollfenster bedient wird. Dieses enthält einige Eingabemöglichkeiten, sowie Ausgabefelder für Sensordaten. Bild 10 zeigt einen Screenshot dieser Applikation. Eine Zusammenfassung aller Bestandteile des Avatars kann Bild 11 entnommen werden.

Die Erstellung des Avatars beginnt zunächst mit dem Erzeugen einer Komponente. Diese bekommt hier den Namen„PeTor 3“. Dieser ist gleichzeitig der Name des Roboters. Sie fasst später alle Bauteile des Avatars zusammen und bietet die Möglichkeit ein Steuerungsplugin zu installieren, welches den Avatar kontrolliert.

Bild 10:Screenshot einer einfachen Beispielapplikation

Component ∗pPeTor3MainComponent = ComponentManager : : g e t S i n g l e t o n P t r ( )−> c r e a t e ( " P e T o r 3 " ) ;

Weiterhin werden alle Bauteile des Avatars, wie am folgenden Beispiel dessen Körpers, aus XML Dateien geladen und positioniert. Nach dem Laden werden diese Elemente direkt der eben erzeug- ten Komponente hinzugefügt.

R i g i d P r i m i t i v e M a n a g e r : : g e t S i n g l e t o n P t r ( )

−> c r e a t e F r o m F i l e ( " PeTor3Body " , " DLBitPeTor3Body . r p . xml " ) ; R i g i d P r i m i t i v e M a n a g e r : : g e t S i n g l e t o n P t r ( )

−>getByName ( " PeTor3Body " )−> s e t P o s i t i o n ( 0 . 0 f , 0 . 0 8 f , 0 . 0 f ) ; pPeTor3MainComponent

−> a t t a c h ( R i g i d P r i m i t i v e M a n a g e r : : g e t S i n g l e t o n P t r ( )−>getByName ( " PeTor3Body " ) ) ;

Herumliegende Elemente werden auf die gleiche Weise erzeugt, mit dem Unterschied, dass sie keiner Komponente hinzugefügt werden müssen.

Nachdem alle Elemente erzeugt wurden, sollen nun auch Aktoren erstellt werden. Das folgende Beispiel zeigt die Erstellung und Installation eines der Motoren. Es wird ganz einfach ein Motor namens„PeTor3LeftMotor“erstellt. Anschließend werden zwei Rigid Primitives an diesen Motor angeschlossen. Die Achse wird definiert, positioniert und der Motor der Komponente hinzugefügt.

Motor ∗p P e T o r 3 L e f t M o t o r = ( DLBit : : Motor∗) A c t u a t o r M a n a g e r : : g e t S i n g l e t o n P t r ( )

−> c r e a t e ( " P e T o r 3 L e f t M o t o r " , A c t u a t o r : : AT_Motor ) ; p P e T o r 3 L e f t M o t o r−> a t t a c h ( " P e T o r 3 W h e e l L e f t " , " PeTor3Body " ) ; p P e T o r 3 L e f t M o t o r−>s e t A n c h o r ( 0 . 5 5 f , 0 . 1 5 f , −0.3 f ) ;

p P e T o r 3 L e f t M o t o r−> s e t A x i s ( 1 . 0 f , 0 . 0 f , 0 . 0 f ) ; pPeTor3MainComponent−> a t t a c h ( p P e T o r 3 L e f t M o t o r ) ;

Die Erzeugung und Installation von Sensoren findet auf die gleiche Weise statt, ein Sensor kann jedoch nur an ein einzelnes Rigid Primitive montiert werden, anstatt an zwei, wie es bei dem eben gezeigten Motor der Fall ist.

Steuerungsplugins müssen vom Benutzer selbst implementiert werden, da nur dieser bestimmen kann, was sein Roboter tun soll. Dazu wird einfach die SchnittstelleControlPlugInimplementiert.

Eine Instanz der resultierenden Klasse kann dann einfach zur Verwaltung an den zuständigen Ma- nager weitergegeben werden. Die Installation geschieht über die Methodeattach, wie schon bei allen anderen Elementen.

(a) Der Avatar soll über zwei Sensoren verfü- gen, eine Kamera und einen Entfernungsmesser.

Beide sollen am Kopf befestigt werden.

(b) Die drei Rigid Primitives der Kopfbefesti- gung sollen durch Servomotoren miteinander verbunden werden.

(c) Auf beiden Seiten des Körpers sollen Räder mit einfachen Drehmotoren befestigt werden.

(d) Damit der Avatar nicht über den Boden schleift, werden an der Unterseite zwei Kugeln über Kugelgelenke befestigt.

Bild 11:Bestandteile des Avatars (Aktoren, Sensoren und Constraints)

C o n t r o l P l u g I n M a n a g e r : : g e t S i n g l e t o n P t r ( )

−> t a k e U s e r C r e a t e d P l u g I n (new P e T o r 3 C o n t r o l P l u g I n ( " P e T o r 3 C o n t r o l P l u g I n " ) ) ; pPeTor3MainComponent−> a t t a c h ( C o n t r o l P l u g I n M a n a g e r : : g e t S i n g l e t o n P t r ( )

−>getByName ( " P e T o r 3 C o n t r o l P l u g I n " ) ) ;

Um eine Steuerung zu realisieren muss in der Implementierung der Schnittstelle ControlPlugIn nur eine einzigeupdate-Methode überladen werden.

4 Abschluss

Es wurde ein Framework zur Untersuchung und Simulation autonomer Robotiksysteme vorge- stellt. Der Schwerpunkt liegt hier in einer einfachen Nutzung der Komponenten auf Quelltextebe- ne, um eine schnelle Erzeugung von Simulationsumgebungen zu ermöglichen, ohne vom Nutzer ein umfangreiches Wissen über die Programmierung von 3D-Simulationen zu verlangen.

Derzeit wird das Robotics Framework bereits am Lehrstuhl für Neuroinformatik an der Ruhr- Universität Bochum eingesetzt, um unterschiedliche Arten von Robotern simulieren zu können, sowie für die Ausbildung Studierender, die bis dahin keinen Kontakt zu grafischer Simulation hatten.

Eine Weiterentwicklung im Rahmen eines Forschungsprojekts an der Bergischen Univerität Wup- pertal ist in Beantragung.

Literatur

[1] I. Iossifidis, C. Bruckhoff, C. Theis, C. Grote, C. Faubel, and G. Schöner. Cora: An anthropo- morphic robot assistant for human environment. InRobot and Human Interactive Communi- cation, 2002. Proceedings. 11th IEEE International Workshop on, pages 392–398, 25-27 Sept.

2002.

[2] Russel Smith. Constraints in der festkörperdynamik. Spieleprogrammierung Gems, 4, 2004.

[3] Russel Smith. Open Dynamics Engine - ODE, 2009.

[4] Torus Knot Software. Object-oriented Graphics Rendering Engine - Ogre 3D, 2001.