Virtuelles Prototyping einer Robotersteuerung durch interaktive 3D-Simulation Christian Geiger*, Georg Lehrenfeld**, Wolfgang Müller* *C-LAB **Heinz-Nixdorf-Institut Paderborn http://www.c-lab.de/vis Der Artikel stellt Vorgehensweise und Erfahrungen bei der Entwicklung der Steuerungsoftware für den zweibeinigen Schreitroboter Centaurob im Rahmen einer interdisziplinären Projektgruppe an der Universität Paderborn vor. In der Testphase wurde die Steuerung an einem virtuellen 3D-Modell des Roboters simuliert bevor die Software auf das physikalische Modell portiert wurde.

1

Einleitung

In jüngster Zeit findet das Prototyping mit virtuellen 3D-Modellen immer mehr Anwendung wie im Bereich von Gebäudeinnenansichten, Landschaftsarchitekturen, Städteplanung und teilweise bei der CAD-Konstruktion. Das Prototyping umfaßt meist Formgebung und die Einpassung von Gegenständen und Pflanzen in existierende Umgebungen. Anwendungen zum Prototyping von funktionalem Verhalten findet man hier zur Zeit eher weniger. Der vorliegende Artikel beschreibt den Entwurf einer Steuerung des zweibeinigen Schreitroboters Centaurob und die Validierung der Steuerung am virtuellen 3D-Modell. Bei dem Roboter Centaurob handelt es sich nach unserem Wissen um den weltweit ersten stabil schreitenden zweibeinigen Roboter dessen Antrieb der auf dem Prinzip der Stewart-Plattform beruht [5]. Stabil schreitend bedeutet hier, daß der Roboter zu jedem Zeitpunkt der Bewegung stabil auf einem Fuß steht. Die Steuerung basiert auf endlichen Automaten und wurde von uns in der parallelen, synchronen Systembeschreibungssprache Esterel [1] implementiert. Der Test erfolgte an einem 3D-Modell des Roboters in einer virtuellen Simulationsumgebung, die mit der High-Level-Grafikbibliothek OpenInventor entwickelt wurde. Im Vordergrund stand hier die Validierung der korrekten synchronen Ansteuerung der beiden Hexapoden für die Ansteuerung der Beine und des Massenverlagerungssystems zur Steuerung des Schwerpunkts. Zur einfachen Portierung der Steuersoftware auf das physikalische Zielsystem wurde auf hoher Abstraktionsebene eine für beide Systeme gemeinsame Schnittstelle entwickelt. Aufgrund der Einschränkung schon existenter Hardware und Software wurde das Gesamtsystem auf einem Netzwerk mit 5 PCs und - für das virtuelle Modell - einer SGI Workstation mit vier verschiedenen Betriebssystemen (Windows 95, NT, Linux, Irix) implementiert. Das realisierte Modell wurde mit dem physikalischen Ro-

boter auf der Hannover Industriemesse 1998 mit großem Erfolg vorgestellt. Das System fand in einer Vielzahl überregionaler Zeitungen und Fernsehsendungen große Beachtung. Der weitere Artikel beschreibt zunächst einige Grundlagen des am Laboratorium für Konstruktionslehre (LKL) der Universität Paderborn [7] entwickelten Schreitroboters Centaurob. Schwerpunkt des Beitrag bildet anschließend die Entwicklung der Robotersteuerung und insbesondere des Teilmoduls der 3D-Simulation, das zum Testen der entwickelten Steuerung konzipiert wurde. Abschließend werden einige Bemerkungen zur Entwicklung dieser Software im Rahmen der studentischen Lehrveranstaltung gemacht.

2

Mobile Roboter

Dieser Abschnitt führt nach einem kurzen Überblick über mobile Roboter in die Grundlagen des am LKL der Universität Paderborn [7] konstruierten zweibeinigen Schreitroboter Centaurob ein.

2.1

Grundlagen

In den letzten Jahrzehnten kam es zur Entwicklung einer großen Anzahl von Servicerobotern für die verschiedensten Einsatzbereiche wie Produktion/Fertigung, Reinigung, Inspektion, so daß an dieser Stelle zur detaillierten Einführungen in die Thematik an die Literatur in [8,12] verwiesen wird. Mobile Serviceroboter lassen sich u.a. durch ihren Bewegungsfreiraum und ihre Antriebsform unterscheiden. Hier findet man stationäre, schienengebundene und frei navigierbare Maschinen. Zur erdgebundenen Fortbewegung verwenden letztere i.a. Ketten, Schnecken, Räder und Beine. In vielen Fällen bevorzugt man die Vorteile der reibungsarmen Fortbewegungsart mit Rädern oder Beinen. Der Radantrieb wird in der Regel auf ebener Fläche oder im Gelände wegen seiner schnellen und stabilen Fortbewegungsform bevorzugt. Sind höhere Hinternisse oder Treppen zu überwinden oder das Gelände extrem uneben, weicht man öfters auf einen Beinantrieb aus. Die Fortbewegung mit vier und mehr Beinen hat hier den Vorteil, daß sich hier ohne Probleme ein statisch stabiler Gang implementiert werden kann. Von statisch stabil spricht man, wenn der Schwerpunkt des Roboters innerhalb einer Fläche liegt, die durch die Kontaktpunkte von 3 Standbeinen, die den Boden berühren, beschrieben wird. Die meisten zwei- und einbeinigen Roboter (und auch der Mensch) bewegt sich dynamisch stabil fort. Beim dynamisch stabilen Gang muß die Tendenz des Umfallens ständig durch eine entsprechende Regelung in Abhängigkeit des „Gleichgewichtssinns“ ausgeglichen werden. Bekannte Beispiele sind hier Raiberts einbeiniger Pogoroboter und die zweibeinigen humanoiden Schreitroboter P2 und P3 von Honda [6].

2.2

CENTAUROB

Der Roboter Centaurob wurde in der Arbeit von Hampel in [5] konstruiert und später am Labor für Konstruktionslehre (LKL) an der Universität Paderborn realisiert [10,11]. Centaurob wurde als fernsteuerbarer Automat mit Kamera zur Inspektion von kontaminierten Räumen konzipiert.

Centaurob bewegt sich auf zwei ineinander greifenden C- förmigen Füßen, die mit Hexapoden nach dem Prinzip der Stewart-Plattform am Roboterrumpf befestigt sind (siehe Abbildung 1a). Stewart-Plattformen, die aus der Anwendung im Bereich von Flugsimulatoren bekannt sind (siehe Abbildung 1b), bilden eine stabile und dennoch frei bewegliche Verbindung zwischen zwei Flächen. Diese Konstruktion zeichnet sich zum einen durch das geringe Eigengewicht und zum anderen eine hohe Tragfähigkeit aus. Ein Hexapod ist aus 6 Teleskopstangen, den sogenannten Lineareinheiten (LEs), mit Schneckengewinde aufgebaut. Die Lineareinheiten sind am Körper und an den Füßen durch eine kardanische Aufhängung gelagert und werden mit jeweils einem Schrittmotoren angesteuert. Am Fußende jeder Lineareinheit befindet sich jeweils eine Kraftmeßdose. Diese erlauben es, die auf den Fuß wirkenden Kräfte exakt zu erfassen und somit Rückschlüsse auf die Beschaffenheit des Untergrundes oder auf etwaige Hinternisse zu ziehen. Der erforderliche Freiheitsgrad für die Verdrehung der Lineareinheiten in axialer Richtung wird durch die Drehung der Gewindespindel in der Spindelmutter gebildet. Die Fußform ist so konzipiert, daß sie eine Bewegung des Roboters in beliebiger Richtung ermöglicht. Die Ausführung der Beine als Hexapoden in Verbindung mit der beschriebenen Fußform erlaubt es, sowohl den Roboterkörper relativ zu dem auf dem Boden stehenden Fuß zu bewegen, als auch den nicht belasteten Fuß innerhalb der konstruktiven Grenzen beliebig zu verfahren und somit Schreitvorgänge durchzuführen. Ein Roboter dieser Bauart ist somit in der Lage, schiefe Ebenen zu begehen, gerade Treppen, Wendeltreppen und, je nach Dimensionierung der Lineareinheiten, auch höhere Hindernisse zu besteigen. Um den Massenschwerpunkt immer in der Mitte des statischen Bereiches des Roboters zu halten, wird zusätzlich ein Massenverlagerungssystem (MVS) eingesetzt. Das Massenverlagerungssystem besteht aus zwei Zahnkränzen am oberen Rumpf des Roboters an denen zwei Gewichte von jeweils 5 kg entlang der Zahnkränze durch Servomotoren

Abbildung 1a. Centaurob

Abbildung 1b. Stewart-Plattforn

Abbildung 1c. Massenverlagerungsssystem

verschoben werden können (siehe Abbildung 1c). Dadurch wird das Rückstellmoment, welches dem Kippmoment entgegenwirkt, maximal groß gehalten. Das MVS kann darüber hinaus Störungen von außen durch Beschleunigung der Zusatzmassen dynamisch ausregeln. Da diese Konstruktion die Stabilität unter Einhaltung gewisser Restriktionen einen zu jederzeit stabilen Gang. Somit kann die Bewegung der Beine in Verbindung mit der Verschieben der Massen des MVS ohne Regelung als reine Steuerung realisiert werden.

3

Systemarchitektur

Ausgehend von dem in Kapitel 2 beschrieben Roboters wurde das Informationstechnische System zur Steuerung entworfen. Die Steuerung wurde hierbei in die Komponenten grafische Bedienoberfläche (GUI), 3D-Simulation, Bewegungssteuerung und Hardwareansteuerung unterteilt (siehe Abbildung 2). Eine zusätzliche Matrixbibliothek implementiert Funktionen zur Ansteuerung der Linerareinheiten. Grafische Benutzungsschnittstelle Bewegungssteuerung

Hardware

Matrixmodul

BILD 3D

3D

Abbildung 2. Systemarchitektur Die Funktionalität der einzelnen Komponenten läßt sich wie folgt skizzieren: • GUI: Die grafische Oberfläche realisiert die Schnittstelle des Bedieners zum Roboter. Über Knöpfe können die Einzelschritte des Roboters in Richtung und Länge gesteuert werden. Um auf möglichst vielen Plattformen einsetzbar zu sein, wurde die Oberfläche mit Java implementiert. • Bewegungssteuerung: Die Bewegungssteuerung setzt die Benutzerbefehle in Elementaroperationen der Lineareinheiten und des Massenverlagerungssystems unter Zuhilfenahme der Funktionen des Matrixmoduls um. Bei entsprechender Rückmeldung der Kraftmeßdosen wird die Bewegung abgebrochen und ein tastende Bewegung eingeleitet. Die Bewegungssteuerung realisiert die entwickelten Algorithmen durch endliche Automaten, die in der synchron parallelen Programmiersprache Esterel und C implementiert wurden. • Hardware-Ansteuerung: Dieses Modul realisiert die Schnittstelle zu der Ansteuerung der Motoren des physikalischen Roboters. Die Funktionalität umfaßt das Management und Abarbeitung der einzelnen Inkrementalschritte eines Motors und wurde in C++ implementiert.

•

Matrixmodul: Dieses Modul beinhaltet alle notwenigen Funktionen für Matrizenberechnungen zur Steuerung der Stewart-Plattform. Es wurde als eigenständige Komponente entwickelt, um die Bewegungssteuerung und 3D-Simulation unabhängig von dem mathematischen Modell zu entwickeln, das beide Module verwenden. Das Modul wurde auf Basis einer existierenden C++-Bibliothek implementiert [2], welche um die erforderlichen Funktionen erweitert wurde. • Virtuelles 3D-Modell: Analog zur Hardware-Ansteuerung realisiert eine 3D-Simulation die Schnittstelle zum virtuellen Modell sowie das gesamte virtuelle Modell inklusive der Simulation der individuellen Komponenten. Die Schnittstelle entspricht exakt der der HW-Ansteuerung. Die Realisierung erfolgte mittels der Grafikbibliothek OpenInventor unter C++ [13]. Die folgende Abschnitte geben eine Beschreibung des Matrixmoduls, der Bewegungssteuerung und des virtuellen 3D-Modells, wobei der Schwerpunkt auf letzterem liegt.

3.1

Matrixmodul

Die Steuerung der Stewart-Plattform läßt sich als lineare Gleichungssysteme in Form von Matrizen beschreiben. Hierzu wurde das Matrixmodul als Erweiterung der C++-Bibliothek newmath09 [3] zur schnellen Vektoren- und Matrizenberechnung implementiert. Das Matrixmodul führt im Prinzip folgende Berechnungen durch: • Bestimmung der Längen der Lineareinheiten aus der Position und Orientierung der Plattform • Bestimmung der Verfahrgeschwindigkeiten der Lineareinheiten, die zum Erreichen obiger Position nötig ist Ein Problem bestand in der Berechnung der Position der Plattform aus den Längen der Lineareinheiten bei Kollisionen. Translationsvektor und Rotationsmatrix für jedes Bein 6 liefern Gleichungen mit jeweils 12 Unbekannten, bestehend aus 3 Elementen des Translationsvektors sowie den 9 Elementen der Rotationsmatrix. Dieses Gleichungssystem kann effizient nicht eindeutig gelöst werden. Das Problem wurde durch Berechnung der Anfangsposition, die sich durch ein eingeschränktes Gleichungssystem beschreiben läßt, und der Interpolation zur am nächsten liegenden Zwischenposition gelöst. Weitere Aufgaben des Matrixmoduls waren neben der Berechnung der Verschiebung der MVS-Massen unter Berücksichtigung des einzuhaltenden Schwerpunkts die Vermeidung von singulären Punkten der Hexapoden. Singuläre Punkte sind Positionen, in denen das Gesamtsystem instabil wird, da Lineareinheiten parallel zueinander stehen.

3.2

Bewegungssteuerung

Die Bewegungssteuerung übernimmt im System die eigentliche Steuerung oder Koordination des Roboters. Sie erhält über eine Netzwerkverbindung Befehle von der grafischen Bedienoberfläche. Diese werden verarbeitet und auf Steuerbefehle umgesetzt, die von der Hardwareansteuerung bzw. dem virtuellen 3D-Modell über eine gleiche Schnittestelle weiterverarbeitet werden können. Durch die gleiche Schnittstelle beider Modelle wurde eine plattformunabhängige Umgebung geschaffen. Die Steuerung wurde in Esterel implemen-

tiert. Esterel ist eine synchrone, parallele Programmiersprache zur Implementierung von kommunizierenden Automaten mit integrierter Werkzeugumgebung (Simulation und Verifikation) zur Entwicklung der Steuerung reaktiver Systeme [1]. Hierbei wird die eigentliche Steuerung in Esterel spezifiziert während komplexe Datentypen und Zusatzfunktionen in einer konventionellen Programmiersprache wie C oder C++ beschrieben werden. Der aus Esterel generierte C-Code läßt sich hinterher einfach mit den externen C- oder C++Modulen zu einem Programm zusammenbinden. Die durch Esterel erzwungene strikte Trennung zwischen Steuerung und Zusatzfunktionen führt in der Regel zu einer natürlichen Modularisierung der Software in Steuerungs- und Kommunikationseinheiten.

Hauptautomat Navigation

Adjust

Abbildung 3. Bewegungssteuerung Die implementierte Steuerung des Roboters besteht aus einem Hauptautomaten, der zwei parallele Teilautomaten steuert. Der Hauptautomat verarbeitet Signale der Bedienoberfläche und reicht die von ihm nicht bearbeiteten Signale an die beiden Teilautomaten weiter. Der Adjust-Automat dient zum Kalibrieren des Roboters nach dem Einschalten des Systems oder zur Neujustierung des Systems nach längerer Laufzeit. Der Navigationsautomat übernimmt die Berechnung und Steuerung der Bewegungen, wie Vorwärts-, Rückwärtsund Seitwärtsbewegungen. Ausgehend von der Initialstellung, in der sich der Roboter auf einem Standbein befindet, kann die Grundbewegung in zwei Schritten wie folgt skizziert werden: 1. Bewege das freie Bein auf neue freie Position auf dem Boden 2. Verlagere den Oberkörper unter Betätigung des MVS über das freie Bein; hierdurch wird das freie Bein zum Standbein (Standfußwechsel) In Schritt 1 wird die neue Position in Richtung und Abstand relativ zur momentanen Position vorgegeben. Schritt 1 beinhaltet ferner das „Ertasten“ der neuen Position bei Hindernissen oder unebenem Boden. Der durch die Kraftmeßdosen erhaltene Kraftvektor am freien Fußes läßt jederzeit Rückschlüsse auf Kollisionen und die Beschaffenheit des Untergrundes zu und erlaubt somit eine vorsichtig tastende Bewegung beim Anfahren der neuen Position, um so einen sicheren Stand beim Standfußwechsel zu gewährleisten Der Navigationsautomat unterteilt sich in mehrere Teilautomaten, wie in Abbildung 4 dargestellt ist: Inkrementalmanager: Der Automat realisiert die unterste Schicht der Bewegungssteuerung. Bei den zur Verfügung gestellten Befehlen handelt es sich um sehr einfache, parametrisierbare Basisbefehle, welche die verschiedenen Inkrementalschritte einer Bewegung des Roboters bestimmen. Dies kann zum Beispiel das Verfahren eines Beins mit 2 Richtungsvektoren, 2 Geschwindigkeiten und 6 Kippwinkeln als Parameter sein. Nur der Inkrementalmanager kommuniziert direkt mit dem Modul der Hardware-Ansteuerung bzw.

Hauptautomat

Manuell

Sicherheitsmanager

Auto

Bewegungsmanager

Listenmanager

Inkrementalmanager Kräfte Hardware-Ansteuerung virtuelles 3D-Modell Abbildung 4. Der Navigationsautomat dem virtuellen 3D-Modell. Der Inkrementalmanager protokolliert den letzten Inkrementalschritt, um bei einem Abbruch der aktuellen Bewegung wieder in einen wohldefinierten Zustand zurückzukehren. Bewegungsmanager: Der Bewegungsmanager zerlegt komplexere Bewegungsabläufe wie z.B „einen großen Schritt schnell nach vorne gehen“ in Inkrementalschritte. Es ist dabei nicht zwingend, daß jeder Bewegungsablauf auch einen eigenen Teilautomaten besitzt. So kann derselbe Automat nur mit unterschiedlichen Parametern aufgerufen werden und mehrere Abläufe realisieren wie z.B. "schnell gehen" und "langsam gehen". Zum Undo speichert der Bewegungsmanager vor jedem Aufruf jedes Inkrementalschritts die aktuellen Werte wie Position der Beine, Kippwinkel der Füße, aktuelles Standbein. Listenmanger: Dieser Automat erlaubt die Abarbeitung von in ASCII-Dateien definierten Listen von Inkrementalbefehlen. Dies ermöglicht die einfache Erstellung zusätzlicher komplexer Bewegungsabläufe, die zusätzlich zu den vordefinierten komplexen Bewegungen ausgeführt werden können. Der Automat übernimmt das Laden und die Ausführung der Listen. Sicherheitsmanager: Der Sicherheitsmanager ist ein kontinuierlich parallel laufender Automat zur Sicherheitsüberwachung für alle Bewegungen. Er reagiert sofort auf zu hohe Werte der Kraftmeßdosen und auf die Betätigung des Not-Aus-Knopfes und stoppt sofort den gerade ausführenden Automaten. Da dieser Automat ständig Einfluß auf alle anderen Automaten nehmen muß, hat er die höchste Priorität. Auto / Manuell: Dieser Automat erlaubt die Umschaltung zwischen automatischem und manuellem Modus. Der automatische Modus führt die koordinierte Bewegung des Körpers mit den Beinen durch. Im manuellen Modus können Körper und Beine unabhängig voneinander in verschiedenen Richtungen bewegt werden. Dies kann zu Testzwecken oder beim Kalibrieren notwendig sein.

3.3

Virtuelles 3D-Modell

Das virtuelle 3D-Modell wurde zur Simulation des realen Roboters entworfen, um die verschiedenen Bewegungsstrategien in den verschiedenen Entwicklungsphasen der Software schnell und effizient zu testen. Bilder des Modells befinden sich im Anhang dieses Artikels. Durch die Simulation konnten die Tests unabhängig vom realen Roboter durchgeführt werden, was verschiedene Vorteile während des Projektverlaufs bot: • Unabhängigkeit: Da die Entwicklung in verschiedenen Teams an unterschiedlichen Orten stattfand, jedoch nur ein realer Prototyp zur Verfügung stand, der sich ebenfalls im Aufbau befand, konnten die verschiedenen Teilmodule nebenläufig und weitestgehend unabhängig voneinander entwickelt und getestet werden. • Geschwindigkeit: Die im ersten Prototyp verwendeten Schrittmotoren, die zur Ansteuerung der Lineareinheiten verwendet wurden, ermöglichten nur eine Geschwindigkeit von 0,01m/s. Dadurch waren Tests, selbst als das physikalische Modell zur Verfügung stand, nur mit erheblichem zeitlichem Aufwand durchzuführen. Die Simulation hingegen bot die Möglichkeit der ca. 10-mal höheren Geschwindigkeit gegenüber dem realen Modell. • Wirksame Visualisierung: Im virtuellen Modell konnten weitere Informationen, wie Lage des Schwerpunkts, sicherer Bewegungsbereich und Kollisionen einfach dargestellt werden. Die 3D-Visualisierung ermöglichte zudem mehrere Kamerasichten. • Interaktive Illustration: Zur Präsentation des Prototyps bot das virtuelle 3D-Modell zudem die Möglichkeit, daß ein Benutzer das virtuelle Modell in einer 3D-Umgebung selbst steuert. Auf einer Silicon Graphics Indigo 2 wurde in der Simulation dabei durchgängig eine Framerate von ca. 20 Bildern pro Sekunde erreicht, was auch bei freier Navigation im virtuellen Raum eine flüssige Darstellung gewährleistete.

3.4

Simulation und Animation des Roboters

Ziel der Entwicklung war die Simulation des Roboters in dem vorgegebenen Projektzeitraum. Dabei war von vornherein klar, daß eine vollständige physikalische Simulation nicht in Frage kam, da diese zu aufwendig war. Für das visuelle Testen der Bewegungsalgorithmen auf dem vorgegebenen Parcours genügte ein relativ einfaches Modell, bei dem das Verfahren der Lineareinheiten und die Rotation des Massenverlagerungssystems die einzigen Stellwerte repräsentieren. Meßwerte in diesem hauptsächlich gesteuerten System sind die Rückmeldungen der Kraftmeßdosen an den Füßen, die in der Simulation durch eine einfache Kollisionserkennung und -visualisierung ermöglicht wurden. An vorgegebenen Daten gab es daher nur die Ausmaße des Roboters, die in die Darstellung und in die Berechnung einfließen. Bei der 3D-Darstellung des physikalischen Modells ist zwischen dem am Bildschirm dargestellten geometrischen Modell und dem Kollisionsmodell zu unterscheiden. Letzteres ist stark vereinfacht, da bei dem Bewegungsablauf eines stabil schreitenden Roboters stets nur eine Kollision zwischen dem freien Fuß und einem Parcours-Element registriert werden muß; der Standfuß steht hierbei stabil. Bei der Kollisionserkennung wurden zudem nicht

so detaillierte Elemente benötigt wie sie bei der Konstruktion zur Verfügung standen. Die Füße wurden durch je 6 Quader und einen flachen Zylinder dargestellt. Das gesamte 3D-Modell des Roboters besteht aus den folgenden masselosen Elementen, die sich ohne Reibung zueinander bewegen und in ihrer Form stark vereinfacht sind: • zwei Füße, die relativ zum Roboter-Koordinatensystem beliebige Positionen und Winkel einnehmen können. Ergänzt werden diese Modelle um die oben erwähnten „Kollisions-Füße“. Letztere werden normalerweise nicht dargestellt. Beim Setzen eines Schalters werden die Defaultmodelle durch das gröbere Kollisionsmodell ersetzt. Dieses bietet den Vorteil, daß das kollidierte Element rot gefärbt wird, so daß eine genauere Lokalisierung der Kollision möglich ist. • je Fuß 6 Lineareinheiten (je zwei ineinandergesteckte Zylinder, deren Verschiebung der Länge entspricht), die am oberen Ende fest am Roboter befestigt sind und unten den Füßen folgen. Optional können diese entsprechend der Entfernung zum singulären Punkt eingefärbt werden. Je näher sich der Fuß einem singulären Punkt nähert, desto mehr färbt sich das Bein rot. • der Körper, der aus verschiedenen einfachen 3D-Primitiven besteht. Die Abdeckung des Massenverlagerungssystems (MVS) kann wahlweise transparent dargestellt werden. Die beiden Massen des MVS bewegen sich in einer Rotation um die Senkrechte. Zusätzlich können folgende Eigenschaften des Systems optional visualisiert werden: • Der Schwerpunkt des Roboters wird als dünner Pfeil vom Roboterkoordinatenursprung zum Schwerpunkt dargestellt und von der Matrixbibliothek berechnet. • Der sichere Bewegungsbereich (mit und ohne Massensverlagerungssystem) wird durch semi-transparente Kreise dargestellt, die den Roboter umgeben. • In zwei Fenstern kann neben einer Sicht auf das Gesamtsystem zusätzlich die in der Endversion zu Inspektionszwecken geplante Videokamera simuliert werden. Eine stereoskopische Darstellung mittels Shutterbrille ist außerdem möglich. Die virtuelle Umgebung, in der sich der Roboter bewegt, besteht aus zwei Elementen: einem Parcours und einer Tempelszene. • der Parcours besteht aus sechs Quadern, die aneinandergereiht sind und ein Quadrat formen. Diese (sehr einfachen) Elemente werden direkt für die Kollisionserkennung verwendet und entsprechen dem echten aus Holz gefertigten Parcours. • die Tempel-Szene modelliert die Umgebung und erfüllt keine wirkliche Funktion. Sie dient lediglich dazu, die Orientierung im Raum zu vereinfachen und die Visualisierung ansprechender zu gestalten. Eine Simulation von Gravitation und Reibung war im gegebenen Zeitrahmen nicht praktikabel, da hierzu eine vollständige, dynamische Simulation nötig ist. Daher wurde ein anderer Weg beschritten, um den Roboter auf dem Boden zu halten und vorwärts zu bewegen. Zu Beginn befindet sich der Roboter zunächst in einer korrekten Position, d. h. er steht auf einem Parcours-Element. Wird nun ein Fuß bewegt, so verändert sich dessen Position relativ zum Roboter. Bei einer Bewegung des Standbeins wird nun zusätzlich der Roboter

entgegengesetzt bewegt, so daß der Standfuß an seinem Platz stehen bleibt. Dabei wurde die Berechnung stark vereinfacht, indem die Rotation des Standbeins nur um die Senkrechte berücksichtigt wurde. Der Fuß vollzieht die gesamte Transformation, also auch die Rotation um alle drei Achsen; der Roboter dreht bei den beiden waagerechten Achsen aber nicht gegen. Dies hat die Konsequenz, daß der Roboter sich nicht zur Seite oder vor- und zurücklehnen kann. Der Wechsel des Standbeins ist ein zentrales Ereignis: Die Position des bisher bewegten Fußes muß in Welt-Koordinaten bestimmt werden und dient dann als Grundlage für die weiteren Berechnungen der Roboterbewegung. Auf die Korrespondenz zur Schnittstelle der Hardwareansteuerung mußte in einem Punkt verzichtet werden: Von der Bewegungssteuerung erhält diese nur die Längen der Lineareinheiten. Damit ist in der Realität die Lage des Fußes eindeutig bestimmt, da sie sich mechanisch einstellt. Eine Simulation dieses Verhaltens war nicht möglich, da die zugehörigen (nichtlinearen) Gleichungssysteme nicht effizient lösbar sind. Für diesen Fall liefert die Bewegungssteuerung dem 3D-Modell zusätzlich die Koordinaten (Position und Winkel) der Füße. Diese werden zusammen mit den Längen der Lineareinheiten und den MVS-Winkeln linear interpoliert. Die reale Fußbewegung ist jedoch nicht wirklich linear, was bei den verwendeten, hinreichend kleinen Inkrementalschritten jedoch nicht zu sichtbaren Fehlern führt. Es wird daher die richtige Zielposition erreicht, an der dann der nächste Inkrementalschritt ansetzt. Bei der Berechnung des Kraftvektors wurde eine weitere Vereinfachung vorgenommen. Statt der Werte der 12 Kraftmeßdosen, die in der gegenwärtigen Simulation nicht vorliegen, wurde nur ein grob genäherter dreidimensionaler Kraftvektor übermittelt.

3.5

Softwareumgebung

Die 3D-Modell besteht aus 3 Software-Modulen: • Schnittstelle zur Bewegungssteuerung (identisch zur Hardware) • Warteschlange für die Inkrementalschritte • Simulation und Darstellung Kommunikationsthread

3D-Simulation

Befehlsqueue

Simulation

Matrixbibliothek

Rendering, Windowmanager

Abbildung 5. Softwarearchitektur des Moduls 3D-Simulation Dies ermöglicht ein asynchrones Ausführen der einzelnen Schritte: Ein Schrittbefehl wird entgegengenommen, in die Warteschlange eingereiht und dort von der Simulation entnom-

men. Zur Realisierung des Gesamtmodells wurde folgende Software verwendet: • RapidApp von SGI zur Gestaltung der Oberfläche. Die meisten Klassen (und damit auch Dateien) wurden von dieser Anwendung erzeugt. Details werden hier allerdings nicht weiter erläutert [14]. • Open Inventor von SGI zur grafischen Darstellung. Open Inventor wird ein (gerichteter, azyklischer) Szene-Graph übergeben, der die Szene anhand von Primitiven und Transformationen beschreibt. Diese Szene wird automatisch dargestellt, wobei der Benutzer sich frei in der Szene bewegen kann (siehe [13]). • I-Collide zur Kollisionserkennung, da Open Inventor in der vorliegenden Version keine solche besitzt [2]. I-Collide ist sehr schnell, benötigt aber eine eigene SzeneBeschreibung, so daß eine Konvertierung realisiert werden mußte. Der Ansatz der Kollisionserkennung in I-Collide ist, die Anzahl paarweiser Vergleiche möglichst zu reduzieren. Im Gegensatz zu O(n*n) Vergleichen bei n zu testenden Objekten reduziert I-Collide die Anzahl der Vergleiche auf O(n+m), wobei m die Anzahl der Objekte ist, die sich „sehr nahe“ sind. Dies erfolgt, indem jedem Körper ein begrenzendes Volumen zugeordnet wird (Bounding Volume). Die Volumina werden sortiert, um Überlappungen Schnittstelle

*Werte in Warteschlange setzten *Kraftmeßdosen werte aus Tabelle liefern

*Rücksetzen Szene *Status liefern *Stopbit setzten / löschen *LE’s vergleichen

Warteschlange für Inkrementalschritte

Start Objekte laden

Ja IncrStep verarbeitet ? Nein Interpolation der LEi’s

Init Kollisions Warten auf Ergebnisse der Bewegungssteuerung

Neue Schritte Warteschlange delta-t berechnen Nein

Systemzeit holen

reset Szene

Berechnung Fußposition und Lage

Schritt vorhanden?

Optionale Visualisierung mitMatrixbib be rechnen

Ja

Kollisionserkennung, Rendern

Interpolation des MVS Nein

Ja

Stopbit gesetzt?

Min Länge erreicht Ja

Nein

Kollision? Ja Werte für Kraftmeßdosen aus Tabelle

Stopbit setzen

Abbildung 6. Der Robotersimulationszyklus

Nein

festzustellen. Nur Elemente mit überlappenden Volumen sind sich nah und werden detailliert auf Kollision überprüft. Die Sortierung erfolgt auf Basis eines Sweep-and-Prune - Algorithmus (vgl. [2]). Die Arbeitsweise des Gesamtsimulationssystems ist in Abb. 6 dargestellt: Nach dem Start, dem Laden der Objekte und der Initialisierung der I-COLLIDE - Bibliothek wird der Roboter in Ausgangsposition gesetzt und die Hauptschleife gestartet. Das Stopbit wird abgefragt: Bei nicht gesetztem Bit wird die Systemzeit angefordert und dann die Werte der Lineareinheiten und der Massen interpoliert. Wenn kein Inkrementalschritt mehr in Bearbeitung ist, wird vorher ein neuer aus der Warteschlange entnommen. Ist diese leer, wird gewartet. Falls die Lineareinheiten zu weit eingefahren sind bzw. ihre maximale Auslenkung besitzen, wird automatisch das Stopbit gesetzt. Sonst wird aus den 12 Längen der Lineareinheiten die aktuelle Fußposition und -lage berechnet. Die Szene wird mit Hilfe von Open Inventor neu gerendert, wobei Kollisionen erkannt werden. Bei einer Kollision, werden passende Werte für die Kraftmeßdosen aus vorberechneten Tabellen entnommen.

4

Zusammenfassung

Durchgeführt wurde die in diesem Beitrag beschriebene Arbeit in einer interdisziplinären Projektgruppe als Veranstaltung des Fachbereichs Mathematik / Informatik der Universität-GH Paderborn im Wintersemester 97/98. 13 Informatikstudenten und fünf Studenten des Maschinenbaus entwickelten die zur Funktion des Roboters benötigte Steuerung. Für jedes Modul wurde eine Untergruppe gebildet, wobei jedoch die Zugehörigkeit zu einer Gruppe variable war, da im Laufe der Entwicklung unterschiedliche Schwerpunkte gesetzt werden mußten. Nach eine Einarbeitungsphase, in der die notwendigen Grundlagen vermittelt wurden, begann die Realisierung Anfang Januar 1998. Bereits zur Deutschen Industriemesse Hannover im April konnte ein funktionsfähiger Prototyp vorgestellt werden, der rege Beachtung bei Messebesuchern, Zeitungen und im Fernsehen fand. Eine Reihe von Bildschirmabzügen des virtuellen Modells und Fotos des realen Systems befindet sich im Anhang. Neben dem erfolgreichen Abschluß einer Projektgruppe war insbesondere die Zusammenarbeit von unterschiedlichen Disziplinen eine wertvolle Erfahrung für die Teilnehmer dieser Lehrveranstaltung. Unter den gegebenen Rahmenbedingungen stellte sich sich sowohl die Modularisierung der Software als auch der gewählte Ansatz des Prototyping der Steuerung in virtueller Umgebung als höchst effizient heraus.

Danksagungen Die Projektgruppe wurde an den Lehrstühlen von Prof. Rammig und Prof. Jorden durchgeführt. Für die Betreuung der Projektgruppe seitens des Maschinenbau standen Prof. Schlattmann und J. Hampel zur Verfügung. Teilnehmer der Projektgruppe waren: T. Andree, E. Berendes, M. Blömeke, A. Hoerster, J. Krokowski, P. Malamos, A. Meyer, M. Rasch, Ch. Reimann, R. Schaefer, H. Staesche, H. Stahlschmidt, J. Stoecklein, T. Weber, B. Wellermann, H. Zabel. U. Hansjürgens führte eine Studienarbeit in Rahmen der Projektgruppe durch. Unterstützung seitens der Elektronik lieferte R. Mueller-Eschenbach.

5 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

[11] [12] [13] [14]

Literatur G. Berry, S. Ramesh, R.K. Shyamasundar. Communicating Reactive Processes. Proc. 20th ACM Conf. on Principles of Programming Languages, Charleston, Virginia, 1993. J. Cohen, M.C. Lin , D. Manocha, B. Mirtich, M. K. Ponamgi, J. Canny . I_COLLIDE Documentation. Technical Report University of North Carolina at Chapel, November 1995. http://www.cs.unc.edu/~geom/I_COLLIDE.html R.B. Davies. Documentation for newmat09 - A matrix library in C++. Wellington, New Zealand, September 1997. http://webnz.com/robert/nzc_nm09.html N. Halbwachs. Synchronous Programming of Reactive Systems. Kluwer, Amsterdam, 1993. J. Hampel. Kontruktive Entwicklung eines statisch stabil laufenden ZweibeinRoboters. Diplomarbeit Universität Paderborn, November 1997. Honda. The Honda Humanoid Robot. WWW, Januar 1999. http:// www.androidworld.com LKL - Laboratorium für Konstruktionslehre. http://wwwfb10.uni-paderborn.de/LKL/LKL.html P.J. McKerrow. Introduction to Robotics. Addison-Wesley, Amsterdam, 1990. Projektgruppe Zweibein. Abschlußbericht. Universität Paderborn, Paderborn, 1999. J. Schlattmann. Development of a two legged robot for use in complex environment. in Proc. 30. International Symposium on Automative Technology and Automation (ISATA). Florenz, Italien, Juni 1997 J. Schlattmann. Development of a highly flexible two-legged walking device. in Proc. 4th International Conference on Computer Integrated Manufacturing. Singapur. 1997 G. von Randow. Roboter - Unsere Nächsten Verwandten. Rowohlt Verlag, Hamburg, 1997. J. Wernecke. The Inventor Mentor: Programming Object Oriented 3D Graphics with Open Inventor - Release 2. Addison-Wesley 1994 D. Young et.al.. Developer Magic: RapidApp User's Guide. Silicon Graphics, 1995.

6

Anhang: Bildschirmabzüge und Fotos

oben: Virtuelles Modell Kamerasicht, MVS, Gesamtsicht, 3D-Viewer, Füße unten: realer Roboter, Projektgruppenteilnehmer „Zweibein“