Ein Roboter, speziell für eine Disziplin bei einem Wettbewerb gebaut... So was wollte ich eigentlich nie machen, denn die Hauptsache bei meinen Basteleien ist doch der robofriend, und man sollte sich nicht verzetteln, schon gar nicht als erwachsener Mann mit endlicher Freizeit. Aber es reizte halt doch. So fing ich an, für die Disziplin "Puck Collect" bei der RobotChallenge 2006 in Wien zu konstruieren.
Der Aufgabe in kurzen Worten: In einem umgrenzten Feld kleine farbige Holzpucks einsammeln und diejenigen in der richtigen Farbe in die eigene Ecke bringen. Man dachte beim Stellen der Aufgabe wohl zuerst an Roboter, die immer nur einen Puck einfangen und in die Ecke schieben, aber mit meinen mechanischen Möglichkeiten wollte ich etwas umfassenderes bauen: Alle Pucks mit einer Mimik aus rotierenden Bürsten einsammelnund auf dem Roboter sortieren, idealerweise die falschen in einem anderen Eck abladen und die richtigen gesammelt nach Hause bringen.
Der Name "if_then_else_kling" verwebt sich mit diesem Vorhaben auf mehrfache Weise:
1. Das Einsammeln von herumliegendem Zeug erinnert an Else Kling, die Hausmeisterin in der Lindenstraße.
2. "if then else" entstammt meiner bevorzugten Programmiersprache Basic bzw. VisualBasic.
3. Wenn ich schon einen so speziellen Roboter baue, soll er zumindest als Versuchsplattform für einen allgemeinen Putzroboter dienen, und nicht mit einem ganz ausgefeilten Mechanismus nur solche Holzpucks einsammeln können und sonst gar nichts. Also: "If (ever), then Else Kling"
Als Basis dient eine Roboterplattform mit 30cm Durchmesser und Schrittmotoren, die ich vor Jahren einmal baute. Zwei rotierende Bürsten bilden die vorderen Ecken des Roboters, damit kann er sogar Ecken auskehren. Eine weitere walzenartige Bürste sammelt die Pucks (oder beliebigen Schmutz) auf und ein Förderband bringt sie in einen Behälter oder eine Sortier-Anlage im hinteren Teil des Roboters. Ein bißchen CAD und das Ganze sieht so aus:
Vom ursprünglichen Chassis blieb doch nicht viel übrig. Die recht einfachen Räder (so ne Art Kofferrollen) wurden durch etwas kleinere Moosgummi-Räder aus dem Modellbaubereich ersetzt. Diese haben super Grip, und durch den geringeren Durchmesser wird die Bodenfreiheit so gering, daß sich auf keinen Fall Holzpucks unter die Bodenplatte klemmen können. Die hintere Stützrolle brauchte zuviel Platz, sie wurde durch eine Kugelrolle ersetzt. Auf jeder Seite trägt ein Alu-Profil die Schrittmotorkarte, einen kräftigen 42mm-Schrittmotor mit 1,7V / 1,4A Wicklungen und führt auch deren Wärme ab. Durch die Zahnriemenuntersetzung ist der Antrieb wirklich kräftig genug, um Schrittverlust oder Aussetzen der Motoren muß man sich keine Sorgen machen.
 |
 |
Über die querlaufende Achse mit Kegelrädern laufen sie gegensinnig und sammeln alles vor dem Roboter in die Mitte zusammen. Das funktioniert ganz gut, lediglich Pucks, die der Roboter weit außen erwischt, werden eher davongeschleudert. Der Antrieb mit dem Getriebemotor kann zwar über PWM vom Controller heruntergeregelt werden, um eventuell das Davonschleudern der Pucks in den Griff zu bekommen, aber letztendlich blieb ich doch beim "Volle Pulle" Betrieb. Die Borsten sind eigentlich etwas zu dick: Der Motor packt es zwar sogar, wenn eine Bürste voll in eine Ecke "gewürgt" wird, aber die Borsten verbiegen sich dann dauerhaft, statt zurückzufedern.
 |
 |
Die Kehrbürsten sammeln alles vor einem Schacht, dessen "Zunge" (auf dem unteren Bild sichtbar) ca. 5mm über dem Boden schwebt - keine Gefahr des Hängenbleibens also für den Roboter. Dennoch finden die Pucks den Weg zur über diese Zunge hinauf - weil sie von den Bürsten, die unter dem Schacht hindurchfegen, leicht angehoben und zum Tanzen gebracht werden, bis sie den Weg über die Kante finden. Im oberen Bild sieht man die dritte, auf der Verbindungswelle montierte "Kehrwalze", die zu einem doppelten Gummilappen mutiert ist. Diese Gummilappen schleudern die Pucks dann auf das Förderband. Der mitlaufende grüne Gummiring verhindert, daß die Pucks gleich wieder nach vorne ausgeschleudert werden und leitet sie auf das Förderband. Dennoch können Pucks, die sich verklemmen, wieder nach vorne rausfluppen. Man glaubt ja gar nicht, wie sich diese einfachen Pucks querstellen, verklemmen, stauen und stapeln können...
 |
 |
Video vom Einsammeln (MPEG4, <1MB)
Läuft über einen gesonderten Getriebemotor recht langsam, nicht PWM-regelbar, aber vom Controller gesteuert vor und zurück. In der momentanen Ausbaustufe fördert das Band die Pucks einfach in den hinteren Raum des Roboters, dort ist genug Platz für fast 20 Pucks, vor allem, wenn sie durch Drehbewegungen auseinandergeschüttelt werden. Das Material des Bandes ist eine Anti-Rutsch-Matte, im Baumarkt als Unterlage für Teppiche erhältlich. Anfangs habe ich das Zeug aufwendig zu einer Schlaufe zusamengenäht, später stellte sich heraus, daß das simple überlappende Zusammenkleben mit Pattex auch allen Ansprüchen an Flexibilität und Haltbarkeit genügt.
 |
 |
Um eine C-Control herum wurde ein Controllerboard mit RS232-Pegelwandler, Stromversorgung und Motortreiber gestrickt. Die C-Control und alle Sensoren werden mit 5V aus einem normalen 7805 versorgt, der dabei trotz Kühlblech schon ordentlich warm wird. Er muß aber auch die ganze überschüssige Spannung des 21,6V-Akkus verbraten. Die Schrittmotorkarten und anderen Motortreiber werden direkt von der Akkuspannung gespeist. Für den Motor der Kehrbürsten ist ein Mosfet an einem PWM-Ausgang der C-Control, und ein L293 treibt zwei weitere kleine Motoren über Portleitungen vorwärts und rückwärts. Momentan ist einer dieser Motorkanäle mit dem Förderband-Motor belegt. Für diverse Analog-Sensoren snd Stiftleisten vorhanden, die immer 5V, GND und den Sensoreingang tragen.
Ein besonderes Kapitel ist die Pulserzeugung für die Schittmotorkarten. In der alten Version der C-Control konnte der Beep-Ausgang mit einem bestimmten Dauerton belegt werden und das Programm trotzdem weiter ablaufen. Den Tonausgang verwendete ich einfach als Puls für beide Stepperkarten und konnte so auch eine Hochlaufkennlinie ins Programm einbauen. Erst bei Inbetriebnahme des Controllerboards bemerkte ich, daß dies mit der C-Control 1 M-Unit 2.0 nicht mehr geht. Was tun? Ein externer Frequenzgenerator mit fester Frequenz? Verschiedene Geschwindigkeiten wollte ich schon fahren. Ein Voltage-Controlled-Oscillator am zweiten PWM-Port? Keine Erfahrung damit. Fertige Bausteine können offensichtlich die Frequenz nur in ganz engen Grenzen verändern. Die Lösung brachte ein Quartz-Oszillator mit programmierbarem Teiler, in Kombination mit einem festen Teiler. Eigentlich wollte ich auch noch einen weiteren progammierbaren Teiler für krumme Teilungsverhältnisse dranhängen, so daß man die Frequenz nicht immer nur halbieren oder verdoppeln kann, erst so läßt sich nämlich eine vernünftige Hochlaufkennlinie erzeugen. Das hat jedoch nicht funktioniert, so mußte ich bei einigen auswählbaren Frequenzen bleiben, die die Motoren im Start-Stop-Betrieb bewältigen.
Ein weiteres Abenteuer war der Akku. Die Schrittmotorkarten benötigen eine möglichst hohe Eingangsspannung, um auch bei hohen Schrittfrequenzen den nötigen Strom in den Spulen aufzubauen. Der zur Verfügung stehende Platz ergab einen 18-zelligen Pack aus Mignon-Zellen. Nur, 18 Mignon-Akkus lassen sich nicht beherrschen. Weder kann man sie einzeln in einem normalen Ladegerät laden - da wird man wahnsinnig. Noch kann man sie als einen zusammenbleibenden Akkupack behanden. Das eigens dafür aufgebaute Delta-Peak Ladegerät schaltet ständig zu früh ab, weil irgendeine der Zellen schneller voll ist und ihren Spannungspeak überschreitet. Und beim Entladen ist auch sofort Schluß, weil immer irgendeiner der Akkus aus unerfindlichen Gründen viel zu schnell leer ist und blitzschnell mit einer sich aufbauenden Gegenspannung gekocht wird. Die Probleme lagen sicher auch daran, daß man bei 18 Zellen nicht unbedingt die teuersten Qualitätsakkus kauft. Schlußendlich habe ich mir damit beholfen: Für alle Versuche fuhr der Roboter an einer Nabelschnur zum Netzgerät, und für den Wettbewerb kamen Alkaline-Batterien in den eigens gebauten Batteriehalter. Diese billigen Batterien haben jetzt schon fast eine Stunde Betriebszeit überstanden.
 |
 |
Zwei Sharp GP2D12 sind so unter der Deckplatte angebracht, daß sie ganz außen am Roboter geradeaus nach vorne schauen. Damit könnte man zwar kleine Hindernisse übersehen, die genau vor dem Roboter liegen, aber das ist unwahrscheinlich. Mit den Wänden gibt es dagegen keine Probleme. Wenn der Roboter geradeaus an einer Wand so ansteht, daß die Bürsten gut die Kante auskehren, ist die Distanz der Sensoren immer noch größer als 10cm, so gibt es keine Fehlsignale. Außerdem kann sich der Roboter mit beiden Sensoren wieder wunderbar senkrecht zur Wand ausrichten.
Eigentlich sind für den Wettbewerb 2 Farbsensoren nötig: Einer, um die Farbe der Pucks zu unterscheiden und einer, um mithilfe der Bodenfarbe nach Hause zu finden. Fertige Farbsensoren sind teuer und trotzdem noch umständlich in der Auswertung: Für jeden der R,G,B Farbkanäle wird eine Frequenz ausgegeben. Ich wollte gerne einen Sensor, der sich an die Analog-Eingänge der C-Control anschließen läßt. Meine Lösung: Eine Operationsverstärker-Schaltung steuert eine rote und eine blaue LED an und wertet die Reflektion mit Photodioden aus. Dazu müssen der rote und blaue Lichtfleck räumlich getrennt sein. Für die großen Farbflächen, die auf dem Boden erkannt werden müssen, geht das auf jeden Fall. Und auch die Oberfläche eines Pucks bietet genug Platz. Und nun noch ein Trick für unterschiedliche Lichtverhältnisse und unterschiedliche Reflektionsgrade (Helligkeit des Farbtons) der weißen, roten und blauen Flächen: Die OP-Schaltung steuert die beiden LEDs gemeinsam so an, daß die Summe der Photodioden-Signale in der Mitte des AD-Wandlerbereichs liegt. Und das funktioniert ziemlich gut.
Momentan ist nur der Bodensensor fertig aufgebaut und abgestimmt. Schaltplan, Widerstandswerte und Meßwerte werden noch folgen.
 |
 |
Sollte verhindern, daß die Pucks einfach bis in den Aufbewahrungsraum durchgeschleudert werden - stattdessen sollten die Pucks falscher Farbe hinter dem Förderband aussortiert werden. Ist bis jetzt nicht fertig. Der Farbsensor ist nicht fertig aufgebaut und eingestellt, und das Hauptproblem ist nicht gelöst: Noch immer verklemmen sich dich die Pucks auf dem Förderband, statt schön im Gänsemarsch unter dem Farbsensor durchzuwandern. Die mechanische Einheit zum Aussortieren existiert auch noch nicht.
Die Möglichkeiten der C-Control 1 Unit 2.0 sind ja gottlob nicht mehr so beschränkt wie die der alten C-Control 1. So entstand ein Programm, welches das Spielfeld mäanderförmig abgrast, an den Wänden umkehrt und am Ende des gesamten Spielfelds (oder bei Zeitmangel) anfängt, die heimatliche Farbbasis zu suchen. Sollte der Roboter zwischendurch ein Hindernis sehen, kehrt er auf seiner aktuellen Mäanderschleife gleich um und merkt sich aber den ausgelassenen Bereich. Der kann dann später aufgesucht werden, meist reicht dazu aber die Zeit nicht. (Die Zeit zum Programmieren dieser "Restflächen-Routine" reichte übrigens auch nicht). Und das Aussortieren falscher Pucks ist mangels Hardware natürlich auch nicht implementiert.
Im Video (MPEG4, <2MB) ist folgendes zu sehen: Roboter fährt los und kommt zu nah an die linke Wand, sieht also ein Hindernis und kehrt um. Die weiteren Mäanderschleifen fährt er normal. Dann kommt er von seiner Startposition aus gesehen ganz rechts an und beschließt das Mäandern. Beim nach Hause fahren kommt er leider wieder zu nah an eine Seitenwand und startet eine Befreiungssequenz, bleibt aber dann stehen, weil er auf "blaue Heimat" programmiert war.