Der Soccerbot ist ein Roboter, der in eingeschränkter Form Fußball spielen kann. Auf dem 2,45×1,82 m großem Spielfeld soll er den Ball erkennen und ins gegnerische Tor schieben. Das Gesamtsystem besteht im wesentlichen aus drei Teilen: Dem Roboter, einer Kamera über dem Spielfeld und einem mit der Kamera verbundenen Laptop zur Bilddaten Auswertung und Verarbeitung. Vom Laptop aus werden in Echtzeit Fahrbefehle über WLAN an den Roboter gesendet. Durch Farbmarkierungen am Roboter soll seine Position erkannt werden. Ebenso muss der Ball in einer Farbe gehalten werden, die sich vom Untergrund abhebt.

Nach Vereinbarung mit der Projektgruppe Frank Robori , die für den Gegenspieler des Soccerbot verantwortlich ist, haben wir festgelegt, dass die Roboter den Ball nicht festhalten, sondern nur schieben dürfen.

Spielstrategie

Bevor wir unseren Roboter zum Ball schicken, berechnen wir einen Schusspunkt, der auf einer Linie von Ball und Tor mit einem definierten Abstand hinter dem Ball liegt. Dann lassen wir den Roboter zum Schusspunkt fahren, wo er sich zum Ball dreht und ihn ins Tor schiebt.

Die Konstruktion unseres Roboters besteht im wesentlichen aus zwei kreisrunden Holzplatten und einer Frontplatte, die den Ball schiebt.

Arduino Mega 2560/Mega ADK + MotoMama v2.0:. Ein Arduino ist ein Mikrocontroller mit diversen Input und Output Schnittstellen (Pins). Über ihn sind alle Komponenten des Roboters miteinander verknüpft und können angesteuert werden. Auf dem Arduino ist ein MotoMama Board gesteckt. Es enthält Schnittstellen für die Motoren und den Akku und einen Steckplatz für den WiFly-Empfänger. Mit der Software Arduino schreibt man ein Programm ,welches der Arduino dann ausführt. Darin legt man fest, an welche Pins der Arduino dann eine Spannung anlegt und sie somit ansteuert. MotoMama Datasheet

WiFly-Empfänger: Über den WiFly-Empfänger empfängt unser Roboter Befehle. Diese Befehle enthalten Informationen über die Fahrtrichtung und Geschwindigkeit, die auf unserem Laptop berechnet werden. Laptop und WiFly Empfänger sind über einen WLAN-Router miteinander verbunden. Die empfangenen Befehle können dann vom Arduino ausgeführt werden. WiFly-Empfänger und Arduino sind über eine serielle Schnittstelle miteinander verbunden. Wir versenden die Befehle als OSC-Nachrichten. Dazu haben wir ein Beispielprogramm aus der verlinkten Libary genommen, welches wir dann für unsere Anforderungen verändert haben. Link zur Libary in Code und Rohdaten

Akku + LiPo Batteriewächter: Der Akku versorgt den Arduino und damit auch alle anderen Bestandteile mit Strom. Der LiPo Batteriewächter ist an den Akku angeschlossen und zeigt den Akkustand an und schützt ihn vor dem Entladen. Der Arduino arbeitet mit einer Spannung von 5 Volt. Seine laut offizieller Website empfohlene Eingangsspannung liegt aber bei 7-12V. Die Spannung wird wahrscheinlich vom Arduino angepasst. Der Akku hat eine Spannung von 7,4 bis ungefähr 8V und ist damit für unseren Arduino geeignet.

Auf der Unterseite sind zwei Gleichstrommotoren mit Plastikgetriebe montiert und ein um 360° drehbares Stützrad. Die Motoren mussten erst zusammengebaut werden. Sie sind mit dem MotoMama Board verbunden.

Auf der oberen Platte sind Farbpunkte für die Bilderkennung angebracht. Der Mittelpunkt der grünen Farbfläche ist der Punkt um den sich die Räder des Roboters drehen, unsere Rotations Achse. Die pinke Farbfläche ist über dem Stützrad angebracht.Die gedachte Line zwischen den Punkten steht im rechten Winkel zur Radachse, mit ihr kann der Winkel zum Schusspunkt bestimmt werden. In unserer Bildverarbeitung dienen die Punkte dazu, den Roboter zu definieren und zu erkennen.

Die vorn am Roboter angebrachte Platte muss den Wettbewerbsbedingungen entsprechen, darf also den Ball nicht umschließen oder unzugänglich für den Gegenspieler machen. Die Aufgabe der Frontplatte ist es, den Ball ins Tor zu schieben. (Ursprünglich war angedacht, an der Frontplatte einen Schießmechanismus anzubringen, der zum Einsatz kommt, wenn der Roboter direkt vor dem Ball Richtung Tor ausgrichtet ist. Das haben wir aber aus Zeitgründen wieder verworfen.)

Zur Bildverarbeitung benutzen wir eine PS3-Kamera, die mit dem Laptop verbunden ist. Diese ist so angebracht, dass das ganze Spielfeld im Bild ist.

Das wahre Herzstück des Roboters ist aber gar nicht in der Konstruktion zu finden. Die Intelligenz des Roboters definiert sich aus dem Bildverarbeitungsprogramm am separaten Laptop. Dieser ist über ein USB Port mit der PS3 Kamera verbunden und verfügt über das Programm Processing. Diese anfängerfreundliche Anwendung zum programmieren wird hauptsächlich im Bereich der Grafik, Simulation und Animation eingesetzt.

Im ersten Schritt lässt man sich die Live Bilder der PS3 Kamera in Processing ausgeben. Nähere Information zum Quellcode und verwendeten libraries siehe Code und Rohdaten.

Nun lässt sich das Geschehen auf dem Spielfeld am Laptop beobachten. Alle relevanten Komponenten, der Roboter, der Ball und das gegnerische Tor, sind im Blickfeld der Kamera. Damit das Programm im Verlauf des Spieles die Koordinaten vom Roboter und Ball bestimmen kann, müssen Farbmarkierungen am Roboter angebracht werden und der Ball ebenfalls farbig sein. Am Roboter ist eine zweite Markierung, die benötigt wird um die Drehrichtung des Roboters zu erkennen.

Erstes Ziel muss also sein zu definieren, welche Farbe welcher Punkt ist. Um sich nicht auf die gleichen Farben für immer festlegen zu müssen und auch wechselnden Lichtverhältnissen trotzen zu können, muss nach einer Eingabemöglichkeit gesucht werden, die es erlaubt, die Farbewerte der Komponenten jederzeit neu zu definieren. Am praktischsten erschien es, die Farbidealwerte per Mausklick in der Funktion „void mousePressed()“ zu definieren. Die Farbe mit der ein Pixel leuchtet, definiert sich aus seinem Rot-, Grün- und Blauwert. Diese Werte werden an dem Pixel, wo sich die Maus zum Zeitpunkt des Klicks befindet, ausgelesen und als Idealfarbwert gespeichert. Wichtig hierbei ist, die vorher festgelegte Reihenfolge zu beachten. In unserem Fall muss der erste Klick über dem vorderen Farbpunkt am Roboter erfolgen. Der zweite Klick am hinteren Roboterpunkt, der dritte über dem Ball und der vierte über dem gegnerischen Tor. Der fünfte Klick setzt die Farbwerte wieder zurück.

Eine Schleife untersucht nun Pixel für Pixel jedes Bild der Kamera. An jedem Pixel werden die RGB Werte ausgelesen und es wird berechnet, ob sie einem der Idealwerte ähnlich sind. Das funktioniert wie folgt: Man stelle sich die RGB Werte einer Farbe als x, y und z Koordinate in einem dreidimensionalen Koordinatensystem vor. Der Rotwert entspricht x, der Grünwert entspricht y und der Blauwert entspricht z. Dann sind zwei gemessene RGB Farbwerte zwei Punkte in diesem Koordinatensystem. Der eine Punkt entspricht dem Farbidealwert, der zweite Punkt ist der Farbwert an dem Pixel am dem sich die Schleife gerade befindet. Der Abstand der Punkte kann mit folgender Formel berechnet werden.
Wenn dieser Abstand zu einem Idealwert einen festgelegten Schwellenwert unterschreitet, definieren wir diesen Pixel als Teil dieser spezifischen Farbfläche. Um nun die Koordinaten von Roboter und Ball anzugeben, müssen die Mittelpunkte der Farbflächen berechnet werden. Das geschieht, indem alle x Koordinaten ebenso wie alle y Koordinaten zusammen addiert werden und durch die Anzahl der Koordinatenpunkte geteilt werden. Die Durchschnittskoordinate ist der Mittelpunkt, den wir als Roboter oder Ballkoordinate definieren.

Es gibt verschiedenste Möglichkeiten den Schusspunkt zu berechnen. Wir verwenden eine, die sich auf Vektoren stützt, da diese in Processing am leichtesten zu verwirklichen ist. Gegeben sind die Koordinaten Ball und Tor. Sie beschreiben wir mit den Ortsvektoren $\vec{a}$ und $\vec{b}$. Vektor $\vec{c}$ geht vom Ball zum Tor und hat die Richtung der gedachten Gerade von Ball und Tor. $\vec{c}$ lässt sich leicht berechnen, nachdem man es in ein Verhältnis mit $\vec{a}$ und $\vec{b}$ gebracht hat.

Ortsvektor $\vec{g}$ ist der Schusspunkt. Um ihn in einer Gleichung beschreiben zu können, ziehen wir uns noch Vektor $\vec{f}$ zur Hilfe, der vom Schusspunkt zum Ball geht. Entsprechend ist

Also brauchen wir $\vec{f}$ bevor wir $\vec{g}$ berechnen können. $\vec{f}$ ist der verlängerte Vektor $\vec{c}$, das heißt, $\vec{c}$ mit einem Faktor multipliziert, hier genannt A.

Diese Gleichung können wir aber auch noch nicht lösen. Was wir aber berechnen können ist die Länge des Vektors $\vec{f}$, also der Betrag von $\vec{f}$. Der ist nämlich

.
q ist der Abstand vom Schusspunkt zum Ball, den wir uns definieren. Wir rechnen also mit dem Betrag von $\vec{f}$ und stellen die Gleichung anschließend nach A um.
$\vert \vec{f} \vert =\vert \vec{c} \vert \cdot A \Rightarrow A =\frac {\vert \vec{f} \vert}{\vert \vec{c} \vert}$
A wird nun in die bereits bestehende Gleichung, die $\vec{f}$ beschreibt, eingesetzt, um $\vec{f}$ zu berechnen.

Jetzt muss nur noch $\vec{f}$ in die Gleichung, die $\vec{g}$ beschreibt, eingesetzt werden und wir haben den Schusspunkt berechnet:
$\vec{g}= \vec{a} - \vec{f}$

Im nächsten Schritt soll sich der Roboter zu seinem Ziel, dem Schusspunkt, ausrichten und auf ihn zufahren.

Nachdem man zwei Vektoren aufstellt, den einen aus den zwei Punkten auf dem Roboter (Variabel „roborobohintenvektor“) und den anderen aus dem vorderen Roboterpunkt und dem Schusspunkt (Variabel „roboschusspunktvektor“), berechnet man mit folgender Formel, um wie viel Grad sich der Roboter drehen muss. Aus diesen Daten lässt sich zwar schon schließen, ob sich der Roboter eher stark oder eher schwach drehen muss, aber er weiß noch nicht, ob er sich mit oder gegen den Uhrzeigersinn drehen muss. Um das zu ermitteln, berechnen wir zusätzlich das Skalar Produkt aus dem Vektor roboschusspunktvektor und der Normalen des Vektors roborobohintenvektor. Das Vorzeichen dieses Skalar Produktes verrät nun die Richtung, in die sich der Roboter drehen muss. Wir haben experimentell ermittelt, das bei einem negativen Skalar Produkt sich der Schusspunkt links vom Roboter, entgegen dem Uhrzeigersinn befindet. Dieses Video dokumentiert die Zuverlässigkeit der Schusspunkt, Vektoren und Winkelberechnung.

In der ersten Phase des Spiels, im Processing Code mit der Variabel phase=0 beschrieben, soll sich der Roboter zum Schusspunkt ausrichten und gleichzeitig auf ihn zufahren. Er soll während der Fahrt in der Lange sein, den Kurs zu korrigieren. Um das zu ermöglichen, leiten wir zwei Geschwindigkeiten ab. Zum einen die Fahrgeschwindigkeit, die konstant auf beide Motoren gleichermaßen verteilt wird und die Drehgeschwindigkeit, die aus der Größe des errechneten Winkels resultiert. Die benutzte map()Funktion ordnet dem Winkel, der zwischen 0° und 180° liegen muss, einem Geschwindigkeitswert zu. Dieser kann von 0 bis maximal 255 definiert werden. Das Geschwindigkeitsmaximum kann aber auch kleiner gefasst werden. Entsprechend der erforderlichen Drehrichtung wird die Drehgeschwindigkeit an einem Motor zur Fahrgeschwindigkeit dazu addiert und gleichzeitig auf der anderen Seite subtrahiert. In unserem Fall bedeutet ein negatives Skalar Produkt:

$\textsf{Motorgeschwindigkeit links} = \textsf{Fahrgeschwindigkeit} - \textsf{Drehgeschwindigkeit}$ $\textsf{Motorgeschwindigkeit rechts}= \textsf{Fahrgeschwindigkeit} + \textsf{Drehgeschwindigkeit}$

Vorteil dieser Methode ist die permanente Kurskorrektur während des Fahrens. Wir mussten nämlich feststellen, dass sich die Motoren keineswegs zuverlässig und konstant drehen, sondern stark von Modell zu Modell abweichen.

In der zweiten Phase ist der Roboter am Schusspunkt und richtet sich zum Ball aus. Er dreht sich um die eigene Achse, also um den vorderen grünen Roboterpunkt. Winkel und Skalar Produkt werden wie in der ersten Phase berechnet, nur wird hier als Bezugspunkt nicht der Schusspunkt sondern der Ball verwendet. Die daraus errechnete Drehgeschwindigkeit wird so lange auf beide Motoren mit entgegengesetzter Drehrichtung (ein Rad dreht sich vorwärts, das andere rückwärts) geleitet, bis der errechnete Winkel einen Schwellenwert unterschreitet und signalisiert, das sich der Roboter zum Ball ausgerichtet hat.

In der dritten Phase schiebt der Roboter den Ball ins Tor. Bezugspunkt ist hier die Torkoordinate. Dabei soll er wie in der ersten Phase, nach dem gleichen Prinzip, den Kurs während der Fahrt korrigieren können und letztlich im Tor stoppen.

Nach nunmehr einem halben Jahr geht unser Projekt dem Ende zu. Rückblickend betrachtet haben wir das umsetzten können was wir uns im Vorfeld vorgenommen hatten.

Der Soccerbot ist gebaut und die Hardware arbeitet. In unseren Programmcodes haben wir alle beschriebenen Schritte umgesetzt. Das Zusammenspiel von Hardware und Software ist eingehend getestet worden, allerdings immer ohne einen Gegenspieler.

In diesen Tests ohne Gegenspieler hat der Soccerbot es oft geschafft, den Ball im Spielfeld ins Tor zu befördern. Wenn er es nicht geschafft hat, lag es meistens daran, dass die Bildverarbeitung empfindlich auf Veränderungen der Lichtverhältnisse reagierte und die Farbpunkte nicht mehr erkannte. Auch hat die Kamera oft geleckt, was dazu führte, das der Roboter am Ball vorbeigefahren ist oder ihn beim Schieben verloren hat.

Bei Tests mit einem Gegenspieler würde aller Voraussicht nach noch dazukommen, dass sich die Roboter gegenseitig behindern und dadurch auch gegenseitig matt setzten.

Verbesserungs- oder Erweiterungsmöglichkeiten für das Projekt sehen wir bei dem Problem der Veränderung der Lichtverhältnisse und der Gegenspielerbehinderung.

So könnte man mit Phototransistoren die Veränderung der Helligkeit wahrnehmen und als Reaktion die Farbidealwerte anpassen, um zu gewährleisten, dass die Bildverarbeitung die Farbpunkte weiter erkennt. Wie zuverlässig diese Methode aber funktionieren würde ist völlig ungewiss.

Jede Form einer Berücksichtigung des Gegenspielers hingegen würde den Algorithmus stark verkomplizieren. Es würde in jedem Fall eine Überarbeitung der Spielstrategie vorrausetzen.

Hier folgen noch einige Videos von unseren bisherigen Tests.

| |