Normaler Weise spielen im Roboterfußball mobile Multi-Agenten-Systeme kooperativ und koordiniert in einer dynamischen Umgebung zusammen. Sie teilen Aufgaben untereinander auf, und agieren autonom.







Im Bereich der humanioden Roboter hat sich Robocup ein weites Ziel gesetzt:

RoboCup will im Jahr 2050 ein Team zur Verfügung haben, mit dem es den menschlichen Fußball Weltmeister nach FIFA Regeln schlägt.




In unserem Fall gibt es aber keine Teams, da wir eins gegen eins spielen. Daher geht es hierbei um mobile Agenten-Systeme. Diese müssen die Aufgabe alleine und gegen einen weiteren Agenten ausführen.


Bei der Software-Strategie haben wir uns an Rodney A. Brooks gehalten und ein reaktives System mit einer Subsumption Architektur implementiert.



Reaktiv

Reaktiv bedeutet in diesem Zusammenhang, dass die Daten der Sensoren direkt die Steuerung des Robotors bedingen. Es werden keine Daten wie z.B. Positionen gespeichert.
Dies bedeutet, dass die Sensordaten zuverlässige Werte liefern müssen. Diese sind aber abhängig von Faktoren aus der Umgebung. So kann unterschiedlicher Lichteinfall oder eine veränderte Temperatur unvorhersehbare Reaktionen auf die Umwelt verursachen. Auch die Batterieleistung ist ausschlaggebend.

In allgemeinerem Kontext bestehen reaktive Systeme auch häufig aus nebenläufigen Prozessen, die - wie auch bei uns - oftmals nicht terminieren.



Subsumption

Diese von Brooks entwickelte Architektur ist hervorragend für ein reaktives System wie unseres geeignet:
Unser Roboter hat zu unterschiedlichen Zeitpunkten verschiedene Ziele, die sich in der Priorität differenzieren.
Zum Beispiel muss er bei der Ballsuche neben dem Ball auch die Wände beobachten. Wenn er sich festfährt, ist der Ballsensor nicht mehr wichtig. Zuerst muss sich der Roboter von der Wand entfernen.
Die möglichen Verhaltensmuster werden also berechnet und das anzuwendene aufgrund der Prioriät ausgewählt.
Diese Berechnungen erfolgen in Echtzeit während sich die Umgebungsbedingungen fortlaufend ändern. Dabei muss der Roboter mit stark verrauschten Signalen seiner Sensoren unmgehen.
Das Problem mit dem Umgang mehrerer Fehleranfälliger Sensoren fällt aber eher in den Bereich der Überlegungen von Dempster/Shafer.

Subsumption bedeutet auf Deutsch Ein- /Unterordnung. Dies wird aus folgendem Diagramm erkenntlich.




Das Beispiel von oben wäre eine Architektur mit zwei Ebenen. Die Ballsuche auf Ebene 1 und die Kollisionsvermeidung auf Ebene 0.

Im Folgenden möchte ich die Arbeit am Roboter anhand von einigen Bildern demonstrieren.
Sie zeigen den Verlauf des Aufbaus. Darunter sind auch Versuche, die später verworfen wurden.


Das erste Bild zeigt ein System, dass eine alternative Entwicklung zum herkömmlichen Greifmechanismus darstellt.
Wir haben es allerdings aus Platzgründen dagegen entschieden.
Auf dem zweiten Bild sieht man den Motor-Block, der aus vier Motoren besteht. Dann ist noch eine Möglichkeit des Hinterrades zu sehen. Hier ist ein Tischtennisball kugelgelagert in Legosteine eingebettet.
Wir haben allerdings mit dem Pendelrad auf weniger Reibung, allerdings auch auf weniger Genauigkeit in der Bewegung gesetzt.


Bei unseren Arbeiten ist es immer wieder nützlich gewesen den Roboter wie ein Auto aufzubocken. Dadurch konnten wir auch einfach Testprogramme laufen lassen, in denen sich die Räder drehen.

Es stellte sich heraus, dass neben dem Board die elf benötigten Akkus das größte Gewicht besitzen. Diese haben wir also zur Gewichtverlagerung genutzt.
Besonders wichtig war auch, dass wir einfach die Akkus wechseln konnten, da diese nicht all zu lange halten.

Auf den oberen Bildern sieht man den Roboter ohne seine Greifvorrichtung. in verschiedenen Designs, die öfters verworfen wurden.
Unten ist speziell der Greifer in seiner Endform abgebildet.

Hier kann man erkennen, dass das AKSEN-Board mit C programmiert wird.
Nicht zu erkennen ist leider, wie viel Kaffee man in der Zeit vernichten kann, während das Programm langsam auf den Roboter "geflasht" wird...

HAW Hamburg, Fachbereich Maschinenbau

• Im Fachbereich Maschinenbau gibt es ein ähnliches Projekt dem unseren.
  Es kämpfen dort auch zwei Roboter gegeneinander, allerdings nach Regeln, die den Unterschieden in der Hardware und der Umgebung genug tun:
  
  Die Robter sind kleiner und benutzen nicht das AKSEN-Board. Statt dessen arbeitet der Maschinenbau mit dem RCX Lego Mindstorms Mikrocomputer.
  Die Roboter haben nur eine Infrarot-Phalanx, die für die Ballerkennung zuständig ist. Die Wanderkennung ist auf Basis von Bumpern realisiert.
  
  
  

  LEGO RCX	Maschinenbau Roboter	IR - Phalanx	Bumper

  
  
  Das Feld ist auch kleiner und hat statt eines Filzbodens einen Boden aus Gummi und alternativ einen aus Papier. Die Wände sind schwarz, und die Tore können an ihrer weißen Farbe erkannt werden.
  
  

  Gummifeld des Maschinenbaus	Papierfeld des Maschinenbaus

  
  
  
  Die meisten Teams verwenden ein Differential für den Antrieb und eine rafinierte Form der Ballführung:
  
  

  Differential in einem Roboter des Maschinenbaus	Hier wird dem Ball ein Spin gegeben, der entgegen dem Roboter dreht. Dadurch ist es möglich Wendemanöver durchzuführen, ohne den Ball mit Hilfe eines Greifers zu fixieren. VIDEO

  
  
  

Profis: Junior League

• Ebenso wie bei uns dient die Junior League zur Ausbildung. Die Anforderungen an die Kenntnisse der Informatik und die sich daraus ergebenden Resultate sind jedoch stark verschieden
  LEGO Mindstorm Bausätze werden von Schülern verwendet um die Fußball-Roboter zu bauen, die dann einzeln oder zu zweit gegeneinander antreten.
  Das Feld gleicht der Papierversion des Maschinenbau-Feldes. Bei den Sensoren verhält es sich ähnlich. Der Ball strahlt -wie unserer- infrarot.
  
  Ein weiterer Unterschied besteht darin, daß in der Junor League nicht nur Fußball gespielt, sondern auch Wettkämpfe in den Bereichen Robotdance und Robotrescue ausgetragen werden.
  
  Diese Liga gibt es seit 1997 in Japan, seit 2001 in Deutschland, seit 2002 in Australien und seit 2003 in den USA.
  

Die Bilder vom Kontest zwischen Studenten von der HAW Hamburg und denen aus Brandenburg und Dortmund gibt es hier

Unseren Roboter kann man natürlich in diversen Varianten weiterentwickeln.
Ich möchte hier einige meiner Ideen aufzählen, die mir für das Projekt und eine eventuelle Studien- oder Diplomarbeit besonders interessant erscheinen.

• Zum einen wäre es möglich den Roboter mit einer Funktion zur Autokalibrierung der Sensoren auszustatten.
  
  
  So könnte er durch Bumper merken, wenn er der Wand zu nah gekommen ist und dementsprechend die Sharps einstellen.
  
  
  Bei den Ballsensoren ist es etwas komplizierter. Der Roboter müsste ebenfalls durch „Trial and Error“ versuchen, den Ball zu approximieren. Hilfreich wären hier Default-Werte oder ein vorgegebener kalibrierter Sensor.
  
  
  Die Torsuche könnte man mit neuronalen Netzen implementieren.
  
  
  
• Der Roboter könnte auch mit weiteren Verhalten ausgestattet werden, die sich aus weiteren gesammelten Daten ergeben. Es wäre möglich den bekannten Verlauf zu dokumentieren und Statistiken daraus abzuleiten.
  Wenn zum Beispiel die Zeit ohne Ball erheblich länger der Zeit mit Ball ist, könnte der Roboter die Prioritäten von Ballsuche und Kollisionsvermeidung verändern.
  Ebenso könnte er seine Geschwindigkeit anpassen, wenn er merkt, dass er den Ball oft erst Links und kurz danach Rechts von sich sieht.
  
  
  
• Weitere Sensoren, wie Kameras wären eine gute Erweiterung um weitere Inputs zu verifizieren. Zum Beispiel könnte man dann mit Farben operieren, die den Gegner identifizieren. Man könnte auch erkennen, ob der Gegner im Ballbesitz ist um ein Tor zu verhindern.
  
  
  
• Für die Kalibrierung haben viele Teilnehmer des Projektes eine Art Menü für das zweizeilige Display entworfen.
  
  Man könnte aber auch einen Schritt weitergehen und daneben noch das modifizieren der kalibrierten Werte oder beliebige Sensor-Tests und Testfahrten anbieten.
  Auch Optionen für den Wettkampf könnte man hier einstellen, sowie man hier den Faktor der genutzten Sleep-Zeiten oder die Taktik definieren könnte.
  
  Wenn man noch einen Schritt weitergeht, wäre es möglich bauähnliche Roboter, also mit gleicher Anzahl Aktoren und Sensoren mit einem solchen Programm zu initialisieren und über das Menü einzustellen.
  Dazu konnte ein weiterer Menüpunkt regeln, welche Schnittstellen des AKSEN-Boards wie belegt sind.
  Dadurch wäre man in der Lage einen Bausatz mit den entsprechenden Komponenten und einer solchen Software ohne Programmierkenntnisse zu einem funktionablen Fußballrobot zusammen zu bauen.
  Dies wäre für den technischen Lehrbereich sehr interessant, wie ich aus Gesprächen mit den Studenten aus dem Fachbereich Maschinenbau erfahren habe. Dort geht es natürlich hauptsächlich um die Konstruktion des Roboters. Da aber immer diese gewisse Ähnlichkeit in der Bauweise geben muss, ist die Idee mit dem Bausatz vor allem für Schüler relevant.
  
  
  
  
  
  
  
  
• Die Idee der Ballführung aus dem Fachbereich Maschinenbau könnte vielleicht auch übernommen werden.
  Dann wäre es auch erlaubt den Ball länger als drei Sekunden zu halten, da der Gegner ihn auch so erkämpfen kann. Dadurch würde Dribbling ein wichtiges Element werden.