Von Wolf Richter
Zum Zeitpunkt dieses Berichts ist die Umsetzung des
Seminarprojektes noch nicht vollständig geschehen. Vielmehr sind zu den
einzelnen Punkten Konzeptstudien entstanden. Die Integration in ein funktionsfähiges
Gesamtsystem steht noch aus.
Schuld an der Verzögerung sind die zu ehrgeizig gewählte
Aufgabenstellung, die optimistische Einschätzungen der Leistungsfähigkeiten des
Lego Mindstorm Systems, insbesondere in bezug auf die Genauigkeit der
Steuermöglichkeiten, die ohne vorherige Versuche geschehen ist, und weitere
unvorhergesehene Überraschungen mit dem Compiler und den Bibliotheken für die
IR Schnittstelle.
Es bestehen zur Zeit funktionsfähige Lösungen für die
Übertragung der Daten von dem RCX zum Zentralrechner, eine einfache
Datenverwaltung und Routinen für die Steuerung des RCX bei gleichzeitiger
Benutzung von Rotations-, Tast- und Lichtsensor und Kommunikation über die IR
Schnittstelle.
Es bestehen Erfahrungen zur Leistungsfähigkeit von
verschiedenen Antriebsmöglichkeiten (Kettenantrieb, Gummiräder, Zahnräder) und
verschiedenen Möglichkeiten zur Bewegungs- und Positionsbestimmung (mit Hilfe
von Licht und Rotationssensor), die allerdings nicht im Sinne der
ursprünglichen Planung funktionierten, geschweige denn für eine Integration
funktionsfähig wären.
Nicht getestet wurde der geplante gleichzeitige Einsatz von
zwei RCX Einheiten in dem Experiment, bei dem weitere Überraschungen zu
erwarten sind.
Es wurden im Laufe des Projektes eine Robotereinheit auf
Lego-Basis entworfen und gebaut, ein Steuerprogramm namens rcxmove.c für die
Steuerung der Robotereinheit und die Übertragung der Daten geschrieben, sowie
eine kleine Datenspeicheranwendung namens rcxkom.c, die auf einem LINUX Rechner
die von der Robotereinheit übertragenen Daten empfängt, speichert und primitiv
visualisiert.
Die Programme wurden in C geschrieben und mit Hilfe des
legOS- Compilers für die RCX Einheit und des gcc für den LINUX Rechner
kompiliert.
Die Datenübertragung zwischen dem Rechner und dem Roboter
findet über die serielle IR-Einheit statt, die Lego mit dem Lego Mindstorm
System ausliefert.
Ein Experimentierfeld mit einem aus schwarzen Linien bestehenden Gitterrater, wie in der Projektbeschreibung beschrieben, wurde bislang nicht angefertigt.
Als Basis für die Konstruktion des Roboters wurde der in der
Constructopedia angegebene Roboter mit Kettenantrieb verwendet. Der
Kettenantrieb wird von zwei Motoren getrieben, einer für jede Seite. Dadurch
ist ein unabhängiger Betrieb der beiden Ketten möglich. Geplant war, dadurch
Drehungen auf der Stelle zu ermöglichen.
Diese Basiseinheit wurde an der vorderen Stossstange mit
einem Drucksensor in Fahrtrichtung und einem Lichtsensor, der in Richtung Boden
leuchtet, ausgerüstet. Die linke Vorderachse wurde mit einem Rotationssensor
versehen, der die Umdrehungen der Achse misst. Die Infrarotschnittstelle am
RCX-Gehäuse blieb unverbaut, da über diese eine dauernde Datenübertragung zum
Zentralrechner stattfindet.
Die Steuerung der Robotereinheit wird durch das Programm
rcxmove geleistet. Rcxmove ist weiterhin für die Positionsbestimmung und die
Kommunikation mit dem Zentralrechner zuständig. Es überwacht die Sensoren und
die Infrarotschnittstelle und steuert die Motoren. Die Überwachung und
Steuerung ist dabei durch threads realisiert.
Ein thread ist dabei für die Steuerung der Motoren,
Überwachung des Drehsensors und des Drucksensors zuständig, einer für die
Überwachung des Lichtsensors und die Positionsbestimmung und einer für die IR
Kommunikation.
Im Anfangszustand wird davon ausgegangen, dass der Roboter
sich auf dem Feld (1,1) befindet und in Fahrtrichtung Süden zeigt. Es wird
weiterhin davon ausgegangen, dass auf dem Experimentierfeld ein Gitterraster
mit schwarzen Linien aufgemalt ist und das Experimentierfeld durch Hindernisse
umschlossen ist.
Ein Hindernis ist dabei ein fester Gegenstand von der Größe
eines Gitterfeldes, der von dem Drucksensor erkannt werden kann. Solche
Hindernisse befinden sich auch auf dem Experimentierfeld.
Bei seiner Fahrt über das Experimentierfeld überquert der
Roboter die schwarze Linien. Das
Überfahren der Linien wird vom Lichtsensor registriert. Je nach Fahrtrichtung,
die intern in der Variablen „direction“ gespeichert ist, wird die x- bzw. die
y-Koordinate um eins erhöht bzw. erniedrigt.
Stößt der Roboter gegen ein Hindernis, was ihm durch die Auslösung des Drucksensors signalisiert wird, setzt er ein halbes Gitterfeld zurück und dreht in der Mitte um 90 Grad nach Links. Die Entfernung des Zurücksetzens sowie der Drehung werden durch den Rotationssensor gemessen.
Dieses Verfahren führt aus verschiedenen Gründen zu großen
Ungenauigkeiten.
Zunächst kann der Rotationssensor höchstens in viertel
Umdrehungsschritten abgefragt werden. Dadurch addieren sich die kleinen Fehler
bereits nach wenigen Drehungen zu relativ großen Differenzen auf. Die Folge:
Der Roboter fährt nicht mehr parallel zu den Linien, sondern in einem
deutlichen Winkel. Dadurch wird die Positionsbestimmung gestört, die ja davon
ausgeht, dass die Einheit Linien im rechten Winkel überfährt.
Ein ganz großes Problem stellte sich in mechanischer
Hinsicht. Die Reibung des Gummis der Ketten ist so groß, dass die Drehung nur
sehr langsam ausgeführt wird und nur dadurch möglich wird, dass Räder
durchdrehen bzw. rutschen. Dies ist natürlich für eine akkurate
Positionsbestimmung unbrauchbar. Erstaunlicherweise zeigte ein von mir zu Hause
mit ähnlichen Teilen gebauter Prototyp auf verschiedenen Untergründen (IKEA
Buche Furnier, 80g Papier, mehrfach abgeschliffener Holzfußboden aus der Zeit
der industriellen Revolution) dieses Problem nicht. Leider war es mir bislang
nicht möglich, mein Modell mit dem Programm „rcxmove“ zu testen.
Die am Institut entwickelten Alternativen drehten zwar in
der Regel besser, dafür aber noch unzuverlässiger. Vorne kleine und hinten
große Gummiräder brachten bislang die besten Erfolge. Der von Oliver
entwickelte Zahnradantrieb, bei dem anstelle der Räder Zahnräder eingesetzt
wurden, konnte nicht nur optisch wenig überzeugen. Vielmehr nutzte er die
Eigenschaft, dass Plastikzahnräder in Querrichtung keinen Halt bieten und auf
glatten Böden prächtig rutschen. Deshalb zeigte das Modell auch rasante
Dreheigenschaften, die gemessenen Winkel wiesen aber Toleranzen von über 20
Grad pro Drehung auf.
Als Ergebnis kann zur Zeit nur gesagt werden, dass eine
Fahrtrichtungssteuerung mit Hilfe des Rotationssensors und Messung der
Achsendrehung nicht möglich ist. Dazu müsste es gelingen, eine verlust- und vor
allem rutschfreie Drehtechnik zu entwickeln.
Erfolgsversprechender scheint die Verfolgung einer
Positionierungs- und Steuerungsstrategie zu sein, die während der Fahrt eine
ständige Nachsteuerung ermöglicht, z.B. durch das Folgen von auf der Erde
aufgezeichneten Linien. Zur Diskussion weiterer Steuerungsmöglichkeiten siehe
auch die Projektbeschreibung.
Ist ein Hindernis gefunden, teilt rcxmove dies der Datenbank mit. Dazu wird das „found“-Flag auf „1“ gesetzt. Wird die Robotereinheit das nächste Mal vom Zentralrechner nach der Position gefragt, übermittelt sie die Position zusammen mit dem gesetzten „found“-Flag. Sollte in der Zwischenzeit eine schwarze Linie überfahren worden sein, wird zwar die interne Position entsprechend verändert, nicht aber die zur Übertragung anstehende, da ja die Position des Hindernisses und nicht die aktuelle übertragen werden soll. Erst wenn die Position des Hindernisses übertragen worden ist und das „found“-Flag wieder auf 0 gesetzt ist, wird die zu übertragene Position wieder regelmäßig aktualisiert.
Als Grundlage für die Konstruktion der Datenbank wurde das
Programm firmdl.c verwendet, von dem die Kommunikationsteile übernommen wurden.
Insbesondere die Routinen zum Öffnen der Schnittstelle und dem Beginn der
Kommunikation erwiesen sich als außerordentlich hilfreich.
Als Ergebnis entstand das Programm „rcxkom“, das die
Datenspeicherung und –verwaltung sowie die Kommunikation mit den Robotern übernimmt.
Die Datenbank speichert die Daten in einem zweidimensionalen
Feld. Jeder Eintrag in dem Feld repräsentiert ein Quadrat auf der
Experimentierfläche. Zu Beginn enthalten alle Einträge den Wert „o“. Dabei
steht „o“ für ein noch nicht erforschtes Quadrat oder eines auf dem kein
Hindernis angetroffen wurde, und „x“
für ein Quadrat auf dem ein Hindernis angetroffen wurde. Eine offensichtliche
Erweiterung wäre die Ergänzung dieser Symbolik um ein Zeichen für ein bereits
erforschtes Quadrat ohne Hindernis.
Das Feld kann mit Hilfe der Funktion display_table()
ausgegeben werden. Die Darstellung entspricht der Draufsicht auf das
Experimentierfeld und dem aktuellen Stand der Erforschung.
Für die Ansteuerung der beiden RCX-Explorer wurde folgendes
Verfahren gewählt: Über die Infrarotschnittstelle sendet der Zentralrechner
abwechselnd ein Null und eine Eins. Den beiden Explorereinheiten ist jeweils
eine der Kennungen Null oder Eins zugeordnet. Wird nun die Kennung einer der
beiden Einheiten aufgerufen, antwortet die angesprochene mit ihrer Kennung und
den zu übertragenden Daten wie oben beschrieben. Die andere Einheit ist ruhig
bis ein Datensatz mit ihrer Kennung beginnt. Es findet eine Überprüfung der
Länge des gesendeten Datensatzes statt, eine Fehlerkorrektur gibt es zur Zeit
aber nicht.
Der übertragene Datensatz besteht aus der Kennung der sendenden Einheit, der Positionsangabe und dem „found“ Flag. Ist das „found“-Flag gesetzt wird die angegebene Position in der Tabelle mit einem „x“ versehen.
Die Datenübertragung zwischen Robotereinheit und
Zentralrechner geschieht über IR. Die verwendete Übertragungsart ist 8N1.
Die Kommunikation wird von dem Zentralrechner eingeleitet,
der abwechselnd 0 und 1 sendet, wobei 0 für den einen und 1 für den anderen RCX
steht.
Der gerufenen RCX beantwortet die Anfrage mit der Angabe
seiner Position. Für die Antwort des RCX an den Zentralrechner wird ein
Datenformat fester Länge verwendet:
Übertragen wird ein Integer Feld der Länge 4.
Erste Stelle: 0 bzw. 1 // RCX-Kennung der sendenden Einheit,
um festzustellen, ob auch die richtige geantwortet hat. Weiterer Vorteil: Die
andere Einheit wird durch den Datenversand nicht gestört, da sie nur auf
Datensätze, die mit ihrer eigenen Kennung beginnen, reagiert.
Zweite Stelle: x-Koordinate
Dritte Stelle:
Y-Koordinate
Vierte Stelle: Hindernis gefunden ja (1) oder nein (0)
Die nächste anstehende Verbesserungen wäre die Aufgabe der
festen Längen durch Hinzufügen einer Stelle für die Länge des übertragenen
Feldes. Dadurch könnten die Kommunikationsmöglichkeiten beträchtlich erweitert
werden. Eine weitere Erweiterung wäre die Möglichkeit, die Robotereinheiten
untereinander kommunizieren zu lassen. Dazu wären keine Veränderungen am
Datenformat nötig. Allerdings müsste man sich Gedanken über die Reihenfolge
beim Senden der Nachrichten Gedanken machen, um Kollisionen zu vermeiden.
Papert, Seymour, Lego et al., Constructopedia, Cambridge,
MA/Aarhus/Legoland, 1998
Richter, Wolf, Projektbeschreibung „Lego Explorer Duo“,
Berlin, 1999, www.informatik.hu-berlin.de/~wrichter/projekte