Die technische Entwicklung des bugs und die Tücken der Software
I - Wie alles begann
Zu Beginn des Projektes hielten wir ein paar Einzelteile in der Hand, und wussten gar nicht so recht, wie wir die alle verbinden wollten. Da war ein Paket Fischertechnik-Bauteile, das Fischertechnik-Interface, ein Akku, serielle Kabel, der IPC-Chip samt umgebendem DK40 und noch ein paar Kleinteile. Unsere "Software-Abteilung", zu der ich gehöre, stellte sich nun, konfrontiert mit quasi null Hintergrundwissen über Robotik, aber auch einer gehörigen Portion Interesse, ungefähr folgende Fragen:
1. Nutzen wir das Fischertechnik Interface?
Diese Frage war schnell beantwortet: Natürlich! Es schien uns der einfachste Weg zu sein, die Motoren und Sensoren über das Interface anzusteueren - schließlich hat sich Fischertechnik bestimmt irgendwas bei dieser Konstruktion gedacht....
2. Wie funktioniert der IPC-Chip, was können wir damit machen?
Wir verbrachten die ersten 2-3 Treffen hauptsächlich damit, herauszufinden, welche Schnittstellen (2x RS232 (wir hatten nie beide gleichzeitig in Betrieb), 1x 10Mbit/s RJ45 Netzwerk, Stromanschlüsse) für uns wichtig waren, und wie wir sie in einem selbstgeschriebenen Programm nutzen konnten.
3. Wie zum ... verbinden wir den IPC mit dem Interface?
Spätestens jetzt begannen unsere Köpfe zu rauchen. Nein, die Verkabelung war nicht
unser Problem, vielmehr die Steuerung der Motoren bzw. das Auslesen der Sensoren.
Zur Funktionsübersicht schlossen wir das Interface erst mal an einen "normalen" PC an,
installierten das bunte Softwarepaket und starteten die Interface-Diagnose.
Nach kurzen Interpretation der Anzeigen stellten wir fest:
4 Motoren konnte man einzeln ansteuern und jeweils rechts- oder linksherum rotieren lassen.
8 digitale Sensoren konnten ausgelesen werden, und mit den Schaltern ausgelöst werden.
So weit, so gut. Beim Besuch der Fischertechnik Website begegneten wir den PASCAL-Treibern im Quelltext. Wir hofften, anhand der Quelltexte mehr über das Interface zu erfahren, doch weit gefehlt: Nicht nur, dass der interessante Teil Assemblercode war, obendrein funktionierte er auch nicht. Wir suchten lange unseren Fehler (Kabel richtig angeschlossen? Brauchen wir einen FOSSIL-Treiber für Windows ME? Funktioniert die Schnittstelle wirklich richtig? Aber warum gibt das Programm einfach keine Fehlermeldung aus, sondern verweigert schlicht seine Arbeit?). Ein Telefonat mit der Hotline klärte dann, dass die Routinen alle von "Fans" geschrieben wurden und man keinerlei Support erwarten dürfe!
Also haben wir weitergesucht, und eine Spezifikation des Protokolls zwischen PC und FT Interface gefunden. Diese haben wir dann in einem eigenen Programm verwirklicht und siehe da: Die Motoren verrieten durch kurzes, lautes Schnurren, dass sie gerade aktiviert wurden! Wir hatten es erst mal geschafft!
Ab jetzt konnten wir so richtig loslegen.
II - Bastelstunde
Unsere Hardwaretruppe schuf diverse Versionen des "bugs" - so nannten wir unser Gefährt - , die wir dann gemeinsam immer wieder verwarfen, aus den verschiedensten Gründen (keinerlei Laufgenauigkeit bei dem bug mit Beinen, d.h. wir hätten niemals gewusst, wo der bugs nach einer Bewegung steht; oder er fuhr zu schnell etc.). Bis zum Wochenende auf Schloss Heiligenhoven hatten wir dann endlich unsere Form gefunden: 2 große, breite Gummireifen, die viel Halt auf dem Untergrund hatten, vorne und hintern glatte Stützen. Zugegebenermaßen war der bug nicht geländetauglich, aber er sollte ja nur auf dem glatten Boden oder einem Tisch fahren.
Kai und ich machten dann die meiste Arbeit an den Softwareroutinen. Wir schrieben ein paar Funktionen
unter dem guten alten Borland C++ 3.1 unter DOS, um die FOSSIL - kompatiblen seriellen Schnittstellen
vom IPC benutzen zu können. Dann schrieben wir unseren Programmablauf:
Der Bug sollte die einzuscannende Fläche im Zick-Zack Kurs abfahren. Das bedeutet, erst mal ein gutes
Stück geradeaus, dann nur einen Reifen drehen, so dass das Fahrzeug eine 180° Rechtskurve macht, dann
wieder geradeaus, dann 180° links und wieder von vorn - bis die definierte Fläche abgefahren ist. Leider
kamen wir nie dazu, diesen Ablauf je zu starten, denn ab dem Sonntag auf Schloss Heiligenhofen verfolgte
unsere Gruppe der Fehlerteufel - unser "Bug" war im wahrsten Sinne des Wortes von bugs befallen.
Doch dazu später mehr.
Auch diesen Teil hatten wir schnell fertig. Nun hatten wir aber noch keinen Schrittzähler im bug. Wir konnten also noch nicht messen, wie weit er gefahren ist. Wir fanden 2 Schrittzähler in cefalons privaten Jugendrelikten (also ein demontierter FT-Baukran). Dazu fehlte jedoch jegliche technische Erklärung, wie diese anzuschließen waren. Nach einigem Ausprobieren wussten wir, dass 2 der Anschlüsse für eine konstante Stromversorgung der IR-Lampe im Schrittzähler sorgten und der 3. Anschluss an einen digitalen Sensoranschluss am Interface anzubringen war. Ein spezielles Rad mit abwechselnd roten und schwarzen Streifen auf dem Rand musste so in unserem Getriebe verankert werden, dass dieser Rand genau zwischen der IR-Lampe und dem IR-Sensor im Schrittzähler entlang lief. 32 rote und 32 schwarze Streifen sausten nun pro Umdrehung durch den Sensor.
Wir stießen mit diesem Sensor allerdings an die Grenze der Übertragungsgeschwindigkeit zwischen Interface
und IPC (9600 baud). In dem Protokoll konnte man nur gezielt beim Interface mit einem Befehl nachfragen, wie
denn der aktuelle Zustand der Sensoren so aussieht. Da der Sensor ja auch nur zwischen rot und schwarz unterschied,
mussten wir ganz sicher gehen, dass wir nicht einen roten oder einen schwarzen Balken verpassten. Das bedeutete,
das wir den Schrittzähler nicht direkt am Motor, sondern erst nach reichlicher Untersetzung (noch mehr als das
eigentlich Rad) benutzen konnten.
An dieser Stelle hätte ich mir von Fischertechnik mehr Informationen erhofft. In der Bauanleitung für den
Baukran schlossen die Technikfreaks und Fans den Schrittzähler nämlich vor dem Getriebe an die Achsen an, also
direkt am Motor! Wir konnten zwar ein BASIC-Programm (nicht etwa DOS, sondern für den C64!) auftreiben,
dieses benutzte aber einmal mehr Assemblerroutinen (noch nicht mal Quellcode, sondern übersetzt), die wir nicht
analysieren konnten. Ich hätte gerne gewusst, wie man diese Schrittzähler richtig anspricht.
Mithilfe der Untersetzung schafften wir es dennoch zuverlässig, jede Reifenstandsänderung mitzubekommen. Wenn der Motor lief, waren es ungefär 5 Messungpunkte in rot und 5 Messpunkte in schwarz. Dies entsprach einer Messgenauigkeit von ca. 5mm. Der bug wusste also auf 5mm genau, vor er sich befand. In unseren Tests (20 cm vor- und wieder zurückfahren) bestätigten wir diese Genauigkeit und waren davon beeindruckt.
Zum Schluss des Wochenendes konnten wir also zielsicher vor- und zurückfahren. Die 180° Kurve hatten wir noch nicht gemessen, da die Zeit mittlerweile knapp wurde, da die Abschlusspräsentation für das Wochenende vorbereitet werden wollte...
III - Hardwarebugs
Wie oben bereits angesprochen arbeitete unsere Hardware diverse Male gegen uns. Von vorneherein besaßen wir leider einen defekten IPC-Chip. Dieser wollte aus unverständlichem Grund sein Netzwerkinterface nicht starten, wenn beim einschalten des IPC kein Terminal angeschlossen war. Uns war nicht klar, dass das nicht normal war, schließlich kannten wir den Chip noch nicht vorher. Da die anderen Gruppen uns aber etwas verständnislos anschauten, dass wir ständig unser geliehenes Terminal dabei hatten, merkten wir dann, dass hier ein Defekt vorliegen musste. Nach kurzer Rücksprache mit dem Beck-Entwickler war ein Austausch-Chip schon so gut wie unterwegs.
Als wir nach dem Wochenende beim nächsten Treffen mit dem neuen Chip weiter arbeiteten, fiel plötzlich das nächste Bauteil aus: Nun bekam der IPC keinerlei Daten mehr per seriellem Kabel, sondern konnte nur noch senden. Unser angeschlossenes Terminal bestätigte das: Die Boot-Meldungen erschienen sofort auf dem Bildschirm, aber auf Eingaben reagierte der Chip nicht. Der Verdacht lag nahe, dass das nicht gerade hochgelobte DK40 seinen Geist aufgegeben hätte. Wieder konnte die Firma Beck uns schnell Abhilfe schaffen und sandte ein neues. Der Fehler blieb allerdings.
Wir konnten es nicht glauben, aber es war tatsächlich das silberne Adapterstück von DB9 (Anschluss am DK40) auf RS232, dass unverrichteter Dinge seinen Dienst quittierte. Das vermeintlich defekte Bauteil in diesem Adapter, den marden kurzerhand zerlegte und überprüfte, konnten wir leider auch nicht mehr bei Conrad Elektronik nachkaufen. Und so war dann auch der letzte Donnerstag Abend verstrichen, ohne dass wir nach dem Wochenende wirklich weiter gekommen wären.
IV - Schlusswort
Trotz unzähliger Problemen und Aufgaben, die immer wieder erledigt und bearbeitet werden wollten, hat es zumindest bis zur Pannenserie Spaß gemacht. Wir haben vieles heraus gefunden, lange recherchiert, aber auch einigen Ärger gehabt. Schlussendlich hat leider unsere Motivation zum Ende hin stark nachgelassen, da unsere Aufgabenverteilung nicht unbedingt optimal gestaltet war. Aber aus Fehlern können wir am meisten lernen....
In diesem Sinne,
Pyro.