Marcel Dulisch. Bachelorarbeit

Universität Bielefeld Technische Fakultät Bachelorarbeit Integration einer Pfadplanung für den Katana Arm auf einem mobilen Roboter unter Berücksic...
0 downloads 0 Views 4MB Size
Universität Bielefeld

Technische Fakultät

Bachelorarbeit

Integration einer Pfadplanung für den Katana Arm auf einem mobilen Roboter unter Berücksichtigung der Plattformeinschränkungen

vorgelegt von:

Marcel Dulisch

1.Betreuer:

M. Sc. Florian Lier

2.Betreuer:

Dipl.-Inform. Frederic Siepmann

Bielefeld, den 27.06.2011

Inhaltsverzeichnis 1

2

Einleitung

1

1.1

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Herausforderungen und Ziele . . . . . . . . . . . . . . . . . . . . . .

3

Verwandte Arbeiten

4

2.1

Webots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

Blender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

3

Inverse Kinematik und Pfadplaner

4

Die verwendete Hard- und Software

5

10

4.1

Die BIRON Plattform . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2

Das Kommunikationsframework XCF . . . . . . . . . . . . . . . . . 11

4.3

Der Neuronics Katana Arm . . . . . . . . . . . . . . . . . . . . . . 12

4.4

Die Armansteuerung KNI . . . . . . . . . . . . . . . . . . . . . . . 14

4.5

OpenRAVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Systemintegration

5.1

6

8

17

ArmControlServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1

Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.1.2

Reale Ansteuerung . . . . . . . . . . . . . . . . . . . . . . . 18

5.2

ArmControlRemoteServer . . . . . . . . . . . . . . . . . . . . . . . 19

5.3

Ablauf einer Bewegung des Katana Arms . . . . . . . . . . . . . . . 19

Evaluation

6.1

21

Testszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1.1

Präzision des Katana Arms . . . . . . . . . . . . . . . . . . 21

i

6.2

6.3

6.1.2

Präzision von OpenRAVE . . . . . . . . . . . . . . . . . . . 21

6.1.3

Erweiterung des Arbetisraumes . . . . . . . . . . . . . . . . 22

6.1.4

Kollisionsdetektion . . . . . . . . . . . . . . . . . . . . . . . 22

Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.2.1

Präzision des Katana Arms . . . . . . . . . . . . . . . . . . 22

6.2.2

Präzision von OpenRAVE . . . . . . . . . . . . . . . . . . . 23

6.2.3

Erweiterung des Arbetisraumes . . . . . . . . . . . . . . . . 23

6.2.4

Kollisionsdetektion . . . . . . . . . . . . . . . . . . . . . . . 24

Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7

Fazit und Ausblick

26

8

Literaturverzeichnis

28

9

Anhang

30

9.1

Maÿe des Katana Arms . . . . . . . . . . . . . . . . . . . . . . . . . 30

9.2

Flussdiagramm des ArmControlServers . . . . . . . . . . . . . . . . 31

9.3

Codebeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

9.4

Erklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

ii

1 Einleitung Heutzutage wird es für Serviceroboter, welche dem Menschen Aufgaben abnehmen sollen, immer wichtiger, nicht nur sprechen und verstehen zu können. Sie sollten Aufgaben erfüllen können, bei denen es notwendig ist, Objekte anheben und transportieren zu können. Diese Fähigkeit ist notwendig für Serviceroboter, damit sie Getränke oder Lebensmittel zu einem Menschen bringen oder sie die Wohnung aufräumen können, um dem Menschen Arbeit abzunehmen. Die besondere Schwierigkeit gegenüber Industrierobotern liegt darin, das die Umwelt in der Industrie statisch ist, eine Wohnung, in der ein Serviceroboter tätig ist, sich jedoch ständig verändert. Durch die dynamische Umgebung werden an ihn deutlich höhere Ansprüche gestellt als an die Industrieroboter. Der Serviceroboter muss zum Beispiel sehr vorsichtig agieren, da in seinem unmittelbaren Umfeld Menschen sind, die er weder verletzen noch behindern darf. Um einem Menschen etwas zu trinken zu bringen, muss der Serviceroboter erst einmal das Getränk erkennen. Wenn er es erkannt hat, muss er die Position des Getränkes abschätzen. Diese Daten werden an einen Manipulator, ein Gerät, das die physikalische Interaktion mit der Umgebung ermöglicht, weitergegeben. Der Manipulator kann allerdings noch mehr Informationen über seine Umwelt erhalten. So kann man ihm mitteilen, ob das Getränk von einem anderen Objekt verdeckt ist, so dass er nicht direkt an das Getränk herankommt. Aus diesen Informationen muss sich der Manipulator dann eine Trajektorie, eine Abfolge von Bewegungen (siehe Kap. 3), berechnen. Mit Hilfe dieser Trajektorie kann der Manipulator sich in Richtung des Getränkes um das Objekt, dass das Getränk verdeckt, herum bewegen. Dann muss der Manipulator das Getränk noch greifen und in eine sichere Trageposition manövrieren. Da ein solches Manipulationsverhalten erst programmiert werden muss, beschäftigt sich diese Bachelorarbeit damit, das Greifen eines Objektes autonom durch den Roboter erst zu simulieren und dann in der Realität auszuführen.

1

1.1 Motivation

Mit 3D-Sensoren ist es möglich, Objekte wie Getränke zu erkennen, die auf einer planaren Oberäche z.B. auf einem Regal oder einem Tisch stehen [Lai09]. Mit den Daten über die Position ist es somit möglich, diese Objekte zu greifen. Hierfür wird in dieser Arbeit der Neuronics Katana Arm (siehe 4.3), der in der mobilen BIRON Plattform (siehe 4.1) verbaut ist, verwendet. Um greifen zu können, muss der Katana Arm allerdings erst aus seiner schützenden Plattform herausgedreht werden. Dies geschieht entweder mit einer fest implementierten Ansteuerung der einzelnen Motoren oder durch eine Trajektorienplanung (vgl. Kap. 3). Da die Trajektorie eine dynamische Lösung ist, sollte diese einer festen Implementierung vorgezogen werden. Dadurch ist es dem Katana Arm möglich, sich aus der Plattform herauszudrehen, selbst wenn sich diese verändert. Die aktuelle Softwareansteuerung des Katana Arms (vgl. Kap. 4.3) Katana Native Interface (KNI) vgl. Kap. 4.4 besitzt keine Möglichkeit, um eine solche Trajektorie zu berechnen. Daher wird nur mit der Methode der festen Implementation gearbeitet. Mit Hilfe solcher Trajektorien kann man geschickt um Objekte manövrieren, um ein anderes, weiter hinten liegendes, Objekt greifen zu können. Da Roboterarme meist sehr empndliche Motoren besitzen, kann es bei zu starker Beanspruchung sehr schnell zu defekten oder überhitzen Motoren kommen. Daher ist es umso wichtiger, eine Simulation des Katana Arms, inklusive seiner Einschränkungen, zu besitzen. In dieser kann vor dem eigentlichen Testen in der Realität bereits festgestellt werden, ob das Szenario funktionieren kann. Es ist wichtig, dass das Gesamtsystem weiÿ, dass der Katana Arm an der gewünschten Position angekommen ist, um entscheiden zu können, ob ein Kommando erneut gesendet werden sollte. Wenn es nicht erneut gesendet werden soll, kann das System den Katana Arm gezielt wieder in die Plattform bewegen, ohne Schaden an sich selbst oder seiner Umgebung zu nehmen. Der Arbeitsraum, die Positionen, die von dem Katana Arm erreicht werden können, ist durch die Plattform sehr stark verkleinert. Dieses Verhalten ist von Nachteil, da die KNI viele Punkte aus dem Randbereich des Arbeitsraumes nicht anfahren kann. Mit der Software OpenRAVE (siehe 4.5) ist dies möglich, weshalb sie im Rahmen dieser Arbeit verwendet wird.

2

1.2 Herausforderungen und Ziele

Um neue Bewegungsabläufe wie das Herausdrehen aus der Plattform BIRON zu integrieren, soll im Rahmen dieser Bachelorarbeit ein Pfadplaner sowie eine Trajektorienplanung (vgl. Kap. 3) aus OpenRAVE eingebunden werden. Des Weiteren soll es ermöglicht werden, innerhalb der OpenRAVE Simulation testen zu können, ob eine geplante Aktion mit dem Arm erfolgreich sein kann. Der Arbeitsraum soll auf die physikalisch möglichen Grenzen erweitert werden. Ein weiteres Ziel dieser Arbeit soll sein, die bisher verwendete Software nicht einzuschränken, sondern nur zu erweitern. Es soll kein Nachteil durch geringere Genauigkeit des Katana Arms entstehen.

3

2 Verwandte Arbeiten 2.1 Webots

Webots ist eine Entwicklungsumgebung zur Modellierung, Programmierung und Simulation von mobilen Robotern, in der es möglich ist, fahrende, iegende und laufende Roboter zu simulieren. Es können Umgebungen und komplexere Welten simuliert werden. Webots ist in C++ [Addis86] und Java [Lindh99] programmierbar. Die Umgebungen können mittels VRML1 erzeugt werden. Es gibt einige vor-

c 2011 Cyberbotics Ltd. Abb. 2.1: Simulation des Katana Arms in Webots, denierte Roboter wie den benötigten Neuronics Katana Arm (siehe Abb. 2.1). Webots ist eine kommerzielle Software, die in zwei Versionen vertrieben wird. Als

professional Version, in der es möglich ist, eigene physikalische Gesetze zu denieren oder die günstigere education Version, die für Lehrzwecke gedacht ist. Webots ist derzeit sowohl für Linux als auch für Windows und MacOS in Version sechs 1 Virtual

Reality Modeling Language, http://www.w3.org/MarkUp/VRML/ Stand: 27.06.2011

4

(Stand: 26.06.2011) erhältlich. Die Benutzeroberächen zur Steuerung des Simulators sind intuitiv benutzbar [KORD05]. Auÿerdem ist es einfach möglich, neue Szenarien sowie neue Roboter zu entwerfen.

Abb. 2.2: Simulationsumgebung Webots http://www.cyberbotics.com/overview Stand: 27.06.2011 Bereits integriert ist eine Kollisionsdetektion [Lin98], jedoch kein Algorithmus zur Trajektorienplanung. Diesen müsste man durch eine externe Software hinzufügen. Dadurch wird die Integration in das Gesamtsystem deutlich komplizierter. Deshalb wurde von dieser Software abgesehen.

2.2 Blender

Blender ist eine frei zugängliche 3D Grak Software, mit der man Objekte erstellen, sie mit Texturen belegen, rendern2 , und animieren kann. Blender kann mit 2 Erstellung

einer Grak aus einem Modell

5

der Skriptsprache Python[Lutz11] angesprochen werden. So ist es möglich, neue Funktionen in Blender hinzuzufügen.

Abb. 2.3: Die Benutzeroberäche von Blender, Orange Project3 Da Blender von Haus aus bereits über sehr gute Simulationsfähigkeiten verfügt, wurde geprüft, ob es sich für eine Pfadplanung sowie Kollisionsdetektion für den Katana Arm eignet. Zu den gröÿten Vorteilen von Blender zählt die sehr schnelle grasche Animation sowie individuelle Anpassungsmöglichkeiten der Arbeitsoberäche [Bruy04]. Auÿerdem bietet es die Möglichkeit, Videos, die zuvor intern simuliert wurden, direkt zu rendern und aufzunehmen. Des Weiteren sind die Basisalgorithmen der Robotik wie inverse Kinematik-Löser und Trajektorienplanung schon integriert. Es existieren bereits fertige Modelle des Katana Arms für Blender, jedoch müssen diese an die vorhandene Version des Katana Arms angepasst werden. Nach der Anpassung des Models müssen dem Arm noch Gültigkeitsbereiche für die 3 http://www.elephantsdream.org

Stand: 27.06.2011

6

Motorstellungen gegeben werden sowie eine interne Struktur (Skelett), damit der inverse Kinematik-Löser eine Lösung für den Arm berechnen kann. Allerdings ist das nicht unbedingt gegeben, da dieser Löser ein Basis-Löser ist und nicht so viele Lösungen ndet. Diesen Nachteil macht der PfadplanungsalgorithAbb. 2.4: Der mit

Katana Blender

Arm mus nicht besser, denn dieser Spline Interpolaerstellt. tionsalgorithmus [Meier90] wird bei einer recht

http://sourceforge.net

geringen Anzahl von Freiheitsgraden ungenau.

/Model_Repository

So können unter Umständen falsche Werte geliefert werden. Es ist keine Kollisionsdetektion

zwischen dem Arm und anderen Gegenständen wie der Basis festzustellen. Ein weiterer groÿer Nachteil besteht darin, dass Blender nicht intuitiv genug benutzbar ist (vgl. Abb. 2.3). Aus Gründen der hohen Systemauslastung, der schlechten Pfadplanung und der kontraintuitiven Benutzbarkeit, wurde Blender nicht für diese Bachelorarbeit verwendet.

7

3 Inverse Kinematik und Pfadplaner In diesem Kapitel wird auf die Grundlagen der inversen Kinematik und die Pfadplanung eingegangen. Ziel der inversen Kinematik ist es, anhand einer Endeektor1

Position und -Rotation die einzelnen Gelenkwinkel des Arms zu berechnen. Um

die inverse Kinematik einfacher berechnen zu können, hat ein Roboterarm meistens sechs Freiheitsgrade (DoF: Degree of Freedom). Ein Arm mit sechs DoF hat mindestens sechs Gelenke. Die sechs Freiheitsgrade teilen sich in drei DoF für die Position und drei DoF für die Orientierung des Endeekors im Raum auf. Um jetzt aus der Position und der Orientierung des Endeekors die Motorstellungen berechnen zu können, teilt man das Problem in zwei kleinere auf: ein Positionsund ein Orientierungsproblem [Wenz08]. Das Positionsproblem lässt sich geometrisch lösen. Somit erhält man bereits drei der sechs Motorstellungen. Das Orientierungsproblem lässt sich dann analytisch lösen. Dadurch sind die anderen drei Motorstellungen bekannt und das Problem der inversen Kinematik ist gelöst. Jedoch kommt es vor, dass es für eine Endeektor-Stellung mehrere Lösungen für die Motorstellungen gibt. Das nennt man Singularität [Dyn86]. Im Rahmen dieser Bachelorarbeit wurde für einen solchen Fall die Lösung ausgewählt, bei der der Arm den kürzesten Weg zurücklegen muss. Des Weiteren wird die Lösung so abgewandelt, dass die Richtung des Greifers immer auf das zu greifende Objekt zeigt. Ein Pfadplaner wird jetzt benötigt, um von der aktuellen zu der von der inversen Kinematik berechneten Position zu gelangen. Der in OpenRAVE verwendete

1 Das

Werkzeug z.B. der Greifer eines Roboterarms

8

Birrt2 [Beren09] Pfadplaner ist eine Abwandlung des rrt3 [Ku00] Planers. Der rrt-Planer breitet sich baumstrukturartig aus. Jeder vom Baum abgehende Ast, stellt dabei einen neuen Satz von Motorstellungen dar. Der Algorithmus exploriert so seine komplette Umgebung. Wenn er an einer Stelle auf ein Hindernis stöÿt, wird der Baum an diesem Knoten nicht weiter erweitert. So entsteht eine 'Karte' von möglichen Kongurationen für den Arm. Wenn eine Kombination jetzt den Endeektor auf der Zielkoordinate hat, wird aufgehört zu explorieren und dieser Weg als Pfad zum Ziel verwendet. Der Unterschied zum Birrt-Planer ist, das dieser nicht nur vom Start das Ziel, sondern zugleich vom Ziel zum Start exploriert. Dadurch wird das Finden einer Lösung beschleunigt. Eine Lösung die vom Start zum Ziel führt, nennt man Trajektorie.

2 Bi-directional-Rapidly-Exploring

Zufallsbaum 3 Rapidly-Exploring Random Tree

Random Tree - In beide Richtungen schnell explorierender

9

4 Die verwendete Hard- und Software 4.1 Die BIRON Plattform

Die BIRON1 Plattform, mit der die Universität Bielefeld an der @Home Liga des Robocups2 teilnimmt, ist mit einer dierentialen Motorsteuerung [DeSan95] ausgestattet (Abb. 4.1). Das heiÿt, zwei Räder, die links und rechts an der Plattform angebracht sind, bewegen den Roboter. Sie hat einen Sick LMS 200 Laser3 , der zur Erkennung von Beinpaaren und zur Hindernisdetektion verwendet wird. Des Weiteren besitzt die Plattform vordere, hintere und seitliche Stoÿfänger. Diese stoppen den Roboter, falls er

Abb. 4.1:

Die Roboterplattform Biron

trotz der Hindernisvermeidung des Lasers mit einem Hindernis kollidieren sollte. Der Sensorkopf des Roboters besteht Companion http://aiweb.techfak.uni-bielefeld.de/taxonomy/term/9 Stand: 27.06.2011 2 www.robocup.org stand: 27.06.2011 3 https://www.mysick.com/partnerPortal/ProductCatalog/DataSheet.aspx?ProductID=33755# Stand: 27.06.2011

1

BielefeldRobot

10

aus zwei Grasshopper Kameras4 , die zur Gesichtserkennung verwendet werden, einem Mikrofon und einer Kinect5 , die die nötigen Tiefeninformationen über zu greifende Objekte liefert [Lai09]. Der gesamte Roboter wird von zwei leistungsstarken Dell6 Laptops gesteuert. Diese kommunizieren über das XCF miteinander.

4.2 Das Kommunikationsframework XCF

Da auf dem Roboter sehr viele verschiedene Programme parallel laufen und ihre Ergebnisse und Anfragen an andere Programme verbreiten müssen, wurde das XCF -

XML enabled Communication Framework7

[Wred04] entwickelt. Dieses

kommuniziert sowohl über das Netzwerk zwischen verschiedenen Computern sowie auf einem einzigen PC. Dadurch ist es für die einzelnen Komponenten möglich, ihre Ergebnisse mit anderen Programmen auszutauschen. Ein weiterer Vorteil von XCF ist, dass es verschiedene Programmiersprachen miteinander in Verbindung bringen kann. In XCF gibt es mehrere Möglichkeiten, Daten zu verbreiten. Die Einfachste ist, einen Publisher zu erstellen, der die Daten im XML8 Format veröentlicht. Diese sind dann so lange aktuell, bis sie von einem Subscriber gelesen werden. Der Publisher kann die Daten an einen aktiven Speicher übergeben, wo die Daten aufbewahrt werden, bis sie durch Mechanismen des `Vergessens` aus dem Speicher gelöscht werden. Der Nachteil bei dieser Variante ist, dass der Publisher nie weiÿ, ob und wann eine andere Komponente die von ihm veröentlichten Daten gelesen hat. Darum gibt es noch eine weitere Möglichkeit, Daten über das XCF zu versenden,und zwar explizit nur an einen Server, der die Eingabe verarbeitet. Nach der Verarbeitung werden die Ergebnisse an den Server zurück gesendet. Somit ist es durch XCF möglich, Komponenten auszutauschen, ohne groÿe Änderungen an deren Implementierung machen zu müssen. Zur Kontrolle, welche Komponenten bereits gestartet sind und welche möglicherweise bereits abgestürzt sind, gibt es

4 http://www.ptgrey.com/products/grasshopper/grasshopper_rewire_camera.asp 27.06.2011

5 www.xbox360.com/kinect

Stand: 27.06.2011 Stand: 27.06.2011 7 https://code.ai.techfak.uni-bielefeld.de/trac/xcf Stand: 27.06.2011 8 Extensible Markup Language http://www.w3.org/XML/ Stand:27.06.2011 6 www.dell.com/latitude

11

Stand:

die vdemo9 Startumgebung. Hier lassen sich die Komponenten gezielt entweder einzeln oder in einem Block starten. Durch Knopfdruck kann die Fehlermeldung einzelner Komponenten ausgegeben werden.

4.3 Der Neuronics Katana Arm

Der in dieser Bachelorarbeit verwendete Neuronics Katana Arm ist die Version 6M90A_G. Die Besonderheit dieses Arms liegt darin, dass der Greifer nicht nach vorne in Richtung der letzten Verbindung zeigt, sondern dass dieser um 90 Grad abgewinkelt ist (vgl. Abb. 4.5). Der Arm hat fünf Freiheitsgrade. Er kann Objekte mit einem Gewicht von maximal 400 Gramm und einem Durchmesser von bis zu 13 cm heben. Die genauen Abmessungen werden im Anhang Abb. 9.1 kenntlich gemacht. In Abb. 4.2 sieht man, wie groÿ der Arbeitsraum ist, den der Ka-

Abb. 4.2: Der Arbeitsraum des Katana Arms ohne Einschränkungen

tana Arm zur Verfügung hat. Wenn er in der BIRON Plattform eingebaut ist,

verliert der Katana Arm einen Groÿteil seines Arbeitsraumes, weil er von der Plattform eingeschränkt wird. Im ausgestreckten Zustand kann der Katana Arm noch Objekte manipulieren, die ca. 50 cm von ihm entfernt sind. Des Weiteren ist die Präzision zu erwähnen. Selbst nach mehreren Bewegungen ist der Katana Arm noch sehr präzise was durch die verbauten Encoderscheiben zu erklären ist. Eine Scheibe enthält alle 0.5◦ eine Markierung, anhand derer der Katana Arm ablesen kann, wie weit er gedreht ist. Bei jedem Start des Arms wird er kalibriert. Dabei wird jeder Motor bis zum Anschlag gedreht. Aus dieser Position wird dann von 9 http://redmine.ni.techfak.uni-bielefeld.de/wiki/grasplab/Vdemo

12

Stand: 27.06.2011

einer Encoderscheibe abgelesen, um wie viel Grad der Arm gedreht ist. Dies wird dann als Ursprung des Motors gespeichert. Als Besonderheit besitzt der hier verwendete Katana Arm einen Greifer, der mit 13 Sensoren ausgestattet ist (siehe Abb. 4.3):

• fünf Entfernungssensoren im Inneren • zwei Entfernungssensoren sowohl oben als auch auf den Auÿenseiten • vier Drucksensoren im Inneren des Greifers Damit ist es dem Arm möglich zu 'wissen', ob er ein Objekt gegrien oder daneben gegrien hat. Dadurch sind Interaktionen mit dem Menschen möglich (siehe Abb. 4.3).

Abb. 4.3: Der Greifer des Neuronics Katana Arms. Die Entfernungssensoren sind durch die schwarzen, die Drucksensoren durch die roten Pfeile dargestellt. Die beiden Zangen sind symmetrisch aufgebaut.

13

4.4 Die Armansteuerung KNI

Der Neuronics Katana Arm wird über das Katana Native Interface (KNI) gesteuert. Diese quelloene Software wird von Neuronics10 , dem Hersteller des Katana Arms, bereitgestellt. Sie beinhaltet einen algebraischen sowie einen analytischen Löser [Dyn86] für die inverse Kinematik. Man kann den Greifer im kartesischen Raum11 über die inverse Kinematik steuern, die aber nicht sehr stabil ist. Dies äuÿert sich, indem der Katana Arm versucht, einen Punkt aus dem Randbereich des Arbeitsraumes anzufahren. Kurz vor Erreichen des Punktes fährt er wieder zum Ausgangspunkt. Daher kann die KNI so kaum verwendet werden, um gezielt Koordinaten anzufahren. Man kann, nachdem eine Lösung gefunden wurde, den Greifer entweder linear oder willkürlich zu der Zielposition fahren lassen. Die lineare Variante verhindert unvorhersehbare Bewegungen. Sie verhindert jedoch nicht, dass der Arm mit sich selbst oder der BIRON Plattform, auf der er montiert ist, kollidiert. Eine andere Möglichkeit, den Katana Arm über die KNI zu steuern, ist, die einzelnen Gelenke zu drehen, wodurch sich der Greifer unkontrolliert bewegt und Kollisionen wahrscheinlich sind. Die Sensoren aus dem Greifer können über die KNI abgefragt werden. Diese haben ein sehr hohes Rauschen, sodass sie nur als Schalter verwendet werden können (an/aus). Wir benutzen den Sensor in der Mitte um zu überprüfen, ob das zu greifende Objekt innerhalb des Greifers ist, um diesen dann schlieÿen zu können. Die unteren Sensoren werden abgefragt, wenn sich der Greifer einem Objekt nähert. Dabei geht er nicht nur näher an das Objekt heran, sondern fährt auch ein Stück tiefer in Richtung Oberäche, auf der das Objekt steht. Dies erhöht die Reichweite des Katana Arms enorm. Durch diese Sensoren wird überprüft, ob die Oberäche nicht schon zu nah gekommen ist, sodass es eine Kollision geben würde. Wenn der Greifer ein Objekt trägt, sind die äuÿeren Sensoren dafür da, den Greifer zu önen, falls sie von einem Menschen berührt werden.

10 www.neuronics.ch 11 Koordinaten

Stand: 27.06.2011 System mit X-Y-Z Achsen die Senkrecht aufeinander stehen

14

4.5 OpenRAVE

OpenRAVE

12

ist eine quelloene Software, die mit mobilen, ein- und mehrarmi-

gen Plattformen umgehen kann. OpenRAVE ist ein modular aufgebautes System, das mit sehr vielen verschiedenen Modulen ausgestattet ist. Zu den Hauptmodulen zählt der Löser für die inverse Kinematik, diverse Pfadplanungsalgorithmen, die Kollisionsdetektion und die grasche Oberäche. Es ist über diverse Schnittstellen ansprechbar. Zu den wichtigsten Programmiersprachen gehören Python, C++ und Matlab/Octave [Bruce97]. Da OpenRAVE noch in der Entwicklungs-

Abb. 4.4: Die Simulationsumgebung von OpenRAVE

12 Open

Robotics and Animation Virtual Environment

15

phase ist, gibt es verschiedene Versionen, jedoch kein ozielles Release13 . Daher ist es nur möglich, OpenRAVE über das Arbeits-SVN14 herunterzuladen. Es hat eine ganze Gemeinde hinter sich, die mit dieser Software arbeitet. OpenRAVE ist auf den Betriebssystemen Microsoft Windows, MacOS und Linux lauähig. Es ist ein noch sehr junges System, wodurch Funktionen falsche Ergebnissen liefern oder komplett abstürzen können. Gegenüber diesem Nachteil überwiegen jedoch die Vorteile, wie zum Beispiel der bereits integrierte Neuronics Katana Arm. Dieser hat allerdings noch einen um 90◦ gedrehten Greifer. Dies wurde an den Katana Arm, der hier verwendet wurde, angepasst (vgl. Abb. 4.5). Auÿerdem ist es durch das integrierte Plugin für die inverse Kinematik für jeden Arm möglich, also auch für den veränderten Katana Arm, eine Lösung zu berechnen. Dadurch können die Motorstellungen zu einem beliebigen Punkt innerhalb des erreichbaren Raumes berechnet werden. Mit diesen Stellungen ist es dann möglich, mit einem der integrierten Pfadplanungsalgorithmen, einen Pfad von der aktuellen Stellung des Arms zu der neuen Stellung und somit auch zu der neuen Koordinate zu berechnen. Die Simulation visualisiert zu jeder Zeit die Stellung des Arms und lässt Fehler oder problematische Gelenkstellungen erkennen. Des Weiteren ist es dynamisch möglich, Objekte in die Simulation zu laden. Das bedeutet, dass es nicht notwendig ist, das gesamte System neu starten zu müssen, wenn sich die Umgebung des Roboters ändert.

(a) Der Neuronics Katana Arm mit (b) Der Neuronics Katana Arm waagerechtem Greifer mit um 90-Grad gedrehtem Greifer

Abb. 4.5: Der Katana Arm in der Simulation von OpenRAVE mit dem Originalund dem verändertem Greifer 13 Ozielle 14 Apache

Markteinführung eines Produktes Subversion http://subversion.apache.org Stand: 27.06.2011

16

5 Systemintegration Die hier zu entwickelnde Software soll dazu in der Lage sein, eine einfach zu bedienende Simulationsumgebung bereitzustellen. Des Weiteren soll sie den Katana Arm ansteuern und kollisionsfrei zu seinem Ziel bewegen. Das Ziel kann trotz gröÿerer Entfernung zuverlässig angesteuert werden. Der Weg dahin wird mit der inversen Kinematik sowie dem Pfadplaner aus OpenRAVE berechnet.

5.1 ArmControlServer

Der ArmControlServer ist eine von Torben Töniges [Tönig09] entwickelte Software, um verschiedene Arme über das XCF (vgl. Kap. 4.2) ansteuern zu können. Dieser wurde um sowohl eine Simulation für den Katana Arm als auch um die Ansteuerung für den realen Katana Arm erweitert. 5.1.1 Simulation

Die Simulation des Arms ist eine nützliche Funktionalität, um Programmierfehler bereits vor dem Testen an der empndlichen Hardware beheben zu können. Die Simulation wird aus vdemo gestartet (siehe Abb.9.2). Die Software ist so implementiert, das zuerst der ArmControlServerMain startet. Diese Klasse erstellt den XCF Server, der Aufgaben entgegennimmt und an den KatanaSimulator weitergibt der daraufhin eine Verbindung zu OpenRAVE startet. Hier werden die inverse Kinematik und die Trajektorie für den Pfad berechnet (vgl. Kap. 3). Nach der Berechnung bewegt sich der Arm in der Simulation so, wie es ihm gesagt wurde. Entweder macht er einen Bewegungsablauf, schlieÿt oder önet den Greifer, oder bewegt sich zu einer Koordinate im Raum. Um die Benutzung zu vereinfachen wurde darauf verzichtet, dem Greifer explizite Winkel angeben zu können. Diese

17

Abb. 5.1: Die Simulationsumgebung von OpenRAVE mit sich bewegendem Katana Arm. Die rote Linie deutet den abgefahrenen Weg des Greifers an. sind immer so gesetzt, dass das zu greifende Objekt direkt vor der Önung des Greifers steht (vgl. Kap. 3). Bei jeder Bewegung wird zusätzlich eine rote Linie gezeichnet (siehe Abb. 5.1), die den Weg markiert, den der Greifer abfährt. Die Box um den Arm deutet schematisch die BIRON Plattform an. Die Abmessungen sind allerdings korrekt, da mit diesen die Kollisionsdetektion berechnet wird. 5.1.2 Reale Ansteuerung

Die reale Ansteuerung ist eine Erweiterung der Simulation. Hier wird zusätzlich noch der reale Katana Arm mit dem Arm aus der Simulation synchron gehalten. Sowohl der Ursprung als auch die Minimal- und Maximalencoderwerte der Motoren in der Simulation unterscheiden sich von den Werten des realen Katana Arms. Daher musste hier eine Umrechnung gemacht werden. Da jeweils die Minimal- und die Maximalwerte bekannt sind, konnte eine Formel für die Umrechnung durch Linearregression [Dougl06] berechnet werden. Dies ist möglich, da sich sowohl die

18

Motoren in der Simulation und die realen Motoren linear innerhalb ihres Winkelbereiches1 bewegen (siehe Abb. 5.2).

(a) Ein Motor des Katana Arms

(b) Ein Motor der Simulation

Abb. 5.2: Eingezeichnet ist der Winkelbereich eines Gelenkes.

5.2 ArmControlRemoteServer

Der ArmControlRemoteServer ist ein eigenständiges Programm. Dieses wird über die Konsole2 aufgerufen. Über Kommandozeilenargumente3 kann man angeben, was der Arm ausführen soll. Der ArmControlRemoteServer verbindet sich dann über das XCF mit dem ArmControlServer. Nachdem die beiden verbunden sind, sendet der RemoteServer die Anfrage an den Server der die Anfrage nach oben genanntem Schema ausführt (siehe Anhang 9.2). Die Rückgaben, die der Server versendet, werden dann von dem RemoteServer auf der Konsole ausgegeben. So hat man alle Funktionen, die der Server bietet, bequem zur Verfügung.

5.3 Ablauf einer Bewegung des Katana Arms

Um den Katana Arm sowie den simulierten Arm zu bewegen, sind einige Berechnungen notwendig. Erst muss die inverse Kinematik gelöst werden. Als Lösung 1 Bereich,

in dem sich der Motor bewegen kann zur Befehlseingabe und zur Ausgabe der Befehlsergebnisse eines Computers 3 Parameter, die dem Programm beim Start übergeben werden 2 Einheit

19

Abb. 5.3: In dem roten Bereich sind die Komponenten aufgelistet, die immer starten. In dem gelben die, die nur für die Simulation verwendet werden und in dem grünen die, die für die Bewegung des realen Katana Arms benötigt werden. Vdemo wird von einem PC aus gestartet. Aus vdemo kann man dann den ArmControlServerMain starten. Dieser sendet die Daten der Aufgaben an den KatanaSimulator für die Simulation oder an den KatanaConnector für die reale Bewegung. Diese Komponenten senden die Daten aufbereitet an OpenRAVE weiter, das die Bewegungen berechnet und simuliert. Im grünen Bereich werden die berechneten Bewegungsmuster an die KNI geschickt, welche mit diesen den Katana Arm bewegt. erhält man die Motorstellungen, mit denen der Endeektor am Zielpunkt ist. Mit diesen Stellungen kann man dann den Pfadplaner verwenden. Dieser liefert als Ergebnis eine Trajektorie (siehe Abb. 9.3), woraus im Abstand von 0.1 Sekunden Motorkongurationen berechnet werden. Diese Motorkongurationen werden nun alle, wie in Kapitel 5.1.2 beschrieben, in Motorstellungen des realen Katana Arms umgerechnet. Danach werden die Motorstellungen mit dem Versatz von 0.1 Sekunden an die KNI gesendet, die den realen Arm bewegt.

20

6 Evaluation Ziel der Evaluation soll es sein zu überprüfen, ob der Katana Arm weiterhin so präzise ist, wie er es ohne die Erweiterung durch OpenRAVE war. Es soll getestet werden, ob der Arbeitsraum des Katana Arms erhöht wurde. Dann soll untersucht werden, ob die Simulation sich äquivalent zum realen Katana Arm verhält. Als letztes wird die Kollisionsdetektion auf die Probe gestellt.

6.1 Testszenarien 6.1.1 Präzision des Katana Arms

Um zu überprüfen, ob die Präzision erhalten geblieben ist, wurde der Katana Arm mit der Ansteuerung KNI zu 15 Positionen gefahren. Diese Positionen wurden erreicht, indem die einzelnen Motoren angesteuert wurden. Hierbei ist zu berücksichtigen, dass dafür die inverse Kinematik der KNI nicht verwendet wurde. Dann wurden die Endeektor-Koordinaten aus der KNI gelesen und dieselben 15 Positionen mittels OpenRAVE und dessen Pfadplanungsalgorithmus angefahren. Auch hierbei wurde die inverse Kinematik nicht benutzt. Es wurden wieder nur Motorstellungen übergeben. Dann wurden die Endeector-Koordinaten aus der KNI ausgelesen. 6.1.2 Präzision von OpenRAVE

Als zweites sollte die Simulation auf die Probe gestellt werden. Da der Katana Arm in der Realität dieselben Bewegungen macht wie in der Simulation, wurden für diesen Test dieselben 15 Positionen in OpenRAVE angefahren wie aus dem ersten Testszenario. Allerdings wurden die Endeektor-Koordinaten nicht aus der

21

KNI, sondern aus OpenRAVE ausgelesen. 6.1.3 Erweiterung des Arbetisraumes

Als drittes wurde der Arbeitsraum getestet. Dazu wurden der KNI Punkte aus dem Randbereich des Arbeitsraumes gesendet und notiert, ob die KNI die inverse Kinematik für diesen Punkt lösen konnte und ob der Katana Arm diesen dann erreichte. Dasselbe wurde mit OpenRAVE gemacht. Jedoch wurde dies nur in der Simulation überprüft, da der reale Arm bei Bewegungen aus OpenRAVE bisher noch sehr stark ruckelt. Dies wirkt sich negativ auf die Lebensdauer der Motoren aus, weshalb dieser Test nicht in der Realität ausgefüht wurde. Auÿerdem musste keine Orientierung angegeben werden, da auf diese, siehe Kap 5.1.1, bei der Implementierung in OpenRAVE verzichtet wurde. 6.1.4 Kollisionsdetektion

Bei diesem Test sollte der Katana Arm 15 Punkt innerhalb seines Arbeitsraumes aus seiner Ausgangsstellung auf der BIRON Plattform anfahren. Hierbei wurde überprüft, ob es zu einer Kollision mit sich selbst, oder der Plattform gekommen ist. Dieser Test wurde sowohl mit der KNI als auch mit OpenRAVE am realen Arm durchgeführt.

6.2 Ergebnisse 6.2.1 Präzision des Katana Arms

Beim ersten Test ist immer derselbe Wert als Endeektorposition ausgegeben worden. Zwar ist die Bewegung bis zu der Koordinate deutlich langsamer, aber dennoch sehr präzise. Wie in Abb. 6.1 zu sehen, ist die Präzision bei jedem angefahrenem Punkt zu 100 % gegeben.

22

Abb. 6.1: Die Grak zeigt, das der Katana Arm mit OpenRAVE immer zu 100 % zu der selben Koordinate gefahren ist wie mit der KNI.

6.2.2 Präzision von OpenRAVE

Bei dem zweiten Test, ist das identische Ergebnis für die Endeektorposition in der Simulation und durch die KNI errechnet worden. Dies ist ebenfalls in Abb. 6.1 zu erkennen. 6.2.3 Erweiterung des Arbetisraumes

Für den dritten Test wurden folgende Koordinaten aus dem Randbereich des Arbeitsraumes an die KNI und OpenRAVE übergeben. Position\Nummer X-Koordinate in mm Y-Koordinate in mm Z-Koordinate in mm

1 170 10 390

2 150 10 420

3 100 10 420

4 0 10 430

5 -30 10 427

6 -50 10 440

7 -100 10 420

8 -150 10 400

9 200 10 380

Tabelle 6.1: Die Tabelle zeigt die Positionen, die der Endeektor für den dritten Test anfahren musste. Jeder dieser Punkte wurde mehrfach angefahren. Das Ergebnis war jedoch immer dasselbe. Darum wird hier aufgeführt, wann die inverse Kinematik der KNI eine Lösung berechnen konnte und wann der Katana Arm sich zu dieser bewegt hat (siehe Abb. 6.2). In der zweiten Grak (siehe Abb. 6.3) sieht man, wann die in-

23

Abb. 6.2: Die Grak zeigt, dass die KNI für einige Punkte die inverse Kinematik oder die Bewegung zu dem Zielpunkt nicht berechnen kann. verse Kinematik aus OpenRAVE eine Lösung gefunden hat und ob der Arm in der Simulation zu der Koordinate fahren konnte. Es lässt sich ablesen, dass die inverse Kinematik aus OpenRAVE 20 % mehr Lösungen ndet, als die der KNI. Es wird nur dann keine Lösung gefunden, wenn der Arm physikalisch nicht an diese Position fahren kann.

Abb. 6.3: Die Grak zeigt, dass der inverse Kinematik Löser sowie die Pfadplanung in OpenRAVE immer zum Ziel geführt haben, wenn es physikaisch möglich war.

6.2.4 Kollisionsdetektion

In dem letzten Test kann man sehen, dass es der KNI nie gelungen ist, den Arm sicher aus der Plattform herauszudrehen. Der Arm kollidierte bei jedem Versuch mit der BIRON Plattform (siehe Abb. 6.4). Allerdings ist es OpenRAVE immer gelungen, einen kollisionsfreien Pfad aus der Plattform zu nden.

Abb. 6.4: Die Grak zeigt, dass es bei jedem Versuch mit der KNI zu einer Kollision gekommen ist. Jedoch nie bei OpenRAVE.

24

6.3 Analyse

Zusammenfassend lässt sich sagen, dass der Katana Arm seine Präzision beibehält. Diese Präzision ist sowohl für die Trajektorienplanung, als auch für das sichere Greifen von Objekten sehr wichtig. Der Katana Arm ist nicht nur in der Realität sehr präzise, sondern auch in der Simulation. Daher ist die Simulation ein gutes Werkzeug, um den realen Katana Arm ohne Nachteile in der Entwicklung zu schonen. Da der Arm Kollisionen mit sich selbst oder der BIRON Plattform immer vermieden hat, kann man sich sicher sein, dass es zu keinen Kollisionen dieser Art kommt. Des Weiteren ist die inverse Kinematik aus OpenRAVE deutlich stabiler als die der KNI. Stabiler bedeutet, dass, wenn es eine Lösung gibt, diese auch gefunden und ausgeführt wird. Wenn es je-

Abb. 6.5: Die Katana Arm Stellun-

doch keine Lösung gibt, meldet die inverse Kinematik aus OpenRAVE, anders als die der KNI, dies korrekt. In diesem Punkt ist die KNI sehr willkürlich. Es gibt Punkte, für die die KNI eine Lösung berechnen kann, es

gen im Randbereich des Arbeitsraumes. Ein Groÿteil von ihnen ist durch die KNI nicht erreichbar. (siehe Tabelle 6.1)

dann aber nicht schat, diese Lösung anzufahren. Auÿerdem gibt es Punkte, die die KNI anfahren kann, obwohl sie scheinbar keine Lösung der inversen Kinematik gefunden hat. Dies macht die KNI unberechenbar und für die BIRON Plattform fast unbenutzbar. Daher ist OpenRAVE mit 20 % mehr Lösungen eine sehr gute Alternative.

25

7 Fazit und Ausblick Der ArmControlServer wurde erfolgreich um OpenRAVE und eine Simulation erweitert, die in das Gesamtsystem BIRON integriert wurden. Die Simulation ist intuitiv benutzbar und zeigt zu 100 % an, was der Arm gerade ausführt. Die inverse Kinematik wurde mit der Pfadplanung und Trajektorien-Erstellung aus OpenRAVE kombiniert. Dadurch kann sich der Katana Arm ohne Kollisionen zu den Greifobjekten und zu 100 % sicher aus seiner Plattform heraus bewegen. Die aufwendige, feste Implementierung der Bewegungsabläufe, um den Arm aus der Basis herauszudrehen, wurde durch eine gut zu verwendende Trajektorienplanung abgelöst. Wie in der Evaluation zu sehen, ist der Löser für die inverse Kinematik um 20 % stabiler geworden. Dadurch ist in Zukunft nicht mehr damit zu rechnen, dass der Arm ein Ziel, das im Randbereich seines Arbeitsraumes liegt, nicht erreicht. Daher ist es sinnvoll OpenRAVE sowie die Simulation auf einem Serviceroboter zu benutzen. Weil die Einschränkungen der Plattform und die sich wechselnde Umwelt eine solche Software benötigen. Für die Zukunft muss die ruckelnde Bewegung des Katana Arms bei der Ansteuerung entfernt werden. Die schematische Darstellung der Roboterplattform BIRON, die im Simulator vorhanden ist, konnte durch ein Modell mit mehr Details ersetzt werden. Dieses sollte sich im Raum bewegen können, damit die Simulation noch realistischer wird. Des Weiteren könnte die Trajektorienplanung um sich verändernde Umwelteinüsse wie bewegte Objekte erweitert werden. Dadurch könnten Objekte, die das zu greifende Objekt blockieren, umgangen werden. Dies wäre nützlich um festzustellen, ob verschiedene Objekte aufeinander stehen. Dann kann entweder der 'Stapel' Objekte von oben nach unten abgeräumt werden oder es wird vermieden, dass ein oben liegendes Objekt beim Greifen des unteren herunterfällt. Wenn diese Objekte in der Simulation vorhanden sind, ist es sinnvoll, die Sensoren des Greifers zur Testerleichterung zu integrieren. Es wäre gut, wenn die hier

26

einwickelte Komponente nicht sequenziell sondern parallel in mehreren Threads ausgeführt werden würde. Dies könnte eine Menge Zeit ersparen, denn momentan gibt es nur einen Thread für den Programmuss und einen für die grasche Oberäche. Es sollte aber einen Weiteren geben, der den Arm ansteuert. Dadurch würde die aktuelle Bewegung und die Berechnung für die nächste Bewegung parallel ausgeführt werden. Es sollte in Erwägung gezogen werden, einen neuen Arm zu kaufen. Denn der Katana Arm hat einen doch sehr kleinen Arbeitsraum, was dazu führt, dass viele Objekte nicht erreicht werden.

27

8 Literaturverzeichnis [Bruy04]

Blender for robotics and robotics for Blender, Herman Bruyninckx, Dept. of Mechanical Engineering K.U.Leuven, Belgium, 2004

[Baill85]

J. Baillieul. Kinematic programming alternatives for redundant manipulators. In IEEE Int. Conf. Robotics and Automation, pages 722728, St. Louis, MS, 1985.

[Baill86]

J. Baillieul. Avoiding obstacles and resolving kinematic redundancy. In IEEE Int. Conf. Robotics and Automation, pages 16981704, San Fransisco, CA, 1986.

[JPaul08]

Jan Paulus, Vision Based Mobile Manipulation, 2008

[Lai09]

Sparse Distance Learning for Object Recognition Combining RGB and Depth Informationl, Kevin Lai, Liefeng Bo, Xiaofeng Ren, and Dieter Fox, 2010

[Lin98]

Collision detection between geometric models, Ming C. Lin & Stefan Gottschalk, University of North Carolina, 1998

[Meier90]

Eindimensionale Spline-Interpolations-Algorithmen, Prof. Dr. Helmuth Späth unter Mitarbeit von Dipl.-Math. Jörg Meier Fachbereich Mathematik, Universität Oldenburg, 1990

[DeSan95] R. M. DeSantis (1995). Modeling and path-tracking control of e mobile wheeled robot with a dierential drive. Robotica, 13, pp 401-410 doi:10.1017/S026357470001883X [Tönig09] Torben Töniges, Integration der Greifarmansteuerung für den Einsatz auf einem mobilen Roboter, 2009

28

[Dougl06] Introduction to Linear Regression Analysis, MONTGOMERY Douglas C., PECK Elizabeth A., VINING G.Georey, 05.2006 [Wenz08]

Automatische Konguration der Bewegungssteuerung von Industrierobotern, Michael Wenz, 2008

[Dyn86]

Inverse Kinematic Solutions With Singularity Robustness for Robot Manipulator Control, J. Dyn. Sys., Meas., September 1986

[Ku00]

RRT-connect: An ecient approach to single-query path planning, Kuner, J.J.Jr., LaValle, S.M. 2000

[Beren09] Manipulation planning on constraint manifolds, Berenson, Dmitry; Srinivasa, Siddhartha S.; Ferguson, Dave; Kuner, James J., Mai 2009 [Addis86] The C++ Programming Language, Addison-Wesley, 1986 [Lindh99] Java Virtual Machine Specication, Tim Lindholm , Frank Yellin, 1999 [Lutz11]

Programming Python, Mark Lutz, 2011

[Bruce97] Mastering MATLAB 5: A Comprehensive Tutorial and Reference, Duane Hanselman, Bruce C. Littleeld, 1997 [KORD05] Cutting edge robotics page 47, Vedran Kordic, 2005 [Wred04]

An XML based framework for cognitive vision architectures, S. Wrede, J. Fritsch, C. Bauckhage, G. Sagerer, 2004

29

9 Anhang 9.1 Maÿe des Katana Arms

Abb. 9.1: Die genauen Abmessungen des Neuronics Katana Arms

30

9.2 Flussdiagramm des ArmControlServers

Abb. 9.2: Flussdiagramm des ArmControlServers. Nach dem Starten des ArmControlServersMain (1) aus vdemo (2) wird der XCF Server erstellt (3). Danach wird der KatanaSimulator (4) gestartet. Dieser übermittelt die aus XCF stammenden Anfragen (5) an OpenRAVE (6). OpenRAVE berechnet dann die Motorstellungen und visualisiert den Arm (7). Wenn nicht nur die Simulation gestartet wurde, übermittelt OpenRAVE die berechneten Motorstellungen und Trajektorien an die KNI (8), welche direkt mit dem Arm kommuniziert.

31

9.3 Codebeispiel

1 params−>vgoalconfig= actJointsSimulator ; 2 probot−>GetActiveDOFValues ( params−>vinitialconfig ) ; 3 planner−>InitPlan ( probot , params ) ; 4 planner−>PlanPath ( ptraj ) ; 5 ptraj−>CalcTrajTiming ( probot , TrajectoryBase : : CUBIC ,

true , true ) ; 7 for ( dReal ftime = 0 ; ftime GetTotalDuration ( ) ; 8 ftime += 0 . 1 ) { 9 TrajectoryBase : : TPOINT tp ; 10 ptraj−>SampleTrajectory ( ftime , tp ) ; 11 djoints . push_back ( tp . q ) ; 12 } 13 probot−>SetActiveMotion ( ptraj ) ; 14 for ( int i = 0 ; djoints . size ( ) > i ; i++) { 15 for ( int j = 0 ; j < djoints [ i ] . size ( ) ; j++) { 16 setRealValue ( j , djoints [ i ] [ j ] ) ; 17 } 18 usleep ( 0 . 1 ∗ 1000 ∗ 1 0 0 0 ) ; 19 } 6

Abb. 9.3: Berechnung der Trajektorie. Als erstes wird die Zielkonguration sowie die Startkonguration der Motoren in params gespeichert (1,2). Dann wird der Plan initialisiert (3) und geplant (4). Daraufhin wird die Trajektorie berechnet (5,6). Jetzt werden alle 0.1 Sekunden (7,8) Punkte aus der Trajektorie herausgenommen (10) und abgespeichert (11). Nun wird die Trajektorie im Simulator ausgeführt (13).Als letzter Schritt werden alle Motorstellungen an die KNI übertragen (16). Allerdings wird nach jedem Satz von Motorstellungen wieder 0.1 Sekunden gewartet, um die Simulation und den echten Arm synchron zu halten.

32

9.4 Erklärung

Hiermit versichere ich. die vorliegende Bachelorarbeit selbständig angefertigt und keine weiteren als die angegebenen Hilfsmittel und Quellen verwendet zu haben.

Bielefeld, den 27.Juni.2011 Marcel Dulisch

33