Vielen Dank an unsere

Sponsoren und Förderer

Der Roboter Numerobis

Der Roboter Numerobis

Numerobis In dieser Eurobot-Saison ist der RCA mit Numerobis auf den antiken Baustellen von Atlantis unterwegs.

Für die Namensfindung haben wir uns bei einem berühmten Baumeister der Antike, genauer gesagt des alten Ägyptens, bedient. Und zwar kein geringerer als Numerobis (der nach eigener Aussage "keine geraden Linien" mag und durch Auftritte bei verschiedenen Asterix Filmen bekannt wurde).

Video: Vorstellung von Numerobis [mp4, 47 MB]

Konzeptentwicklung

Bootcamp Wie in jedem Jahr fiel die Bekanntgabe der Regeln mit dem Beginn des Wintersemesters zusammen. Um zum Einem die Konzeptentwicklung zu beschleunigen und zum Anderen die neuen Vereinsmitglieder schnell ins Team zu integrieren, wurde wieder ein Bootcamp am Rursee in der Eifel veranstaltet. Nach dem Studium des Regelwerks wurden dann die gewünschten Ziele für das Konzept festgelegt:

  • externe Encoderräder (nach den schlechten Erfahrungen mit unebenen Spielfeldern beim Maikäfer)
  • spezielle Sensorik, die es ermöglicht sich an jeder wichtigen Spielfeldposition (Spender, Bauzonen) genau zu positionieren
  • robuste, kräftige Mechanik (Maikäfer fehlte die Kraft in den Ärmchen um den Ballspender schnell zu leeren)
  • schnelles Leeren des Scheibenspenders
  • Aufnehmen der Scheiben vom Spielfeld bei der Fahrt
  • Aufnehmen der Balken
  • Scannen der Bauzone
  • Bauen ohne viel zu rangieren

Tempel Points Colculator Mit viel LEGO, Papier und guter Laune wurden an einem Wochenende das grundsätzliche Konzept erarbeitet, dass in den folgenden Wochen in einen handfesten und funktionstüchtigen Roboter umgesetzt wurden. Um die strategischen Ziele beim Bauen zu evaluieren, existierte eine kleine Webanwendung, mit der die Punkte unterschiedlicher Türme berechnet werden konnte. Wie immer tauchten viel mehr Ideen auf, als sich an einem Roboter umsetzen lassen. Aber spätestens beim Eurobot-Finale tauchten fast alle Ideen bei dem einem oder anderem Bot auf ;-)

Das entwickelte Konzept lässt sich in mehrere Baugruppen unterteilen:

  • Antrieb
  • Scheibenhandling
  • Balkenhandling
  • Bauplatzscanner
  • Strategie

Antrieb

Unser Antrieb besteht dieses Jahr aus zwei kräftigen GR42x25 Motoren von Dunkermotoren die über Zahnräder die Antriebsräder antreiben (im Endeffekt haben sich die Zahnräder als Fehler herausgestellt, da dadurch zu viel Spiel im Antriebsstrang entsteht und der Roboter beim drehen schwingt). Die beiden Antriebsmotoren sind Strom-geregelt, dadurch können wir den Roboter mit konstanter Kraft fahren lassen. Dies ist zum Beispiel beim Ausrichten an der Bande sinnvoll, da sonsten die Motorregler den Strom immer weiter hoch regeln würden wenn der Roboter an der Bande angekommen ist und sich nicht weiterbewegen kann. Bei Numerobis wird er jetzt einfach mit einer festgelegten Kraft gehalten ohne die Motoren in die Begrenzung zu treiben.

Die Position messen wird dabei nicht wie die letzten Jahre über die Drehungen der Antriebsmotoren, sondern über externe Räder mit Encoder. Diese sind besonders leichtgängig, extra gelagert und werden durch Federn auf den Boden gedrückt, so dass sie immer im Kontakt mit dem Boden bleiben. Selbst wenn sich die Antriebsräder kurz aufbocken sollten. Es entstehen trotzdem natürlich immer kleine Fehler die dann mit der Zeit aufintegriert werden, weicht die gedachte Position immer stärker von der realen Position ab.

Daher besitzt Numerobis noch eine Vielzahl von  Sensoren um alle Spielelemente relativ anfahren zu können, also nicht abhängig von einer globalen Position, sondern nur Aufgrund der aktuellen Sensorwerte. Es schauen jeweils zwei Sharp IR-Abstandsensoren zur jeder Seite hinaus, welche die Bande detektieren um so parallel zu dieser fahren können. Ein ähnlicher Sensor lässt sich auch nach vorne ausklappen um so in konstanten Abstand an der niedrigen Bande am Bauplatz entlang fahren zu können. Zum Ausrichten hat Numerobis zwei Reflextaster knapp über dem Boden die anzeigen wenn er fast an der Bande angekommen ist. Außerdem schauen vier Reflextaster nach vorne die Scheiben direkt vor ihm erkennen können um so die Fahrtrichtung ein wenig korrigieren zu können das die Scheiben im Einlass landen.

Scheibenhandling

Optimierung des Schiebers am Holzmodell Der Roboter ist mit einer mittigen Öffnung versehen, um direkt über Scheiben hinweg fahren zu können. Diese Öffnung ist so groß, dass auch der gesamte Scheibenspender hinein passt. Wird eine Scheibe innerhalb des Roboters detektiert, wird die von einem Schieber in die seitliche Tasche gestoßen. Der Schieber ist so geformt, dass er Scheiben unter dem Spender hervor schieben kann ohne sich bei der Rückbewegung zu verkeilen (Video: Schieber am Spender [3gp, 145kB]).

Detailansicht Scheibengreifer Durch den Schieber werden die Scheiben in eine definierte Position geschoben, von dort nimmt sie ein in zwei Achsen linearer (senkrecht und seitlich) beweglicher Greifer die Scheiben auf. Durch das Anheben der Scheibe mit dem Greifer wird Platz für eine neue Scheibe gemacht. Der Greifer setzt die alten Scheiben auf der neuen ab und greift sich die unterste Scheibe. So werden bis zu 4 Scheiben übereinander im Greifer gestapelt.

Zum Bauen wird der Greifer zur Seite hin ausgefahren. Somit kann ein Turm von vier Scheiben in einer Bewegung abgesetzt werden (Video: Scheiben aufnehmen und Turm bauen [avi, 2,5 MB]). Durch ein kombinieren von Greiferbewegung und Vorwärtsfahren des Roboters können auch sehr einfach Doppeltürme gebaut werden.

Mechanik im Detail

Der Schieber und die Form der Bodenplatte für die Führung der Scheibe wurden mit CAD und Holzmodellen genau bestimmt. Hierbei gab es drei Bedingungen zu beachten:

  • ein Verklemmen der aufzunehmenden Scheibe zu verhindern, auch wenn diese nicht optimal im Einzug liegt: Dazu wurde neben einer geschwungenen Form, ein Kugellager an der Spitze vorgesehen. Dadurch kann sich die Scheiben mit geringer Reibungskraft entlang der Bodenplatte gegen den Schieber drehen.
  • eine weitere Scheibe, die während einer Bewegung des Schiebers in den Einlauf kommt, darf diesen bei der Rückbewegung nicht blockieren: Durch eine entsprechende Form erreicht.
  • beim Ausleeren des Spender dürfen die oberen Scheiben im Spender weder den Schieber noch sich selbst verkannt: Die Oberseite des Schiebers ist knapp unterhalb einer liegenden Scheibe, dadurch 'fallen' die oberen Scheiben zunächst nur ein kleines Stück und durch den Buckel wird verhindert, dass die Scheiben hinter den Schieber kippen.

Rückseite des Greifers Die senkrechte Bewegung des Arms wird über eine Spindelstange angetrieben. Dabei schauen die Zahnräder der Gewindestange und des Motors in die Deckelplatte hinein, dies hat neben dem Raumgewinn von einigen Millimetern den Vorteil, dass die Position auch von Hand verstellt werden kann.

Die Linearbewegung wird über eine Zahnstange erreicht. Bei voll ausgefahrenem Arm mit vier Scheiben Last wirkt ein großes Hebelmoment auf den Führungen, was lange Zeit zu einer Verkantung des Antriebs führte. Aber durch eine Versteifung der Führungen konnte dieses Problem behoben werden.

Der Greifmeachnismuss selbst ist so ausgelegt, dass zum Halten der Scheiben keine Kraft über das Servo aufgewendet werden muss, sondern diese von einer Feder gehalten werden. Nur zum Zugreifen und Loslassen muss das Servo kurzzeitig Kraft aufbringen.

Steuerung

Das gesamte Scheibenhandling wird von 3 großen Getriebemotoren und einem Servo bewegt. Die Getriebemotoren besitzen alle eine Strom- und Positionsregelung. Beim Einschalten des Roboters kalibrieren sich alle Motoren in dem sie in Endpositionen fahren. Hierdurch wird gleichzeitig die Funktionsfähigkeit der Aktorik überprüft.

Neben den Positions- und Stromwerten stehen der Steuerung noch diverse Sensorwerte zur Verfügung. Hierzu zählt besonders der  Reflextaster, der erkennt, dass eine Scheibe im Einlass liegt. Der zweite wichtige Sensor ist der Farbsensor zur Bestimmung der aufgenommenen Scheibe, da nur die eigenen Scheiben mitgeführt werden dürfen.

Für einen schnellen Ablauf der Bewegungen beim Aufnehmen der Scheiben und auch beim Bauen, müssen die Steuerungen der Aktoren genau aufeinander abgestimmt sein. Einen Überblick, die die implementierten Funktionen liefert diese Übersicht zur Ablaufsteuerung [pdf, 620 kB]. Das gesamte Handling (inkl. dem Aussetzen fremder Scheiben) wurde auf AVRs implementiert. Die Strategie auf dem PC verarbeitet nur noch die Anzahl an Scheiben, die sich im Roboter befinden.

Balkenhandling

Das Balkenhandling wurden unter 3 Bedingungen entwickelt:

  • Es müssen zwei der drei Balken gleichzeitig  transportiert werden können. Somit ist es möglich einen Scheiben - Balken - Scheiben - Balken - Tempel zu bauen ohne Material zu besorgen.
  • Das Ausladen des Balkens beim Tempelbau sollte nach dem Scheibenausladen ohne weiteres Rangieren erfolgen.
  • Aufnehmen der zwei Balken mit minimalem Rangieren.

Dies alles wurde erreicht, indem die Balken in einem Aufzugsystem auf der gleichen Seite gehalten werden, an der die Scheiben ausgeladen werden. Dabei ist die Position so gewählt, dass ein abgesetzter Balken direkt auf dem vorher ausgeladenen Doppelturm liegt.

Im Detail

Balkenaufzug Die Mechanik des Aufzugs ist nahezu identisch mit der des Greifers und besteht aus einer Gewindestange die von einem Getriebemotor mit Stromregelung und Encoder angetrieben wird. Die beiden Balken werden jeweils von einer Spannfelder gehalten, wodurch Toleranzen in der Balkenlänge automatisch ausgeglichen werden. Mit einem Servo werden beide Klemmen gleichzeitig aufgezogen.

Der Balkenhalter ist mit einem Gelenk an der Rückseite mit dem Aufzug verbunden. Der Scheibengreifer kann so, wenn er auf der höchsten Ebene auslädt, den Balkengreifer zu Seite hin hinaus drücken und die Scheiben absetzen. Der Balkenhalter ragt dann über die Plaxiglasscheibe des Spielfeldes hinaus.

Mit dem IR-Sensor am Aufzug wird beim Fahren entlang der Bauzone nach Hindernisse gesucht, damit der Balken, der über der Bauzone schwebt, nicht versehentlich Bauwerke einreist.

Mit dem ausklappbaren IR-Sensor (Bande) wird beim Balken-Aufnehmen der Abstand zur Bande gemessen. Somit ist es möglich sehr genau in geringen Abstand entlang der Band zu Fahren und so von einem Balkenspender zum nächsten zu fahren. Da der Balkenhalter an der Seite angebracht ist, kann der Roboter in einer Bewegung entlang der Bande fahren und die Balken aufnehmen. 

Bodenfarbsensoren Um  die genau Position des Balkenspenders zu bestimmen, hat der Roboter im Unterboden Farbsensoren zur Detektion der schwarzen Streifen auf dem Spielfeld.

Video: Aufnehmen von Balken [avi, 2,6 MB]

Bauplatzscanner

Mit dem Scheibenhandling und dem Balkenaufzug ist es möglich nahezu jeden beliebigen Tempel auf beliebigen Unterkonstruktionen zu bauen. Um diese Möglichkeiten auszunutzen wurde ein Bauplatzscanner entwickelt, der die genaue Konstruktion auf dem Bauplatz erkennt. 

Der Sensor besteht aus 8 Reflexlichttastern, die übereinander neben dem Scheibenhandling angeordnet sind. Für jede Ebene ist ein Sensor vorgesehen. Bei einem Scan-Vorgang fährt der Roboter einmal an der Bauzone entlang. Die Sensoren werde von einem AVR abgefragt, der die aufbereiteten Daten zusammen mit der genauen Position des Roboters an den PC sendet.

Ergebnis des BuildareascannersDie Auswertung auf dem PC setzt die Daten zu einem Bild zusammen und untersucht dieses auf die optimale Bauposition und die Form des Tempel, die in Abhängigkeit von den Spielelementen im Roboter die meisten Punkte liefert. Dies wird an die Strategie gesendet, die dann das entsprechende Verhalten startet.

Simulator

Als Simulator wurde wie in den Jahren zuvor Stage aus dem Player-Projekt eingesetzt. Mit er Version 3.0 ist dieser nun auch 2 1/2 D fähig. Mit dem Simulator werden alle Komponenten simuliert, die in AVRs implementiert sind. Aufgrund des ICC-RCCP-Frameworks besitzt der Simulator das gleiche Interface wie die AVRs. Somit ist es möglich, die Strategie und die Verhalten alleine auf dem PC zu testen. Des weiteren können einzelne Komponenten des Simulators deaktiviert werden und durch die realen Komponenten auf dem Roboter ersetzt werden.

Video: Homolugation in Stage [avi, 1,4MB]

Strategie

Komponenten Das in den letzten Jahr entwickelte ICC-RCCP-Framework für eine transparente Kommunikation zwischen Komponenten auf Mikrocontrollern (über CAN) und dem PC (über TIPC) wurde auch dieses Jahr verwendet. Die Komponenten werden in 4 Gruppen unterteilt: 

  • Sensoren (z.B. Distanzsensoren (USS, IR)): Liefern bereits umgerechnete Werte (z.B. in Millimeter).
  • Aktoren (z.B. Driver): Steuern die Motoren (Position, Geschwindigkeit, Drehmoment) an und Koordinieren das Zusammenspiel mehrerer Motoren.
  • Verhalten (Architect): Steuern zusammenhängende Funktionen an und treffen selbständig Entscheidungen um das Ziel des Verhaltens bestmöglich zu erreichen. Ist ein Ziel erreicht oder ist es nicht mehr erreichbar übergibt das Verhalten dies an die Strategie.
  • Strategie: Startet und Beendet Verhalten, Trifft die Entscheidung, welches Verhalten gestartet werden soll

Aufgrund des ICC-RCCP-Frameworks können die Komponenten an beliebigen Orten implementiert werden.

Strategie zur Homulugation Die Strategie selbst ist eine FSM, die nach einer fest vorgegebenen Abfolge von States am Start, aus sechs Verhalten auswählen kann. Dabei springen die Strategie nach Abschluss (Erfolgreich oder nicht) zunächst in einen Sammel-State, von dem aus wieder alle sechs Verhalten zur Auswahl stehen. Abhängig von weiteren Bedingungen wird dann das neue Verhalten ausgewählt.

Es können nun verschiedene Strategie implementiert werden, indem eine abstrakte Strategie (bei der die Auswahlfunktion nicht implementiert ist) abgeleitet wird. Es muss dann nur noch diese eine Funktion umgesetzt werden.

Video: Spiel in Dresden [avi, 16MB]