Windows auf dem Roboter

Spätestens bei aufwändigen Algorithmen wie bei der Bildverarbeitung kommt man meistens nicht umhin, einen im Vergleich zum Mikrocontroller sehr rechenstarken PC zu verwenden. Es gibt zwar auch hier Kameramodule, die Aufgaben wie das Finden von Farben selbst übernehmen. Ebenso bieten sich Funkkameras an, mit denen die Bildverarbeitung auf einem zentralen Rechner durchgeführt und deren Daten dann an den Roboter zurückgesendet werden können. Wenn man sich aber doch für einen kleines Mainboard entscheidet, das auf dem Roboter installiert wird, kommt die Frage nach dem richtigen Betriebssystem auf.

Die Linux-Benutzer unter uns werden sicherlich auch hier dieses OS wählen, da es sehr einfach auf die relativ niedrigen Bedürfnisse optimiert werden kann. Dies ist unter Windows hingegen nicht so einfach, man installiert entweder alles oder nichts. Diejenigen, die dennoch Windows verwenden möchten, könnten von der im Folgenden vorgestellten Variante profitieren.

Vor kurzem bin ich durch Zufall auf Windows XP embedded gestoßen. Dabei handelt es sich um eine modulare Version von Windows XP, mit der ein angepasstes System erstellt werden kann. Dieses kann so eingerichtet werden, dass es erstens nur die Gerätetreiber, die wirklich benötigt werden, enthält. Der Nachteil dabei zwar, dass neue Komponenten dann nicht mehr wie sonst üblich nur eingesteckt werden müssen, um zu funktionieren. Der Vorteil ist aber der geringe Speicherverbrauch, der (zweitens) auch dadurch vermindert wird, dass Systemkomponenten wie Hardware-Manager, Assistenten oder Sicherheitscenter, aber auch Mitbringsel wie Hintergrundbilder und Sounds nur dann installiert werden, wenn man sie wirklich braucht. Dies wiederum kann (drittens) verhindern, dass das plötzliche Anspringen von Diensten wie Automatische Updates oder Festplattendefragmentierung die Systemleistung verringert.

Würde man alle Komponenten installieren, sollte das System einer Windows XP Professional Installation entsprechen.

Windows XP embedded ist im normalen Handel nicht erhältlich, da es für Firmen gedacht ist, die für eine ganze Serie von Geräten ein System-Image wie oben beschrieben erstellen und für dieses dann eine Lizenz erwerben. Eingesetzt wird Windows embedded zum Beispiel bei Geldautomaten oder den Kassen bei McDonalds. 

Kostenlos ist jedoch eine Testversion (Download bei Microsoft), die nur in der Laufzeit der Images auf drei Monate beschränkt ist. Nach der Installation eines Images fährt dieses also nach dieser Zeit nicht mehr hoch und muss neu installiert werden. Die Entwicklungsumgebung hingegen funktioniert meiner Erfahrung nach (ich übernehme aber keine Garantie dafür) unbegrenzt. Da wohl kaum ein Hobby-Robotiker länger als drei Monate den Roboter "verwendet", ohne daran etwas zu verändern, ist Windows embedded denke ich eine sehr interessante Angelegenheit.

Genaue Schritt-für-Schritt-Anleitung für das Erstellen eines Images gibt es im Internet einige. Interessant sind besonders die Videos auf der Microsoft-Website, die alles genau beschreiben: Video-Tutorials von Microsoft.

Hier möchte ich nur ein paar allgemeinere Dinge ansprechen.

Die Installation läuft nicht in einem Rutsch ab, vielmehr muss man sechs Komponenten hintereinander installieren, was jedoch sehr einfach ist. Der Download enthält drei Ordner ("DISK1", "DISK2" und "disk3"), wobei sich das durchzuführende Setup in "DISK1" befindet. Über das angezeigte Fenster können dann zunächst die Tools "Component Designer", "Target Designer", "Component Database Manager" sowie weitere nötige Programme installiert werden.

Im zweiten Schritt erfolgt die Installation der Database Engine. Die Komponenten werden in einer Datenbank verwaltet, weshalb eine solche zunächst installiert werden muss. Es handelt sich dabei um die Microsoft SQL Desktop Engine. Hat man diese schon installiert, so kann der Schritt übersprungen werden.

Danach wird die eigentliche Komponenten-Datenbank installiert, was verglichen mit den anderen Installationen mit Abstand am längsten dauert.

Mittlerweile gibt es das Service-Pack II (hat wohl direkt etwas mit dem SPII für das normale WinXP zu tun), das zwar mitgeliefert wird, jedoch separat installiert werden muss. Dazu führt man das Setup im "disk3"-Verzeichnis aus. Links sind nun die Einträge "Database Engine Update", "Tools Update" und "Database Update" aufgeführt, wie wieder hintereinander ausgeführt werden müssen.

Die eigentliche Arbeit bei der Erstellung einer so genannten Konfiguration, aus der dann das lauffähige Image erstellt wird, geschieht im Target Designer. Hier werden die System-Komponenten ausgewählt, die das System später beinhalten soll. Die verfügbaren Komponenten werden links angezeigt und lassen sich auch durchsuchen. Um einen Überblick zu bekommen kann man hier einmal ein paar Begriffe wie "Device Manager" oder "System Control Panel" eingeben. Über das Kontextmenü gelangt man zu einer Beschreibung der gewählten Komponente.

In der Mitte werden die Komponenten angezeigt, die das eigene Image enthalten wird. Per Drag and Drop können hier Einträge von links eingefügt werden. Das Erstellen eines lauffähigen Systems würde sehr viel mehr Arbeit machen und noch viel mehr Wissen über den Aufbau von Windows erfordern, wenn der Target Manager hier nicht Abhilfe schaffen würde. Nachdem man einige Komponenten hinzugefügt hat, muss überprüft werden, ob diese Komponenten wiederum andere Komponenten benötigen. Hierfür eignet sich der Dependency Check ("Configuration / Check Dependencies").

Er fügt benötigte Komponenten automatisch hinzu, sofern dazu nur eine Möglichkeit zur Auswahl steht. Im anderen Fall wird am Ende eine Aufgabeliste erstellt, in der angegeben ist, was für Typen von Komponenten noch hinzugefügt werden müssen. Beispielsweise muss man dann selbst entscheiden, ob man die deutsche oder englische Sprachunterstützung hinzufügen will, der Target Designer besteht lediglich darauf, dass irgendeine ausgewählt wird.

Das automatische Hinzufügen der benötigten Komponenten hat jedoch auch einen Nachteil - man kann ihn scheinbar nicht rückgängig machen. Fügt man also eine neue Komponente hinzu und lässt den Dependency Check laufen, und stellt im Nachinein fest, dass man die eben hinzugefügte Komponenten doch nicht benötigt, so gibt es wie mir scheint keine Möglichkeit, die nun ebenfalls überflüssigen, automatisch hinzugefügten Komponenten ebenfalls zu entfernen. Ich habe es mir deshalb angewöhnt, immer vor dem ersten Dependency Check eine Sicherungskopie zu erstellen, die also nur die von mir selbst hinzugefügten Komponenten enthält. Will ich dann eine Komponente doch wieder entfernen, gehe ich zu dieser Kopie zurück, lösche sie dort und mache einen neuen Dependency Check (und speichere unter einem anderen Namen).

Bei der Auswahl der Komponenten sollte man natürlich generell zuerst überlegen, was man überhaupt machen möchte, also ob man die neuen XP-Styles möchte, oder ob das alte Grau ausreichend ist, welches Dateisystem gewünscht ist (hier muss man zum Beispiel auch daran denken, dass man die Dateisysteme CDFS oder UDFS hinzufügen muss, wenn man CDs und DVDs lesen können möchte) oder ob man den Task Manager braucht. Für die grundlegenden Hardware-Treiber hilft die Verwendung des Target Analyzers.

Dies ist ein kleines Tool, das im "utilities"-Verzeichnis ausgehend vom Installationsverzeichnis von Windows Embedded zu finden ist. Es wird auf dem Rechner, auf dem später das Image laufen soll, ausgeführt, und stellt eine Liste mit Komponenten zusammen, die nötig sein werden, um alle Hardware-Komponenten, die dort installiert sind, zu verwenden. Dies gilt allerdings nur für die Hardware, die mit Standard-Treibern läuft, denn die Windows Embedded Datenbank enthält natürlich nur die Windows Standard-Treiber.

Ein Problem bei dem ganzen Vorgang ist, dass also vorher auf dem Zielgerät eine Windows-Installation vorhanden sein muss, auf der der Target Analyzer ausgeführt werden kann. Dies scheint zunächst irgendwie sehr umständlich, auf der anderen Seite muss man wahrscheinlich zugeben, dass es anders einfach nicht machbar ist.

Beim Ausführen des Programms wird eine Datei erstellt, die dann zur Erstellung einer eigenen Komponente, die man zum Beispiel "Hardware Config" nennen könnte, verwendet wird. Dieser Vorgang wird in einigen Tutorials beschrieben, weshalb ich dies hier nicht weiter ausführen möchte.

Hat man irgendwann seine Konfiguration fertiggestellt, muss das Image über "Configuration / Build Target Image" erstellt werden. Das fertige Image wird nicht wie ein normales Windows installiert sondern einfach auf die Festplatte kopiert und ausgeführt. Der Begriff Image ist eigentlich nicht korrekt, es handelt sich nämlich einfach um ein Verzeichnis mit den Systemdaten, das demnach genauso aussieht wie die System-Partition eines normalen Windows. Der Speicherbedarf ist hingegen wesentlich geringer, was aber natürlich von der Anzahl der gewählten Komponenten abhängt. Für einen Roboter sollte man schätzungsweise zwischen 100 und 200 MB einplanen, was nicht heißen soll, dass wesentlich kleinere Images unmöglich sind.

Das Kopieren der Dateien auf das Device stellt die letzte Hürde da. Denn wenn dort kein Betriebssystem installiert ist, muss man tatsächlich die Platte in einen anderen Rechner einbauen, was sehr mühsam ist, gerade wenn man viel experimentiert.
Ich habe deshalb zwei Partitionen eingerichtet, wobei auf beiden ein Image installiert ist. Das erste ist das für den eigentlichen "Roboter-Betrieb", das zwei ist eins, mit dem ich die Dateien des ersten vom USB-Stick oder per Netzwerk kopieren kann. Klingt umständlich, ist aber sehr praktikabel, besonders weil die Images wie bereits angesprochen nicht so viel Festplattenkapazität beanspruchen und zwei zusammen immer noch wesentlich weniger Platz brauchen als eine normale XP-Installation. Man kann natürlich auf der zweiten Partition auch normales XP installieren, wenn man es für den Target Analyzer sowieso braucht.

Man muss durchaus ein paar Dinge beachten, wenn man mit Windows embedded glücklich werden will. Microsoft gibt an, dass man das erste lauffähige Image innerhalb einer Stunde zusammengestellt hat. Obwohl ich zugeben muss, dass ich wesentlich länger gebraucht habe, ist das ganze Software-Paket recht einfach zu bedienen, und die Informationen im Internet sind auch nicht die schlechtesten, wenn auch meist nur auf englisch.

Ein fertiges Image fährt recht schnell hoch und läuft auch sehr stabil. Die geringe Größe macht es möglich, statt einer Festplatte einen USB-Stick zu verwenden, was ich jedoch bisher noch nicht probiert habe. Keine Festplatte zu benötigen ist ein echter Gewinn.

Interessiert man sich ein wenig für Betriebssysteme, kann die Zusammenstellung der Konfiguration durchaus auch Spaß machen. Meiner Meinung nach lohnt es sich auf jeden Fall, Windows embedded einmal auszuprobieren, dann sollte man aber Zeit mitbringen.