4. Robotik mit Lego Mindstorms

4.1. Zielsetzung

In diesem Abschnittt beschreiben wir unsere Erfahrungen mit dem Lego Mindstorms Baukasten. Unser Ziel ist es, einen Roboter zu schaffen, der sich möglichst autonom und ohne menschliches Eingreifen bewegen kann. Der Roboter darf nicht mit Hindernissen kollidieren. Als weitere Herausforderung soll er Objekte in der Form und Größe von Getränkedosen erkennen und zu einem vordefinierten Ablagepunkt transportieren können. Zur Kollisionsvermeidung haben wir einen Ultraschallsensor vorgesehen, mit dem der Roboter Hindernisse frühzeitig und berührungslos erkennen kann. Für die Navigation zur Basis (um das eingesammelte Objekt abzulegen) wollen wir ein Laser-gestütztes Navigationssystem einsetzen. Es dirigiert den Roboter mittels eines Leitstrahls zur Basis zurück.

4.2. Die Realität

Im Laufe des Projekt mussten wir leider mehr und mehr feststellen, dass sich unser Ziel mit den vorhandenen Ressourcen nicht erreichen lässt und wir Kompromisse eingehen müssen. Mit dem Ausstieg zweier Teammitglieder fehlten uns sowohl die personellen als auch die zeitlichen Ressourcen, ausserdem erwiesen sich einige Details komplexer als gedacht, so dass wir schnell an die Grenzen des Legobaukastens stießen. Er enthält bei weitem nicht genug Teile, um alle geplanten Komponenten in der nötigen Qualität bauen zu können. So brauchten wir z.B. zwei Motoren für den Antrieb und selbst durch Hinzufügen eines (privat gekauften) dritten Motors war der Greifer nicht zufriedenstellend zu realisieren, da sich der Greifer zwar öffnete und schloss, es jedoch nicht möglich war, das zu transportierende Objekt mittels eines weiteren Motors (der zwar vorhanden war, jedoch nicht mehr mit einem freien Port am RCX verbunden werden konnte) anzuheben. Diese Einschränkung hätte sich zwar auf der elektrischen Seite durch einen Ausgangsexpander lösen lassen. Wir sahen jedoch davon ab, weil der weitere Motor und die zusätzliche Hebemechanik den Roboter noch schwerer und schwerfälliger gemacht hätten.

Unser erster Roboter sah folgendermaßen aus:

Dieser Roboter enthielt vorne einen Ultraschallsensor, oben die Sensoren zur Lasernavigation und am Heck einen Greifer für (große) Getränkedosen bis hin zu leeren Colaflaschen. Der Roboter war zwar in der Lage, Flaschen zu greifen und hinter sich her zu schleifen, wirklich überzeugen konnte uns dieses Modell jedoch nicht. Deshalb entschlossen wir uns, ein neues zu bauen und unser Konzept zu ändern.

Der Greifer hatte sich nicht bewährt, da er die Objekte nicht anheben konnte. Um den Ultraschallsensor nicht durch das gerade transportierte Objekt zu verdecken, war das Heck der einzig mögliche Befestigungspunkt. In Konsequenz daraus musste sich der Roboter vor dem Greifen eines Objektes zunächst um 180 drehen, was am nicht vorhandenen Kompass scheiterte. Somit konnten wir die Drehung nur zeitgesteuert ausführen. Das war jedoch sehr stark vom Untergrund und der Batterieladung abhängig, so dass die Genauigkeit arg zu wünschen übrig ließ. Wir beschlossen deshalb, auf einen Greifer zu verzichten und uns nur noch auf die Navigation zu konzentrieren.

Aufgrund der Sicherheitsbedenken, die wir im Kapitel über die Lasernavigation näher erläutern, verzichteten wir bei unserem neuen Modell auch auf das Lasersystem.

Wir kamen zu folgendem Roboter. Es handelt sich dabei um unser endgültiges Modell.

Der Roboter ist insgesamt etwas stabiler ausgelegt und verwendet zum Antrieb ausschließlich Zahnräder. Dies eliminiert die fehleranfälligen Riemen. Desweiteren besitzt dieser Roboter einen Ultraschallsensor, der sich wie eine Radarantenne in einem Bereich von bis zu 270 drehen lässt. Die Seitenwahrnehmung von Hindernissen ist so deutlich verbessert und der Roboter kann jetzt entscheiden, in welche Richtung ein Ausweichmanöver am vielversprechendsten ist.

4.3. Mechanik

Auf die Mechanik gehen wir aus den in der Einleitung angesprochenen Gründen im Detail nicht weiter ein, zur Funktionsweise sei auf die Bilder und die Videos auf der CD verwiesen.

Es sei nur kurz erwähnt, dass das Lego-Systen sehr instabil ist, und wir ständig bemüht waren, einen in der Praxis vertretbaren Kompromiss zwischen Stabilität und Größe/Gewicht der Komponenten zu finden.

4.4. Ultraschallsensor

Unser Roboter verwendet einen Ultraschallsensor zur Erkennung von Hindernissen vor dem Roboter. Die Hindernisse werden dabei nicht nur erkannt, sondern auch ihre Entfernung zum Roboter wird gemessen.

4.4.1. Das Messverfahren

Der Sensor besteht aus einem Ultraschallsender und einem -empfänger. Der Sender sendet in regelmässigen Abständen kurze Schallpakete mit einer Frequenz von ca. 40 kHz. Diese Pakete werden von Hindernissen reflektiert und ihr Echo gelangt zum US-Empfänger, der ein elektrisches Signal an die Auswertungsschaltung weitergibt. Aus dem zeitlichen Abstand zwischen dem gesendeten Signal und dem Empfang des Echos lässt sich über die Schallgeschwindigkeit die Entfernung zwischen dem Roboter und dem Hindernis berechnen.

4.4.2. Technische Realisierung

Wir verwenden für unseren Roboter den Bausatz 68-461-78 der Firma ELV (http://www.elv.de). Dieser Bausatz enthält alle nötigen Komponenten, um das Ultraschallsignal zu erzeugen, auszuwerten und auf einer 10-stufigen LED-Leuchtzeile darzustellen. Die komplette Beschreibung des Bausatzes inklusive Schaltplan befindet sich in der Originalanleitung von ELV auf der CD, deswegen gehen wir an dieser Stelle nur grob vereinfachend auf seine Funktionsweise ein: Mit jedem Aussenden eines Schallpaketes wird ein Flipflop gesetzt, welches beim Empfang des Echos wieder zurückgesetzt wird. Solange das Flipflop gesetzt ist, der Schall also unterwegs ist, wird ein 4-Bit-Dualzähler hochgezählt, der ähnlich einer Stoppuhr die Zeit misst. Der Zähler bleibt beim Erreichen des Zählerstandes 10 stehen. Die Frequenz, mit der der Zähler inkrementiert wird, lässt sich auf der Platine mittels eines Jumpers in drei Stufen einstellen und ermöglicht so die Wahl der Messauflösung und des Messbereichs (maximal messbare Distanz).

Die Stromversorgung des Sensors haben wir über ein langes Kabel und ein externes Netzteil gelöst, da wir den Roboter nicht mit einem weiteren Akkusatz belasten wollten. Eine Mitbenutzung der RCX-Batterien scheidet leider aus, da zum einen deren Spannung zu gering ist und dies zum anderen wegen der gemeinsamen Schaltungsmasse (siehe nächsten Abschnitt) eine Beschädigung/Zerstörung des RCX zur Folge haben könnte.

4.4.3. Anbindung an den RCX

Damit der Roboter auf Hindernisse reagieren kann, muss die gemessene Entfernung dem RCX zugänglich gemacht werden. Die technisch einfachste Lösung wäre gewesen, das Ausgangssignal des Flipflops abzugreifen und (über geeignete Elektronik) auf einen Eingang des RCX zu geben. Leider ist der RCX zu langsam, um den Zählvorgang per Software durchführen zu können. Es ist somit unvermeidlich, etwas mehr Hardwareaufwand zu betreiben und die Zeitmessung vom Bausatz durchführen zu lassen. Genau diesen Weg haben wir auch beschritten, in dem wir die Anzeigeelektronik weggelassen und statt dessen ein vieradriges Kabel mit den Zählerausgängen verlötet haben. Leider verfügt der RCX lediglich über drei Eingänge, so dass eine digitale Übertragung des Messwertes nicht in Frage kommt. Das parallele Einlesen der 4 Bits ist mit drei Eingängen nicht möglich und ein serielles Einlesen (z.B. mittels eines Schieberegisters) wäre zu aufwendig, da es ebenfalls weitere Synchronisationsleitungen erfordert hätte. Wir haben uns deswegen entschlossen, den digitalen Messwert mittels eines Digial-Analog-Wandlers (DAC) in einen analogen Spannungs bzw. Widerstandswert umzuwandeln. Das Schaltbild zeigt den Aufbau unseres DAC:

Jedes Bit (x0 bis x3) steuert einen Transistor an, der einen Widerstand in den Stromkreis des RCX-Eingangs schaltet. Durch die verschiedenen Wertigkeiten der Widerstände ergeben sich je nach anliegender Bitkombination unterschiedliche Gesamtwiderstände, die der RCX messen und per Software wieder in ihren ursprünglichen Zustand (4 Bit Zahl) umwandeln kann.

Die im Schaltplan abgedruckten Werte sind leider etwas ungeschickt gewählt, da sich die Widerstandswerte, die aus den Zahlen 6 und 9 resultieren, zu stark ähneln, um vom RCX eindeutig unterschieden werden zu können:

Stufex3x2x1x0Widerstand in kOhmRCX-Messwert(*):
00000unendlich1023
10001120951
2001059889
3001148,1864
4010053876
5010144,8854
6011037,9830
7011135,2819
8100042845
9100138830
10101034,1813
(*) Eingang als Temperatursensor im RAW-Modus konfiguriert.

Dieses Manko lässt sich jedoch leicht durch Ändern der Widerstandswerte beheben. Ein weitaus größeres Problem ist die Abhängigkeit der vom RCX ermittelten Messwerte von der Batteriespannung und der Belastung der übrigen Eingänge des RCX. Die Messwerte weichen zwar nur um wenige Einheiten ab, dies erschwert jedoch die Umwandlung der Werte mittels Konvertierungstabellen.

Eine weitere Fehlerquelle für Messungenauigkeiten liegt im Messverfahren begründet. Da der Ultraschallsensor nicht feststellen kann, ob das gerade empfange Paket mit dem zuletzt gesendeten identisch ist, kann der Sensor selbst dann einen kleinen Messwert zurückliefern, wenn sich kein Objekt innerhalb des Messbereichs befindet. Der Grund lieg darin, dass ein altes und von einem weit entfernten Hindernis reflektiertes Paket kurz nach der Aussendung eines neuen Paketes am Empfänger eintrifft und dieser irrtümlich den Empfang des gerade gesendeten Paketes meldet, was in einem viel zu kleinen Messwert resultiert.

4.4.4. Mechanik zur Drehung des Ultraschallsensors

Die Mechanik zur Drehung des Ultraschallsensors besteht, wie die Bilder auf der CD zeigen, aus einem Motor mit Getriebe und dem bereits vom Getränkeautomaten bekannten Potentiometer zur Winkelmessung. Der Roboter ist somit in der Lage, die Richtung des Sensors zu ermitteln und zu verändern.

4.5. Laserleitsystem

Wir hatten ursprünglich geplant, unseren Roboter über einen Laserstrahl wieder zurück zur Basis zu lenken, ähnlich dem Prinzip der Leitstrahlen in der Luftfahrt. Wir haben zwei mögliche Ansätze zur Lösung dieses Problems diskutiert (siehe nächsten Abschnitt), sind dann jedoch zu dem Schluss gekommen, dass unsere Leitsysteme zu große gesundheitliche Risiken beinhalten, um in der Alltagspraxis eingesetzt zu werden. Dies bedeutet freilich nicht, dass Laserstrahlen generell keine Verwendung in der Robotik finden - ganz im Gegenteil, sie lassen sich sehr vielseitig einsetzen. Da dieser Bericht die gesamte Projektentwicklung dokumentieren soll, haben wir uns entschlossen, das Laserleitsystem an dieser Stelle zu dokumentieren. Wir betrachten unser Laser-Experiment nicht als gescheitert, das System funktioniert und ließe sich nach weiteren Untersuchungen sicherlich auch entschärfen. Dies war uns jedoch im zeitlich und finanziellen Rahmen dieser Semesterarbeit nicht mehr möglich. Im Kapitel "Sicherheit" am Ende dieses Abschnitts gehen wir noch genauer auf die Gründe für den Laser-Verzicht ein.

4.5.1. Funktion des Laserleitsystems

Eine Bemerkung vorweg: Alle vorgestellten Formen der Laserortung setzen eine direkte Sichtverbindung zwischen Basis und Roboter voraus. Dies liegt in der Strahlennatur des (Laser-)Lichtes und lässt sich nicht ohne weiteres vermeiden. Ein Ausweg wäre möglicherweise eine Videokamera oberhalb des Versuchsbereichs, die Blinksignale des Roboters auswerten und daraus Position und Orientierung berechnen könnte. Wir beschränken uns im Folgenden jedoch auf Laser gestützte Systeme.

Unsere erste Idee war eine Art Kreuzpeilung, bei der sich der Laser auf dem Roboter befindet und eine oder mehrere mit Lichtsensoren ausgestattete Basisstationen anstrahlt. Um zur Basis zu gelangen, müsste sich der Roboter lediglich einmal um die eigene Achse drehen, bis er mit seinem Laserstrahl den Lichtsensor der Basis trifft (was die Basis über eine IR-Message an den RCX melden könnte). Der Roboter müsste nun lediglich geradeaus fahren, um die Basis zu erreichen. Zur Erhöhung der Genauigkeit bietet es sich jedoch an, die Peilung in bestimmten Zeitintervallen zu wiederholen, um Kursabweichungen in Folge von Reibung oder Geschwindigkeitsdifferenzen zwischen den Motoren der linken und der rechten Antriebskette zu kompensieren.

Da der Einsatz unseres Lasers auf einem mobilen Fahrzeug wie dem Lego-Roboter zu gefährlich war (der Roboter hätte umkippen und der Strahl unsere Augen schädigen können), haben wir uns für eine andere, zwar weniger effektive, aber dennoch funktionierende Variante entschieden.

Das Prinzip arbeitet wie folgt: Ein Laserstrahl verläuft diagonal über den Bewegungsbereich des Roboters, am Austrittspunkt des Strahls befindet sich die Basis, zu der der Roboter zurückkehren soll. Der Roboter verfügt über zwei Lichtsensoren, die das Laserlicht in ein elektrisches Signal für den RCX umwandeln. Der erste Lichtsensor besitzt einen 360-Erfassungsbereich, so dass jede Durchquerung des Strahls erfasst wird. Der zweite Sensor ist nach vorne ausgerichtet, er erfasst nur Licht, das direkt von vorne auf den Roboter trifft.

Um zurück zur Basis zu gelangen, muss der Roboter nun so lange den Versuchsbereich durchqueren, bis er mit seinem 360-Sensor auf den Laserstrahl trifft. Der Sensor sollte sich auf der Drehachse des Roboters befinden, so dass er den Strahl auch bei einer Drehung des Roboters nicht verlässt. Der Roboter kann sich nun einmal um die eigene Achse drehen, bis er mit seinem Frontsensor den Strahl erkennt und ihm zur Basis folgen kann.

Der Frontsensor besteht bei unserem Roboter aus dem normalen Lego-Lichtsensor, bei dem die integrierte RCX jedoch deaktiviert wurde. Dies geschieht durch Konfiguration des RCX-Einganges als Temperatursensor, wodurch die der RCX keine Betriebsspannung an den Sensoreingang anlegt.

Den 360-Sensor haben wir aus einem Fototransistor, einem 1k-Schutzwiderstand und einem Papierröhrchen zum Schutz des Sensors gegen Streulicht gebaut. Dabei handelt es sich um einen Fototransistor aus einem alten Kosmos-Experimentierkasten, fertig auf einer Platine verlötet.

Zur Messung muss der Sensor über ein Kabel mit dem RCX verbunden werden (Polarität beachten!) und der Eingang als Temperatursensor im RAW-Modus (vgl. Programmierung im Software-Kapitel) betrieben werden.

4.5.2. Laserquelle

Wir haben als Laser ein 3mW-Lasermodul verwendet, das durch ein Papierrohr gegen Blickkontakt abgeschirmt wurde. Ein Stativ aus Fischertechnik diente zur Befestigung und Einstellung der Höhe (siehe Fotos auf der CD). Mit Hilfe eines zweiten Fischertechnik-Stativs gleicher Höhe wurde der Laserstrahl parallel zum Untergrund ausgerichtet.

4.5.3. Sicherheit

Wie oben bereits angesprochen, birgt Laserstrahlung Gefahren für die Gesundheit, sie kann u.a. zu thermischen Netzhautverbrennungen führen, die von bleibenden Augenschäden bis hin zur Erblindung reichen können. Aus diesem Grund sind Sicherheitsvorkehrungen nötig, Laserstrahlung darf nicht in das menschliche (oder tierische) Auge dringen. Bei dem von uns eingesetzten 3mW-Laser der Schutzklasse 3a reicht nach allgemeiner Expertenmeinung der Lidschlussreflex aus, um das Auge vor bleibenden Schäden zu bewahren, jedoch ist selbst das an hellen Oberflächen reflektierte Licht extrem hell. Wir haben um den Laser ein Schutzrohr aus Papier gebaut, um die Gefahr, versehentlich in den Strahl zu blicken, zu minimieren. Der Laserstrahl wurde am Ende des Laserbereichs durch eine dunkle, diffus reflektierende Pappscheibe entschärft. Die Justage des Strahls erfolgte mittels einer Videokamera, so dass der Vorgang gefahrlos auf einem Monitor beobachtet werden konnte.

4.6. Programmierung mit NQC

4.6.1. Programmbibliothek

Quellcode siehe ROBOT.NQH.

Diese Bibliothek enthält die elementaren Low-Level-Routinen zum Zugriff auf die Hardware des Roboters und isoliert das Hauptprogramm weitestgehend von den Details wie RCX-Portbelegung etc.. Die #define-Anweisungen am Anfang des Programms dienen der Konfiguration, mit ihnen wird festgelegt, welche Funktionen von der Hardware unterstützt werden und über welche Ports sie erreichbar sind. Die im Folgenden abgedruckte Version gehört zum neuen Robotermodell. Das heißt, zur Compilierung der Software für den alten Roboter (z.B. Programm 1 zur Lasernavigation) ist die alte Version dieser Datei zu verwenden, welche sich auf der CD befindet.

4.6.2. Beispielprogramm 1: Lasernavigation (Modell 1)

Quellcode siehe LASER1.NQC.

Dieses Programm lässt den Roboter solange geradeaus fahren, bis er den Laserstrahl kreuzt, stoppt dann und richtet sich in Richtung des Lasers aus. Der Roboter folgt daraufhin dem Strahl und richtet sich bei Bedarf neu aus.

Das Programm verwendet verschiedene Modi, die den aktuellen Zustand des Roboters und seine primären Handlungsweisen festlegen. Hintergrund dieses Gedanken ist, dass Roboter oft mehrere Aufgaben simultan ausführen müssen und diese Aufgaben verschiedene Prioritäten besitzen. Es wäre z.B. denkbar, dass der Roboter einem Gang folgt und in diesem einem Hindernis ausweichen muss. Die Modi sind ein erster Versuch, diese Problemstellung in ein Programm zu fassen. Das zweite Beispielprogramm verfeinert dieses Konzept noch durch das Hinzufügen von verschachtelten Modi.

Jeder Modus erhält bei seiner Aktivierung die Chance, sich zu initialisieren. Er wird dann zyklisch aufgerufen um Sensordaten auszuwerden und den Roboter zu steuern.

ModeEingangsbedingungModusverhalten
NONE- keine -Automatik ist aus, manuelle Steuerung über IR-Fernbedienung möglich
STOP- keine -Robober hält an und wartet im Modus 'NONE' auf weitere Befehle
FIND-LASER- keine -Der Roboter fährt gerade aus, bis der 360-Lichtsensor den Laserstrahl kreuzt. Dann stoppt der Roboter und geht in den Modus 'ROTATELASER'
Dieser Mode wird über eine IR-Nachricht gestartet.
ROTATE-LASER360-Sensor befindet sich im Laserstrahl.Der Roboter dreht sich auf der Stelle, bis der gerichtete Lichtsensor auf den Laserstrahl ausgerichtet ist. Dann stoppt der Roboter und geht in den Modus 'FOLLOWLASER'
FOLLOW-LASERDer gerichtete Lichtsensor befindet sich im Laserstrahl.Der Roboter fährt geradeaus auf die Laserquelle zu. Wenn der gerichtete Lichtsensor aus dem Strahl herausfährt, dreht sich der Roboter für kurze Zeit nach rechts und verzweigt dann wieder in den Mode 'ROTATELASER'.
Anmerkung: Dieser Modus beendet sich nicht, der Roboter rammt folglich früher oder später die Basis, da das Erkennen der Kollision per Ultraschall nicht implementiert ist!

Klassifikation: Das Programm stellt eine erste Grundlage dar, es müsste allerdings für den Praxiseinsatz noch verfeinert werden, insbesondere was die Fehlerbehandlung angeht. Da wir das Laserprojekt eingestellt haben, wurde dieses Programm nicht weiter entwickelt und ist deswegen auch als nicht zu Ende geführt zu sehen.

4.6.3. Beispielprogramm 2: Ultraschallnavigation (Modell 2)

Quellcode siehe ROBOT5.NQC.

Dieses Programm fährt geradeaus, bis ein Hindernis erkannt worden ist. Es weicht diesem bei Bedarf aus.

Das Programm basiert auf dem Modus-Konzept des ersten Beispiels, es erweitert es jedoch durch die Möglichkeit, Modi wie Unterprogramme aufzurufen und einen Timeout als Zeitbeschränkung festzulegen.

ModeEingangsbedingungModusverhalten
NONE- keine -Automatik ist aus, manuelle Steuerung über IR-Fernbedienung möglich
RET- keine -Der letzte Modus wird vom Mode-Stack geholt und initialisiert.
STOP- keine -Robober hält an und wartet im Modus 'NONE' auf weitere Befehle
MOVE-AROUND- keine -Der Roboter bewegt sich umher, bei Hindernissen wird ROTATEFREELEFT bzw. ROTATEFREERIGHT aufgerufen.
ROTATE-FREE-LEFTEs befindet sich ein Hindernis vor dem Roboter, das ihn an der Weiterfahrt hindert.Der Roboter dreht sich links herum bis der der Weg vor dem Roboter frei ist. Die Mindestdrehzeit beträgt 1 Sekunde, damit sich der Roboter nicht zu kleinschrittig bewegt.
ROTATE-FREE-RIGHTvgl. ROTATEFREELEFTvgl. ROTATEFREELEFT


Zurück


Letztes Update: 17.04.2002; © by LST