Autoren:
Datum: 20.02.97
Im Zeitraum vom Wintersemester 1994/1995 bis zum Ende des Sommersemesters 1996 (und darüber hinaus) fand an der Universität Bremen im Fachbereich 3 - Studiengang Informatik - das Projekt SAUS (Sensomotorik autonomer Systeme) unter der Leitung von Prof. Dr. Bernd Krieg-Brückner statt. Der vorliegende Projektendbericht beschreibt die Zielsetzung, den Verlauf und das Ergebnis des Projekts.
Das Projektstudium ist eine Besonderheit des Studiengangs Informatik an der Universität Bremen; ein Projekt bildet einen wesentlichen Bestandteil des Hauptstudiums. Das Projekt erstreckt sich über einen Zeitraum von vier Semestern, in denen sich die Teilnehmer intensiv mit Teilproblemen auseinandersetzen, die zum Erreichen des Projektziels beitragen sollen. Lernziel eines solchen Projektes ist es, eine umfangreiche Aufgabe in Gruppenarbeit zu bearbeiten und zu lösen. Damit werden die Teilnehmenden intensiv mit den Möglichkeiten und Problemen von (möglicherweise fachübergreifender) Gruppenarbeit sowie ihrer Organisation konfrontiert.
Das Projekt SAUS wurde von folgenden Mitgliedern des DFG Graduiertenkollegs Raumorientierung und Handlungsorganisation autonomer Systeme betreut: Andreas Bühlmeier, Holger Dürer, Matthias Heger, Christoph Herwig und Thomas Röfer. Die bis zum Ende des Projekts verbliebenen Teilnehmer sind: Arend Behrens, Michael Czierwitzki, Dominik Dunekamp, Torsten Henneken, Jörg Kollmann, Siegmund Kubon, Jan Kuhlmann, Axel Lankenau, Andree Mädl, Norbert Meyer, Oliver Meyer, Claas Ruschmeyer, Tilman Schröder, Thomas Schwarzenbacher, Patrick Steiner, Henning Tietgens, Albert Wilkens und Jörg Zabel.
Das Projekt SAUS setzte sich mit Fragen und Problemen der Navigation teilautonomer Systeme auseinander. Dies beinhaltet die Themen Sensorik, also Wahrnehmung der Umgebung und der eigenen Bewegung, Motorik (Steuerung der eigenen Bewegung) und Navigation als Planung der Bewegung aufgrund der Wahrnehmungen. Dabei wurde das hochgesteckte Ziel gesetzt, einen Rollstuhl zu konstruieren, der in der Lage ist, seine Umgebung selbstständig zu erforschen, um schließlich beliebig vorgegebene Ziele innerhalb dieser Umgebung sicher - d.h. kollisionsfrei - erreichen zu können. Damit sollte für alte oder schwerbehinderte Menschen die Möglichkeit geschaffen werden, sich relativ unabhängig in ihrer Wohnung bewegen zu können.
Die grundlegende Motivation dieses Themas, sowie ein grober Überblick über den Verlauf des Projektes und die Bildung der verschiedenen Teilgruppen werden im folgenden beschrieben. In den nachfolgenden Kapiteln werden die Arbeiten und Ergebnisse der Teilgruppen dokumentiert. Der Hauptteil dieses Berichts wird mit einer Zusammenfassung der Ergebnisse und einem Ausblick abgeschlossen (Kapitel bericht:Ausblick).
In den Anhängen befindet sich die ausführliche technische Dokumentation der Arbeiten der einzelnen Teilgruppen.
Viele technische Entwicklungen orientieren sich an von der Natur gegebenen Vorbildern; zum Beispiel Flugzeug, Kamera, Ultraschallortung. Auch in der Informatik gibt es Konzepte, die versuchen, natürliche Vorbilder nachzubilden - z.B. neuronale Netze. Deshalb war es naheliegend, auch bei der Definition unserer Zielsetzungen auf solche Vorbilder zurückzugreifen. Da die Navigation bei verschiedenen Tierarten bereits weitgehend erforscht ist, bestand ein erstes Zwischenziel darin, sich mit dem Verhalten von Tieren, wie Ameisen, Bienen und Fledermäusen auseinanderzusetzen, um herauszufinden, welche Sensoren diese Tiere zur Orientierung benutzen und wie sie die Wege zu Futterplätzen und zurück wiederfinden können. Dann sollte untersucht werden, ob es möglich ist, dieses Verhalten mit Hilfe der vorhandenen oder zusätzlicher Sensoren für den Rollstuhl nachzubilden. Auch sollte untersucht werden, ob auf eine metrische Karte zur Navigation verzichtet werden kann, da auch die Natur häufig ohne solches Wissen auskommt.
Mit den in dieser Phase der "Grundlagenforschung" gewonnenen Erkenntnissen sollten dann Gruppen gebildet werden, die sich mit den Teilaspekten autonomer Navigation auseinandersetzen und entsprechende Beiträge implementieren sollten, um schließlich die Komponenten zu einem funktionsfähigen Ganzen zusammenzufügen.
Das Ergebnis sollte ein Rollstuhl sein, der durch Orientierung an Vorbildern der Natur in der Lage ist, seine Umgebung zu erlernen, um sich dann auf günstigen Wegen zu bewegen, und auch dynamischen oder temporären Hindernissen, wie vorbeilaufenden Menschen, auszuweichen.
Im folgenden wird der historische Verlauf mit den wichtigsten Stationen und Ereignissen des Projektes beschrieben. Dieses soll hier völlig wertungsfrei sein, denn Kritik und Ausblick sind in Kapitel bericht:Ausblick zu finden. Es sei noch erwähnt, daß natürlich auch während der vorlesungsfreien Zeit am Projekt gearbeitet wurde, auch wenn aufgrund des historsichen Überblicks ein anderer Eindruck gewonnen werden kann.
Das erste Plenum des Projektes SAUS fand am 27. Oktober 1994 mit sehr vielen Studenten statt (Die genaue Anzahl läßt sich aufgrund der ungenauen Aussagen in den anfänglichen Protokollen nicht mehr feststellen, aber schätzungsweise waren es ca. 25 Studenten.) . Das erste Treffen des Projektes diente vor allem dem Bekanntmachen der Studenten und Kollegiaten bzw. Projektbetreuern und dem genauen Defineren unseres Projektziels. Uns wurde für das erste Projektsemester der Besuch von Vorlesungen über Konnektionismus, Bildverarbeitung und Grundlagen wissensbasierter Systeme als projektbegleitende Veranstaltungen nahegelegt, was aber nicht alle Studenten in die Tat umsetzten. Als vorläufige Tätigkeit des ersten Projektsemesters wurde für die Projektteilnehmer das "Reinschnüffeln" in alle möglichen Bereiche der Robotik und Navigation festgelegt. An dieser Stelle sei eine von Prof. Dr. Bernd Krieg-Brückners (im folgenden mit BKB abgekürzt) Aussagen besonders hervorgehoben, die sich tatsächlich bewahrheitet hat: "Wir machen ein Super-Projekt!"
In den weiteren Treffen des Projektes wurden u.a. die Einrichtung einer Newsgroup zwecks besserer und schnellerer Kommunikation, das Anlegen einer SAUS-Homepage und eines SAUS-Ordners beschlossen. Sowohl Newsgroup als auch der Ordner wurden anfänglich nur mäßig bis gar nicht und im weiteren Projektverlauf überhaupt nicht mehr genutzt. Lediglich die Home-Page und die erst später eingerichtete email-Gruppe grp-saus wurden bis zum Ende des Projektes frequent genutzt.
Die Programme Khoros (digitale Bildverarbeitung), Planet, SESAME (Simulation von neuronalen Netzen) und SimRobot (Roboter-Simulation) wurden uns von den Projektbetreuern vorgestellt, wobei sich Khoros und vor allem SimRobot im weiteren Projektverlauf als wichtigste Werkzeuge herauskristallisierten. Desweiteren fingen wir an, uns mit dem Rollstuhl und den bereits vorhandenen Sensoren auseinanderzusetzen.
Am 7. und 8. Dezember 1994 trafen wir uns zu einer zweitägigen Klausurtagung in der Jugendherberge Worpswede. Ziel war es, sich noch besser kennenzulernen und Vorträge von Projektbetreuern zu hören und viele weitere Details zu besprechen.
Gegen Ende des ersten bzw. Anfang des zweiten Semesters kristallisierten sich die einzelnen Arbeitsgebiete bzw. (fast endgültigen) Arbeitsgruppen heraus:
Auch im zweiten Semester fand ein längeres Projekttreffen statt; diesmal wurde es auf den 4. und 5. Mai 1995 in die Jugendherberge Verden (Aller) gelegt. Auch hier konnten viele noch offene Fragen beantwortet und Vorträge und detaillierte Berichte aus den einzelnen Arbeitsgruppen gehört werden. Hier wurde eine neue (ziemlich endgültige) Gruppenaufteilung diskutiert und beschlossen:
Im weiteren Verlauf des zweiten Semesters wurde trotz heftiger Meinungsverschiedenheiten SGML als Dokumentationssprache und C++ als Programmiersprache für unser Projekt festgelegt; wir bekamen jetzt auch ein eigenes Verzeichnis (/home/saus) mit reichlich Plattenplatz.
Nachdem sich herausstellte, daß die bisherigen Ultraschallsensoren alleine nicht zum Navigieren geeignet waren, wurden weitere Ultraschallsensoren mit einer schmaleren Schallkeule angeschafft.
Die Navigationsgruppe forderte zum ersten mal eine Positionsbestimmung, da Navigationsalgorithmen im allgemeinen auf diese aufbauen. Wir wollten versuchen, diese Aufgabe mit Hilfe von Bildverarbeitung zu lösen. Außerdem beschlossen wir, um den Komplexitätsheitsgrad zu senken, das Einsatzgebiet des Rollstuhls auf Innenräume einzuschränken; so konnte die Positionsbestimmung einfacher gelöst werden.
Jetzt beschäftigte sich die Navigationsgruppe mit dem Parti-Game Algorithmus und dem Long-Ji Lin Ansatz zur Navigation, und es wurde ziemlich kurzfristig entschieden, den Parti-Game Algorithmus zur Navigation auf dem Rollstuhl zu benutzen, und andere Ansätze weiter parallel zu untersuchen.
Vom 5. bis 14. September 1995 fuhren sechs Projektteilnehmer zu einem Robotik-Kurs von Dr. Ulrich Nehmzow (Lehrender an der Universität Manchester in Artificial Intelligence im Fachbereich Computer Science. Außerdem ist er dort zuständig für das Robotiklabor. ) nach Orkney. Der interressierte Leser sei hier auf den Orkney-Bericht (ork95 ) hingewiesen, der diesem Dokument beigefügt ist.
Im dritten Semester fand ebenfalls wieder eine zweitägige Klausurtagung statt, am 9. und 10. November 1995 in der Jugenherberge Syke. Auch wurden hier wieder detaillierte Berichte der einzelnen Arbeitsgruppen vorgetragen und weitere wichtige Fragen für den laufenden Projektbetrieb geklärt.
Jan Kuhlmann wurde nun offizieller SGML-Beauftragter. Die Navigationsgruppe verfolgte ab diesem Zeitpunkt einen weiteren neuen Navigationsansatz, der auf einer festen Grundrißkarte basiert. Auch hier stellte sich heraus, daß für diesen Ansatz eine Positionsbestimmung benötigt wird.
Aufgrund der Erkenntnis, daß eine Positionsbestimmung unumgänglich ist, wurde eine weitere Arbeitsgruppe, die Selbstlokalisationsgruppe, gegründet. Sie setzte sich aus Studenten der Hardware- und Bildverarbeitungsgruppe zusammen.
Bisher hatte das Projekt nur seinen Namen SAUS, aber ein entsprechendes Logo fehlte noch. Daher wurde während des dritten Semesters endlich ein Logo (siehe Deckblatt) für unser Projekt entwickelt.
Der erste Höhepunkt in unserem Projekt bestand darin, daß wir Prof. Dr.-Ing. Axel Gräser (Zuständig für den Bereich Servicerobotik im Fachbereich 1 der Universität Bremen und daher sehr an unserem Projekt interressiert.) und der DASA (Die Daimler-Benz Aerospace AG war an dem gesamten Verlauf unseres Projektes interessiert und hat deshalb die Fahrt nach Orkney gesponsort.) unser Projekt, die bisherigen Ergebnisse und Ziele vorstellen wollten. Hierzu wurde schon einmal der Endbericht "geprobt", denn es mußte ein Zwischenbericht angefertigt werden, der u.a. als Präsentationsunterstützung dienen sollte. Der Vortrag wurde am 8. Februar 1996 gehalten.
Gegen Ende des dritten Semesters einigte man sich auf das Betriebssystem Windows95 und auch die PC-Hardware wurde endlich gekauft. Zusätzlich wurden noch Infrarot-Sensoren für den Rollstuhl angeschafft.
Gleich im ersten Plenum des vierten Semesters wurde die Teilnahme des Projektes am "Tag der Forschung", welcher am 26. Oktober 1996 in der Universität Bremen stattfinden sollte, entschieden (Obwohl das Projekt zu diesem Zeitpunkt offiziell längst beendet sein würde.) . Diese Vorstellung sollte ein schöner Abschluß für unser Projekt werden.
Am 2. und 3. Mai 1996 fand die letzte Projekttagung in der Universität Bremen und nicht in einer Jugendherberge statt. Auch hier waren wieder detaillierte Berichte der einzelnen Gruppen zu hören und es wurden weitere Entscheidungen für das erfolgreiche Fortschreiten des Projektes gefällt.
Im Verlauf dieses Semesters wurde u.a. für die Kommunikation innerhalb unseres Rollstuhlsystems eine Client/Server-Implementierung unter Windows95 vorgenommen und auch die Positionsbestimmung nahm erste Formen an. In den einzelnen Gruppen wurde weiterhin trotz diverser Hindernisse und Stolpersteine fieberhaft auf das nächste Ziel hingearbeitet:
Am 28. Juni 1996 fand in der Universität Bremen der Projekttag des Studiengangs Informatik statt, auf dem alle Projekte, die im Wintersemester 1994/95 begonnen hatten, ihre Ziele und Ergebnisse vorstellten. Für das Projekt SAUS verlief dieser sehr erfolgreich. Zu Beginn unserer Präsentation trug Dominik Dunekamp ein selbst kreiertes Gedicht vor, welches im Anhang gedicht diesem Endbericht beigelegt ist. Der Rollstuhl, sein Konzept, die Hardware, die verschiedenen Navigationsalgrorithmen usw. wurden - eigebettet in einer Rahmengeschichte - vorgestellt. Die Zuschauer (Studenten und Lehrende der Universität Bremen) waren positiv überrascht, denn letztendlich konnten wir nicht nur über unser Projekt und dessen Ziele reden, sondern unseren Rollstuhl auch tatsächlich vorführen: der Rollstuhl fuhr selbständig in den Vortragsraum herein, indem er einen Studenten verfolgte (Siegmund Kubon). Außerdem navigierte er in einer aufgebauten Szene von einem beliebigen Start- zu einem beliebigen Zielpunkt.
Nach diesem erfolgreichen Tag konnten wir uns allerdings nicht ausruhen, sondern mußten auf das nächste Ziel hinarbeiten, den Tag der Forschung. Denn letztendlich sollte hier alles noch besser als auf dem Projekttag funktionieren und so arbeiteten alle weiter an dem Rollstuhl. Es wurde beispielsweise eine manuelle Versionskontrolle festgelegt, damit "Fallbacks" möglich wurden und die Videopositionierung wurde auf zweifarbige Landmarken erweitert.
Am 26. Oktober 1996 stellte sich unser Projekt SAUS auf dem Tag der Forschung vor. Hier soll nicht unerwähnt bleiben, daß selbst die Fernsehnachrichtensendung "Buten & Binnen" von Radio Bremen am Vorabend über den Tag der Forschung, und auch speziell über das Projekt SAUS, berichtete. Aufgrund dieser Tatsache kamen besonders viele Leute zu unserem Stand und wollten den Rollstuhl sehen. Radio Bremen machte im Rahmen seines Hörfunkprogramms ein Live-Interview mit Axel Lankenau. Auch ein leitender Angestellter der Rollstuhlfirma MEYRA sah sich den Rollstuhl an, was BKB gleich zum Knüpfen weiterer Beziehungen nutzte. So wurde der Universität Bremen von dieser Firma ein Rollstuhl der neusten Generation zu günstigen Konditionen überlassen.
Der letzte zeitliche Abschnitt des Projektes SAUS bestand im wesentlichen in der Fertigstellung dieses Dokumentes. Anzumerken bleibt noch, daß sich auch einige Themen für Diplomarbeiten aus diesem Projekt ergeben haben (siehe Kapitel bericht:Ausblick). Für einige Themen gibt es bereits ein paar Interessenten unter den Projektteilnehmern.
Autoren:
Datum: 20.02.97
Zusammenfassung:
In diesem Kapitel wird die Arbeit der Hardwaregruppe im Projekt SAUS beschrieben.
Die Hardware-Gruppe bestand aus den Mitgliedern Michael Czierwitzki, Norbert Meyer, Tilman Schröder, Albert Wilkes und Jörg Zabel. Das Ziel dieser Gruppe war es, den Rollstuhl als funktionsfähige Experimentierplattform für die darauf zurückgreifenden, übergeordneten Navigationsalgorithmen zu gestalten. Dazu war es im einzelnen erforderlich,
Die Sensorik des Rollstuhls setzt sich aus den folgenden Sensortypen zusammen:
Die Ansteuerung der Aktoren bzw. Auswertung der Sensoren wird von Micro-Controllern (sogenannten Knoten) vorgenommen. Diese Knoten sind über eine CAN-Bus-Architektur mit dem PC verbunden. Der CAN-Bus (Controller-Area-Network) ist ein Bus-System, das ursprünglich für die Automobilindustrie entwickelt wurde. Er zeichnet sich dadurch aus, daß eine hohe Sicherheit bei der Datenübertragung erreicht wird.
Insgesamt sind die zur Handhabung der Hardware zur Verfügung gestellten Dienste auf fünf Micro-Controller aufgeteilt. Die konkrete Aufgabenverteilung ist graphisch in der Abbildung
arch veranschaulicht.
(Abbildung:
Bei der Aufgabenverteilung mußte nicht nur auf die beschränkte Rechenleistung der Controller, sondern auch auf die zu beachtenden Sicherheitsaspekte Rücksicht genommen werden. Die sicherheitskritischsten Dienste (Geschwindigkeit und Bumper) wurden auf dem Alpha-Knoten konzentriert. Der Rollstuhl wird bei Ausfall dieses Knotens oder bei einer durch die Bumper festgestellten Kollision direkt über eine elektrische Schaltung gestoppt. Der Ausfall des Alpha-Knotens wird dadurch registriert, daß die Oszillation eines dafür dedizierten MC-Ports entfällt. An dem diesem Port nachgeschalteten Hochpaßfilter liegt dann keine ausreichende Spannung an, um das Relais zur Motorsteuerung zu schalten, wodurch der Rollstuhl angehalten wird. Der Notstop des Rollstuhls erfolgt unabhängig vom jeweiligen Software-Zustand des Gesamtsystems. Denn dies muß auch entgegen anders lautender Befehle vom PC geschehen können oder wenn der PC zwar ein STOP-Signal schickt, der Can-Bus aber aus irgendeinem Grunde gestört ist. Außerdem ist die Reaktionszeit aufgrund der Tatsache, daß primär keinerlei Software dabei im Spiel sein muß, deutlich besser. Um ferner zu gewährleisten, daß die Knoten noch ihre Aufgaben erfüllen und nicht abgestürzt sind, werden von den Knoten in regelmäßigen Intervallen sogenannte Alive-Nachrichten zum PC gesendet. Bleiben für einen Knoten diese Nachrichten über ein definierten Zeitraum aus, wird für die Anwendungsprogramme signalisiert, daß der Knoten nicht mehr aktiv ist. Auf der höheren Ebene muß dann entschieden werden, ob die Aufgaben des Programms weiterhin erfüllt werden können oder aus Sicherheitsgründen gestoppt werden muß. Schließlich wurde noch versucht, das Kommunikationsverhalten zwischen dem PC und den Micro-Controllern mit einer CSP-Spezifikation formal zu erfassen und damit evtl. vorhandene Fehler, wie sie bei verteilten Systemen auftreten können, aufzudecken.
Der Alpha-Knoten leistet die folgenden beiden Aufgaben:
Die Bezeichung Odometrie-Agent wird hier deshalb gewählt, weil der Knoten selbst nur die Raddrehungen der Antriebsräder innerhalb eines vorher vorgegebenen Zeitintervalls bestimmt und die Daten periodisch an den PC schickt, auf dem dann die eigentliche Wegintegration (die eigentliche Übersetzung von Odometrie) passiert. Daraus, daß beide Zählerstände (Räder) sich um einen gleichen Wert fortbewegt haben, weiß man eben nur, daß die Ausrichtung dieselbe geblieben ist (hinreichend, aber nicht notwendig z.B. 360 Drehung). Tatsächlich kann der Rollstuhl abver genausogut eine gerade Strecke wie auch eine "5" oder eine "8" gefahren sein. Um die genaue Position bestimmen zu können, ist es notwendig, (eine mit diesem Verfahren immer diskrete und aus einzelnen Teilstücken bestehende Positionsbestimmung (es werden nur 4*30 Events pro Radumdrehung registriert, nicht unendlich viele)) in soviele genügend genaue Teilstücke zerlegt zu haben, daß nicht nur u.U. die Ausrichtung, sondern auch die Position berechnet werden kann. Die Aufgabe, alle Sensorübergänge mitzubekommen, ist schon bei nicht ganz so glücklicher Eistellung der Sensoren so rechenzeitintensiv (wenn man es nicht per Interrupt macht), so daß es - damals (vor dem Aufbohren der Löcher in der Lochscheibe) noch mehr als jetzt - sinnvoll war, keine anderen Funktionen auf dem Knoten unterzubringen. Daher sieht der Knoten auch noch verhältnismäßig aufgeräumt auf. Der Knoten übermittelt jeweils für das linke und rechte Antriebsrad getrennt folgende Daten : Geschwindigkeit des Rads, gefahrene Strecke des Rads seit dem letzten Zurücksetzen oder Überlauf und einen Radfehlerzähler, der die Anzahl erwarteter aber übersprungener Sensorübergänge darstellt. Der Knoten bietet folgende Funktionsweisen an : Periodisches Senden der Zählerwerte in Vielfachen von 0.1 s, einmaliges Senden oder "deaktiviert". Nicht unerwähnt bleiben sollte, daß die Geschwindigkeit nicht normiert wird, sie ist lediglich die im letzten Zeitintervall zurückgelegte Strecke (X2-X1) zwischen dem räumlichen Anfangspunkt X1 und dem Endpunkt X2 des Zeitintervalls und muß noch durch die Länge des Zeitintervalls DELTA t geteilt werden, um einen Differenzenquotienten zu erhalten. Daher sind "Geschwindigkeitswerte" die mit unterschiedlichen Zeitintervallen für das periodische Senden ermittelt wurden auch nicht vergleichbar.
Der Gamma-Knoten leistet die folgenden beiden Aufgaben:
Die zweite Aufgabe des Knotens beinhaltet die Überwachung der Infrarot-Sensoren. Die sechs Infrarot-Sensoren des Rollstuhls sind direkt über einen Port des Micro-Controllers mit dem Gamma-Knoten verbunden. Jede Statusänderung eines Infrarot-Bumpers veranlaßt den Knoten, automatisch die Zustände aller Infrarot-Sensoren an den PC zu senden. Somit wird sichergestellt, daß sowohl Hindernisdetektionen als auch der Verlust von Hindernisdetektionen erkannt werden. Der Inhalt einer Konstanten im Knotenprogramm entscheidet darüber, ob eine Nachricht, die die Rollstuhlgeschwindigkeit auf Null setzt, zum Alpha-Knoten abgesetzt werden soll, sobald ein Hindernis von den Sensoren erkannt wird. Diese Funktion sollte aktiviert werden, wenn besonders hohe Sicherheitsanforderungen bestehen. Darüberhinaus kann der Knoten auch vom PC explizit aufgefordert werden, den Zustand der Infrarot-Sensoren zum PC zurückzusenden.
Die Aufgaben des Delta- und Epsilon-Knotens betreffen die Ansteuerung und Auswertung der Ultraschall-Sensoren. Beiden Knoten erfüllen hierbei nahezu die gleiche Funktion, sie unterscheiden sich lediglich darin, daß der Delta-Knoten für die 8 Nah-Sensoren und der Epsilon-Knoten für die 4 Fern-Sensoren verantwortlich ist. Die Sensoren sind dabei nicht direkt mit dem Knoten verbunden, sondern werden über jeweils ein Steuer-Gerät (Auswerte-Elektonik, an der max. 8 Sensoren angeschlossen werden können) kontrolliert, das über die serielle Schnittstelle des Knotens angesprochen werden kann.
Durch sogenannte Sende- und Lesemasken wird festgelegt, welcher Sensor bei einer Ultraschall-Messung senden und welcher lesen soll. Werden mehrere dieser von den beiden Knoten verwalteten Sende- und Lesemaskenpaare (Strategien) definiert, arbeitet der Knoten diese zyklisch sequentiell ab. Zur einfacheren Handhabung der Sensoransteuerung, haben wir einige zweckmäßige Strategien fest vorgegeben. Die Ergebnis-Werte dieser Strategien werden vom Knoten selbständig in regelmäßigen Abständen zum PC übermittelt.
Darüberhinaus besteht die Möglichkeit eigene Strategien in den Strategie-Zyklus der beiden Knoten zu integrieren, die entweder regelmäßig oder aber einmalig auszuführen sind. Zu beachten ist lediglich, daß die Umstellung der Auswerte-Elektronik von einer Strategie auf die folgende einige Zeit in Anspruch nimmt, so daß abzuwägen ist, ob für die jeweilige Anwendung die Definition weiterer Strategien sinnvoll ist. Die so hinzugefügten Strategien können aus der Strategie-Liste des jeweiligen Knotens durch entsprechende Nachrichten auch wieder entfernt werden.
Die von der Auswerte-Elektronik und schließlich zum PC übermittelten Entfernungsinformationen werden in cm angegeben und befinden sich im Intervall zwischen 10 cm und 999 cm. Die Ergebniswerte von der Auswerte-Elektronik werden vom Knoten nicht ausgewertet, sondern neutral übermittelt. Der Grund hierfür liegt in den zusätzlich benötigten Informationen und dem relativ komplexen Auswerte-Algorithmus (Berücksichtigung der aktuellen Fahrtrichtung etc.) begründet, der den Micro-Controller hoffnungslos überfordern würde. Demzufolge ist das Modul, das die Kollision des Rollstuhls mit Hilfe der Sonar-Meßwerte verhindern soll, auf dem Rollstuhlrechner implementiert.
Die am PC angebotene Schnittstelle zur Hardware kapselt die Dienste der auf den Knoten geleisteten Aufgaben und stellt diese für die höheren Anwendungen zur Verfügung. Diese Schnittstelle stellt ein Modul des SAUS-Systems dar. Aufgrund des modularen Aufbaus ist es möglich, dieses Modul durch das Simulationsprogramm SimRobot zu ersetzt. Ein Navigationsmodul kann somit beispielsweise, ohne geändert werden zu müssen, zunächst in der Simulation und anschließend am realen Rollstuhl getestet werden. Neben der Kapselung der Hardware-Dienste übernimmt das Schnittstellen-Modul noch zusätzliche Funktionen.
Der Sensor-Schild fragt die Ultraschall- und Infrarotsensoren ab und hält den Rollstuhl bei einer drohenden Kollision an. In diesem Fall wird ein Flag gesetzt, das von den anderen Modulen abgefragt werden kann. Der Rollstuhl kann erst dann wieder bewegt werden, wenn das Hindernis nicht mehr vorhanden ist oder wenn eine andere, hindernisfreie Fahrtrichtung gesetzt wird.
Mit Hilfe der Odometriesensoren wird eine Positionsbestimmung vorgenommen. Die Induktiv-Sensoren an den Vorderrädern des Rollstuhls detektieren hierbei die Lochübergänge der an den Rädern befestigten Lochscheiben. Diese Impulse werden vom Beta-Knoten gezählt und regelmäßig zum PC übermittelt. Aus diesen Werten wird anschließend die neue x- und y-Position sowie die Orientierung des Rollstuhls ermittelt. Die aus den Odometrie-Zählern berechnete Position des Rollstuhls stellt jedoch nur eine der beiden Grundlagen für die Selbstlokalisation des Rollstuhls dar. Da sich die Ungenauigkeiten bei der Odometrie-Positionsangabe mit zunehmender Strecke progressiv erhöhen, wird als zweite Komponente zur Lokalisation des Rollstuhls die Positionsbestimmung auf Grundlage der Bildverarbeitung dazu benutzt, die Positionskoordinaten des Rollstuhls regelmäßig zu aktualisieren. Diese Aktualisierung kann jedoch nur dann erfolgen, wenn die Kamera zur Positionsbestimmung geeignete Landmarken erkennen konnte, was nicht immer garantiert werden kann, da z.B. Landmarken durch Hindernisse verdeckt sein können.
Zur sicheren Übertragung von CAN-Bus-Nachrichten vom PC zu den Micro-Controllern ist ein Protokoll implementiert, welches sicherstellt, daß nur dann eine Nachricht gesendet wird, wenn der Knoten empfangsbereit ist. Dadurch ist gewährleistet, daß keine Nachrichten bei der Übertragung verloren gehen. Dazu melden sich die Knoten in regelmäßigen Abständen und sofort nach dem Bearbeiten einer empfangenen Nachricht beim PC, welcher die nächste Nachricht immer erst dann an den Knoten schickt, wenn dieser das Bearbeiten der letzten gemeldet hat. Außerdem kann der PC so einen ausgefallenen Knoten detektieren. Hat sich ein Knoten zu lange nicht mehr gemeldet, wird er als ausgefallen markiert. Es wird dann solange nicht weiter versucht, Nachrichten zu ihm zu schicken, bis er sich wieder gemeldet hat.
Das Modul, das den Rollstuhl durch eine Engstelle, wie z.B. eine Tür, führen soll, hat genau genommen keinen direkten Bezug zur Hardware. Es ist vielmehr ein Dienst, der den Navigationsmodulen zur Verfügung gestellt wird und ausschließlich diese spezielle Aufgabe erfüllen soll. Da das Module jedoch von Mitgliedern der Hardwaregruppe entwickelt worden ist, soll es dennoch an dieser Stelle kurz vorgestellt werden. Sobald die Navigationsalgorithmen das Türdurchfahren-Modul aufrufen, um durch eine Tür zu rangieren, übernimmt dieses Modul die gesamte Kontrolle über die Steuerung des Rollstuhls. Die Erzeugung der Fahrkommandos wird ausschließlich aus den Entfernungswerten und Signalen der Ultraschall- bzw. Infrarot-Sensoren abgeleitet. Stellt das Modul fest, daß die Engstelle passiert worden ist, wird die Verantwortung für die Rollstuhlsteuerung wieder an die Navigationsalgorithmen zurückgegeben.
Autoren:
Datum: 19. November 1996
Zusammenfassung:
Eingeleitet durch die Suche nach einer passenden Programmiersprache für die Realisierung unserer autonomen Rollstuhlsteuerung, stellte sich auch die Frage nach dem Aufbau und Zusammenhang der einzelnen Module untereinander.
Vor der Implementierung der einzelnen Komponenten des
Rollstuhls stand eine lange Diskussion darüber, ob die
einzelnen Aufgaben (die jede von einer anderen Gruppe
von Studenten implementiert wurde) in einem einzelnen
Programm realisiert werden, oder ob jede Gruppe ein
eigenes Programm entwickeln sollte, das soweit autark
ist, wie es das Gesamtsystem erlaubt.
Bedingt durch zum Teil aufwendige und rechenintensive
Teilaufgaben (z. B. die Bildverarbeitung) wurde
entschieden, die einzelnen Aufgaben nebenläufig arbeiten zu
lassen. Jede Teilgruppe sollte ein eigenes Programm
schreiben, so daß diese als nebenläufige Prozesse auf dem
Rollstuhl - PC laufen konnten.
Um den benötigten Datenaustausch zwischen den einzelnen
Modulen zu ermöglichen, wurde entschieden, die einzelnen
Prozesse über eine Socket - Kommunikation miteinander zu
verbinden. Um zu verhindern, daß jedes Modul mit allen
anderen in Kontakt treten muß, um neue Informationen zu
sammeln, entschieden wir uns, bei der Kommunikation eine
Stern - Topologie zu verwenden. Das Zentrum dieses Sterns
bildet ein Kommunikationsserver, der sowohl die
Kommunikation zwischen den einzelnen Prozessen steuert, als
auch die neuesten Informationen bereitstellt.
(Abbildung:
Autoren:
Datum: 20.02.97
Zusammenfassung:
Kurze Zusammenfassung des Berichtes über die Videopositionierung.
Wie bereits in dem historischen Teil der Einleitung erwähnt, wird für die Navigationsalgorithmen eine Positionsbestimmung benötigt. Da die Bestimmung der Position anhand der Odometriedaten über längere Distanzen zu große Abweichungen aufweist, soll eine exaktere Lokalisation mittels Landmarken erfolgen. Es werden Bilder mit einer Farbvideokamera aufgenommen und mit entsprechenden Bildverarbeitungsalgorithmen ausgewertet. Mit Hilfe der ausgewerteten Daten soll die Position und Ausrichtung des Rollstuhls in einer vordefinierten Umgebung bestimmt werden.
Zur Bestimmung der Position mit Hilfe einer Videokamera werden in einer Szene selbst definierte (zweifarbige) Landmarken angebracht. Aufgrund der Tatsache, daß künstliche (selbst definierte) Landmarken in der Szene angebracht werden, können die genauen Koordinaten, Ausmaße und Farben der Landmarken in dem Gesamtsystem des Rollstuhls fest vorgegeben werden. Letztendlich geht es darum, in einem mit der Kamera aufgenommenen Bild Landmarken zu identifizieren, und mit Hilfe des Vorwissens die Position und Ausrichtung der Kamera zu errechnen. Aus diesen Informationen läßt sich - aufgrund der fixen Montierung der Kamera auf dem Rollstuhl - sehr einfach die Position des Rollstuhls ermitteln.
Um die Position der Kamera zu berechnen, benötigt man
mindestens zwei Landmarken im Bild, was Abbildung
eo verdeutlicht.
(Abbildung:
Autoren:
Datum: 20.02.97
Zusammenfassung:
In diesem Kapitel wird die Arbeit der Navigationsgruppe im Projekt SAUS beschrieben.
Im Laufe des zweiten Projektsemesters begann sich eine Gruppe von Projektmitgliedern herauszukristallisieren, die sich mit der Software auf dem Rollstuhl beschäftigen wollte, insbesondere mit den Algorithmen, die ihn von einem Punkt zu einem anderen fahren lassen sollten. Es entstand die Navigationsgruppe. Wir setzten uns zusammen, um zu diskutieren, welche Möglichkeiten es geben könnte, unser Ziel zu erreichen. Unser Ideal war es damals noch, das Verhalten natürlicher Wesen wie Bienen oder Ameisen bei der Navigation nachzuprogrammieren; wir dachten über neuronale Netze nach und über topologische Karten, wir wollten den Rollstuhl allein aufgrund der Sensoreindrücke durch den Raum bewegen, so daß er -in beliebiger Umgebung ausgesetzt- immer wieder 'nach Hause' finden könnte. Die Analyse der damals zur Verfügung stehenden Sensorik jedoch brachte schnell Ernüchterung in unser Denken: Es standen vier Ultraschallsensoren mit relativ breiter Schallkeule zur Verfügung. Unsere Leitfrage wurde: Können so wenige derart schlecht auflösende Sensoren ausreichen, um sich in einer beliebigen Umgebung zu orientieren?
Je länger wir darüber nachdachten, desto mehr waren wir überzeugt, daß wir unsere Leitfrage negativ beantworten mußten: Wir kamen zu dem Schluß, daß die Sensoren nicht ausreichen konnten. Wenn wir nun aber wüßten, wo wir uns gerade ungefähr befinden, könnten wir unter Zuhilfenahme gespeicherter Werte aus der Vergangenheit (aus Erfahrungen also) die Qualität der Sensoren relativ aufwerten, indem wir in der Umgebung des Rollstuhls nach bestimmten Sensoreindrücken, die wir in der Vergangenheit schon einmal hatten, 'suchen', um die Position des Rollstuhls genauer zu bestimmen und so unseren Weg zum Ziel fortsetzen zu können. Die Ideen der Positionsbestimmung und des Wissensbasis kamen auf.
Bei der Positionsbestimmung dachten wir an eine Einheit, die zu Beginn der Fahrt mit der aktuellen (Referenz-)Position initialisiert wird, und die während der Fahrt z.B. mittels Odometrie (auch die war schon am Rollstuhl vorhanden) ungefähr notiert, wo wir sind. Auf Anfrage hin sollte die Positionsbestimmung mitteilen, welche Position wir aufgrund ihrer Meßdaten haben müßten. Wir wollten diese Position aufgrund unseres Erfahrungsschatzes in Abstimmung mit den derzeitigen Ultraschallsensormeßwerten abgleichen, um so im Gegenzug der Positionsbestimmung eine neue Referenzposition zu geben.
Auf den Erfahrungsschatz sollte während der Fahrt zugegriffen werden können, um die aktuellen Ultraschallsensorwerte mit den Werten des Erfahrungsschatzes in Einklang bringen zu können und damit die Position der Positionsbestimmung verifizieren oder verbessern zu können. Ein derartiger Erfahrungsschatz muß gesammelt und gespeichert werden. Unsere Idee war es, die gemessenen Ultraschallwerte in Abstimmung mit der jeweiligen Position in einer Karte abzuspeichern, die während der Fahrt erzeugt und verändert werden sollte.
Gegen Ende des zweiten Projektsemesters präsentierte Jan Kuhlmann dann stellvertretend für die Navigationsgruppe die erste Lösungsidee für die Navigationsgruppe des Projekts SAUS ( (kuhlmann951 ) und (kuhlmann952 )), die wir gemeinsam entwickelt hatten. Wir hatten versucht, den Themenkomplex Navigation durch Modularisierung zu strukturieren, um später durch Abgabe eines oder mehrerer Module an eine andere Projektgruppe unseren Aufgabenbereich auf ein Maß zu reduzieren, das bewältigt werden konnte. Die Module, die wir identifizierten, waren insbesondere eine Positionsbestimmung, eine Karte, Navigationsalgorithmen ('Wegfinder', wie wir uns damals ausdrückten) und ein Greedy-Controller ('Wegbereiniger', ein Modul also, das ein kinematisch beschränktes Objekt wie einen Rollstuhl ohne Berücksichtigung eventueller Hindernisse so steuern kann, daß es aus einer beliebigen Position und Ausrichtung zu einer beliebigen anderen Position und Ausrichtung gelangen kann). Wir als Navigationsgruppe fühlten uns insbesondere für die Navigationsalgorithmen zuständig, die sich ihrerseits nur schwer von der zugrundeliegenden Karte und dem nachfolgenden Greedy-Controller trennen lassen. So blieb als zu veräußerndes Modul nur noch die Positionsbestimmung.
Als Teil der Navigationsgruppe beschäftigten sich Jörg Kollmann und Axel Lankenau ab Ende des zweiten Projektsemesters mit der Untersuchung des Partigame-Algorithmus (moat95 ). Zunächst ging es darum, den Algorithmus in seiner ursprünglichen Form zu implementieren und mit SimRobot (siem94 ) zu testen.
Dabei wurde ein omnidirektional beweglicher zylindrischer Agent eingesetzt, um das Augenmerk voll auf die Funktionsweise des Algorithmus richten zu können. So war es möglich, bereits in dieser Zeit einige Verbesserungen am Algorithmus vorzunehmen. Der Semesterbericht (kola95 ) bildete den Abschluß dieser Phase und dokumentiert den Stand der Entwicklung bevor die Rollstuhlanwendung in Angriff genommen wurde.
Die Umsetzung des Partigame-Algorithmus von der simulierten omnidirektional beweglichen Tonne bis hin zum realen Rollstuhl wurde im SAUS-Zwischenbericht (saus96 ) und in unserem Abschlußbericht (kola96 ) ausführlich dokumentiert.
In dieser Zusammenfassung sollen kurz die Konzepte des Partigame-Algorithmus im allgemeinen und die Schwierigkeiten bei der Rollstuhlnavigation im speziellen angesprochen werden.
Bis heute ist eine Vielzahl von Ideen entwickelt worden, wie ein autonomer Roboter navigieren sollte. Der derzeitige Stand der Technik sind Roboter, die in der Lage sind, ihre Umgebung im großen und ganzen selbständig zu erkunden und entweder eine metrische oder eine topologische Karte aufzubauen. Als Alternative zur Kartenorientierung wird auch noch das Erlernen von Sensor-Motor-Kopplungen verfolgt.
Die verschiedenen Navigationsalgorithmen unterscheiden sich im Lernverfahren sowie in der Anzahl und Art der Voraussetzungen, die erfüllt sein müssen, damit sie wunschgemäß funktionieren.
Der Partigame-Algorithmus ist ursprünglich für die Wegplanung in mehrdimensionalen Zustandsräumen entwickelt worden. Der Zustandsraum eines mehrgelenkigen Roboterarms zum Beispiel ist ein n-dimensionaler kontinuierlicher Raum, wobei jede seiner Dimensionen ein Gelenk des Roboterarms repräsentiert. Der Einsatz dieses Algorithmus für die Rollstuhlnavigation liegt nicht völlig fern, da gerade hier der Vorteil der Planung im Zustandsraum gegenüber der Wegplanung in der realen Welt zur Geltung kommt.
Erfolgt die Planung im diskretisierten Zustandsraum, so erspart man sich die extrem komplizierte exakte Lokalisierung von Hindernissen in einer Karte. Es wird lediglich das Wissen benötigt, ob es möglich ist, den Roboter von einem Zustand in den anderen zu überführen, ohne daß dabei eine Kollision auftritt.
Neben der Planung im Zustandsraum, basiert der Partigame-Algorithmus auf drei weiteren Konzepten:
In den folgenden Abschnitten werden diese Aspekte etwas näher betrachtet.
Da der Zustandsraum kontinuierlich ist, muß er diskretisiert werden, indem eine Aufteilung in eine endliche Anzahl von Zellen vorgenommen wird. Jede Zelle repräsentiert dann eine Menge von Zuständen.
Soll in einer hindernisreichen Umgebung navigiert werden, muß die Auflösung eines solchen Zellrasters sehr hoch sein. Dies liegt ganz einfach daran, daß der Roboter auf eine genaue Positionsbestimmung angewiesen ist, je näher er sich an einem Hindernis befindet, um entsprechend exakt reagieren zu können. Ähnlich verhält es sich beim Autofahren, wo man auf einer einsamen Autobahn problemlos zwanzig Zentimenter von der Ideallinie abweichen darf, während die gleiche Ungenauigkeit beim Einparken in eine Garage schon mal den Außenspiegel kosten kann.
Offensichtlich ist das Raster so fein zu wählen, wie es die "schwierigsten" Gebiete vorschreiben. Unglücklicherweise ergibt dies eine enorme Anzahl von Zellen im Zustandsraum, insbesondere auch in Bereichen, in denen sich gar keine Hindernisse befinden.
Der Partigame-Algorithmus verfolgt daher die Idee der schrittweisen Diskretisierung des Zustandsraumes. Das heißt, daß nach und nach die Auflösung des Zellrasters in den problematischen Gebieten erhöht wird.
(Abbildung:
In Abbildung partition wird die Funktionsweise der schrittweisen Verfeinerung des Rasters veranschaulicht. Zu Beginn besteht der gesamte Zustandsraum aus einer einzigen großen Zelle. Wenn der Roboter im Laufe seiner Erkundungsfahrten einem Hindernis zu nahe kommt, entscheidet der Algorithmus, daß die gewählte Auflösung dem Problem nicht angemessen war. Daher wird das Zellraster weiter verfeinert.
Eine solche Verfeinerung geschieht immer dann, wenn der Algorithmus aus der aktuellen Zelle aufgrund des derzeitigen Wissensstandes keinen Weg zum Ziel erkennen kann. Dabei werden alle Zellen geteilt, die im kritischen Bereich liegen. Der kritische Bereich ist genau die Grenze zwischen den Zellen, aus denen ein Weg zum Ziel bekannt ist und denen, für die das nicht gilt.
Das Lernvermögen des Algorithmus besteht in seiner Fähigkeit, die Nachbarschaftsbeziehungen zwischen den Zellen des Zustandsraums in einer Art Erfahrungsschatz zu speichern. Die Wegplanung erfolgt dann auf der Grundlage der Zerlegung des Zustandsraums in Kombination mit dem aktuellen Erfahrungsschatz. Sie wird weiterhin von der im folgenden Abschnitt vorgestellten Worst-Case Annahme beeinflußt.
Falls der Roboter zwei widersprüchliche Erfahrungen beim Versuch, aus einer Zelle in eine andere zu gelangen, gemacht hat, so stellt sich die Frage, welche dieser Erfahrungen der Algorithmus "glauben" soll. Ist es zum Beispiel in der in Abbildung wcintro dargestellten Situation einmal gelungen, aus Zelle A in Zelle B überzuwechseln, während ein anderer Versuch scheiterte, so ist nicht klar, ob von Zelle S über die Zwischenzellen A und B die Zielzelle Z zu erreichen ist.
(Abbildung:
Dies liegt an der Tatsache, daß der Erfahrungsschatz auf der Abstraktionsebene der Zellen aufgebaut wird. Es ist also gar nicht bekannt, von welchem Zustand aus der ehemals erfolgreiche Übergang gelang. Im Partigame-Algorithmus kommt an dieser Stelle das unter anderem aus der Spieltheorie (daher der Name) bekannte Alpha-Beta-Suchverfahren zum Einsatz.
Wird der Weg von einer Start- zu einer Zielzelle geplant, so ist auf den Zwischenstationen stets mit dem Schlimmsten zu rechnen. Es könnte ja sein, daß der Roboter jeweils in dem Zustand einer Zwischenzelle landet, der einmal Ausgangspunkt für eine negative Erfahrung war.
Dieses Vorgehen hat sich insbesondere bei der hier beschriebenen Rollstuhlanwendung ausgezahlt. Da ein möglichst angenehmes Fahrverhalten erzielt werden soll, ist es eindeutig von Vorteil, wenn nicht ständig ausprobiert wird, ob es an einer undurchsichtigen Stelle doch ein Weiterkommen gibt.
Wenn auf diese Weise ein Weg erfolgreich geplant wurde, so muß der Roboter diesen Pfad nur noch abfahren, um zum Ziel zu gelangen. Er kann dabei davon ausgehen, daß sich auf der Strecke keine bekannten Hindernisse befinden.
Um genau diese Aufgabe zu übernehmen, gibt es den sogenannten Greedy-Controller. Dabei handelt es sich um ein vom eigentlichen Partigame-Algorithmus unabhängiges Modul, das in der Lage ist, den Roboter im hindernisfreien Raum aus einer Startposition in eine beliebige Zielposition zu manövrieren.
Falls sich auf dem mit dem Greedy-Controller abgefahrenen Pfad zum Ziel doch ein Hindernis befindet, das der Planungskomponente nicht bekannt war, muß selbstverständlich eine Kollisionserkennung stattfinden. Dabei ist unter einer Kollision nicht ein physikalisches Berühren zu verstehen sondern die Tatsache, daß der Roboter einem Hindernis zu nahe gekommen ist.
Wie schon erwähnt, wird die Aufgabe des Greedy-Controllers mit sinkender Zellgröße immer schwieriger, da er sehr genau manövrieren muß. Um überhaupt eine Chance zu haben, wird ein weiteres Modul zur Selbstlokalisation des Roboters benötigt.
Diese ebenfalls vom eigentlichen Algorithmus unabhängige Komponente hat die Aufgabe, zu jeder Zeit eine möglichst exakte Position des Roboters zu liefern. Diese Position ist ein Vektor, dessen Komponenten die wichtigen Größen des Roboters repräsentieren, wie zum Beispiel die momentanen x-y-Koordinaten, die Ausrichtung usw. Dieser Vektor läßt sich dann auf einen Punkt im Zustandsraum abbilden, der als Grundlage für die Planung herangezogen wird.
Zu den Schwierigkeiten bei der Navigation mit den in vielen Robotikexperimenten verwendeten omnidirektionalen Plattformen, kommen im Falle eines autonomen kinematisch beschränkten Fahrzeugs noch einige Probleme hinzu. Aufgabe. Dies liegt an der äußerst geringen Manövrierfähigkeit zum Beispiel eines Rollstuhls. In einer beliebigen Situation ist es beispielsweise extrem schwierig, einfach 42 cm nach rechts zu fahren.
Die Verwendung des Partigame-Algorithmus zur Navigation eines solchen Gefährts erlaubt zwei Herangehensweisen an dieses Problem. Wird ein Zustandsraum gewählt, der exakt den kinematischen Beschränkungen des Rollstuhls entspricht, so läßt sich der bisher beschriebene Ansatz gut verwirklichen. Dies ist allerdings leichter gesagt als getan, da die Bewegungsfähigkeit eines Rollstuhls sich nicht einfach in einen Zustandsraum übertragen läßt. Besonders problematisch ist zum Beispiel die Skalierung der Achsen, die notwendigerweise unterschiedliche Einheiten haben müssen. "Ist das Drehen um 45 Grad einfacher als 3 Meter nach rechts zu fahren?" und ähnliche Fragen sind zu klären.
Der andere, hier gewählte Ansatz sieht vor, mit einem herkömmlichen Zustandsraum zu arbeiten und die Komplexität des Rollstuhls mit einem intelligenten, vorrausschauenden Greedy-Controller anzugehen.
Trotz massiver Schwierigkeiten mit der Sensorik und der zugrunde liegende Systemarchitektur hat der Partigame-Algorithmus einige Navigationsaufgaben gut gelöst. Es zeigte sich, daß der Lernvorgang sehr schnell ist. In einer künstlichen Umgebung von circa sechs mal acht Metern Größe konnte der Rollstuhl selbständig zwischen fünf beliebig gewählten Zielen navigieren.
Schwierigkeiten ergaben sich vor allem dann, wenn der Rollstuhl zu nah an eine Raumwand kam, so daß kaum noch sinnvolle Rangiermöglichkeiten bestanden.
Um ein wirklich in der Realität einsetzbares System zu entwickeln, ist neben der Verbesserung der Sensorik und Rollstuhltechnik besonders der Einsatz eines an die Freiheitsgrade des Rollstuhls angepaßten Zustandsraumes interessant. Ferner bleibt die Erkennung und Behandlung von temporären Hindernissen, wie zum Beispiel einem Besucher, eine große Herausforderung.
Als ein Teil der Navigationsgruppe haben wir einen Ansatz untersucht, der sich in seinen zugrundeliegenden Ideen von den beiden anderen in diesem Kapitel vorgestellten deutlich unterscheidet und geringere Voraussetzungen benötigt. Das von Long-Ji Lin in (lin93 ) vorgestellte Verfahren zur Navigation autonomer mobiler Roboter orientiert sich vorrangig an natürlichem Verhalten. Das bedeutet, daß auf der Basis von abstrakten "Belohnungen" und "Bestrafungen" größtenteils selbständig gelernt wird, in jeder Situation angemessen und in beabsichtigter Weise zu reagieren. Dabei soll grundsätzlich auf die Vorgabe oder den internen Aufbau einer metrischen Karte der Umwelt verzichtet werden, da eine absolute Positionsbestimmung in der Realität sehr aufwendig zu realisieren ist und im allgemeinen eine umfangreiche Änderung der räumlichen Gegebenheiten mit sich zieht. Das Verfahren von Lin ermöglicht einem Roboter, verschiedene grundlegende Verhalten zu lernen und diese dann sinnvoll zu kombinieren, um Navigationsaufgaben zu bewältigen. Ein weiterer wesentlicher Aspekt des Verfahrens ist die leichte Portierbarkeit auf beliebige mobile Roboter und deren Sensoranordnungen mit nur geringem Aufwand bei der Anpassung der Implementierung. Außerdem ist der Algorithmus unabhängig von den räumlichen Gegebenheiten; es ist nur geringer externer Aufwand notwendig, um das Navigationsgebiet zu strukturieren.
Der wesentliche Unterschied zu den beiden anderen im Projekt untersuchten Verfahren besteht darin, daß von diesem Algorithmus kein vollständigr Weg vom Start bis zum Ziel geplant wird, sondern immer nur der nächste Schritt. Damit kann auf aufwendige Planungsalgorithmen verzichtet werden und die Reaktion auf dynamische Hindernisse ist leicht zu integrieren.
In diesem Kapitel stellen Dominik Dunekamp und Oliver Meyer die Ergebnisse ihrer Untersuchungen und Erweiterungen dieses Algorithmus für den Einsatz auf einem realen Rollstuhl vor. Eine ausführlichere Beschreibung dieser Arbeiten wird in (dume95 ) und (dume96 ) gegeben.
Das wesentliche Ziel des Ansatzes besteht in dem selbständigen Erlernen eines Navigationsverfahrens für komplexe Umgebungen, wie zum Beispiel eine behindertengerechte Wohnung. Das Verfahren ermöglicht in erster Linie das Finden eines Weges von einer beliebigen Ausgangsposition zu einer einzigen vorgegebenen Zielposition; es läßt sich aber auch einfach und effizient auf mehrere unterschiedliche Zielpositionen erweitern.
Um die Lernzeiten des Roboters zu verkürzen, benutzt Lin
die Integration des Lernens durch Vormachen (teaching). Diese
Technik läßt sich problemlos und ohne viel Aufwand in das gewählte
Verfahren integrieren und führt bei
gleichem Zeitaufwand (Anzahl der Lernschritte) zu
beachtlichen Verbesserungen des Gesamtverhaltens. Eine weitere
Verkürzung der Lernzeiten bringt die Nutzung eines hierarchischen
Ansatzes, bei dem zuerst einfache, elementare Verhalten
(behaviours)
gelernt werden, die dann zur Lösung anspruchsvollerer Aufgaben
kombiniert werden. Die grundlegende Architektur ist im Bild
LinHierarchie dargestellt und wird im folgenden
eingehender erläutert.
(Abbildung:
Um die Bewältigung der Navigation zu erleichtern und sie zu strukturieren, hat Lin in seiner Doktorarbeit einige einfache Teilaufgaben formuliert, die grundlegende Navigationsprobleme lösen. Für uns sind dabei Wandverfolgung, daß heißt also das zu einer Raumbegrenzung parallele Fahren durch den Raum mit gleichmäßigem Abstand (auf der linken und rechten Seite) und das Durchfahren einer Tür, wenn sich das Fahrzeug bereits in der Nähe der Tür befindet, von besonderem Interesse. (Es ist möglich, weitere Elementarverhalten zu integrieren. Falls die Gesamtnavigation zu keinem befriedigendem Ergebnis führt, kann man an dieser Stelle jederzeit über eine Erweiterung nachdenken.)
Von dem Roboter werden dabei für jedes Verhalten Situations/Aktions-Paare gelernt. Eine Situation kann dabei neben den aktuellen Sensordaten auch aus internen Informationen über die Vergangenheit und eventuell externen, von anderen Modulen aufbereiteten Daten bestehen. Um diese Paare zu lernen, wird das Prinzip des Reinforcement-Learning mit Neuronalen Netzen kombiniert. Das bedeutet, daß der Roboter dabei situationsabhängig von seiner Umwelt für jeden Schritt eine Belohnung oder eine Bestrafung bekommt (Belohnung und Bestrafung sind hier abstrakt zu sehen; es handelt sich dabei lediglich um eine Bewertung (Reinforcement) in Form einer positiven oder negativen Zahl), wobei es gilt, die Summe aller in Zukunft möglichen Belohnungen auf dem Weg zum Ziel zu maximieren; das tatsächliche Erreichen des Ziels führt dann jeweils zu einer besonders hohen Belohnung. Dabei werden die unmittelbaren konkreten Bewertungen stärker gewichtet als jene, die weit in der Zukunft liegen, um zum einen vorrangig auf die aktuellen Probleme zu reagieren und zum anderen den Weg zum Ziel so kurz wie möglich zu halten (eine zeitlich frühere Belohnung erscheint durch die Gewichtung als höhere Belohnung). Die Neuronalen Netze werden benutzt, um Vorhersagen über die zu erwartende Gesamtbelohnung bei der Ausführung einer bestimmten Aktion in einer gegebenen Situation zu machen; durch ihre Fähigkeit, auf ähnliche Eingaben ähnliche Ausgaben zu liefern, kann auch für Situationen, die noch niemals erreicht wurden, aber eine Ähnlichkeit zu bereits "erlebten" aufweisen, angemessen reagiert werden. Ausgeführt wird dann jeweils die Aktion, für welche die Netzwerke die höchste Belohnung voraussagen.
Die erlernten Grundverhalten werden benutzt, um durch "geschicktes" Wechseln an den richtigen Positionen das gewünschte Ziel zu erreichen, das heißt auf einer höheren Hierarchiestufe der Steuereinheit werden anstelle von Aktionen wie "Vorwärtsfahren" oder "Kreisbogen fahren" Grundverhalten wie zum Beispiel "Wandverfolgung links" benutzt.
Um das Navigationsgebiet für diese Zerlegung zu
strukturieren, wird es bei dem Ansatz von Lin in kleine, sich
großräumig
überschneidende Gebiete unterteilt. Innerhalb eines jeden Gebietes
wird dann eine Position ausgewählt,
die als Navigationspunkt (Unterziel)
dient und zum einen möglichst markante Sensorwerte liefern
und zum anderen einen günstigen Ausgangspunkt zur weiteren
Navigation darstellen sollte. Von dem System wird dann wiederum
mit Hilfe des "Reinforcement-Learning" gelernt, aus
der näheren Umgebung eines solchen Navigationspunktes
zu diesem zu fahren. Da sich die Gebiete
überschneiden, ist es dann möglich, von jeweils einem Unterziel zum
nächsten zu gelangen und so letztendlich zu einem globalen
Ziel. In Bild
LinNavigationszerlegung ist eine
beispielhafte partielle Zerlegung eines Navigationsraumes
dargestellt. Um den Raum auf der linken Seite verlassen zu
können, wird, je nach passendem Navigationsgebiet, zuerst das
Unterziel A oder B angesteuert. Ist einer dieser beiden Punkte
erreicht, so befindet sich der Roboter in dem
"Einzugsgebiet" des Unterziels C und kann nun zu
diesem navigieren.
(Abbildung:
Einige von Lin vorgeschlagene Prinzipien, die von ihm für den Einsatz eines omnidirektionalen Vehikels in der Simulation konzipiert wurden, sind für die Verwendung eines realen Roboters nur bedingt geeignet, insbesondere wenn das verwendete Fahrzeug kinematisch beschränkt ist. Dazu zählen zum Beispiel die Bewertungsgrundlagen für das "Reinforcement-Learning", die sich als zu einfach strukturiert gezeigt haben. Weiterhin ist bei der realen Anwendung kein selbständiges Lernen in der zweiten Hierarchieebene möglich, da das verwendete Fahrzeug nicht in der Lage ist, sich zufällig in einer begrenzten Umgebung zu plazieren, was in der Trainingsphase notwendig ist. Ein weiteres Problem der realen Anwendung ist die Einschränkung, daß es nicht mehr möglich ist, Aktionen exakt festzulegen, da die auftretenden Verzögerungszeiten nicht gleichmäßig sind. Daraus ergeben sich unterschiedliche Bewertungen für gleiche Aktions-/Situations-Zusammenhänge, was dazu führt, daß das Lernen extrem behindert und zum Teil sogar unmöglich wird.
In der Simulation mit einem kinematisch beschränkten Fahrzeug war erkennbar, daß der Algorithmus von Lin in der Lage ist, mit eingeschränkten Bewegungsmöglichkeiten und geringen, aber gleichmäßigen Verzögerungen zurechtzukommen. Es zeigte sich aber auch, daß die ursprünglich eingesetzten Backpropagation-Netze zu langsam lernen; ihre Ersetzung durch Competitive-Learning-Netze führte zu wesentlichen Verbesserungen der Lernzeiten.
Es hat sich gezeigt, daß die Abhängigkeiten von der Hardware größer sind, als der Ansatz vermuten läßt. Bei fast jeder Änderung der Sensoranordnung, der Sensorvorverarbeitung, der Bewertungsfunktion etc. sind die bereits trainierten Netzwerke unbrauchbar, alle Verhalten müssen neu gelernt werden. Besonders aufwendig daran ist, daß zusätzlich die vorgemachten Lektionen neu erstellt werden müssen. Damit sind Experimente mit diesem Ansatz prinzipiell sehr zeitaufwendig, zumal häufig erst nach längeren Lernphasen sichtbar wird, ob die gemachten Änderungen sinnvoll sind oder nicht. Dies gilt insbesondere für Experimente mit realen Fahrzeugen, da hier aufgrund der immer unterschiedlichen Bedingungen die Vergleichbarkeit zusätzlich erschwert wird.
In diesem Abschnitt stellt Jan Kuhlmann die Motivation und Ergebnisse seiner Arbeit 'Navigation in der Karte' im Projekt SAUS kurz vor. Die ausführliche Beschreibung seiner Aktivitäten sind (kuhlmann961 ), (kuhlmann963 ) und (kuhlmann964 ) zu entnehmen.
Ausgangspunkt dieser Untergruppe war der Erfahrungsschatz, also die Karte, mit der die Navigationsgruppe arbeiten wollte. Nach der Verabschiedung und Anerkennung der Idee der Navigationsgruppe begann Jan Kuhlmann mit der Programmierung einer möglichst allgemeinen Kartenklasse, die als Basis für die Navigationsgruppe dienen konnte (s. (kuhlmann961 )).
Inzwischen jedoch stellten wir fest, daß es gut sein könnte, wenn sich die Navigationsgruppe aufteilt in Untergruppen, die sich aufgrund der Komplexität der Aufgabenstellung und der geringen Abschätzbarkeit des Erfolges je einen eigenen Algorithmus aussuchen sollte, um das Gesamtziel zu verfolgen. Im Zuge dieser Aufteilung wollten wir dem Partigame-Algortihmus und dem Algorithmus von Long-Ji Lin Aufmerksamkeit schenken. Während die Lin-Gruppe gar keine Karte mehr brauchte, zog es die Partigame-Gruppe vor, eine eigene Karte zu programmieren, die speziell auf ihre Bedürfnisse ausgerichtet war, so daß die fertiggestellte Kartenklasse zu verstauben drohte.
So entstand der Navigationsansatz 'Navigation in der Karte' im Projekt SAUS vollständig aus eigenen Ideen und Ansätzen. Es handelt sich hier um einen von vornherein integrierten Ansatz, der ohne Zwischenschritte über omnidirektional bewegliche Fahrzeuge direkt für den kinematisch beschränkten Rollstuhl ausgelegt wurde. Er basiert auf einer metrischen Karte, die sich der Rollstuhl während seiner Fahrt durch die Umgebung mit Hilfe von Ultraschallsensordaten selbst erstellt, einem Satz von Navigationsalgorithmen, die in der Karte planen, einem Greedy-Controller, der die geplanten Vektoren der Navigationsalgorithmen in Fahrkommandos für den Rollstuhl umsetzt und einem Interface zur Ansteuerung und Kommunikation mit dem realen Rollstuhl. Notwendige Voraussetzung sind dafür nur das Wissen über die maximale Größe der zu befahrenden Umgebung und über die Position des Rollstuhls in dieser Umgebung.
Der Algorithmus besteht aus drei deutlich voneinander abgegrenzten Modulen, die in den folgenden Abschnitten genauer beschrieben werden.
Dieses Modul stellt eine metrische Karte zur Verfügung, die als Liste von miteinander über Durchgänge verbunden Räumen organisiert ist, und zur Aufgabe hat, im Rahmen ihrer Auflösung abzuspeichern, ob sich an einer bestimmten Stelle in der Karte ein Hindernis befindet oder nicht. In sie werden während der Fahrt des Rollstuhls Sensormeßwerte eingetragen und auf ihrer Basis findet die Navigation von einem Punkt zu einem anderen statt.
So stellt dieses Modul verschiedene Arten von Hilfsmitteln bereit:
In der Karte wird nicht nur digital gespeichert, ob sich an einer bestimmten Stelle ein Hindernis befindet oder nicht, sondern es können Werte in einem bestimmten Bereich (z.B. von 0 bis 255) eingetragen werden, um die Sicherheit zu repräsentieren, mit der ein Hindernis an der betreffenden Stelle steht. Auf diese Weise kann mit der Karte leicht ein 'langsames Vergessen' realisiert werden, um im Endeffekt die Sicherheit des Rollstuhlfahrers zu erhöhen, auch wenn die Ultraschallsensoren falsche Werte liefern.
Routinen zum Laden und Speichern der Karte sind ein unbedingtes Muß, wenn der Rollstuhl nicht alles über seine Umgebung vergessen soll, wenn er abgeschaltet wird. Optional ist es so auch möglich, Teile der Karte vorzugeben, um etwa feste bekannte Hindernisse zu identifzieren und die Lernphase zu verkürzen.
Die Karte stellt einen Satz von Navigationsroutinen zur Verfügung, mit dem eine direkte Navigation von einem beliebigen Punkt in der Karte zu einem beliebigen anderen Punkt in der Karte unter Berücksichtigung der in der Karte eingetragenen Hindernisse möglich ist. Das Ergebnis eine Aufrufs an die Hauptnavigationsroutine ist eine Liste von Vektoren, die nacheinander angefahren werden müssen, um das Ziel zu erreichen, und die direkt an den Greedy-Controller übergeben werden kann. Dabei wird stets so geplant, daß die geradlinige Verbindung der Navigationsvektoren den größtmöglichen Abstand von allen in der Karte gespeicherten Hindernissen hat, um dem Greedy-Controller möglichst großen Rangierraum zu verschaffen.
Der Navigationsalgorithmus arbeitet vereinfacht wie folgt: Um den Startpunkt herum wird ein möglichst großes hindernisfreies Segment in der Karte berechnet. Wenn das Ziel innerhalb dieses Segmentes liegt, kann das Ziel vom Startpunkt aus direkt angefahren werden. Sonst wird der Rand des Segmentes nach hindernisfreien Strecken abgesucht, die der Rollstuhl durchfahren kann. Die Mitte einer solchen Strecke wird der neue Startpunkt, und der Algorithmus startet erneut. Das Ergebnis ist eine Liste von (Start-)Punkten, die nacheinander möglichst geradlinig angefahren werden müssen, um vom Start zum Ziel zu gelangen, wobei der Abstand von Hindernissen maximal ist.
Die Bewegung eines Rollstuhls ist ein nicht triviales Unterfangen, weil er sich weder auf der Stelle drehen noch seitwärts bewegen kann. Die von den Navigationsalgorithmen gelieferten Vektoren können daher im allgemeinen nicht ohne einen gewissen Rangieraufwand nachgefahren werden. Diesen Rangieraufwand zu bewältigen ist die Aufgabe des implementierten Greedy-Controllers.
Dieses Modul hat also so drei elementare Aufgaben:
Im allgemeinen hat der Rollstuhl anfangs nicht die richtige Ausrichtung, wenn er auf einen bestimmtes Wegpunkt zufahren soll. Die Implementierung rangiert den Rollstuhl so, daß er diese Ausrichtung und damit den Wegpunkt erreicht. Dabei stehen verschiedene Teilziele in Konkurrenz: Der Abstand vom kürzesten Pfad zum Wegpunkt (die sog. Ablage vom Sollpfad) so möglichst klein bleiben aber der Rollstuhl soll möglichst nicht rückwärts fahren. Der implementierte Algorithmus berechnet hierzu einen Führungspunkt, der immer kurz vor dem Rollstuhl auf dem berechneten Weg liegt, und den der Rollstuhl als Ziel anpeilt. Wenn der Rollstuhl sich auf den Führungspunkt zubewegt, bewegt sich der Führungspunkt seinerseits im nächsten Schritt vom Rollstuhl weg (es folgt hier der Esel der Karotte). Auf diese Weise werden seitliche Ablagen des Rollstuhls vom berechneten Sollweg schnell abgebaut. Das Fahren des Rollstuhls auf den Führungspunkt zu erfolgt dabei auf Kreisbögen, da der Rollstuhl aufgrund seiner Konstruktion sich nicht einfach seitwärts bewegen kann. In Fällen, in denen sich der Rollstuhl selbst mit maximalem Lenkradeinschlag nicht dem Führungspunkt nähern kann, versucht der Algorithmus, den Sollweg rückwärts fahrend zu erreichen.
Da der Rollstuhl sich nicht auf der Stelle drehen kann, ist es nötig, Kurven schon vor Erreichen eines Wendepunktes einzuleiten, wenn man nicht zu weit vom Sollpfad abweichen will. Kurven werden sozusagen geschnitten, um die mittlere Abweichung vom Sollpfad möglichst gering zu halten. Dies ist dadurch implementiert, daß der Führungspunkt direkt dem Sollpfad nachläuft, also schon auf den übernächsten Wegpunkt einschwenkt, wenn der Rollstuhl selbst den nächsten Wegpunkt noch gar nicht erreicht hat.
Schließlich muß der Rollstuhl einen beliebige Endausrichtung erreichen können. Dies wird realisiert, indem der Führungspunkt bei Erreichen des Endziels abhängig vom Anstand des Rollstuhls vom Endziel in Richtung Endausrichtung einmal vor und einmal hinter den Rollstuhl gelegt wird, so daß der Rollstuhl die Endausrichtung erreicht, ohne weit von der Endposition abzuweichen. So kann man den Rollstuhl quasi 'auf der Stelle' drehen.
Der Greedy-Controller erzeugt bei seiner Arbeit pro Aufruf bzw. Berechnungsschritt ein Paar von Geschwindigkeits- und Lenkradsteuersignalen für den Rollstuhl.
Der Greedy-Controller braucht für seine Arbeit für jeden Berechnungschritt die aktuelle Position des Rollstuhls, was leider in Tests mit dem realen Rollstuhl die Hardware überfordert hat und damit nur zu schlechten Ergebnissen geführt hat.
Schließlich ermöglicht das dritte Modul die Übertragung der vom Greedy-Controller gelieferten Fahrkommandos an den Rollstuhl und den Empfang von Sensordaten sowie das Transformieren und Weiterleiten solcher Daten für und an die entsprechenden Module. Hier findet die Koordination und der Aufruf der Algorithmen der anderen Module statt:
Auf Anfrage des Rollstuhls hin wird ein Greedy-Controller-Schritt durchgeführt und dessen Ergebnis an den Rollstuhl übermittelt.
Pro Berechnungsschritt wird die Position vom Rollstuhl angefordert und dem Greedy-Controller bereitgestellt, sowie für die Sensorvorverarbeitung benutzt.
Sensordaten werden vom Rollstuhl angefordert und vorverarbeitet. Wenn ein Ultraschallsensor an einer bestimmten Stelle ein Hindernis detektiert hat, wird dieses mit einem hohen Wert in die Karte eingetragen. Wenn er kein Hindernis detektiert hat, wird der entsprechende Kartenwert erniedrigt. Wenn ein neu erkanntes Hindernis ein einem Kartensegment liegt, das zur Navigation benutzt wurde, wird der Navigationsalgorithmus neu gestartet und der Greedy-Controller mit den neuen Werten versorgt.
Wenn das Endziel erreicht ist, wird vom Rollstuhl das nächste Ziel angefordert.
Die Kartenalgorithmen wurden mit SimRobot ausführlich in unterschiedlichen Umgebungen getestet und optimiert. Der simulierte Rollstuhl verfügte über annähernd dieselben Fahreigenschaften wie der reale Rollstuhl, sowie über je zwei Ultraschallsensoren mit schmaler Keule vorn und hinten am Rollstuhl und zwei Ultraschallsensoren mit breiten Keule seitlich am Rollstuhl. Tests mit abgeschalteten Sensoren in bekannten Umgebungen (also bei vollständig vorgegebener Karte) zeigten sehr gutes Navigations- und Rangierverhalten. Tests mit eingeschalteten Sensoren bei unbekannter Umgebung (also ohne vorgegebene Karte) zeigten deutlich, daß Sensorwerte korrekt verarbeitet und entsprechende Hindernisse korrekt in die Karte eingetragen wurden. Auch mutwillig verfälschte Sensorwert wußte die Software zu meistern, indem neu geplant wurde und die falsch eingetragenen Hindernisse bei mehrmaligem späteren Nicht-Erkennen aus der Karte gelöscht wurden. Auf diese Weise können die Kartenalgorithmen also auch vergessen und auch mit beweglichen Hindenrissen zurechtkommen.
Einzig in der Lernphase, also bei vollständig unbekannter Umgebung, kam es vor, daß sich der Rollstuhl in Ecken verfing, aus denen er nicht mehr herauskam. Diese Erfahrung hat ihn aber im folgenden gelehrt, solche Ecken nicht wieder zu besuchen. Ein zweites Problem waren ganz allgemein zu kleine Räume, in denen der Greedy-Controller nicht genug Platz zum Rangieren hatte. Hier konnte es passieren, daß der Rollstuhl in schneller Folge von einer Vorwärtsfahrt mit vollen Linksausschlag der Lenkräder auf Rückwärtsfahrt mit vollem Rechtsausschlag wechselte, um seine gewünschte Ausrichtung zu erreichen. Es war abzusehen, daß derartige Versuche zumindest in der Realität Probleme erzeugen würden.
Aufgrund der lange andauernden Schwierigkeiten mit der Hardware konnten die Kartenalgorithmen nur unzureichend auf dem realen Rollstuhl getestet werden. Bei den Tests haben sich dann auch Probleme aufgetan, die in der Simulation nicht aufgetreten waren:
Die vom Rollstuhl gelieferte Position war häufig ungenau und erfuhr teilweise zu selten ein update. So rechnete der Greedy-Controller oft mit falschen oder veralteten Werten, die das Fahrverahlten des Rollstuhl nachhaltig beeinflußten.
Obwohl die Kartenalgorithmen nur dann Fahrkommandos lieferten, wenn diese auch vom Rollstuhl angefordert wurden, dauerte es oft mehr als eine Sekunde, bis das Fahrkommando schließlich umgesetzt wurde. In dieser Zeit fuhr der Rolstuhl auch bei langsamster Fahrt ca. 20-30 cm, so daß das Fahrkommando zum Zeitpunkt der Ausführung praktisch längst veraltet war. Anpassungen zielten darauf, den Rollstuhl immer wieder anzuhalten, auf eine neue Position zu warten, erst die Lenkräder einzustellen und dann ein kurzes Stück zu fahren, um die Prozedur erneut zu starten. Dies ergab ein zwar besser nachvollziehbares aber ruckeliges Fahrverhalten.
Ein großes Problem, das die Eintragung von Hindernissen in die Karte betraf, war die fehlende Synchronisation zwischen Sensorwerten und Position. Die Kartenalgorithmen interpretieren die Sensorwerte relativ zur Position, so daß Zeitdifferenzen sich fatal mit der Auswirkung bemerkbar machen, daß Hindernisse an falschen Stellen in die Karte eingetragen werden. Dazu kommt, daß auch die Sensorwerte nur relativ selten ein update erfuhren, so daß leicht schon mal zwei Sekunden zwischen zwei in Korrelation gebrachten Positions- und Sensorwerten liegen konnten, was einen Fehler von 40-60 cm in der Hindernisposition plus den Fehler des Ultraschallsensors ausmachen konnte.
Autoren:
Datum: Dezember 1996
Zusammenfassung:
Dieser Bericht stellte ein Zusammenfassung der Projektberichte der Bildverarbeitungsgruppe dar. Für jede dieser Zusammenfassungen existiert ein gleichnamiger ausführlicher Bericht.
Menschen sind durch eine Vielzahl von Sensoren (Augen, Ohren usw.) in der Lage Erkenntnisse über ihre Umwelt zu erlangen. Diese gewonnenen Informationen können dann analysiert und ggf. für Entscheidungen herangezogen werden.
Die Augen sind für den Menschen eine wichtige Informationsquelle. Sie helfen uns Erkenntnisse über unsere dynamische Umgebung zu erlangen, da wir in einer Welt starrer und beweglicher Objekte Gefahren und Probleme rechtzeitig erkennen müssen. Durch unsere Augen können wir unproblematisch Objektbewegung, Eigenbewegung und Tiefe abschätzen. Für einen Roboter ist die Kamera ein hochauflösender Sensor, ähnlich wie für uns das Auge.
Gleich zu Beginn des zweiten Projektsemesters hatten wir uns das Ziel gesetzt, mit Hilfe einer Kamera den Rollstuhl kollisionsfrei zu navigieren. Um dieses Ziel erreichen zu können, mußten zunächst einmal Teilziele definiert werden. Daraufhin haben sich in der Bildverarbeitungsgruppe Untergruppen gebildet, die sich jeweils mit einem der Teilziele beschäftigten. Im folgenden werden die Ergebnisse der Teilziele kurz vorgestellt.
In der Bildverarbeitungsgruppe haben wir uns auf die Benutzung der Softwarepakete Khoros und SimRobot geeinigt. Khoros ist ein komplexes Softwarepaket, das in erster Linie zur Ver- und Bearbeitung von Bilder dient. SimRobot dagegen dient zur Simulation sensorbestückter Agenten in einer dreidimensionalen Umwelt; das Programm wird in (siem94 ) näher beschrieben. Da es nicht möglich gewesen ist, beide Programme zu kombinieren, wurde ein Interface erarbeitet, welches es dem Benutzer erlaubt, Steuerprogramme von SimRobot in Khoros einzubinden.
Mit Hilfe dieses Interfaces kann jetzt ein Kamerabild aus einer beliebigen SimRobot-Szene direkt unter der Khoros-Oberfläche ausgelesen werden. Damit wird das ständige Wechseln zwischen den einzelnen Softwarepaketen erspart, was besonders beim Testen neuer Algorithmen eine deutliche Zeitersparnis zur Folge hat. Das Kamerbild wird automatisch in das khorosspezifische Dateiformat VIFF umgewandelt und kann somit ohne weitere Konvertierungen bearbeitet werden. Problematisch bei der Implementierung war die Einbindung der SimRobot Steuerprogramme, welche in C++ geschrieben waren, in die der in C geschriebenen Khoros Funktionen. Eine ausführliche Beschreibung des Khoros-SimRobot Interfaces ist unter (kubon95 ) zu finden.
In der Bildverarbeitungsgruppe haben wir uns zu Beginn des Projektes das Ziel gesetzt mit Hilfe einer Kamera den Rollstuhl kollisionsfrei zu navigieren. Jedoch war für uns die reale Abbildung eines Stereosehsystems nicht realisierbar, da nur eine Kamera zur Verfügung stand. So mußte ein Weg gefunden werden, die gelieferten 2D-Bilddaten der Kamera in nutzbare Informationen über die Tiefe umzuwandeln. Dazu verfolgten wir den Ansatz der Bildfolgenverarbeitung. Dort werden während der Fahrt kontinuierlich Kameradaten dazu genutzt, um Informationen über die Eigenbewegung zu erlangen. Letztendlich soll durch Sensorfusion eine zuverlässige Navigation in unbekannter Umwelt erreicht werden.
Im folgenden soll nun ein kurzer Einblick in die theoretischen Hintergründe und anschließend ein grober Überblick über die praktischen Tests und Erfahrungen gegeben werden. Eine ausführliche Beschreibung der Bildfolgenverarbeitung ist unter (bldflg96 ) zu finden.
Mit dem Prinzip der Normalenflußfelder versuchen wir aus 2D-Bildern Informationen über unsere Bewegung und damit über die dritte Dimension ( Tiefeninformation ) zu erlangen. Wir betrachten dabei die Pixelbewegung auf der Bildebene unserer Kamera zwischen den einzelnen Bildern. Dabei ist zu erkennen, daß die Vektoren zu den Bewegungsbildrändern immer länger werden und hinten wieder zusammenfließen. An den Bildrändern ist die Pixelgeschwindigkeit daher höher als weiter in der Mitte. Die Geschwindigkeit der Pixel ist in dem Punkt, auf den man sich hinbewegt gleich Null. Dieser Punkt ist der Ursprung des Bewegungsflusses und wird Focus of expansion (kurz FOE) genannt. Das Flußfeld entsteht bei reiner Translation von diesem Punkt aus explosionsartig (siehe Abb.
gibsonku).
(Abbildung:
Mit Hilfe des FOE und dem Wert des Wert des Time to collison (kurz TTC), der angibt, wann man mit dem Objekt, bei konstant fortgeführter Bewegung in Richtung des FOE, zusammenstoßen wird, läßt sich ein Roboter letztendlich navigieren.
Um aus einer Bildfolge Informationen zur Berechnung von FOE und TTC zu bekommen, müssen die Einzelbilder vorher bearbeitet werden. Dazu werden aus dem Einzelbild mit Hilfe eines Differenzialoperators (z.B. Sobeloperator) die Grauwertkanten extrahiert. Daraufhin wird untersucht, wie sich der Kantenverlauf in einer Bildfolge verändert.
Betrachtet man aufeinanderfolgende Einzelbilder, die jeweils in einem diskreten Zeitabstand von der Kamera aufgenommen wurden, so erkennt man eine Verschiebung der einzelnen Objekte. Nun wird ein Vektor zwischen einem Pixel im Ausgangsbild und demselben Pixel im anschließenden Bild aufgespannt. Dieses wiederholt man für mehrere Pixel und erhält dadurch ein Bewegungsfluß in Form eines Vektorfeldes.
Aus dem Vorhergegangenem läßt sich eine Kurve mit der Geschwindigkeit des jeweiligen Punktes erstellen. Nachdem in dieser Kurve die z.B. durch Rauschen entstandenen ungültigen Werte korrigiert wurden, muß die Kurve geglättet werden. Mehrmaliges Glätten hat sich als sinnvoll erwiesen. Dazu haben sich Binomialfilter ( z.B. ( 1 4 6 4 1 ) ) bewährt. Aus dieser Kurve läßt sich dann im Idealfall der FOE ablesen. Danach betrachtet man die Flächen links und rechts des FOE und setzt diese in Beziehung. Der aus dieser Beziehung abgeleitete Wert gibt dann an, welche Entscheidung zur Richtungsänderung getroffen werden soll. Die Abbildung
vorgehenku zeigt unser Vorgehen in Form eines Ablaufdiagramms.
(Abbildung:
Die nachfolgenden Abschnitte behandeln chronologisch die Experimente. Zuerst wurden die erarbeiteten Formeln in der Simulation getestet. Anschließend wurde Bildsequenzen aufgenommen und danach verarbeitet. Zum Schluß wurde mit "Live-Bildern" gearbeitet.
In SimRobot wurden zuerst die theoretischen Kenntnisse getestet. Die Formeln sollten erst auf ihre Funktionalität und Korrektheit überprüft werden, bevor sie in der Realität auf die Probe gestellt werden.
SimRobot bot die Möglichkeit unseren Algorithmus unter optimalen Umständen zu testen. Auf diese Art und Weise konnte die formale Korrektheit überprüft und der Algorithmus verbessert werden. Erst anschließend sollten auftretende unvorhergesehene Ereignisse bedacht werden.
Es wurde in SimRobot ein Robotermodell erstellt, mit dem anhand einiger einfacher Szenen der Algorithmus getestet wurde. In diesen Szenen wurde eine günstige Textur (cosinusförmiger Grauwertverlauf) verwandt.
Die benutzten Szenen wurden an häufig auftretende Standardsituationen angepaßt. Dazu bewegt sich der Roboter auf eine gerade, schräge und versetzte Wand (Parallel vor einer Wand befindet sich von der Fläche her eine kleinere Wand.) zu, sowie parallel zu zwei Wänden.
Aus diesen Tests wird eine weitere Testsequenz abgeleitet, in der vorher getestete Szenen in kombinierter Form auftreten. In dieser Szene soll der Roboter innerhalb eines Ganges zentriert fahren. Es hat sich gezeigt, daß die anfängliche Ausrichtung des Roboters im Prinzip weniger relevant ist, jedoch sollte er nicht direkt auf die Wand ausgerichtet sein. Nach jedem Schritt wird die Tiefe ermittelt und der Roboter richtet sich ggf. neu aus. Damit nicht nach jedem Schritt eine Richtungsänderung durchgeführt wird, wurde eine Schwelle definiert, um eine geeignete Fahrt zu simulieren.
Problematisch sind zu große Schritte des Roboters und eine zu kleine Textur. In diesen Fällen treten Probleme bei der FOE-Bestimmung auf.
Mit Hilfe des Linearschlittens, der uns nahezu eine optimale Translation (ohne Rotation) ermöglicht, wird unser Algorithmus in einer realen Umgebung unter optimierten Umständen weiter getestet, bei denen die Kamera vollkommen gerade auf dem Schlitten montiert werden und die Lichtquelle intensitätskonstant sein muß. Dazu entwickelten wir ein Testprogramm mit dem eindimensionale Flußfelder berechnet und live Bildsequenzen aufgenommen und sofort ausgewertet werden können. In diesem Testprogramm sollen die möglichen Parameter ausgetestet werden. Dabei variieren wir die Schrittgröße und überprüfen die Links-Rechts-Entscheidung des Roboters. Erst später sollen sinnvolle Parameter unter nicht optimalen Bedingungen getestet werden.
In 99,9% aller Fälle konnten wir eine korrekte Entscheidung feststellen.
Da der Rollstuhl zu dem Zeitpunkt als er von uns benötigt wurde, aufgrund der mangelden Hardwareausstattung noch nicht benutzbar war, bauten wir uns mit einem Fischertechnikbaukasten einen eigenen Roboter. Ein lenkbarer Fishertechnikroboter stellte sich als problematisch heraus, da es nahezu unmöglich war den Roboter rein translatorisch fahren zu lassen. Aus diesem Grund testeten wir unseren Algorithmus nur mit einem geradeausfahrenden Roboter. Die Entscheidung wird über zwei am Roboter angebrachte Lampen signalisiert. Trotz der notwendigen Einschränkungen fährt der Roboter nicht absolut geradeaus, da die Räder unterschiedlich auf dem Untergrund fassen. Desweiteren wirken sich die nötigen Verbindungskabel zum Computer ebenfalls störend auf die Bewegung aus. Optimale Ergebnisse ließen sich somit in den seltensten Fällen erreichen, da sich neben einer nicht geraden Fahrt auch die Kamera nicht absolut genau ausrichten läßt.
Ausgedehnte Tests konnten nicht mit dem Rollstuhl durchgeführt werden. Da andere Teilgruppen wichtiger für bevorstehende Präsentationen waren, stellten wir unsere Arbeit am Rollstuhl in den Hintergrund. Ein weiteres Problem lag in der implementierten Version unseres Testprogramms, das nur in einer MS-Dos-Version vorlag. Das Rollstuhlsystem wurde allerdings in Visual C++ unter Windows95 implementiert. Aus diesem Grund war eine Nutzung von Rollstuhleigenschaften (z.B. Lenkung) nicht möglich. Desweiteren mußte eine, für diese Größe, optimale Textur entworfen werden, da sonst eine eindeutige Zuordnung nicht möglich wäre.
Wir führten zwar einige Tests durch, die aber nicht in ausreichendem Maße aussagekräftig waren. Die einzige Erkenntnis, die aus den Tests gezogen werden konnte, ist, daß die Problematik die beim Fischertechgnikroboter auftrat, noch verstärkt zu beobachten war.
Nach einigen Experimenten in realer Umgebung haben wir feststellen müssen, daß sich aufgrund nicht optimalen Testbedingungen, der FOE nicht immer genau in der Mitte der Bildzeile befindet. Nachträglich wurde eine neue FOE-Berechnung implementiert, so daß dieses Problem abgefangen werden konnte. Jedoch ist diese Berechnung dann sehr problematisch, wenn zusätzlich zu einer nahen Textur eine weiter entfernte nicht homogene Fläche gesehen wird. Da sich die Gradienten dieser nicht homogenen Fläche kaum bewegen, wird der FOE in der Mitte dieser Fläche errechnet. Damit können wir keine korrekte Entscheidung treffen.
Für die Zukunft wäre es denkbar das Testprogramm in Visual C++ unter Windows95 zu implementieren, um die Bildfolgenverarbeitung in das Rollstuhlsystem zu integrieren. Wenn das Testprogramm dann in der neuen Version vorliegt, können reale Tests mit dem Rollstuhl besser durchgeführt werden. Der Algorithmus könnte auch noch um die Rotationskomponenten erweitert werden. Bisher betrachten wir aus verschiedenen Gründen nur ein eindimensionales Bild, welches zusätzlich auf die zweite Dimension erweitert werden könnte. Diese Erweiterung ist jedoch kein triviales Problem und wird sicherlich einige Zeit in Anspruch nehmen. Sämtliche Test müßten wiederholt und alle Parameter neu abgestimmt werden.
In dieser Projektarbeit sollte mit Hilfe der Aktiven Konturen und/oder der Objekterkennung eine Objektverfolgung realisiert werden.
Die Objektverfolgung sollte zunächst für einen Roboterarm genutzt werden. Mit Hilfe des Armes sollte aus einem Bücherregal ein Buch herausgeholt werden. Die Position des Armes und die des Buches sollte dabei ständig durch die Aktiven Konturen verfolgt (Tracking) werden. Dadurch sollte eine genaue Steuerung des Roboterarms ermöglicht werden. Da dem Projekt im absehbarer Zeit kein Roboterarm zur Verfügung stehen wird, haben wir uns zunächst entschieden die Objektverfolgung für das Verfolgen bewegter Objekten zu nutzen.
Im folgenden soll nun ein kurzer Einblick in die theoretischen Hintergründe und anschließend ein grober Überblick über die praktischen Experimente und Erfahrungen gegeben werden. Eine ausführliche Beschreibung der Projektarbeit ist unter (bekub96 ) zu finden.
Um automatisch Konturen in einem Bild zu finden, geht man klassischerweise so vor, daß zuerst Konturlinien und -punkte extrahiert werden, so z.B. Kanten und Ecken. Diese versucht man dann bestmöglich miteinander zu verbinden, so daß geschlossene Konturen entstehen. In der Regel lassen sich die richtigen Konturen eines Objektes nicht automatisch finden, noch richtig verbinden.
Der Mensch erkennt aufgrund seiner reichen Erfahrungen und seinem komplexen Wissen Objektkonturen sehr gut, nämlich glatt und geschlossen. Mit Hilfe der Aktiven Konturen wird versucht, dieses Verhalten des Menschen maschinell nachzuahmen. Oft ist es möglich, eine grobe Vorstellung von der Form und dem Ort einer gesuchten Kontur anzugeben. Dieses Modell der Kontur projiziert man in das Bild und läßt die Kontur selbständig innerhalb der gesetzten Möglichkeiten nach der optimalen Kontur suchen.
In der Abb. iterpicku ist das Prinzip der Aktiven Konturen verdeutlicht. Zuerst wird aus dem Bild eine Energiefunktion erzeugt. In der Initialisierungsphase wird nun die Aktive Kontur an dir grob geschätzte Position der zu suchenden Objektkontur gelegt. Als nächstes wird versucht die Energie der Aktiven Kontur zu minimieren. Hierfür werden die einzelne Konturelemente auf der Energiekontur in Richtung eines Energieminimums bewegt. Dabei werden sie allerdings auch von internen Kräften, der Dehn- und Verformbarkeit der Aktiven Kontur, beeinflußt. In Abhängigkeit von der gewählten Energie, paßt sich die Aktive Kontur infolge der Energieminimierung an unterschiedlichen Merkmalen im Bild an, wie z.B. Kanten und Linien.
(Abbildung:
Nach dem mathematischen Modell ergibt sich die Energie einer Aktiven Kontur aus der sogenannten internen Energie und der Bildenergie. Die interne Energie bestimmt die Dehn- und Verformbarkeit der Aktiven Kontur. Die Bildenergie wird aus dem Bild gewonnen. Sie bestimmt letztendlich an welchen Merkmalen im Bild sich die Aktive Kontur anpaßt.
Für die Erzeugung der Bildenergie extrahierten wir zuerst mit Hilfe eines Differenzialoperators (z.B. Sobeloperator) die Grauwertkanten eines Objektes. Danach wurde das erzeugte Kantenbild mit einem Binomialfilter geglättet. So entstand eine glatte Energiefunktion, die an den Objektkanten ein Energieminimum aufwies. Bei einfacheren Bildern, die z.B. ein helles Objekt auf einem dunklen Hintergrund beinhalteten, reichte eine einfache Glättung des Bildes aus.
Die Abbildung iverfolgku zeigt die Objektverfolgung mittels der Aktiven Kontur. Oben im Bild ist die Anpassung der Aktiven Kontur an das Energiefeld zu sehen. Die Verfolgung einer Kontur ist im unteren Teil des Bildes dargestellt.
(Abbildung:
Das Erkennen eines Objektes gehört in der Bildverarbeitung zu den schwersten Aufgaben überhaupt. Das liegt an der Tatsache, daß ein Objekt selten so aussieht, wie man es erwartet. Verzerrungen, Schatten, Spiegelungen, Rotationen usw. lassen Gegenstände in einem immer anderen Licht erscheinen. Je komplizierter ein Objekt ist, desto umfangreicher sind die Veränderungen bei Perspektivenverschiebungen und Rotationen. Selbst das leichte Drehen eines Buchstabens z.B., ändert sein Aussehen dramatisch. Das menschliche Gehirn ist mit solchen Erkennungsaufgaben kaum aus der Fassung zu bringen, räumliche Vorstellungskraft und assoziatives Denkvermögen leisten hierbei gute Dienste. Der Computer hingegen gerät ins "Schwitzen", muß er doch sämtliche Möglichkeiten durchprobieren und auch noch damit rechnen, daß er das Objekt nicht vollständig "sieht", weil der Segmentierungsalgorithmus versagt hat.
Wir programmierten uns eine Objekterkennung für das automatische Setzen der Snakepunkte. Dazu benutzten wir hauptsächlich einen selbstentwickelten Segmentierungsalgorithmus, der dazu in der Lage war, das Objekt pixelgenau vom Hintergund zu separieren. Das Segmentieren basiert auf einem toleranten Füll- und Suchalgorithmus, der das Bild spiralförmig nach einer passenden Fläche absucht und dann für jedes angrenzende Pixel entscheidet, ob es zur Fläche gehört oder nicht.
Als weitere Komponente gehört zu unserer Objekterkennung eine Formerkennung, mit der geprüft wird, ob die segmentierte Fläche tatsächlich das Zielobjekt ist. Da unser Objekt sehr einfach ist, ist eine Berechnung der Form nicht besonders aufwendig. Zum Prüfen der Form wird einfach der berechnete Umfang mit dem Segmentierten verglichen. Stimmen diese überein, dann ist das Objekt gültig, sonst nicht (siehe Bild erkennenku).
(Abbildung:
Das Zusammenspiel der Segmentierung mit der Formerkennung ist in den Bildern real1ku bis real2ku zu sehen. Bild real1ku zeigt das Originalbild. Bild real2ku zeigt das Ergebnis der Segmentierung. Dabei wurde nicht nur das Zielobjekt (Kreis) segmentiert, sondern auch noch diverse andere Flächen. Die Formerkennung sortiert die ungültigen Flächen schließlich aus und läßt nur noch das Zielobjekt übrig (Bild real3ku).
(Abbildung:
(Abbildung:
(Abbildung:
Die Aktiven Konturen und die Objekterkennung mußten ihre Leistungsfähigkeit in zahlreichen Versuchen unter Beweis stellen. Diese Versuche werden in den folgenden Abschnitten beschrieben.
Ob die Aktiven Konturen überhaupt dazu in der Lage sind einem Objekt zu folgen, testeten wir in der Simulation. Dazu benutzten wir SimRobot. Das Bildverarbeitungsprogramm Khoros unterstützte uns dabei. Damit wir es mit SimRobot zusammen verwenden konnten, mußte ein passendes Modul geschrieben werden.
In der Simulation verfolgten die Aktiven Konturen dann einen künstlichen, weißen Kreis, der sich in einer Kreisbahn bewegte. Der Versuch verlief sehr erfolgreich. Die Aktiven Konturen hatten ihren ersten Test bestanden.
Als nächstes stellte sich die Frage, wie sie die Aktiven Konturen bei realen Bildern verhalten würden. Dazu ließen wir eine Modelleisenbahn einen kreisförmigen Kurs abfahren. Als Objekt wurde ein weiße Styroporkugel auf das Gehäuse der Eisenbahn geklebt. Der Hintergrund wurde durch schwarze Pappe verdeckt. Eine Kamera nahm nun das Szenario auf und lieferte uns die realen Bilder.
Auch diesen Versuch überstanden die Aktiven Konturen ohne größere Blessuren. Sie schafften es tatsächlich den Ball zu verfolgen. Allerdings durfte sich die Einsanbahn dabei nur sehr langsam bewegen, und der Hintergrund mußte schwarz sein.
Der nächste Schritt unserer Versuchsreihe bestand darin, die Kamera auf das Objekt reagieren zu lassen. Dazu benötigten wir bewegbaren Untersatz. Da uns zu diesem Zeitpunkt der Rollstuhl noch nicht zu Verfügung stand, bauten wir uns selbst einen fahrbaren Untersatz - sozusagen einen kleinen Roboter - aus Fischertechnik. Dieser Roboter besaß vier Räder, wobei die beiden vorderen von einem Motor angetrieben wurden. Eine Lenkung fehlte. Als Ersatz dafür benutzten wir einen selbstgebauten Drehteller (ebenfalls aus Fischertechnik), mit dem die Kamera nach links und rechts geschwenkt werden konnte.
Bei diesem Versuch führten wir die Objekterkennung ein. Mit ihr sollte die Snake automatisch initialisiert werden.
Als Objekt benutzten wir eine faustgroße Styroporkugel. Diese hielten wir an einem Stab vor die Kamera und bewegten sie so als wollten wir einen Hund mit einem Knochen locken.
Der Roboter bewegte sich tatsächlich und folgte der Kugel mit der Kamera. Allerdings nur sehr langsam. Die Aktiven Konturen waren der Aufgabe offensichtlich nicht mehr gewachsen. Bewegten wir die Kugel zu schnell, verlor die Snake das Objekt. Die Objekterkennung hingegen überraschte uns positiv. Sie war schnell und sicher. Sie war sogar so gut, daß sie im Notfall die Objektverfolgung alleine übernehmen konnte.
Der finale Test stand bevor - eine Objektverfolgung mit dem Rollstuhl. Trotz der neuen Framegrabberkarte waren die Aktiven Konturen zu langsam. So ließen wir sie in "Frieden" ruhen und konzentrierten uns voll auf die Objekterkennung. Sie übernahm jetzt nicht bloß das Setzen der Snakepunkte sondern gleich die komplette Objektverfolgung. Als Objekt benutzten wir diesmal einen weißen Papierkreis. Der Hintergrund mußte nicht mehr schwarz sein, es genügte, wenn der Papierkreis einen schwarzen Rand bekam.
Die Objektverfolgung klappte hervorragend. Die Objekterkennung war so schnell, daß sie sogar Personen verfolgen konnte (wenn diese einen weißen Kreis bei sich hatten).
Dieser letzte Test war ein voller Erfolg. Seine Ergebnisse wurden live am Projekttag und am Tag der Forschung präsentiert.
Ein Problem bei der Objektverfolgung war es, daß das Objekt leicht aus dem Blickwinkel der Kamera geriet. Dies führte dazu, daß der Rollstuhl manchmal stehenblieb und das Objekt auch nicht mehr wiederfand. Diese Schwachstelle könnte in naher Zukunft dadurch behoben werden, daß ein Drehteller zwischen Kamera und Rollstuhl befestigt wird. Dieser könnte die Kamera dynamisch nachschwenken und im Falle eines Objektverlustes eine Suchbewegung durchführen.
Im Rahmen des Projekts SAUS wurde eine Farbkamera der Firma Sony auf Basis eines Camcordermoduls angeschafft. Die Kamera besitzt ein Interface, mit dem über die serielle Schnittstelle eines PCs camcorderspezifische Funktionen, wie z.B. zum Ändern der Zoom- und Blende-Werte, aufgerufen werden können.
Es wurde ein Gehäuse für die Kamera angefertigt und eine Bibliothek für die Steuerfunktionen erstellt. Außerdem existiert ein interaktives Testprogramm für die Steuerfunktionen. Nähere Informationen über die Bibliothek und die Kamera können in dem Abschlußbericht (kubon96 ).
Die Pan-Tilt-Unit (auch Drehteller genannt) konnte von der Bildverarbeitungsgruppe nicht zur Lösung von Problemen mit dem Rollstuhl benutzt werden, da die Anschaffung erst nach eigentlicher Beendigung des Projektes erfolgte (10/96). Da ein solcher Drehteller jedoch viele weitere Möglichkeiten im Bezug zur Verarbeitung von Bilddaten bietet, habe ich (Claas Ruschmeyer) mich damit ein wenig tiefgründiger beschäftigt. Der ausführliche Bericht ist unter (rusch96 ) zu finden. Anfänglich haben sich auch Arend Behrens (Mit Arend Behrens zusammen versuche ich (Claas Ruschmeyer) z.Zt. die Objektverfolgung mit dem Drehteller und dem Rollstuhl zu kombinieren.) und Siegmund Kubon bei den Tests beteiligt.
Die Pan-Tilt-Unit kann aufgrund der geringen Abmessung, der hohen Genauigkeit und Schnelligkeit in der Robotik gut eingesetzt werden. Z.B. kann mit Hilfe zweier Units ein Stereosehsystem realisiert werden. Weiterhin ist das intelligente Lokalisieren von Landmarken denkbar. Eine weitere Anwendung wäre das Tracken von Objekten, womit man letztendlich sogar Eigenbewegung oder auch Objektbewegung ermitteln kann. Um die Position des SAUS-Rollstuhles in einem bestimmten Raum, mit Hilfe einer starr auf dem Rollstuhl montierten Kamera, zu ermitteln, mußten viele Landmarken an den Raumwänden in geeigneter Höhe befestigt werden. Nur so ist gewährleistet, daß jederzeit die Position bestimmt werden kann. Ein Drehteller hätte dieses Problem vereinfacht, da man nach den z.B. vier Landmarken in den Raumecken mit der jetzt beweglichen Kamera suchen könnte. Durch Kombination der Werte der Pan-Tilt-Verdrehung mit dem bisherigen Positionsbestimmungsansatz könnte eine neue Positionsbestimmung realisiert werden.
Zunächst möchten wir diskutieren, was Studenten bei der Durchführung eines Projektes im Hauptstudium - wie es in der Universität Bremen vorgesehen ist - lernen, und ob solch ein Projekt überhaupt sinnvoll ist. Aufgrund unserer Erfahrungen können wir dies positiv beantworten. Wichtig hierbei erscheint uns jedoch, daß der Weg das eigentliche Ziel ist, und nicht das gesetzte Projektziel. Bei diesem Projekt stand interdisziplinäres wissenschaftliches teamorientiertes Arbeiten im Vordergrund. Hierbei wurden wir von unseren Projektbetreuern kräftig unterstützt und motiviert. Besonders das interdisziplinäre wissenschaftliche Arbeiten ist für die Studenten eine wertvolle und lehrreiche Erfahrung, vor allem im Hinblick auf die sich anschließende Diplomarbeit. Auch das Arbeiten im Team an einem gemeinsamen Projekt halten wir für das spätere Berufsleben in Wirtschaft, Industrie und Forschung für eine wichtige Fähigkeit. Alle diese Erfahrungen und Gründe sprechen deutlich für die Durchführung eines Projektes im Hauptstudium.
Als nächstes sollen verschiedene Aspekte unseres Projektes näher beleuchtet werden. So wollen wir hier zunächst klären, in wie weit die anfängliche Zielsetzung von dem tatsächlichen Projektergebnis differiert. Hier wird der aufmerksame Leser bereits selber erkennen, daß man weder sagen kann, daß das Projektziel total verfehlt wurde, noch daß es erreicht wurde. Das ursprüngliche Ziel des Projektes sollte ein Rollstuhl sein, der sich selbständig, ohne jegliches Vorwissen in einer beliebigen Umgebung zurechtfindet und lernt, von einem beliebigen Startpunkt zu einem beliebigen Zielpunkt zu finden. Jedoch schon recht früh erkannten wir, daß dieses Ziel wohl viel zu hoch gesteckt zu sein schien, und wir uns mit diversen Einschränkungen abfinden mußten. Die erste wesentliche Einschränkung war, daß wir den Rollstuhl nur für Innenräume und nicht für eine freie Umgebung konzipieren wollten bzw. mußten. Nur so war es nach unserer Vorstellung möglich, daß der Rollstuhl sich orientieren kann, da aufgrund der vorhandenen Wände die Grenzen der Rollstuhlwelt klar definiert werden. Ohne diese Einschränkung könnte die Welt des Rollstuhls bis ins Unendliche wachsen und dieses sahen wir als äußerst problematisch. Außerdem wurde diese Einschränkung zur Voraussetzung für die Video-Positionsbestimmung, da hierfür die Rollstuhlwelt vordefinierte Landmarken enthalten muß. Hierdurch wird die zweite wesentliche Einschränkung deutlich, die wir in Kauf nehmen mußten: viele bunte Pappen an den Wänden der Rollstuhlwelt (Jede Landmarke besteht aus zwei farbigen Pappen.) . Man kann durchaus behaupten, daß wir innerhalb dieser Einschränkungen das Projektziel erreicht haben: der Rollstuhl kann in einer vordefinerten Szene mit angebrachten Landmarken von einem beliebigen Start- zu einem beliebigen Zielpunkt navigieren.
Aber trotzdem gab es einige Dinge, die im Verlauf des Projektes geschehen sind, die nicht unerwähnt bleiben sollten. Beim Zurückdenken an den Beginn des Projektes müssen wir feststellen, daß anfangs das Projekt recht unstrukturiert verlief. Es wäre schön gewesen, wenn es bereits eher klare Definitionen oder sogar Meilensteine gegeben hätte. Es wäre dann möglich gewesen, die Rollstuhlplattform früher fertig zu haben und nicht erst im vierten Projektsemester. Somit hätte die Navigationsgruppe bereits viel früher ihre Algorithmen direkt am Rollstuhl testen können. Außerdem hat die weitgehend freie Arbeitseinteilung - meist ohne jegliche Deadlines oder Meilensteine - viel Spaß gemacht, war jedoch ein weiterer Hauptgrund für das Chaos vor dem DASA-Vortrag, dem Projekttag und dem Tag der Forschung. Hinzu kam, daß die jeweilige Organisationsgruppe oft zu passiv war, und einige Projektteilnehmer manchmal gar nicht wußten, wer dieser eigentlich zugeteilt war. Auch der klägliche Versuch, nach (!) dem vierten Projektsemester ein Qualitätsmanagement einzuführen, trug seinen Teil zur Verunsicherung der Studenten bei. Auf jeden Fall haben wir jetzt gemerkt, daß die Kommunikation und Zusammenarbeit innerhalb der einzelnen Gruppen ziemlich gut funktionierte, zwischen den Gruppen jedoch arge Kommunikationsprobleme auftraten.
In diesem Absatz wenden wir uns den netten Menschen zu, die für die Projektleitung bzw. -betreuung zuständig waren. Zunächst möchten wir lobend erwähnen, daß sämtliche Projektbetreuer (Sie hätten es verdient, hier noch einmal aufgezählt zu werden, aber das haben wir schon im Vorwort (Abschnitt bericht:vorwort) getan.) zu jeder Zeit, egal ob in der Uni oder per Telefon zu Hause, für unsere Fragen und Probleme ein offenes Ohr hatten (Meistens konnte uns auch geholfen werden.) . Ein ganz besonderes Lob gebührt hierbei Thomas Röfer und Andreas Bühlmeier.
Wie schon erwähnt wurde, konnte nach Abschluß des Projektes ein Rollstuhl der neusten Generation günstig erworben werden, der z.B. direkt über eine RS232-Schnittstelle angesteuert werden kann. An diesem Rollstuhl können nun neue Experimente und wissenschaftliche Untersuchungen getätigt werden. Da dieser Rollstuhl im Moment für wissenschaftliche Zwecke noch nicht einsatzbereit ist, bleibt der "alte" Rollstuhl (in der Sensoranordnung unverändert) weiterhin bestehen. Auch ein Kamera-Drehteller wurde angeschafft, einen Bericht über schon erfolgte Arbeiten mit diesem Drehteller ist im Anhang einzusehen.
Wie schon in den einzelnen Anhängen beschrieben, besteht für einige dieser Teilarbeiten die Möglichkeit, sie im Rahmen einer Diplomarbeit weiterzuentwickeln. Mehrere dieser möglichen Diplomarbeiten basieren auf den oben beschriebenen neuen Errungenschaften:
In Anlehnung an das Anfangs genannte Zitat von BKB wollen wir diesen Bericht mit folgendem Kommentar abschießen:
"Es war tatsächlich ein SUPER PROJEKT"
Autoren:
Datum: 28.12.96
Zusammenfassung:
In diesem Dokument soll beschrieben werden, welche Erfahrungen die Hardwaregruppe von SAUS bei der Ausstattung des Rollstuhls gemacht hat. Dazu werden im folgenden eine Ablaufbeschreibung angegeben, die die einzelnen Fortschritte zeigt und Schwierigkeiten aufführt, mit denen wir im Laufe des Projektes konfrontiert wurden.
Zu Anfang des Wintersemesters 1994/95 wurde in einer der ersten Sitzungen das Gesamtprojekt in verschiedene zu erledigende Aufgaben aufgeteilt. Eine dieser Gruppen war unsere CAN-Bus- oder Hardwaregruppe, die die Aufgabe hatte, den Rollstuhl so mit Sensorik, Elektronikkomponenten und Programmen für die Rechner auszustatten, so daß die anderen Gruppen, die sich mit verschiedenen Navigations- und Bildverarbeitungsalgoritmen beschäftigten, diese auf dem Rollstuhl testen und verbessern konnten.
Zu Beginn des Projektes bestand die Hardwaregruppe aus neun Personen, die sich jedoch durch Ausstieg aus dem Projekt zunächst auf sieben und weiter durch Umgruppierungen im Projekt auf fünf Personen reduzierten.
Der Anfang der Arbeit war eine Sichtung dessen, was vorhanden war, bzw. das Überlegen, wie bei der Entwicklung vorgegangen werden sollte.
Vorhanden waren: