MODULBASIERTES HARDWARE-DESIGN FÜR AUTONOME MOBILE MEHRZWECK-ROBOTER

Transkript

1 TAGUNGSBAND -1- MIKROELEKTRONIK 2003 MODULBASIERTES HARDWARE-DESIGN FÜR AUTONOME MOBILE MEHRZWECK-ROBOTER Gerald Steinbauer 1, Arndt Mühlenfeld 1, Roland Koholka 3, Robert Röhrer 2, Harald Hartl 2, Franz Wotawa 1 1 Institut für Softwaretechnologie, Technische Universität Graz {steinbauer, amuehlen, wotawa}@ist.tugraz.at 2 Institut für Elektronik, Technische Universität Graz {robert.roehrer, harald.hartl}@tugraz.at 3 Knapp Logistik Automation Graz koholka@knapp.com Zusammenfassung: Dieser Artikel beschreibt einen Designansatz für mobile Roboter der Problemefelder anderer Ansätze vermeidet. Diese Problemfelder sind Robustheit, Wiederverwendung und Austauschbarkeit von Komponenten, Flexibilität und Adaptierbarkeit. Der Ansatz basiert auf einer durchgehenden Modularisierung der Hard- und Software. Wir präsentieren den Modulansatz und praktische Resultate des Designansatzes, den wir in der Entwicklung einer neuen Roboterplattform für die RoboCup Middle Size League (MSL) verwendet haben. EINFÜHRUNG Das Design robuster und flexibler Hard- und Software für einen mobile Roboter stellt eine herausfordernde Aufgabe dar. Ein gutes Design sollte Robustheit, Flexibilität, einfache Austauschbarkeit und Wiederverwendung von Komponenten, eine zuverlässige Kommunikation zwischen den Komponenten und eine einfache Adaption des Systems für neue Aufgaben gewährleisten. Um diese Ziele zu erreichen haben wir einen Designansatz für mobile Roboter entwickelt, der auf einer durchgehenden Modularisierung der Hard- und Software des Roboters basiert. Die Hardware-Modularisierung basiert auf einer Kapselung der verschiedenen physischen Funktionen des Roboters in autonome Module mit definierten Schnittstellen. Die Modularisierung der Software basiert auf zwei Konzepten: (1) Software-Design und (2) Software-Architektur. Ersteres ermöglicht eine Aufteilung der Software in Schichten mit

2 TAGUNGSBAND -2- MIKROELEKTRONIK 2003 steigenden Abstraktionsgrad während sich Zweiteres mit Implementationsdetails, wie Einbindung und Kommunikation von Softwaremodulen, beschäftigt. Die Software- Architektur basiert auf Middleware for Cooperative Robotics (MIRO) [1]. MIRO ist ein CORBA-basiertes Framework für Roboter-Anwendungen. Wir verwendeten diesen Designansatz zur Entwicklung der Roboter unseres RoboCup MSL Teams [2]. Die RoboCup MSL [3] bietet eine ideale Testplattform zur Entwicklung und zum Test neuer Ansätze in der Robotik. In der MSL spielen Teams von bis zu vier vollkommen autonomer Roboter auf einem 10 x 6 m großen Feld gegeneinander Fußball. Die Roboter dürfen eine Größe von bis zu 60x60x80cm (BxTxH) haben und müssen sämtliche Ausrüstung (Sensorik, Rechner, Stromversorgung) am Roboter haben. Die Roboter müssen vollkommen autonom agieren und es sind keinerlei Eingriffe von Außen erlaubt. Einzig eine Kommunikation zwischen den Roboters ist gestattet. Alle bei mobilen Robotern auftretenden Problemfelder, wie Mechanik, Elektronik, Bildverarbeitung, Sensorik, Sensor Fusion, Entscheidungsfindung um nur einige zu nennen, müssen zufrieden stellend gelöst werden, um in der MSL erfolgreich zu sein. Die für das MSL-Szenario entwickelten Ansätze lassen sich auch für allgemeinere Aufgaben adaptieren und bringen uns dem Ziel, mobile Roboter zu entwickeln, die in einem allgemeinen und eventuell unbekannten Umfeld agieren können, einen Schritt näher. Durch den Modulansatz lassen sich unsere Roboter neben Roboter-Fußball sehr leicht für andere Serviceaufgaben adaptieren ohne das gesamte Konzept der Roboter zu ändern. HARDWARE DESIGN In vorhergehenden Studien fanden wir vier Funktionen, die nötig sind damit ein mobiler Roboter eine gegebene Aufgabe in einem gegebenen Umfeld erfüllen kann. Diese Funktionen sind: (1) Bewegung, (2) Wahrnehmung der Umwelt, (3) Manipulation der Umwelt und (4) Informationsverarbeitung. Die Charakteristik der Fähigkeiten kann von Aufgabe zu Aufgabe verschieden sein, z.b. ein Kickmechanismus während eines RoboCup-Turnieres oder ein Roboterarm mit Greifer während Servicearbeiten. Eine Kapselung dieser Funktionen in verschiedene lose gekoppelte Module ist der erste Schritt in Richtung flexiblen Hardware- Design. Daher wurde die Hardware der Roboter in vier Schichten aufgeteilt. Jede dieser Schichten implementiert eine der oben erwähnten Funktionen. Die einzelnen Schichten werden gestapelt und ergeben die Roboterplattform (siehe Abbildung 1).

3 TAGUNGSBAND -3- MIKROELEKTRONIK 2003 Abbildung 1: Die modularisierte Roboter-Plattform Das Design der verschiedenen Schichten ist nur soweit eingeschränkt, das die Schichten die geforderte Funktion und drei definierte Schnittstellen zur Verfügung stellen müssen. Die mechanische Schnittstelle sorgt dafür, das sich die einzelnen Schichten mechanisch zusammenfügen. Ein schneller zuverlässiger CAN-Bus sorgt für die Kommunikation zwischen den Schichten. Jede Schicht kann direkt mit allen anderen Schichten kommunizieren. Eine einzelne 24V-Versorgung sorgt für die Versorgung der einzelnen Schichten. Der CAN-Bus und die Versorgung sind durch den gesamten Roboter durchgeführt. Ein Austausch von Schichten mit verschieden Charkteristiken der Funktionen ist leicht möglich, wenn die obigen Bedingungen eingehalten werden. Jede Schicht ist mit einer eigenen Recheneinheit ausgestattet, entweder ein C167 Mikrocontroller oder einem Pentiumbasierter Single-Board-PC. Dadurch kann jede Schicht vollkommen autonom arbeiten. Dieser Umstand vereinfacht zusätzlich den Entwicklungsprozess, da jedes Modul unabhängig entwickelt und getestet werden kann ohne dass das gesamte System bereits fertig gestellt sein muss. Ein Blockdiagramm der Module ist in Abbildung 2 zu sehen. Für die drei untersten Schichten wurde ein Standard-Modul mit dem C167-Mikrocontroller verwendet, das ohne Modifikation für verschiedene Module wieder verwendet werden kann [4]. DRIVING LAYER Der Driving Layer stellt den Antrieb des Roboters zur Verfügung. Im momentanen Design ist diese Schicht durch einen omnidirektionalen Antrieb implementiert. Er wird durch vier um jeweils 90 versetzte Motoren, an die je ein omnidirektionales Rad montiert ist, gebildet.

4 TAGUNGSBAND -4- MIKROELEKTRONIK 2003 Durch individuelle Kontrolle der Geschwindigkeit und Drehrichtung jedes Motors laut eines kinematischen Modells kann sich der Roboter in jede beliebige Richtung bewegen und sich simultan um die vertikale Achse drehen. Diese Eigenschaft verhindert ein Steckenbleiben des Roboters in Ecken und schmalen Durchlässen in einem Büroumfeld und in einem Gedränge während einer Fußballspieles. Diese Schicht nimmt auch die Akku-Packs des Roboters auf um den Schwerpunkt des Roboters möglichst tief zu halten. Abbildung 2: Blockdiagramm Module ACTUATOR LAYER Jede Interaktion mit der Umwelt wird durch den Aktuator Layer durchgeführt. Diese Schicht ist während eines Fußballspieles durch einen pneumatischen Kickmechanismus und während Servicearbeiten durch eine Roboterarm mit Greifer implementiert. SENSOR LAYER Der Sensor Layer stellt die gesamte Wahrnehmung der Umgebung zur Verfügung. Diese Schicht enthält zwei Sensorensysteme. Wir verwenden einen Sick Laser Range Finder für Abstandsmessungen rund um den Roboter. Dieser Sensor hat eine hohe Auflösung (0.5 ) und liefert sehr genaue Messdaten (±1 cm auf 80 m). Für die Anbindung dieses Sensors wurde ein RS422/USB Konverter für nicht standardisierte Baudraten basierend auf dem FT232BM IC entwickelt [5]. Ein Nachteil dieses Sensors ist die Einschränkung des Messung auf 180 rund um den Roboter. Aus diesem Grund wird dieser Sensor von einem weitern Sensorsystem, ein Ring von 24 Sonarsensoren unterstützt. Diese Sensoren haben zwar eine signifikant geringere Messgenauigkeit, bieten jedoch ein qualitatives Bild rund um den gesamten Roboter. Derzeit untersuchen wir zwei verschiedene Implementationen dieses Systems. Eine ausführliche Beschreibung findet sich im Absatz Praktische Resultate.

5 TAGUNGSBAND -5- MIKROELEKTRONIK 2003 CONROL LAYER Die höhere Informationsverarbeitung wird im Control Layer durchgeführt. Diese inkludiert die Verarbeitung der rohen Sensordaten, die Entscheidungsfindung und die High-Level Steuerung. Aus diesem Grund ist diese Schicht mit einem leistungstarken Prozessor, 850 MHz Pentium III Single-Board-PC mit 256 MB Speicher und einer 20 GB Harddisk, ausgestattet. Diese Schicht bietet außerdem einen Kommunikationskanal zu anderen Robotern oder externen Rechnern via Funk-LAN. Auf Grund des nötigen Blickwinkels (Kamera am höchsten Punkt des Roboters) und der Verbindung zum PC mittels der Firewire-Schnittstelle ist die Omnidirektionale Kamera über dieser Schicht montiert. Eine wichtige Randbedingung im Aufbau dieser Schicht war die Verwendung standardisierter Schnittstellen (PCI, USB, Firewire, CAN). Dieser Umstand vereinfacht den Austausch von Komponenten in dieser Schicht. PRAKTISCHE RESULTATE Unsere Erfahrungen zeigen, dass diese Art von Designansatz die Zeit und die Kosten bei der Entwicklung mobiler Roboter reduziert und gleichzeitig die Flexibilität und Robustheit der Roboter erhöht. Durch die Anwendung dieses Designansatzes konnten wir trotz limitierter personellen und finanziellen Resourcen innerhalb eines Jahres ein neues Team von Fußballrobotern entwickeln. Eine Roboterplattform kostet weniger als 9000 Euro und das Basissystem (Hard- und Software) wurde von einer Gruppe von nur neun Studenten implementiert (32 Mannmonate). Ein praktisches Ergebnis zeigt die Vorteile eines modulbasierten Design. Wir entwickelten zwei Versionen des Sensor Layers. Beide Versionen arbeiten im Roboter vollkommen transparent. Eine Version basiert auf den bekannten Sonar- Sensoren von Polaroid (siehe Abbildung 3). Die zweite Version arbeitet mit Sensoren von Devantec (siehe Abbildung 4). Beide Versionen arbeiten mit dem exakt gleiche Layout (24 Sensoren mit gleichen Abstand rund um den Roboter). Der erste Sensortyp hat eine höhere Auflösung (~25 Schallkeule) und eine genauere Messgenauigkeit. Er hat aber auch eine höhere minimale Messdistanz (~15cm). Der zweite Sensortyp liefert zwar schlechtere Messergebnisse (~35 Schallkeule), ist jedoch flexibler und hat eine geringere minimale Messdistanz (3cm). Die Flexibilität dieses Sensortyps ergibt sich durch dessen Anbindung mittels eines seriellen Bus (I 2 C). Dadurch können Feuerverzögerungen und Feuerreihenfolgen sehr leicht durch Software geändert werden [6]. Die Wahl des verwendeten Sensortyps hängt von der Aufgabe ab.

6 TAGUNGSBAND -6- MIKROELEKTRONIK 2003 Abbildung 3: Sensor Layer basierend auf Polaroid Abbildung 4: Sensor Layer basierend auf Devantec SCHLUSSFOLGERUNG Wir präsentieren eine Designansatz für autonome mobile Roboter. Der Ansatz beruht auf einer durchgehenden Modularisierung der Hard- und Software. Roboter-Design die auf diesen Ansatz beruhen sind flexibler in ihrer Anwendung und können leichter für neue Aufgaben adaptiert werden. Die Hardware-Modularisierung basiert auf einer Kapselung der physischen Funktionen. Die Software-Modularisierung basiert auf dem MIRO-Framework. Durch die CORBA-basierte Architektur der Software ist eine Adaption von Software-Modulen und eine Integration neuer Software-Module sehr leicht möglich. Wir werden die neue Roboterplattform im RoboCup Turnier 2003 verwenden, an dem wir als erste österreichische Universität in der MSL teilnehmen werden. Weiters verwenden wir die Roboter für unsere Forschungen im Bereich Systemdiagnose, Bildverarbeitung, maschinelles Lernern, Multi-Agent Systems und Systemdesign. LITERATUR 1. Gerhard Kraetzmar und andere, MIRO Middleware for Cooperative Robotics. In RoboCup 2001: Robot Soccer World Cup V, Lecture Notes in Computer Science, Nummer 2377, Springer, Gerald Steinbauer, Michael Faschinger, Gordon Fraser, Arndt Mühlenfeld, Stefan Richter, Gernot Wöber und Jürgen Wolf, "Mostly Harmelss Team Description". Proceedings of RoboCup-2003 Symposium 3. Kitano H., "RoboCup-97: Robot Soccer World Cup I", Lecture Notes in Artifical Intelligence, Nummer 1395, Springer, F. Mayr, R. Röhrer, V. Surducan, The implementation of a microcontroller sub-board with a sophisticated downloading mechanism. Proceedings of the 4th International Workshop on Basis of Electronics, Technical University of Cluj-Napoca, Romania, 5. Jan Axelson, USB Complete, Second Edition. Verlag Lakeview Research, J. Borenstein, Y. Koren, Error eliminating rapid ultrasonic firing for mobile robot obstacle avoidance. IEEE Transactions on Robotics and Automation, 11(1): , 1995