Sämtliche acaBot-Roboter haben eines gemeinsam: das ist der "Arduino On Board". Auf diesem läuft entweder die acaBot Firmware oder der acaBot Motor Controller. Diesem Umstand der Arduino-Verwendung ist geschuldet, dass alle unsere acaBot-Roboter einen auf "(u)ino" endenden Namen haben, wie aCTino, PINGuino, URGino, CLAWino, KICKuino, MECANuino. Die im Namen enthaltenen groß geschriebenen Buchstaben stehen jeweils für eine Besonderheit des Bots, der mit dieser Schreibung Tribut gezollt wird. Näheres hierzu siehe in den Beschreibungen der Bots unten.

Soweit nicht anders angegeben, sind die acaBot-Roboter mit einem MBoard ausgestattet. Es handelt sich dabei um ein Arduino-Leonardo Derivat, das die nötigen zwei H-Brücken zur Ansteuerung der beiden Motoren sowie einen Bee-Carrier zur wahlweisen Aufnahme eines XBee-, Wifi-Bee oder Bluetooth-Bee Funkmoduls schon integriert hat. Durch diese Integration kann sehr viel Platz gespart werden.

der aCTino - ein toller Schulungsroboter für unsere Schülerpraktikanten

Der aCTino (sprich: Azetino) war der erste Bot aus der acaBot Serie. Das "CT" soll an den Bot erinnern, aus dem der aCTino hervorgegangen ist, das ist der CT-Bot aus der gleichnamigen Computerzeitschrift "ct" aus dem Heise-Verlag in Verbindung mit der Elektronik-Firma Segor aus Berlin. Zwar hat der aCTino nicht mehr viel mit dem CT-Bot gemeinsam (außer der Grundplatte und den schicken Rädern), aber die runde Form und die Ausmaße in Höhe und Durchmesser sind in etwa von ihm übernommen.

  • Der aCTino wurde als Schulungsroboter für Schülerpraktikanten gebaut. Mit seinen drei IR-Abstandssensoren, die den Bot geradeaus (0°) sowie in 45°-Winkeln sowohl leicht nach links und rechts sehen lassen, gibt er den Schülern schon sehr viele Möglichkeiten für recht anspruchsvolle Programmieraufgaben.
aCTino
Höhe: 15 cm, Breite/Durchmesser: 12 cm

der PINGuino - nicht nur niedlich anzusehen mit seinen beiden Glubschaugen

Der PINGuino hat nicht wirklich etwas mit einem Pinguin zu tun; der Name ist zurückzuführen auf einen Ultraschall-Sensor namens Ping. Auf dem einen "Auge" des Ping wird ein Ultraschall-Impuls ausgesendet, an einem Objekt reflektiert und dann auf dem anderen Auge empfangen. Aus der Laufzeit lässt sich die Distanz des Bots zum Objekt (z.B. eine Wand) ermitteln. Der Ping-Sensor ist auf einen Servo-Motor montiert, der im 180 Grad Winkelbereich hin und her schwenkt und somit die gesamte Front des Bots sehr fein abscannen kann. (Zum Vergleich: die drei IR-Sensoren des aCTino sind fest montiert und "starren" unveränderbar in ihre vorgegebene Richtung.) Der Nachteil des Ping-Sensors ist: ein gesamter Frontalscan kann bei schneller Servo-Geschwindigkeit durchaus 2 Sekunden betragen, aber dafür kann er in jedem beliebigen Winkelbereich feinjustiert werden und somit Ecken und Kanten von Objekten/Wänden genauer betrachten, bevor er bemüht ist, ihnen auszuweichen.

  • Der PINGuino wurde bislang in mehreren Master-Projekten für Handy-App-Steuerungen eingesetzt. Dabei läuft der Steuercode zur Realisierung einer Aufgabe nicht parallel zur acaBot-Firmware auf dem Arduino, sondern in einer Handy-App, die über WLan mit dem Bot verbunden ist.

der URGino - die Königsklasse unter den acaBots

Ohne zu übertreiben kann man sagen: der URGino ist in der Lage alles zu erfüllen, was im akademischen Roboteralltag sinnvoll als Aufgabenstellung im Bereich der Lokalisation und Navigation formuliert werden kann. Es sind zwei Dinge, die diesen Bot so mächtig machen: ein zusätzlicher Raspberry Pi und ein Laser-Scanner (ein URG-Hokuyo).

Der Steuercode, der bei den vorangegangen Bots neben der acaBot-Firmware auf dem Arduino-MBoard lief, befindet sich beim URGino nun auf dem Raspberry Pi; der Code auf dem MBoard ist nur noch ein reiner Motor-Controller und sorgt ausschließlich für die präzisen Motor-Bewegungen. Der Laser-Scanner sendet seine Daten über einen USB-Port an den "Raspi"; der hierfür erstellte Treiber wird in das Anwenderprogramm eingebunden.

  • Ein besonders anspruchsvolles Projekt aus der Praxis zur Navigation und Lokalisation mit dem URGino lässt diesen in einer realen, abgegrenzten Umgebung simultan zu einem Avatar in einem Simulator (namens Player) fahren, der die reale Umgebung des URGino als Karte kennt. Näheres hierzu findet sich in dem Unterverzeichnis: "URGino-Bot going Player".
  • Ein verstärkter Einsatz des URGino in Master-Projekten ist geplant. Als Use-Cases formulierte Szenarien sollen den Bot dazu bringen, bestimmte Aufgaben zu erfüllen; die hierfür nötigen Middleware-Funktionen, auf die in den Use-Case-Szenarien zurückgegriffen werden soll, werden derzeit als Bachelor- und Masterarbeiten vergeben. 

der CLAWino - GAME ON: die Kids lieben ihn

GAME ON - das Spiel kann beginnen! Der CLAWino (engl. claw = Greifer, Klaue) wurde als Spiele-Roboter für die Kinder auf der LNdW gebaut. Trotz seines doch sehr martialischen Aussehens sind die Kids begeistert von ihm. Technisch gesehen ist er ein aCTino, jedoch ohne irgendwelche Distanzsensoren, aber dafür mit zwei Servo-Motoren ausgestattet, die den Arm heben und senken sowie den Greifer öffnen und schließen. Gelenkt wird dieser Bot von den Kindern mit unserer acaPad-Fernsteuerung, die mittels zweier Thumbsticks durch die linke Hand des Bedieners die Fahrt des Bots und durch die rechte Hand die Bewegung des Greifers steuern. In den Händen der Kinder dient dieser Bot dem Geschicklichkeitstransport eines Bonbon tragenden Bowling-Kegels.

Eine weitere Verwendung des CLAWino findet sich bei den Schülerpraktikanten. Mit seiner Befähigung, in dem Greifer einen Stift zu halten, können für den CLAWino - ähnlich wie bei der Turtle einfache Programme zum Zeichnen von geometrischen Figuren geschrieben werden. Anders als bei der Turtle, die hierfür mit einfachen Schleifenanweisungen geführt wird, erfolgt die diesbezügliche Programmierung des CLAWino über die etwas komplexeren State-Machines. 

... Anschleichen ... (aber nicht zu ungestüm und dabei versehentlich den Kegel umstoßen)
... und Zuschlagen ...

der KICKuino - GAME ON: unser erster Versuch, einen guten Fussball-Bot zu bauen

Nach sehr vielen Vorüberlegungen und gründlichen Ideensammlungen lief bei der Konstruktion dieses Fußball-Roboters alles nach Plan ... aber der Plan war doof.

Wer das Bedürfnis hat, sich in Frusttoleranz zu üben, ist mit dem Spielen dieses ferngesteuerten KICKuino-Bots ziemlich gut bedient. "Das Beinchen heben", um den Ball zu schießen, tut der Bot mithilfe eines Solenoid (Hubmagnet). Dieser wird für eine kurze Impulszeit mit seiner doppelten Nennspannung in Überlast betrieben, damit ein ordentlicher Bumms entsteht und der Ball (ein Tischfussball oder ein Tischtennisball - ein Golfball ist zu schwer) schön schnell und möglichst weit fliegt. So kickt denn der KICKuino zwar auch richtig gut, aber dennoch:

"This Bot sucks!" Dabei hatte alles so gut angefangen. Wir wollten - als erweitertes Programm neben dem CLAWino (s.o.) zur Belustigung der Kinder auf der LNdW - einen netten Fußball-Roboter bauen, der Spaß macht. Aber das Ergebnis, nämlich der KICKuino, ist mit der acaPad-Fernbedienung richtig schwer zu steuern. Bei schnellen Bewegungen (wie das beim Fußballspielen so üblich ist) verliert er schnell den Ball aus der Führungsgabel. Dieser Effekt war vorher nicht absehbar. Die Kunst bei diesem Bot liegt darin, nicht mehr anzuhalten, nachdem man einmal losgefahren ist, dabei aber auch die Richtung ändert. Benötigt wird ein sehr gutes Reaktionsvermögen und eine noch bessere Feinmotorik mit dem Thumbstick der Fernbedienung. Viele haben sich an diesem Bot schon versucht, aber alle sind mehr oder weniger gescheitert, waren frustiert. Nur einer war bislang erfolgreich ... nämlich Brian, mein acaBot-Partner (zuständig für die Programmierung im acaBot-Projekt). Brian hat die Bedienung dieses Bots mit der acaPad-Fernbedienung perfekt unter Kontrolle. Wie er das macht? Keine Ahnung. Aber es sieht echt cool aus, wenn Brian den KICKuino über den Tisch sausen lässt und Tore schießt. 

der KICKuino
Nach sehr vielen Vorüberlegungen und gründlichen Ideensammlungen lief bei der Konstruktion dieses Fußball-Roboters alles nach Plan ... aber der Plan war doof

Um den KICKuino, der für das Fußballspiel mit schnellen Richtungsänderungen nicht so richtig geeignet ist, nicht umsonst gebaut zu haben, haben wir uns für ihn eine andere Aufgabenstellung ausgedacht. In einem nicht zu leichten aber auch nicht zu schweren Geschicklichkeitsspiel, bei dem es nur auf vorsichtige, nicht aber schnelle Bewegungen ankommt, werden die Kinder auf der LNdW mit ihm kick-bowlen. Wer es schafft, innerhalb einer vorgegebenen Zeit zwei Kegel von einem Sockel zu schießen, geht als Gewinner mit einem Bonbon nach Hause.

(Die beiden Kegel stehen auf einem leicht erhöhten Podest mit einer einseitigen, schrägen Rampe, damit sie nur durch das Auftreffen des harten Fußballs fallen können, nicht aber durch den Stoß des Bots selbst. Die Annäherung an die Kegel vor dem Schuss ist nur von einer Seite sinnvoll, dadurch wird der Schwierigkeitsgrad des Spiels ein wenig erhöht.)

... Anschleichen ... und Zuschlagen ...

der MECANuino-Base (aka MECANuinoKick) - GAME ON: ein echter Hot Shot acaBot zum erfolgreichen Toreschießen

Nach der Pleite mit dem KICKuino (s.o.) haben wir die Idee aber nicht aufgegeben, doch noch zu einem gut funktionierenden, schnell manövrierbaren Fußball-Robotor zu kommen. Das Ergebnis unserer Bemühungen ist der MECANuino. Er trägt seinen Namen über die Bezeichnung seiner Räder, Mecanum-Räder. Das Antriebsprinzip der Mecanum-Bewegung ermöglicht die omni-direktionale Bewegung "in alle Richtungen". Wäre der MECANuino ein Auto, könnte man ihn seitwärts oder schräg vorwärts/rückwärts einparken, oder auf der Stelle drehen, ohne dabei die Stellung der Räder zu ändern. Man spricht hier auch von einem holonomen System, das sich dadurch auszeichnet, dass sich die Lage des Körpers (hier der Bot) durch Koordinaten beschreiben lässt, die gänzlich unabhängig voneinander sind. Dieses holonome Fortbewegungs-System, das durch die omni-direktionalen Mecanum-Räder ermöglicht wird, machen diesen Bot zu einem echten Favoriten unter den gut manövrierbaren Fußball-Robotern.

Im Gegensatz zu den anderen, oben besprochenen Bots, fährt der MECANuino nicht auf zwei sondern auf vier Rädern, die von einer entsprechenden Anzahl an acaBot-Motorfunktionen angetrieben und geregelt werden. Diese Motorfunktionen befinden sich in der acaBotQuad-Firmware. Ein weiterer Unterschied zu den zweirädrigen acaBot-Robotern betrifft den Arduino-on-Board. Der ist bedingt durch die beiden zusätzlichen Motoren/Encoder bei den MECANuinos kein MBoard-Leonardo mehr, sondern ein Mega2560, da dieser über mehr interruptfähige GPIOs verfügt.

der MECANuino-Base
Ein richtig gut funktionierender Fußball-Roboter mit einem "omni-direktionalen" Antrieb lässt sich "holonom" bewegen und besitzt dadurch die nötige Möglichkeit zur schnellen Richtungsänderung.

der MECANuino-Pi (aka MECANuino-Camera oder "Goal Keeper") - unser erster echter autoMobRob

Da das Fußballspielen ohne einen Gegner aber irgendwie langweilig ist, haben wir noch einen Torwart dazu gebaut. Da für ihn dasselbe Kriterium hinsichtlich der Manövrierbarkeit gilt wie für den "Ball-Kicker", besitzt auch er die omni-direktionalen Mecanum-Räder.

Als wir nach der Fertigstellung gefragt wurden "Kann der auch autonom?", mussten wir zunächst passen, "Nee, der kann nur mobil ...", denn unser Bot konnte - als einfacher mobRob (mobiler Roboter) - ja tatsächlich nur über die acaPad-Fernbedienung manuell gesteuert werden. Also haben wir eine Pi-Camera (=speziell für den Raspberry Pi vertriebene Kamera) hinzugefügt, mit der über den Software-Algorithmus des "Blob-Finding" der Ball identifiziert werden kann, und fertig war unser autonomer Torwart, der automatisch seine Position dem auf ihn zukommenden Ball anpasst - und somit nicht notwendig mehr einen menschlichen Bediener benötigt. Auch ein paar "Rule Based System"-Verhaltensweisen sind mit der zunächst sehr einfachen, trivialen Autonomie hinzugekommen, denn der Bot darf nicht einfach stehenbleiben, wenn er den Kamera-Blick auf den Ball verliert, sondern er muss aus der History des Ball-Verlaufes individuelle Entscheidungen über die Aufenthaltswahrscheinlichkeit des Balles treffen und ein entsprechendes Ball-Follower-Verhalten aufweisen.

Wen es interessiert, wie der Bot durch die Kamera zum Fußball kommt, sollte sich einmal das Poster dazu ansehen.: Through the Goal-Keeper's Eye

Vom Programmier-Paradigma her, funktioniert der MECANuino-Pi nicht wie der MECANuino-Base (s.o.), sondern ist verwandt mit dem URGino (s.o.). Wegen der vier Räder ebenfalls mit einem Arduino-Mega2650 ausgestattet, und nicht mehr mit dem MBoard-Leonardo, ist auf diesem der acaBotMcQuad Motor Controller implementiert. Das Anwenderprogramm läuft (wie beim URGino) auf dem Raspberry Pi, mit dem der MECANuino-Pi-Bot zusätzlich ausgestattet wurde. Der Camera-Anschluss erfolgt (analog zum Laser-Scanner beim URGino) über einen USB-Port des "Raspi"; der hierfür erstellte Treiber wird in das Anwenderprogramm eingebunden.

der MECANuino-Pi
18 x 13 x 13 cm
Through the Goal-Keeper's Eye
Im "Kampf der Giganten" kann der Goal Keeper sowohl autonom als auch über Fernbedienung laufen. Der Kicker-Bot hingegen ist (zurzeit noch) ausschließlich mobil, nicht autonom.

der MECANuino-Pixy - (ein verbesserter Goal-Keeper)

Bei dem MECANuino-Pixy handelt es sich um die verbesserte Hardware-Version des MECANuino-PI. Jedoch betrifft diese Verbesserung nur die Kamera. Die Raspberry Pi Camera wurde durch eine Pixy-Cam ausgetauscht. Nichts gegen die Raspi-Cam, sie war billig und lieferte super Bilder, aber zur Identifizierung des auf den Goal-Keeper zulaufenden Fußballes war der Raspberry-Pi stark mit dem Rechenaufwand zum Blobfinding (Rausrechnen des Balles aus dem Gesamtbild) beschäftigt. Dies hatte eine relativ niedrige Bildverarbeitungsrate zur Folge, die zwischen 5 und 15 Frames pro Sekunde lag. Bei den hohen Geschwindigkeiten, die der Fußball annehmen konnte, wenn er auf den Goal-Keeper zurollte, reichte diese Bildrate oft nicht aus, um den Goal-Keeper rechtzeitig zum Halten des Balles neu zu positionieren. Die Pixy-Cam ist diesen Punkt betreffend besser einsetzbar, denn sie verfügt über eine eigene Steuerlogik zum Blobfinding und liefert konstant 50 Bilder pro Sekunde. Damit ist der Raspberry Pi von dieser Arbeit befreit und kann sich mit ausgefeilten Algorithmen um die Autonomie des Goal-Keepers kümmern.

Diesen verbesserten Goal-Keeper verdanken wir Sven Hallmann, der sich im Rahmen seiner Bachelor-Arbeit unter anderem um ein erstklassiges Bot-Behaviour in der Funktion eines Goal-Keepers gekümmert hat.