Die Story

Im August 2001 schrieb der dänische Spielzeughersteller Lego zusammen mit den Firmen Siemens und Hitachi einen Wettbewerb aus, die Lego-Mind-storms-Space-Competition. Die Aufgabe: Es sollte ein autonom operierender Roboter konstruiert werden, der in der Schwerelosigkeit auf der internationalen Raumstation ISS arbeitet. Der siegreiche Roboter wurde mit einer russischen Trägerrakete zur ISS gebracht und anschließend von den Kosmonauten in Betrieb genommen.
Mitmachen konnte jeder, der mindestens 18 Jahre alt, und in der Schweiz, Österreich oder Deutschland lebt. Als technische Randbedingungen wurden das Maximalgewicht von 1,5 kg und eine Außenmasse von höchstens 30*30*30cm festgelegt. Verwendet werden durften nur Teile aus drei bestimmten Baukästen der Lego Mindstorms-Serie. Diese waren vorher in aufwendigen Labortests auf ihre ISS-Tauglichkeit überprüft worden. Bei der Programmierung war Freestile zugelassen. 124 Teams sendeten ihr Konzept ein, und eine hochkarätige Jury, unter der Schirm-herrschaft des deutschen Astronauten Ulf Merbold, wählten schließlich zehn Finalisten aus. Mitte Oktober 2001 war es dann soweit, in München wurden die zehn fertigen Roboter der Jury präsentiert. Gewinner wurde der Roboter Jitter, den mein Sohn mit mir zusammen entwickelt hat. Mitte Dezember 2001 hatten wir beide die Gelegenheit, unsere Konstruktion live vom russischen ISS-Kontrollzentrum aus zu beobachten.

Die Mechanik

Jitter (siehe Abb. 1) ist ein Roboter mit der Aufgabe, selbstständig kleine umhervagabundierende Teile in der ISS einzusammeln. Ein Greifmechanismus (drei schwarze Haken), der durch drei (gelbe) Tasthaare an der Vorderseite ausgelöst wird, schlägt bei Berührung das gefundene Teil in einen, im unteren Bereich angebrachten Sammelkorb. Sicher ist dies nur eine fiktive Aufgabe, aber die NASA entwickelt zur Zeit genau solche kleinen autonomen Helfer, genannt PSA (personal satellite assistant) . Der Name Jitter beschreibt eigentlich den Antrieb. Da Propeller aus genoppten Lego-Platten einen erbärmlichen Wirkungsgrad aufweisen, wurde auf den guten alten Massenimpuls zurückgegriffen (zu deutsch abstoßen). Die beiden Rechnerbausteine (RCX) mussten hier (als schwerste Einzel-bauteile) auch noch als Impulsmassen herhalten. Das Prinzip funktioniert wie folgt: Beide RCX sind auf einem leichtgängigen Kreuzschlitten montiert und können sich in einer Ebene bewegen. An dem Schlitten ist ein kleiner quadratischer Käfig fixiert, in dem eine kleine motorgetriebene Nockenscheibe rotiert. Stößt der Roboter an eine Kabinenwand, rutscht der Schlitten dank der RCX-Masse aus der Mittellage. Die Nokenscheibe schlägt an den Käfig und den RCX-Baustein in die entgegengesetzte Richtung (Abb.1). Wer sich noch (schwach) an seine Physik-stunden erinnert, weiß, dass ein solcher Impuls (Masse mal Geschwindigkeit) ausgelöst wird. Es sind zwei dieser Antriebe montiert worden, um in x,y und z-Richtung einen Antrieb zu erhalten. Das ganze Gerät schüttelt sich also (engl. jitter) bei Wandberührung, und stößt sich so auf einer chaotischen Bahn von einer Kabinenwand zur anderen ab. Und das alles funktioniert noch völlig Java-frei.

Die Technik

Doch nun zur Technik. Der Roboter ist mit zwei Rechnern der Lego-Mindstorms-RCX Serie ausgestattet. Mehr war aufgrund des Gewichtslimits nicht möglich. Jeder RCX - Bau-stein besitzt drei Sensoreingänge und drei Steuerausgänge, was nicht sehr viel für eine komplette Lageregelung ist. Abb. 4 zeigt die schematische Architektur des Roboters. Für das Drehen in der Schwere-losigkeit sind drei motorgetriebene Rotoren (Schwungräder) zuständig. Diese sind auf der x,y und z-Achse montiert. Damit der Roboter immer mit der Vorderseite nach vorn fliegt, muss er nach dem Abstoßen in Flugrichtung gedreht werden. An den Kreuz-schlitten wird über drei Rotations-sensoren (für die x,y und z-Achse) die Aufprall- bzw. Abstoß-richtung ge-messen. RCX1 errechnet den Raumvektor und gibt ihn an die Rotoren-steuerung weiter. Die Lageregelung richtet sich weiterhin an der Kabinenbeleuchtung aus. Zwei Licht-sensoren , mit schmal- bzw. weit-winkligem Gesichtfeld, messen die Licht-intensität. Dreht sich der Roboter, ändert sich der Messwert am schmalwinkligen Sensor früher als am Weitwinkligen. In diesem Fall sucht die Lagereglung durch Nickbewegungen wieder das Licht-maxi-mum zu finden. Die beiden RCX-Bausteine tauschen über eine Infrarotverbindung Daten aus. Das Infrarotsignal wird dabei über die äußeren (roten) Flügel an den Augen umgelenkt. Das aus--ge-sen-dete Infra-rotlicht wird auch noch wie ein Infrarotradar zur Erfassung von Bewegungen wie z.B. winkende ISS-Bewohner benutzt. Die IR-Sendedioden sind ziemlich stark und die Licht-sen-soren IR-empfindlich. Zu den drei Licht-sen-soren sind drei Touchsensoren parallel geschaltet, was nicht weiter stört, da sie kaum gleichzeitig angesprochen werden. Ein Touchsensor löst den schon erwähnten Greifer-mecha-nis-mus aus. Die anderen beiden dienen der Kommu-ni-kation. Der obere zum streicheln, der Hintere für einen Klaps. Jitter führt eine Statistik, ob er bei freundlicher Behandlung wie zuwinken, streicheln munter piept und freudig hin und her wackelt oder nur missmutig brummt. Natürlich wir jeder Fang ausgiebig kundgetan.

Initialisierung und Fail-Save

Wenn der Roboter in Betrieb genommen wird, muss er zuerst seine Umgebung kennen lernen. In einer Initi-ali-sierungsphase sucht und misst er durch rotieren zuerst Lichtmaxima und -minima. Durch eine weitere Rotationssequenz wird die Dreh-ge-schwin-dig-keit in der Schwere-losigkeit ermittelt. Fällt eine der Messung unbefriedigend aus oder ist das Intranet gestört, werden Defaultwerte eingesetzt. Auch die Verteilung der Sensoren wurde so gewählt, dass bei Ausfall einzelner Komponenten noch eine maximale Funktion erhalten bleibt. Diese Vorsichtsmaßnahmen sind not-wendig, denn bei Start-beschleu-nigungen von 5g und heftigen Schwin-gungen wird das Material extrem belastet.

Die Lego-Mindstorms Komponenten

Der Kern des Lego-Mindstorms Systems ist der programmierbare RCX-Baustein. Über eine Infrarotverbindung kann dieser von einem PC mit Programmen versorgt werden. Im Inneren arbeitet ein Hitachi H8300 Micro-controller mit 8Bit und 16MHz. Dieser Microcontroller arbeitet normalerweise in Mobiltelefonen, Waschmaschinen oder Organizern. An Speichern stehen 16K ROM und 32 K RAM zur Verfügung. Die 16k ROM enthalten die Basistreiber z.B. für die Infrarot-schnittstelle und einige Low-Level-Funktionen. Die 32K RAM teilen sich das eigentliche Betriebssystem, (in unserem Fall) die Java-VM, das Programm und die Daten! Wer mehr über die RCX-Internas wissen möchte, sei die ausführliche Internetseite von Kekoa Proudfoot empfohlen.
Es sind drei Sensoreingänge und drei Steuerungs-ausgänge vorhanden. Das ist ziemlich spartanisch, aber alles ist perfekt aufeinander abgestimmt. Werkzeuge, Messgeräte oder Elektronik-kenntnisse sind nicht notwendig. Die Anschlüsse sind, wie bei Lego üblich, über Kontaktbausteine realisiert. An Sensoren stehen Touch-, Rotations-, Licht- und Temperatur-Sensoren zur Verfügung. An die Ausgänge lassen sich Motoren oder Lampen anschließen. Zur Interaktion sind vier Taster und ein LCD-Display auf der Oberseite angebracht. An der (dunklen) Stirn-seite befindet sich die Infra-rotschnitt-stelle. Primär dient sie zur Programm-übertragung. Es gibt jedoch auch eine Hand-fern-bedienung über die der RCX ferngesteuert werden kann. Hostseitig wird zur Übertragung ein IR-Sender/Empfänger (IR-Tower) ange-schlossen. Die IR-Schnittstelle kann aber auch zur direkten PC-RCX oder RCX-RCX Kommunikation verwendet werden.

Die Software

Standardmäßig wird zum Lego-Mind-storms-Set eine komplette grafische Progammier-umgebung geliefert. Programmierkenntnisse sind eigentlich nicht erforderlich. Es wird in guter Lego-Manier am Bildschirm aus kleinen Programmklötzchen ein Programm zusammengesteckt. Die populärste Programmierung ist z.Zt. NQC (not quite C). Ein sehr einfach gehaltener C-Subset, der jedoch alle Sensorinterfaces enthält und Multitasking unterstützt. Die größte Beschränkung ist jedoch der geringe verbleibende Speicher mit 6K für Programm und Daten. Es können auch nur 32 Integer-Variablen gespeichert werden . Hierzu gibt es gibt sehr gute Literatur, z.B. Dave Baums Lego Mindstorms Roboter.

Zum Thema Java

Der Grund, warum NQC für den Jitter nicht zum Einsatz kam, lag zum einen an der Variablen-beschränkung und zum anderen... na ja, wenn man schon die Gelegenheit hat, einen Roboter ins Weltall schicken, dann nicht mit einer Programmiersprache, die von einer Zuse Z3 reimplementiert wurde (der Java-Fan hat gesprochen) . Also wer im Internet sucht, wird meist fündig . Es gibt tatsächlich zwei Java-VM-Implementationen für den RCX. Beide stammen von Jose Soloranzo und stehen als Open Source auf der Internetseite von lejos.sourceforge.net zur Ver-fügung. Die erste Version heißt TinyVM und ist mit dem Ziel einer optimalen Speicherausnutzung im-ple-men--tiert worden. Das Ergebnis ist bemerkenswert, 10KB! Dies wird allerdings mit einigen Einschränkungen erkauft, z.B. einer reinen Integer-arithmetik

leJos Java-VM und Betriebssystem

Aus diesem Projekt entstand leJos (spanisch gesprochen lächos). leJos ist mehr als eine JAVA-VM, es ist auch gleichzeitig ein Minibetriebsystem. Das heißt, das ganze originale Betriebssystem des RCX wird gegen leJos ausgetauscht. Der Fokus der leJos VM liegt auf größerer Vollständigkeit und Performance. Mit 17Kb ist diese VM wesentlich größer, aber in die verbleibenden 10-12Kb passen trotzdem Programme von erstaunlicher Größe (siehe Jitter). Um eines vorwegzunehmen, es handelt sich nicht um eine J2ME-Implementation, sondern um ein RCX-spezifisches Java-Subset.
Die wesentlichen Features sind:

• 32-bit Floating point Arithmetik
• Mathematische Funktionen (trig. log. ...)
• Thread-Support
• Sensor, Motor, Button, Serial - Support
• Native Access
• Multiprogram-Downloading

Nicht unterstützt werden z.B.:

• Garbage Collection (vorbereitet)
• runable interface

Abb.3 zeigt das RCX-Environment mit einer leJos-Installation. Da das Hitachi H8300-System selbst einen (native) Bytecodeinterpreter enthält, fällt die java-VM relativ kompakt aus. Der interpretierte Bytecode entspricht in weiten Teilen einem Subset des Standards. Unterschiede bestehen z.B. in der Objekthaltung; hier tauscht der Lader den Bytecode gegen leJos-spezifische Array-Adressen aus. Der Lader akzeptiert soweit normale class-Dateien, sodass die Lieblings-IDE verwendet werden kann.

Installation

Am besten lädt man das ganze leJos-Paket von lejos.sourceforge.net herunter. Es enthält auch Installations-anweisungen für Windows und Linux. Also entpacken, CLASSPATH setzen, usw.. Wenn der Java 2 SDK noch nicht installiert ist, sollte man das jetzt nachholen. Dann kann schon der erste Test starten. Man hat die Möglichkeit, in einem DOS-Fenster mit der Kommandozeilen-Version des Compiler/Loaders zu arbeiten oder ein ebenfalls mitgeliefertes grafisches Tool, den RCX-Downloadmanager, zu verwenden (Abb. 8). Letzteres ist für die ersten Tests zu empfehlen. Mit den oberen Schalt-flächen können Java-Programme ausgewählt, kompiliert und in den RCX-Baustein geladen werden. Mit den unteren Schaltflächen wird die RCX-Firmware ge-gen leJos aus-getauscht bzw. System--einstellungen vor-genommen. Das Textfeld in der Mitte quitiert die Aktionen und gibt Fehler-meldungen des Compilers aus. Alles in allem ein praktisches Werkzeug. Die Kommandozeilen -Steue-rung empfiehlt sich später, um z.B. zusätzliche Compiler oder Loader-Mel-dungen zu er-halten.

Der erste Test

Als erstes muss die Firmware des RCX gegen leJos ausgetauscht werden. Also den Lego-Infrarot-Tower an den Host (z.B. PC) anschließen und mit dem Preferences-Button am Download-manager die Schnittstelle einstellen. Dann muss der RCX-Baustein eingestellt und mit der IR-Sensor-Seite gegenüber dem IR-Tower aufgebaut werden. Dann wird auf Download Firmware geklickt zwei Minuten gewartet. In der Statusleiste wird der Ladeforschritt in % angegeben. Mit der leJos-Installation werden auch einige Beispiele mitgeliefert, die auch von java-Anfängern nachvollziehbar sind. Hier ein erstes Testprogramm, das einen Motor (an Ausgang A) für 3 Sekunden einschaltet und dann ein akustisches Signal abgibt.

1. import josx.platform.rcx.*;
3. public class FirstTest
4. {
5. public static void main
6. (String[] arg)
7. throws Exception
8. {
9. Motor.A.forward();
10. try {Thread.sleep(3000);}
11. catch(InterruptedException ie){}
12. Motor.A.stop();
13. Sound.beepSequence();
14. }
15. }

Jetzt wird das Programm mit dem Open-Button geöffnet und dann auf Compile geklickt. Wenn die Meldung wie in Bild 6 aussieht, kann die Datei FirstTest.class mit dem oberen Download-Button in den RCX-Baustein übertragen werden. Jetzt muss man einen Motor an Ausgang A anschließen und den RCX anstellen und starten.

Das RCX-API

Hier eine Übersicht über das Package josx.platform.rcx, welches die RCX-spezifischen Klassen und Interfaces beinhaltet.

1. Interface Summary
2. ButtonListener Abstraction for receiver of button events.
3. Opcode Opcode constants.
4. Segment LCD segment constants.
5. SensorConstants Constants for Sensor methods.
6. SensorListener Listener of sensor events.
8. Class Summary
9. Button Abstraction for an RCX button.
10. LCD LCD routines.
11. MinLCD Only the most basic APIs from LCD.
12. MinSound Only the most basic APIs from Sound.
13. Motor Abstraction for a motor.
14. Native Provides access to native routines.
15. Poll Provides blocking access to events from the RCX.
16. ROM Provides access to ROM routines that fall in a "miscellaneous" category.
17. Sensor Abstraction for a sensor Serial Low-level API for infra-red communication between an RCX and the IR tower or between two RCXs.
18. Sound RCX sound routines.
19. TextLCD Display text on the LCD screen.

Performance

Bei Robotersteuerungen kommt der Performance eine besondere Bedeutung zu. Von einem 8 Bit Controller sollte man keine Wunder erwarten. Die Floatingpoint-Berechnungen liegen bei 1500-2000 Flops. Jedoch scheint die Thread-Klasse ziemlich maschinen-nah implementiert zu sein. Das heißt, man sollte hier die Java-eigenen Möglichkeiten des Multithreadings nutzen anstatt ein plattes Polling auf Hochsprachenebene zu programmieren. Überhaupt sind die Sensor-Klassen recht effizient und nehmen dem Programmierer die meiste Arbeit beim Eventhandling ab. Die Mindstorms-Java-Gemeinde wächst z.Zt. ziemlich rasch und die im Internet verfügbaren Beispiele decken viele Bereiche ab. Stellvertretend sei hier die Ausarbeitung Advanced programming of the Lego RCX for education der Universität von Dänemark genannt (http://www.iau.dtu.dk/~lego/lego3). Hier findet man Hinter-grund-infor-mationen und eine Reihe von Anregungen für eigene Programme. Wichtig bei Open-Source-Projekten wie leJos ist natürlich der Support. Hier gibt es auch Hilfe (der Autor weiß wovon er spricht).

Fazit zu Lego-Mindstorms und leJos

Die Entscheidung, die Jitter-Software mit Java und leJos zu entwickeln, war sicher sinnvoll. Java bietet gerade dann, wenn ein Projekt unter enormem Zeitdruck steht, deutlich mehr Sicherheit als z.B. Assembler. Die Performanceeinbußen sind erträglich und die leichte Nach-vollziehbarkeit fremder Programmteile ist ein nicht zu unterschätzender Vorteil. Für den, der Roboter oder Messstationen bauen möchte und keine Drehbank und kein Elektroniklabor zu Hause stehen hat und schnell zu einem Prototyp kommen will, ist die Lego-Mindstorms-Serie ein schneller Weg zum Erfolg. Java mit leJos und seinen Werkzeugen ist mehr als nur eine Alternative zur Orginalsoftware. Auch Java-Anfänger haben hier die Möglichkeit, schnell zu brauchbaren Ergebnissen zu gelangen.
Allgemein wird man gerade im Bereich embedded Systems / J2ME in naher Zukunft noch eine Menge erwarten dürfen. Im Januarheft des Javamagazins wurden im Beitrag Silicon Java bereits Nativ-Java-Prozessoren vorgestellt. Einer dieser Prozessoren wird in diesem Frühjahr in einem Mindstorms- kompatiblen Set vorgestellt. Wir dürfen also gespannt sein.