März 2004: Versuche mit dem Epia-Board
Mai 2004: Erstes Gesamtkunstwerk
Sommer - Ende 2004: Stromversorgung aus Akkus
Februar 2005: Erste Gehversuche
März 2005: Erste VisualBasic Programme
Herbst 2005: Außenhaut, Kopf, Beleuchtung
November 2005: Fernsteuerung mit WLan
Sommer 2006: Neues Elektronik-Konzept, neuer Controller
Herbst 2006: Ein zweiter Roboter
Zunächst wollte ich das neu erstandene Board auf seine grundsätzliche Funktion testen. Es wurde also wild mit einem ATX-Netzteil, Floppy, Festplatte und CD verdrahtet und mit Win2000 und allen mitgelieferten Treibern gefüttert.
Nach Installation des VGA-Treibers muß man erst herausfinden, daß kein noch so versteckter Optionsbutton den TV-Out aktiviert, sondern nur ein korrekt mit 75 Ohm terminierter angeschlossener Fernseher. Der von mir verwendete portable Fernseher hatte diesen Abschluß nicht, was zu einiger Verwirrung führte. Man muß dann eben in einen der Cinch-Stecker einen 75Ohm-Widerstand zwischen Signal und Ground einlöten. Der TV-Out funktioniert auch nur, wenn mit angeschlossenem Fernseher gebootet wird, und wenn eine Auflösung von 640x480 oder 800x600 eingestellt ist. Von formatfüllend kann keine Rede sein. Das Bild, das parallel auf dem VGA-Monitor ausgegeben wird, verzieht es ordentlich. Es kann sein, daß ich in die Feinheiten des Treibers nicht genügend eingestiegen bin, daß es Experten-Treiber und Zaubermittel zum Runterladen gibt, aber für das Zeichnen eines Smileys in Schwarzweiß auf dem portablen Fernseher reicht es mir. Hier das Ergebnis:
Wichtig war auch die Stromversorgung. Ich hatte Bedenken, daß das Board gerade an 3,3V, die ich relativ umständlich über einen Linearregler aus 5V generieren werde, saftig Strom zieht. So habe ich erst einmal ein Strommeßgerät nacheinander in die Zuleitungen der verschiedenen Spannungen eingeschleift. Die Peripheriekomponenten wurden noch außer Acht gelassen, das muß ich irgendwann noch nachholen. Letztendlich sind aber nur eine Laptop-Festplatte und ein langsames CD-Laufwerk geplant.
Folgende Tabelle zeigt das Ergebnis. Die Maximalwerte kamen beim Booten zustande, als das Board etwas zu tun hatte. Vielleicht kann man es durch andere Programme noch mehr zum "Schwitzen" bringen, da kenne ich mich nicht aus. Die Idle-Werte gelten, wenn das VisualBasic-Programm statisch den Smiley anzeigt und sonst nichts passiert.
| Spannung | Maximalstrom | Idle-Strom | Bemerkung |
| 3,3 V | 1,75 A | 1,26 A | |
| 5 V | 2,3 A | 0,47 A | |
| 12 V | noch nicht gemessen | noch nicht gemessen | |
| -12 V | 0 mA | 0 mA | Wird vermutlich heute nicht mehr gebraucht, auch nicht für serielle Schnittstelle (hab' ich ausprobiert). |
| -5 V | Waren beim ATX-Netzteil schon gar nicht vorhanden |
Nachdem im CAD eine Blechkiste gezeichnet war, die Motoren und Akkus beherbergen kann, ging es an die ersten mechanischen Arbeiten. Es motiviert nämlich, wenn man etwas sehen und anfassen kann! Nun muß ich hier auch keine virtuellen Gebilde vorstellen, sondern kann schon Fotos zeigen. Natürlich mußte ich die Motoren kurz direkt an die Akkus anschließen - das Versuchsergebnis war befriedigende Geschwindigkeit und ordentliche Kraft. Zumindest auf Fliesenboden drehen die Räder an einem Hindernis einfach durch, obwohl das Fahrwerk bereits über 10 kg wiegt. Auf Teppichboden habe ich mir den Versuch angesichts des schwarzen Gummiflecks auf der Fliese dann verkniffen. Auch beim Starten quietscht es (!), aber eine PWM-Ansteuerung der Motoren wird das schon regeln.
 |
 |
 |
Nun ist auch der Aufbau in seinen Grundzügen fertig. Sieht finde ich schon ganz nett aus. Im folgenden ein paar Verbrecherfotos. Das ganze Laufwerksprogramm habe ich zunächst eingebaut, um für die Programminstallation und Programmierung wirklich einen vollständigen PC an Bord zu haben, an den ich nur Tastatur, Maus und Monitor anstöpseln muß. Später wird wohl mindestens das Floppylaufwerk überflüssig, und wohl auch das CD-Laufwerk, es sei denn, er soll zum Musike machen bei Fuß kommen. Die 3,5"-Festplatte ist fest eingeschraubt, aber ich glaube, bevor der Roboter sich wirklich bewegt, werde ich sie federnd aufhängen und wohl auch auf ein 2,5"-Laufwerk umsteigen.
 |
 |
Ein (Schalt-)Bild sagt natürlich mehr als 1000 Worte, aber da ich zu faul bin, für ein letztlich nicht erfolgreiches Konzept einen sauberen Schaltplan zu zeichnen, wird hier eben ein bißchen schwadroniert.
Zunächst versuchte ich, wie unter Konzept beschrieben, die Ladung der drei 12V-Akkus zu überwachen und auszugleichen, indem sich die Stromversorgung der C-Control über kleine Doppelumschalt-Relais wahlweise an einen der drei Akkus hängen kann. Über weitere Relais werden die Akkus entweder in Ruhe parallel auf eine Ladebuchse geschaltet oder in Serie, um den 36V-Spannungswandler für das Mainboard und die Motoren zu betreiben. Ein kleiner Trick noch: Damit in Ruhe nicht ständig ein Relais angezogen sein muß, ist die C-Control in Ruhestellung der "Wähl"-Relais auch mit der Ladebuchse verbunden.
Beim Starten des Roboters aus der Ruhestellung heraus passierte folgendes nacheinander: Ein Wahlrelais zieht an. Zwei Relais mit je zwei Umschaltkontakten ziehen an, trennen die Akkus von der Ladebuchse und schalten sie in Reihe. Das Mainboard läuft los. Die Spannung des gewählten Akkus wird vom AD-Wandler der C-Control gemessen. Nach einer gewissen Zeit fällt das Wahlrelais ab, die C-Control samt dem Erregerstrom der Relais wird ca. 100ms von dicken Elkos versorgt (bei Linearregelung von 12 auf 5V dürfen die Elkos schon auf 8V absinken), dann zieht ein anderes Wahlrelais an, die Elkos laden sich wieder auf, die Spannung eines anderen Akkus kann gemessen werden. Nach mehreren Umläufen beginnt die C-Control, sich an den Akku mit der höchsten Spannung am längsten anzuhängen und den schwächsten am kürzesten zu belasten.
Das ganze hat im Prinzip schon funktioniert, sogar der Belastungsausgleich der Akkus konnte beobachtet werden (die C-Control hat die Akkuspannungen immer über RS232 an das Mainboard gesendet), ABER: Der Strom, den sich die Elkos zum Wiederaufladen genehmigt haben, hat trotz Versuche mit Drosseln und Vorwiderständen bald die Kontakte der kleinen Wahlrelais angegriffen. Immer öfter kam es vor, daß die C-Control zwischendurch ihre Versorgung verlor. Damit fielen aber auch die Relais ab, welche die Akkus in Reihe schalteten, und dem Mainboard wurde abrupt der Saft abgedreht.
So ging es also nicht, deshalb
Auch hier zunächst ohne Schaltplan, dieser wird aber noch in vorzeigbare Form gebracht.
Ein DC/DC-Wandlerbaustein mit 7...42V Eingangsspannung und 4A Ausgangsstrom versorgt die C-Control und eventuelle weitere Microcontroller mit 5V, und stellt auch dem Mainboard die 5V Standby zur Verfügung wie bei einem normalen ATX-Netzteil.
Weiterhin schalten Relais die Akkus parallel (zum Laden) oder in Serie (zum Betrieb des 36V auf 12/5V Spannungswandlers und der Motoren). Der Wandlerbaustein für die C-Control wird aber immer mit mindestens 12V aus einem Akku versorgt, oder mit den vollen 36V. Auch während der Schaltzeit der Relais sorgen Dioden für eine ununterbrochene Versorgung.
Die unter Komponenten beschriebene 36V-Wandler-Platine versorgt das Mainboard im Betrieb mit 5V und 12V. Die 3,3V werden über eine Linearregelung zusätzlich den 5V entnommen. Die Platine kann am 5V-Ausgang immerhin 5A abliefern.
Über diese beiden DC/DC-Wandler sind C-Control und Mainboard galvanisch von den Akkus getrennt. Die Massen von C-Control und Mainboard sind aber schon miteinander verbunden. Dadurch kann die C-Control auf mit den Signalleitungen der ATX-Stromversorgung umgehen.
Ein kleines Steuerprogramm in der C-Control wartet auf das PSON-Signal (das kommt z.B. durch einen ans Mainboard angeschlossenen Start-Taster), schaltet die Akkus in Serie und gibt nach 1s das PowerGood-Signal aus. Das Mainboard läuft hoch. Jetzt wartet die C-Control auf das Abfallen des PSON-Signals (z.B. wenn man Windows herunterfährt) und schaltet die Akkus danach wieder parallel und somit die Versorgung des Mainboards aus. Und geht wieder in Lauerstellung auf das PSON-Signal. Das kann man beliebig oft wiederholen. Voilà, ein per Akku betriebener PC.
Durch die galvanische Trennung von den Akkus ist natürlich keine direkte Spannungsmessung mehr möglich. Ich werde mich vom Traum der Einzelüberwachung verabschieden und einen externen 12Bit-Wandler einsetzen, dessen Dreidraht-Interface über Optokoppler an die C-Control angebunden wird. Seine Auflösung reicht aus, um sowohl die 36V der in Reihe geschalteten Akkus oder die 12...13,8V während der Ladung zu überwachen.
Nun wurden in Ruhe nochmal alle Ströme, auch die von Festplatte, Floppy und CD gemessen.
Ganz wichtig: Schließlich soll Robbi ja eines Tages selbständig morgens aus seiner Ladestation fahren, ins Schlafzimmer dackeln und mich aufwecken. Programmiertechnisch ist durch die ins Betriebssystem der C-Control eingebaute Echtzeituhr ja schon vorgesorgt. Diese kann sogar mit einem Empfängermodul DCF77-synchronisiert werden.
Leider läuft es noch nicht so, wie ich es mir vorstelle. Es genügt offensichtlich nicht, das Mainboard ungefragt mit Strom zu versorgen und das PowerGood-Signal auszugeben. Statt nun den Starttaster am Mainboard durch ein Relais zu betätigen, werde ich die Tatsache nutzen, daß das Mainboard beim erstmaligen Anlegen der 5V-Standbyspannung gleich startet. Diese Spannung ist in der neuesten Version der Stromversorgung über Relais geschaltet, damit kann man auch zusätzlich Strom sparen.
Die Motoren brauchen sehr wenig Strom, da genügten vier einzelne 12-Ampère-Mosfets, die ich noch in der Schublade liegen hatte, für den Aufbau der H-Brücke. Da ich zwei absolut identische Motortreiber benötigte, habe ich mich mit Platinen-Layouten wieder angefreundet. Ich kann an meinem Arbeitsplatz die aktuelle Version von Protel Schematics nutzen (ein nach meiner Meinung teures und viel zu umständliches Programm, aber ich bin kein Experte und nutze es natürlich nur rudimentär für einfache Schaltpläne und interaktiv geroutete Platinen). Von meinen jugendlichen Basteleien (Mischpulte, Verstärker, Modellbau-Elektronik) standen immer noch Belichtungs- und Ätzgerät im Keller. Also eine einlagige Platine entwerfen...
Die Treiberplatinen enthalten Optokoppler, da in der neuesten Version die 36V der Akkus galvanisch getrennt von der Mainboard- und Microcontrollerversorgung sind. Für die Richtungsumschaltung eines Motors sind zwei Portleitungen des Microcontrollers verantwortlich. Nur wenn diese gegensinnig gesetzt sind, kann der Motor laufen. Außerdem ist pro Motor ein PWM-Ausgang mit 0...100% Duty-Cycle nötig. Auch wenn in der Initialisierungsphase vielleicht noch sämtliche PWM und Portleitungesn des Microcontrollers durch PullUp-Widerstände auf logisch 1 gezogen werden, kann der Motor nicht unkontrolliert laufen.
Die Platine wird am Motor befestigt. Gleich auf der Platine integriert sind zwei Gabellichtschranken, in die später Lochscheiben eingreifen, die direkt auf der Motorwelle montiert sind. Noch wird dies nicht genutzt, denn ich steuere die Motoren vorerst mit der C-Control an. Zum Mitzählen der Impulse ist diese vermutlich zu langsam. Später jedoch wird ein Microcontroller dranhängen, der zwei Quadratur-Encoder-Eingang besitzt, d.h. die um 90° phasenversetzten Signale der zwei Lichtschranken pro Motor steuern direkt einen 32bit-Auf-Ab-Zähler an, dessen Stand im Microcontroller als Register abgefragt werden kann.
Nachdem ein erster Versuch trotz Layoutfehler und Anlaufschwierigkeiten bei der Belichterei und Ätzerei zum Laufen gebracht wurde, baute ich zwei neue, gleiche Platinen auf. Hier das Ergebnis:
 |
 |
Da die C-Control auch zwei PWM-Ausgänge bietet, konnte ich die Motoren sofort ansteuern, ohne erst diesen zusätzlichen 16bit-Controller zu programmieren, den ich später für die Navigation einsetzen möchte. Es hat allerdings doch einige Tage gedauert, bis etwas praktikables entstand.
Vom ersten Ansteuern und Hochbeschleunigen der Motoren ging es weiter zu einer kleinen Anwendung, die über serielle Kommandos gesteuert werden kann. Dazu verwendete ich einfach den Ziffernblock. Eine "8" bedeutet beide Motoren auf Vorwärtsfahrt bringen, "5" bedeutet Anhalten. Wird im Stillstand "7" gedrückt, beschleunigt nur der rechte Motor, der Roboter fährt eine Linkskurve vorwärts. Wenn man die "7" beim Vorwärtsfahren drückt, wird der linke Motor aus der Fahrt heraus angehalten. Und ähnlich für alle anderen Bewegungen einschließlich auf der Stelle drehen. Dies zu programmieren scheint nicht schwer, brachte aber wieder einmal die Eigenheiten der C-Control zutage, die fröhlich Variablen überlaufen läßt, die Ausgaberegister nicht gleichzeitig auf ihren Status prüfen läßt usw. Naja, vielleicht bin ich von anderen Hochsprachen einfach verwöhnt. Am Ende konnte ich mit der Tastatur in der Hand und einem Terminalprogramm auf dem Epia-Mainboard den Roboter schon wie mit einer Kabelfernsteuerung durch die Wohnung lenken.
Ebenso könnte eine VisualBasic-Programm diese seriellen Kommandos geben. Allerdings kann ich nicht einschätzen, wie zeitgenau so ein VB-Programm abläuft. Sicherer erschien mir, im Programm der C-Control noch eine Möglichkeit für Bewegungssequenzen einzubauen. Gesagt, getan. Mittlerweile geübter, war schnell folgendes realisert: Mit der Taste "s" wird eine Sequenz eröffnet. Alle Kommandos vom Ziffernblock werden jetzt nicht mehr ausgeführt, sondern gespeichert. Mit einem "+" und Eingabe weiteren, auch mehrstelligen Zahl kann noch eine Pause bzw. Verlängerung einer bestimmten Bewegung eingegeben werden. Ein "-" schließt die Sequenz, und ein "g" führt sie dann aus.
So konnte ich im Terminal-Modus Sequenzen eingeben, starten, neu eingeben, nebenbei mit Papier und Bleistift protokollieren. Später kann das VB-Programm die Sequenzen übertragen und sie werden genauso ausgeführt.
Gerade mit den ersten Gehversuchen zufrieden, fehlte ein bißchen der Antrieb oder die Zielrichtung, wie es denn weitergehen sollte. Da entdeckte ich den Wettbewerb "Robot Challenge" in Wien, und die Entwicklung bekam zwangsläufig einen großen Schub. Es galt nämlich ein Labyrinth zu durchfahren. Die Vorbereitung auf den Wettbewerb ist hier noch ausführlicher nachzulesen.
Zunächst wurde der Roboter mit einfacher Sensorik ausgestattet: Drei Sharp-Abstandssensoren (zwei schräg nach links und rechts und ein long-range geradeaus), die an den analogen Ports der C-Control hängen. Für komplexere Steuerungsaufgaben konnte und wollte ich die C-Control aber nicht verwenden, also wurde ein Kommunikationsmodus geschaffen, in dem die C-Control nur ein in ein Byte verpacktes unmittelbares Steuerkommando für die Motoren erhält und ihrerseits nur die Sensordaten hochschickt zum Mainboard.
In der Folge entstanden einfache Programme, die den Roboter wackelnd und zuckelnd im konstanten Abstand an einer Wand entlangfahren ließen, bis hin zum komplexen Programm zum Abfahren und Lösen eines einfachen Labyrinths, natürlich ohne die Seitenwände zu berühren oder eine Navigationslinie auf dem Boden zu benötigen!
Davon gibt es ein Video, leider etwas zickig mit den Videoplayern, aber mit Apple Quick Time geht's.
Nach der heißen Phase der Wettbewerbe und des hektischen Lötens und Programmierens gab ich zunächst Ruhe, um dann ganz langsam mit der Ausgestaltung der Außenhaut und des Kopfes zu beginnen.
Zuerst
wollte ich eine ordentliche Schale für den "Unterleib". Diese
war in ihrer groben Form schon aus Schaumstoff (Styrodur-ähnlich) hergestellt,
jetzt finishte ich sie in mehreren Spachtel-, Schleif- und Grundiergängen
zu einer Positivform für die Abformung mit Epoxiharz und Glasfaser. Warum?
Weil die Schaumstoff-Schale sehr leicht eindellt, nicht hohl ist und weil ich
schon immer den Bau eines weiteren oder sogar mehrerer Roboter im Auge hatte.
Der Bau einer Negativ-Form aus Epoxi und Glasfaser ging gründlich in die Hose. An ein Entformen der mühsam aufpolierten Positiv-Form war nicht zu denken. Zum einen durch die senkrechten Wände - es reicht halt nicht, lediglich Hinterschneidungen zu vermeiden. Zum anderen aber durch das gewählte Trennmittel der Firma R+G, ein Trennwachs, das aufgesprüht, noch flüssig eingerieben und poliert wird, bis es steinhart und aalglatt ist. So habe ich jedenfalls die Anleitung verstanden, vielleicht habe ich sie falsch verstanden. Zuletzt mußte ich die auflaminierte Negativform mit der Dremel und Trennscheibe in bierdeckelgroße Teile zerstückeln und mit einem Schraubenzieher abhebeln, wobei einige der zuvor mühsam aufgebrachten Spachtel- und Lackschichten von der Positivform mitgingen.
Zweiter Versuch, eine Negativform aus Silikon. Ein teurer Spaß: Für die benötigten 5 kg 2-Komponenten-Silikon legte ich 140 Euro hin."Nur" 5 kg immerhin, denn ich baute um die mittlerweile wieder ausgebesserte Positivform einen relativ passgenauen Kasten aus Spanplatten. Dieser Kasten ist leicht zerlegbar und auch später zum Stützen der recht dünnwandigen Silikonform nötig. Positivform und Kasten mit dem nächstbesten Fett eingerieben (Bremspaste für Bremszylinder von Autos), gegossen, funktioniert. Entformen und das große Ahhhh-Erlebnis.
Das Laminieren des ersten echten Formstücks ging auch ganz wunderbar.
Das Endergebnis (nach dem Entformen war wirklich nur noch ein leichtes Porenfüllen und anschließendes Lackieren nötig) ist bei den Fotos vom fertigen Roboter zu bewundern.
Der Camping-Fernseher, der als Kopf und zur Darstellung des Gesichts benutzt wird, sollte nun endlich die überflüssigen Knöpfe und Skalen verlieren, ich wollte mich nicht mehr auf den schepprigen Lautsprecher verlassen und vor allem bildete ich mir schon lange "Ohren" für den Roboter ein, die eine Webcam und vielleicht andere Sensoren beherbergen sollten. Außerdem träumte ich von einer LED-Beleuchtung, die alle Farben und weiß darstellen kann und hell genug ist, um als Scheinwerfer für die Webcam zu dienen.
Also erstmal auseinandernehmen. Sicherheitshalber hatte ich schon einen zweiten gekauft.
Glücklicherweise kann man die ganze Sendereinstell-Mimik samt Skala, Platine und Rädern herausnehmen, und die Video-Wiedergabe funktioniert weiterhin. Das war einfacher als ich dachte. Ich habe außerdem noch die Eingangsbuchsen entfernt und direkt Kabel angelötet, und die Bild-Einstellregler durch Trimmpotis ersetzt, so daß ich das hintere Terminalfeld komplett abdecken kann. Ganz zum Schluß wurden dann noch der Skalenschlitz unter dem Visier zugespachtelt und alle Beschriftungen überlackiert.
Das äußere Erscheinungsbild wurde mit der nun schon erprobten Methode Positivform aus Schaum, sauber spachteln und lackieren, Negativform aus Silikon und GfK-Abformung erreicht. Hier hat sich der Aufwand besonders gelohnt, braucht ein vernünftiger Roboter doch zwei Ohren! Wichtiger sind aber die Front und das das Innenleben.
Da steckt viel Arbeit drin, aber es gibt nur kurze Erklärungen, weil mich die Schreiblust gerade verläßt.
Ich wollte ein schmales Lichtband um die Ohren herum. Erstens betont das deren abgerundete Form und rahmt das Gesicht wie zwei Klammern ein. Zweitens hätten konkrete Scheinwerfer (z.B. kleine Haogenstrahler) den Augen im Display-Gesicht Konkurrenz gemacht. Ich bog im Backofen Streifen aus Plexiglas zurecht (über einer aufwendig aus Alu gefrästen Form) und schliff die Stirnseiten. Eine wurde poliert, die andere extra matt gelassen. Die Farben der einzelnen LEDs vermischen sich auf der matten Vorderseite zu einem (einigermaßen) homogenen Leuchteindruck.
Innerhalb des "Lichtbogens" ist eine Webcam angebracht. Sie soll später von einem Servo auf- und abgeschwenkt werden, damit man sowohl den Boden vor dem Roboter sehen kann, als auch einem Menschen nach oben ins Gesicht sehen kann. Die Schwenkachse ist ganz nah an der Vorderseite des Ohrs, damit das Loch, durch das die Webcam schaut, trotz des Schwenkens nicht so groß sein muß.
Die LEDs werden von einem "USB-Warrior" angesteuert. Das ist ein vorprogrammierter Microcontroller, der als USB-Slave 16 I/O-Leitungen bedienen kann. Mit zwölf dieser Pins werden drei simple diskrete 4Bit-AD-Wandler für die drei LED-Farben angesteuert, zwei werden eine spezielle Schaltung für den Betrieb des Servos ansteuern (noch nicht ausprobiert) und zwei sind für weitere Sensoren übrig, z.B. einen Empfänger für normale Fernbedienungen wie für Fernseher.
Nun kam wieder die Programmiererei dran. Und siehe da, mit einem PC-basierten Roboter sind an ein paar Abenden einige hübsche Sachen gezaubert, sogar als Programmier-Laie. Ich spielte zunächst mal mit dem im Windows 2000 enthaltenen NetMeeting. Damit ließ sich ziemlich schnell das Bild der Roboter-Webcam auf den Desktop-Bildschirm bringen, und ein auf dem Roboter laufendes Steuerprogramm ließ sich vom Desktop aus über "Remote Control" fernbedienen. Jetzt noch schnell ein Steuerprogramm gestrickt, das vor allem ein großes Gesicht auf dem Bildschirm zeigt und nur eine schmale Leiste mit Buttons zum Motorensteuern am unteren Rand hat - und los ging die Expedition in abgelegene Zimmer der Wohnung.
Leider war das Starten dieser Anwendung mühselig, denn Netmeeting läßt sich zwar so konfigurieren, daß es Anrufe automatisch annimmt, nicht aber, daß es die Remote Control automatisch zuläßt. Somit mußte beim Start immer noch eine Maus am Roboter sein. Erst mit "VNC" statt Netmeeting war dieses Problem gelöst. Jetzt kann der Roboter eingeschaltet werden, ohne daß irgendein Eingabegerät dranhängen muß, und sogar ferngesteuert runtergefahren werden. Man trotzdem parallel Netmeeting starten, für die Webcam.
Und dann hat ein technikbegeisterter und programmiertechnisch sehr bewanderter Freund angebissen. Und mir zunächst eine Art Steuerfläche programmiert, die wie ein mit der Maus bedienter Joystick funktioniert und mit der man den Roboter ganz flüssig "herumtanzen" lassen kann - und das ganze mir zuliebe sogar in Visual Basic. Doch damit nicht genug - weil das Fernsteuern dieses Programms durch VNC hindurch doch ein bißchen holprig und von der WLan-Verbindung abhängig war, teilte er die Sache in ein Fernsteuerprogramm für den Desktop und ein Empfängerprogramm für den Roboter auf, die beiden kommunizieren über Winsocks. Durch Visual Basic hatte ich die Möglichkeit, auch ein bißchen beizutragen und programmierte die Ansteuerung der LEDs.
Zuletzt wollten wir dem Roboter für den Auftritt auf der Roboexotica in Wien noch etwas spezielles beibringen: Bier an den Tisch bringen. Ich hatte bei Conrad ein RF-Transpondersystem besorgt und ein kleines Tablett mit eingebauter Antenne auf dem Roboter angebracht. Und folgenden Ablauf stellten wir uns vor:
Gast kommt zur Roboter-Homebase und bestellt ein Bier, bekommt als Gutschein schon mal einen Flaschenöffner (mit Transponder dran) in die Hand gedrückt. Geht zu seinem Tisch.
Ich richte den Roboter per bekannter Fernsteuerung auf den Tisch aus, und stelle eine Flasche mit Transponder untendran auf das Tablett. Der Roboter fährt geradeaus auf den Tisch zu. Bei Hindernissen bleibt er stehen und wartet, geht das Hindernis weg, fährt er wieder weiter. Das war das absolute Minimum an Navigation, das uns in der Kürze eingefallen ist, wenn man nur einen Sharp-Entfernungssensor und keine Rad-Encoder zur Verfügung hat.
Ist er am Tisch angekommen, wird der Gast die Bierflasche wegnehmen, öffnen und den Öffner auf das Tablett legen. Daraufhin dreht der Roboter um 180° (in Windows zeitgesteuert, naja, je nach Prozessorlast sinds auch mal 220°) und fährt zurück zur Homebase. Wird der Öffner nicht zurückgelegt, blelibt er stehen und blinkt empört rot mit den Ohren. An der Homebase angekommen (er stoppt auch hier zwischendurch bei Hindernissen), kann ich durch Rausnehmen des Öffners den Ablauf abschließen.
Nach diesem kurzen, aber heftigen Bastel-Endspurt im November 2005 passierte erstmal lange nichts. Es war klar, für eine vernünftige Navigation mußten endlich Rad-Encoder und auch die entsprechende Auswertung auf dem Steuercontroller her, die Abstandssensoren mußten störungsfrei abzulesen sein. Ich wollte auch endlich den Akku-Ladezustand über das Programm sehen können.
Es wurden ordentliche Platinen gelayoutet: Eine kleine für den Rechner, mit Steckern für analoge Sensoren, Steckern für die Motortreiber und dem RS232-Pegelumsetzer direkt on board. Eine große, mit Steckern für die drei Akkus, zur Versorgung der Motoren und des guten alten DC/DC-Wandlerboards, Stromversorgung des Mainboards usw. Das Ziel war: Keine Schraubklemmen mehr, alles zum Abstecken. Klare Verdrahtung der Platinen untereinander. Ist nach einigen Anläufen nun (fast) gelungen:
Ohne Kabel, die nun mal sein müssen (zu 3 Akkus, 2 Motoren, Steuerkabel für Motoren, Verbindungskabel zwischen Powerboard und Controllerboard...) siehts schon besser aus. Nur am DC/DC-Wandler sind noch Kabel fest angelötet.
Hier das Powerboard einzeln. Links sind die ganzen Anschlüsse für Akkus, Motoren und die Eingangsseite des DC/DC-Wandlers. Links unten Optokoppler und der A/D-Wandler zum Messen der Akkuspannung. Unter dem Alublech verbirgt sich der DC/DC-Wandler-Baustein, der das Controllerboard versorgt. Das Alublech ist Kühlkörper für den 3,3V-Regler für das Mainboard. Rechts Stecker für Mainboard und Laufwerke.
Das Controllerboard trägt eine C-Control I Main Unit 2.0. Die Analogeingänge sind ein bißchen mit RC-Gliedern gefiltert, damit Störungen weniger durchkommen. Jeder dieser 3poligen Stecker führt GND, +5V und einen Analogeingang. Die 10poligen sind zum Steuern der Motoren, der 20polige die Nabelschnur zum Powerboard.
Das Auslesen der Akkuspannung funktioniert wunderbar, und positiv überrascht haben mich die Frequenz-/Zählereingänge der neuen C-Control. Zusammen mit Encoderscheiben, die ich endlich an den Motoren angebracht habe, wird sich bestimmt eine saubere Steuerung aufbauen lassen. So habe ich endlich die Übersetzung der Schneckengetriebe herausgefunden: Sie ist stolze 78:1, sprich 546 Impulse pro Radumdrehung mit der 7zähnigen Encoderscheibe. Deshalb ist der Roboter so langsam.
Ab Mitte 2005 habe ich begonnen, alle Teile für den Roboter ein zweites Mal zu beschaffen. Und zwar wirklich identisch. Das heißt gleiches Mainboard Via Epia V8000, absolut identische Festplatten, WLan-Sticks, Webcams, RS232-Erweiterungskarten, C-Control, Fernseher/Kopf. Da hilft natürlich ebay und sorgt auch für positive Überraschungen: So habe ich den zweiten Fernseher statt für 29,95 für unglaubliche 3,81 Euro bekommen. Ja, als Fernseher taugt er wirklich nicht viel...
Der einzige Unterschied zwischen den Robotern wird die Farbe des Mäntelchens sein: Rosa statt blaugrün.
Ein zweiter Roboter bringt natürlich den Vorteil, daß der erste weiter lauffähig bleibt, während am zweiten die ganzen Neuerungen in Elektronik und Software ausprobiert werden können. Wenn der zweite hinreichend funktioniert, wird der erste auf den gleichen Stand aufgerüstet. Dann sind sie wirklich identisch. Ziel: Frühjahr 2007.