Vielen Dank an unsere

Sponsoren und Förderer

Der Roboter Angulatus

Der Roboter Angulatus

Für die strategischen Herausforderungen des 2011er Eurobots, haben wir von Oktober 2010 bis April 2011 unseren Roboter Angulatus entwickelt

Image

Konzept

Simulation möglicher Spielverläufe haben schon am Anfang der Konzeptphase gezeigt, dass es nicht ausreicht die Spielelemente nur zu verschieben, sondern, dass die Punkte für das Bauen komplette Türme den Aufwand rechtfertigen. Besonders die Variante, einen Turm aus König und zwei Bauern aus den "eigenen" Vorräten zu Bauen, sollte schnell und effizient zu lösen sein. Unsere Strategie für dieses Jahr sah deshalb vor, dass wir uns auf folgende Punkte konzentrieren:

  1. Das Bauen von Türmen.
  2. Das Verschieben von Schieben und Türmen von den gegnerischen auf unsere Spielfelder.

Zum einen ist es wichtig durch Bauen von Türmen viele Punkte zu erreichen. Es musste also eine Mechanik konstruiert werden, die Bauern übereinander stapeln kann und eine Sensorik entwickelt werden, die zuverlässig Bauern von Monarchen unterscheiden kann. Außerdem ist eine softwareseitige Implementierung notwendig, die intelligent genug ist um Türme zu bauen und unfertige Türme zu erkennen.

Dem Gegner fertige Türme zu klauen, ist nur dann erfolgreich, wenn er auch selber welche baut. In der Qualifikations-Phase kann man sich darauf aber nicht verlassen. Daher ist eine Kombination von beiden Ansätzen wichtig. Unser Roboter versucht also erst Türme aus den Spielfiguren, die in der Start-Zone aufgestellt sind, zu bauen um selber Punkte zu machen. Anschließend verwendet er die restliche Zeit darauf, diagonal über die gegnerischen Spielfelder zu fahren und dabei ggf. vorhandene Spielsteine auf unsere Spielfelder zu schieben.

Elektronik

ImageFür die Elektronik konnten einige der Module (z.B. H-Brücke mit Treibern, Servoansteuerung, ...) aus dem letzten Jahr übernommen werden. Zur zentralen Steuerung kamen zwei CPU Boards mit jeweils zwei ATxmega-Mikrocontrollern zum Einsatz. Das Display und die Bake wurden aus dem Vorjahr übernommen. Auch die Kommunikation zwischen den Komponenten erfolgt wie die den letzten Jahren schon per CAN.

Durch den Einsatz einer großen Anzahl an Aktoren und der Notwenigkeit das Spiel mit einer Fülle an Sensoren zu überwachen führte dazu, dass die Trägerboards (auf denen die Module angeordnet werden) eine hohe Packungsdichte hatten. Alle Module konnten auf zwei Trägerboards aufgeteilt werden. Wobei das erste den Antrieb und die beiden Arme steuert und das zweite den Lift.

Aktorik: 

  • 2x Antriebsmotoren (diskrete H-Brücke, Strommessung für Drehmomentregelung, Motorencode für Gescheindigkeitsregelung, ext. Odometrieräder für Positionsregelung/-bestimmung)
  • 2x Motor für die Arme für horizontale Bewegung (diskrete H-Brücke, Motorencode für Positionsreglung, Endanschlag für Nullpositionsfindung)
  • 2x Servos für die Arme (vertikale Bewegung)
  • 2x Ventile
  • 2x Pumpen
  • 1x Motor für den Lift (diskrete H-Brücke, Motorencode für Positionsreglung, Endanschlag für Nullpositionsfindung)
  • 1x Motor mit den Greifer im Lift (diskrete H-Brücke, Motorencode für Positionsreglung, Endanschlag für Nullpositionsfindung)
  • 1x Schrittmotor Laserscanner

Sensorik

ImageNeben der direkten Überwachung der Aktorik durch Encoder an den Motoren und Endanschlägen kamen verschiedene zusätzliche Sensoren zum Einsatz, um uns auf dem Spielfeld zurechtfinden zu können und die Spielelemente händeln zu können.

Für eine gute Langzeitpositionierung kamen die schon erprobten zusätzlichen Odometrieräder zum Einsatz. Hierbei handelt es sich um auf der Antriebsachse frei gelagerte Radscheiben mit Encoder. Somit mussten für das Fahrverhalten vier schnelle Encoder ausgewertet werden, was durch eine Master-Slave Architektur der Mikrokontroller erfüllt wird.

Zur Gegnerdetektion wird durch eine Kreuzvalidierung aus Ulltraschallsensoren und der einer aktiven IR-Barke eingesetzt.

Der Barcode auf dem König und der Dame legte nahe einen Barcodescanner einzusetzen. Dank Sponsoring hatten wir eine Industrieversion zur Verfügung. Leider stellte sich auf dem Wettbewerb heraus, das es dieser zu genau nimmt. Erst nach mehreren Versuchen entsprachen die Codes auf den Spielelementen auch wirklich der Norm und wurden zuverlässig erkannt.

Um mit den beiden Saugnäpfen die Spielelemente auch im Vorbeifahren sicher aufzunehmen, wurde ein Laserscanner entwickelt, der neben dem Wickel auch den Abstand eines Hindernisses ausgibt.

Image
3 Erkannte Scheiben mit dem Laserscanner

Mechanik

Unser Ziel war es eine sehr schnell, einfach und möglichst präzise Mechanik zu entwickeln, die Scheiben zuverlässig manipulieren kann.

Mit der Entscheidung Türme bauen zu wollen, wurden die Vorgaben für die Mechanik eingeschränkt. So wurde schnell klar, dass der Roboter je nach Fahrtrichtung auf das Verschieben oder auf das Aufnehmen und Stapeln ausgelegt sein muss. Der Roboter hatte also 2 Fahrtrichtungen.

Image
Atapler zum Bauen

Bei der Stapelseite wurde ein grosses "Maul" mit seitlichen Backen entworfen, dass die Scheiben in einer halbkreisförmige Schale aufnahm und somit auch bei schnellen Richtungswechseln und Drehungen einen sicheren halt bot. Das gesamte Maul war höhenverstellbar und erlaubte die Aufnahme von 3 Scheiben. Zum Bauen von Türmen war es wichtig wichtig eine oder zwei auf eine (oder zwei) auf dem Feld liegende Scheiben präzise zu legen. Gerade wenn der König auf einen Turm gesetzt werden soll, müssen Aufgrund der Höhenbregrenzug die Scheiben sehr gerade gehalten werden. Um den kostruktiven und vertigungstechnischen Aufwand zu reduzieren, wurde das Maul als Schweißkonstruktion entwickelt und mittels Gasflamme selbst geschweißt. Die Nähte haben bisher gut gehalten und dieses Vorgehen hat uns viele kleine Verbindungsteile erspart.

Image
Arme zum Verschieben

Auf der Manipulatorseite werden 2 Arme mit Faltlippensauger eingesetzt. Die Saugleistung wurde wie im letzten Jahr durch kleine aber starke Pumpen von KNF erzeugt. Um die Belastung auf die Sauger während des Verschiebens der Scheiben zu reduzieren werden die Arme mittels Servo angehoben. Dies reduziert die Kontaktfläche der Scheiben mit dem Spielfeld und somit können auch 3er Scheibenstapel sicher verschoben werden. Die Arme waren zusammen mit dem Laserscanner in der Lage im fahren Scheiben zu erkennen, diese anzupeilen, anzusaugen und zur Seite geziehlt auf eins unserer Felder zu verschieben.

Das erfolgreiche Antriebskonzept aus früheren Jahren konnte weiter entwickelt werden und besteht aus zwei Getriebemotoren von Dunkermotoren, die über Riemen die Antriebsräder antreiben. Neben den Rädern sitzen zwei gefederte Odometrieräder, über die die Position des Roboters inkrementell bestimmt wird. Damit sind wir unabhängig von dem Schlupf der Antriebsräder. Bei moderaten Geschwindigkeiten und nicht allzu rabiaten Gegnern bietet dieses System für 90 Sekunden Spielzeit eine ausreichend genaue Position.

Software

Das in den letzten Jahren entwickelte, und seit letztem Jahr als Open-Source veröffentlichte Framework XPCC wurde wieder eingesetzt und in diesem Zuge weiter entwickelt.

Das Grundkonzept der Strategie basiert darauf, dass das Spiel eigentlich recht wenige getrennte Aktionen zulässt. So können wir

  • Scheiben/Türme aufnemen
    • vom Spielfeld
    • aus dem eigenen/gegnerischen Lager
  • Scheiben/Türme auf andere Scheiben/Türme setzen um Türme zu bauen
  • Scheiben/Türme auf ein leeres Feld bringen
  • rückwärts über das Spielfeld fahren und Scheiben/Türme verschieben

Ausgrund dieser Limitierung:

  • wählt die Strategie eine der Aktionen (die gerade sinnvoll ist)
  • fährt an die Position
  • führt die Aktion aus
Image
Fahren im Simulator

Neben der Ansteuerung der Aktorik, die in verschiedenen Komponenten gekapselt ist, liegt somit das besondere Augenmerk auf dem Fahren. Hierzu wurde der Driver aus dem letzten Jaht, dessen Spezialität das Fahren von Routen (Kombination von Kurven und Geraden) war, weiterentwickelt.
Da dieses Jahr das Spielfeld keine festen Hindernisse besaß, wurden neben den statischen Routen aus dem letzten Jahr, auch eine dynamische Routen-Planung entwickelt. Das Spielfeld wird dabei anhand der Schachfelder aufgeteilt (Rastergröße 350mm). Innerhalb dieses groben Rasters wurde dann eine Route geplant. Grundlage der Wegfindung waren dabei möglichst wenig über unsere eigenen Felder zu fahren (um abgelegt oder zufällig liegende Scheiben nicht zu Verschieben), sondern Scheiben von den gegnerischen Feldern wenigstens zu ungültigen Punkten zu verschieben. Bekannt Spielelemente (sei es bei Spielbeginn, durch ablegen oder Erkennen mit Sensoren) werden dazu in einer Liste gespeichert, die der dynamischer Planer zusätzlich nutzt.
Zusätzlich gibt es einen weiteren Routen-Planer der darauf spezialisiert ist diagonal die gegnerischen Felder abzufahren. Auf diese Weise werden Scheiben und Türme des Gegners gefunden und können mit den Armen auf die eigenen Felder verschoeben werden.
Aber auch die statischen Routen kamen wieder zu Einsatz: Am Anfang des Spiels, wenn die meisten Gegner noch in ihrer eigenen Hälfte beschäftigt sind, versuchen wir damit eine optimierte Route, die möglichst viele Punkte bringt abzufahren. Sobald uns dabei der Gegner begegnet, wird in den dynamischen Modus geschaltet. Dieser ist zwar dann langsamer, kann dafür aber besser mit dem Gegner ausweichen.

Der Name Angulatus

Zu guter Letzt nun noch die Aufklärung, was es eigentlich mit dem Namen '''Angulatus''' aufsich hat. Diesen Namen bekam er, weil lange nicht geklärt war wo vorne und hinten war, da beide Fahrrichtungen im Spielverlauf gleichermaßen eingesetzt werden sollten. Somit war auch lange nicht klar, wo rechts und wo links ist. Dies führte gerade in der Software zu einigen Abstimmungsproblemen. So kam es, dass unser Roboter nach der Links-Rechts-Schwäche Angularis benannt wurde. Da es mit Numerorbis, unserem Roboter aus der Saison 2008, schon einen "-bis" in der RCA Familie gab wurde der Name kurzerhand zu Angulatus abgeändert. Dies steht außerdem im Lateinischen für ''eckig'', auch ein auffallendes Merkmal unseres Roboters.

Obwohl unser Roboter nach einer Krankheit benannt ist, so schränkte ihn das nicht in seinen Fähigkeiten ein. Technisch ist der Roboter eine konsequente Weiterentwicklung des letztjährigen Roboters Insitor. So wurden sowohl Teile der Elektronik, als auch der Software übernommen und weiterentwickelt. Gerade mechanisch wurde der Roboter allerdings deutlich komplexer als der letztjährige, insbesondere da es mehr Aktorik gab die untergebracht werden musste.