1. Soccer Server RoboCup Vortrag im Rahmen des Seminars:Agenten in simulierten Umgebungen13.12.2004

2. Agenda • Einleitung • Architektur • Problemstellung der Soccergruppen • Fazit

3. Agenda • Einleitung • Geschichte • Vorstellung • RoboCup Leagues • Simulated League

4. Einleitung • 1997: • IBMs Deep Blue gewinnt gegen Schachweltmeister Garry Kasparov • Autonom gesteuerter Roboter erkundet Mars • Erste Fussball-Weltmeisterschaft für Roboter findet in Nagoya (Japan) statt.  KI durchdringt alle Forschungsbereiche

5. Geschichte • ´92: Erste Gedanken zu Roboter-Fussball (in Kanada und Japan) • ´93: Überlegung eine japanische Roboter- Fussball-Liga zu gründen, für die sich sofort viele ausländische Forscher interessieren • ´95: Erste simulierte Fussballspiele bei der International Joint Conference on Artificial Intelligence (IJCAI-95)

6. Geschichte • ´96: Erster inoffizieller RoboCup mit acht Mannschaften in der Simulationsliga und einem Schaukampf für mittelgroße Roboter • ´97: RoboCup I in Nagoya mit 40 teilnehmenden Teams [...] • ´04: RoboCup VIII in Lissabon mit 346 Teams

7. Geschichte • 1997 Nagoya (Japan) • 1998 Paris (Frankreich) • 1999 Stockholm (Schweden) • 2000 Melbourne (Australien) • 2001 Seattle (USA) • 2002 Fukuoka (Japan) • 2003 Padua (Italien) • 2004 Lissabon (Portugal)

8. Vision • „By mid-21st century, a team of fully autonomous humanoid robot soccer players shall win the soccer game, comply with the official rule of the FIFA, against the winner of the most recent World Cup. „ [Kitano, 1998]

9. RoboCup • Rescue • Junior • Soccer

10. Rescue League • Simulation von Kastastrophen-Situationen • 2 Varianten: • Reale Roboter • Simulated Rescue League • Keine Restriktionen zur Robotergestaltung • Teilweise ferngesteuert, teilweise autonom (Funkabbruch)

11. Rescue League

12. Junior Leagues • Verschiedene Ligen: • Soccer, Rescue, Dance • Dient Schülern und Studenten als Einstieg in den RoboCup • Kaum Restriktionen „It is not whether you win or lose, but how much you learn that counts!“

13. Junior Leagues

14. Soccer Leagues • Humanoid League • 4 legged League • Small sized League • Mid sized League • E-League • Simulated League

15. Humanoid League • 3 Robotergrößen: 40cm, 80cm, ab 120cm • 1-6 Spieler: Feldspieler (und Torwart) • Spielfeldgröße: 7,2 x 10,4 Meter • Disziplinen: • „Auf-einem-Bein-stehen“ • Menschlicher Gang (um Pfosten herum) • Schießen • Elfmeterschießen mit Torwart • Fussball spielen (2 Teams, 3 vs. 3) • Free Style • Performance factors

16. Human League

17. 4 legged League • Nur ein Roboter-Typ: • Spieleranzahl: 4 gegen 4 • Spielfeldgröße: 3 x 4,5 Meter • Hardware darf nicht verändert werden • Kommunikation über TCP/IP (W-LAN) • Programmierung über Open-R Schnittstelle

18. 4 legged League

19. Small sized League • Roboteranzahl: 5 gegen 5 • Robotergröße: • Grundfläche: max. 18 x 18 cm • Höhe: max. 22,5 cm • Spielfeldgröße: 2,4 x 2,9 Meter • Eine gemeinsame Kamera über dem Spielfeld • Schussapparat: schnell rotierende Rolle • Remote Control über einen zentralen Rechner

20. Small sized League

21. Mid sized League • Robotergröße: • Grundfläche: mind. 30 x 30 cm, höchstens 50 x 50 cm • Höhe: 40 – 80 cm • Roboteranzahl: 4 gegen 4 • Spielfeldgröße: 5 x 8 Meter • Eigene Kamera, Rechner an Bord (autonom) • Externer Rechner ohne menschlichen Eingriff erlaubt

22. Mid sized League

23. E-League • Seit 2004 im Programm • Einstiegsliga als Brücke zwischen Junior-League und der professionellen Soccer-League • Roboter entsprechen denen der Small sized League • Leichte Modifikationen und Restriktionen bezüglich der Komplexität um Einstieg zu erleichtern

24. Simulated League • 3 Wettbewerbe: • 2d Soccer Simulation League • 3d Soccer Simulation League • Coach League • 2 Teams mit jeweils 10 Feldspielern, 1 Torwart, Coach (optional) • Spiellänge: 2 x 5 Minuten • normale Fußballregeln: Abseitsregel, Rückpass-Regel, …

25. Simulated League • Spiele häufig einseitig mit eindeutigem Gewinner • Beispiel: RoboCup WM 2001 in SeattleVorrundengruppe E

26. Agenda • Architektur • Übersicht • Monitor • Client-Server-Modelle

27. Übersicht • Client/Server Architektur • Kommunikation über UDP • Server überwacht Welt-Modell (inkl. Referee) • Monitor visualisiert Welt-Modell • Jeder Spieler / Coach ein autonomer Client

28. Übersicht

29. Monitor • Monitor stellt visuelles Interface zur Verfügung • Nachrichtenaustausch über UDP • Alle 100ms Nachricht vom Server • Log-File-Player (meistens) integriert • Zusatzinformationen zu Spieler, Ball • Auswertungsmöglichkeiten (Debugging)

30. Monitor Beispiele • 2 dimensionale Monitore:Soccermonitor • 3 dimensionale Monitore:Magic Box 2 (offizieller RoboCup-Monitor)

31. Agenda • Architektur • Übersicht • Monitor • Client-Server-Modelle

32. Agenda • Client-Server-Modelle • Allgemein zum Client-Server-Modell • Aktualisierung der Umwelt • Positionen an den Monitor weiterleiten • Verschicken der Sensordaten

33. Client-Server Modell • Server ist eine Plattform, auf der Teams Fußballspiele austragen können • Client-Server Architektur • Client meldet sich mit (init TeamName) beim Server an • Kommunikation über UDP/IP • Freie Gestaltung der Teams • Team besteht aus höchstens 12 Clients (10 Feldspieler, 1 Torwart und 1 Coach)

34. Anfrage nach Aktion Sensordaten Bearbeitet die Anfragen Aktualisiert die Umwelt Wertet die Sensordaten aus Entscheidet über nächste Aktion

35. Aktionen • Dash – Rennen • Move – Beamen • Kick – Schießen • Turn – Körper drehen • TurnNeck – Kopf drehen • Catch – Ball fangen • Say – Reden • ChangeView – Sicht ändern • SenseBody – SenseBody Nachricht anfragen • Score – Punktestand anfragen

36. Simulation Step (1) Real-Time-System mit diskreten Zeitintervallen (100ms) 0. Anfragen müssen beim Server vorher eingetroffen sein  Durch eine schlechte Performance, können Zyklen verpasst werden • Aktualisierung der Umwelt (1) (Reihenfolge, in der die Anfragen bearbeitet werden ist zufällig) • Bearbeitung der Anfragen (Beschleunigung, Drehung, Info) • Berechnung der Bewegungen

37. Simulation Step (2) • Aktualisierung der Umwelt (2) • Berechnung der Position • Berechnung der vorläufigen Position • Kollisionsbehandlung • Behandlung von Regelverstößen • Positionen an den Monitor weiterleiten • Verschicken der Sensordaten

38. Agenda • Client-Server-Modelle • Allgemein zum Client-Server-Modell • Aktualisierung der Umwelt • Bearbeitung der Anfragen • Berechnung der Bewegungen • Berechnung der Position • Positionen an den Monitor weiterleiten • Verschicken der Sensordaten

39. } Aktionen • Dash – Rennen • Move – Beamen • Kick – Schießen • Turn – Körper drehen • TurnNeck – Kopf drehen • Catch – Ball fangen • Say – Reden • ChangeView – Sicht ändern • SenseBody – SenseBody Nachricht anfragen • Score – Punktestand anfragen Können nur einmal im Zyklus Ausgeführt werden

40. Richtung, in die die Power ausgeübt wird, hängt von • der bodyDirection des Spielers ab. • Beschleunigung Dash (power) • Effektive Power hängt von • dem power–Parameter (zwischen –100 und 100), • der Leistung und • der dashPowerRate [default 0.006] ab.

41. Stamina (Ausdauer / Durchhaltevermögen) • Maximal am Anfang und nach der Halbzeit • Dash reduziert Stamina • Vorwärtslaufen: Stamina – Power • Rückwärtslaufen: Stamina – 2*Power • In jedem Zyklus wird etwas von der Stamina zurückgewonnen • Die Stamina bestimmt den Effort

42. Move (X, Y) • Spieler kann exakt an eine Position gestellt werden • Kostet keine Stamina • Unterliegt keinen Unschärfen • Feldspieler • Voraussetzung: Play-Mode = beforeKickOff, goal • Kann so lange ausgeführt werden, bis sich der Play-Mode ändert • Torwart • Voraussetzung: Ball im Strafraum gefangen • Kann maximal goalieMaxMoves ausgeführt werden

43. Effektive Power hängt von • dem power–Parameter (zwischen –100 und 100), • dem relativen Winkel des Spielers zum Ball, • der Distanz zwischen Spieler und Ball und • der kickPowerRate [default 0.027] ab Kick (power, direction) (1) • Voraussetzung: Ball ist in der kickableMargin [default 0.7] • Während einer Runde können mehrere Spieler den Ball schießen

44. Richtung, in die die Power ausgeübt wird, hängt von • dem direction-Parameter (zwischen –180 und 180) und • dem relativen Winkel des Spielers zum Ball ab. • Beschleunigung Kick (power,direction) (2) Ein guter Schuss kann den Ball bis zu einer Distanz von 45 schießen • Nach 15 Runden  Distanz: 27 / Restgeschwindigkeit: ca. 1 • Nach 53 Runden  Distanz: 43 / Restgeschwindigkeit: ca. 0.1

45. Effektive Drehung hängt von • dem moment–Parameter (zwischen –180 und 180), • dem Trägheitsmoment [default 5] und • der aktuellen Geschwindigkeit des Spielers ab. Turn (moment)

46. TurnNeck (angle) • HeadDirection ist relativ zum Körper Sichtwinkel kann sich durch Turn oder TurnNeck ändern • Der Kopf kann maximal bis zu einer headDirection von +90° oder –90° gedreht werden. • TurnNeck kann mit Dash, Kick oder Turn ausgeführt werden

47. Catch (direction) • Torwart kann in jeder Richtung den Ball mit einer catchProbability fangen • Voraussetzung: Ball ist in der catchableArea und Torwart ist im Strafraum • Fangversuch Missglückt  Torwart muss 5 Zyklen warten, bis er es erneut versuchen kann Geglückt Torwart kann zu einer geeigneten Position „moven“ und den Ball abspielen

48. Agenda • Client-Server-Modelle • Allgemein zum Client-Server-Modell • Aktualisierung der Umwelt • Bearbeitung der Anfragen • Berechnung der Bewegungen • Berechnung der Position • Positionen an den Monitor weiterleiten • Verschicken der Sensordaten

49. Geschwindigkeit = alte Geschwindigkeit* Dämpfungsfaktor * zufällige Verfälschung + Beschleunigung Berechnung der Bewegung

50. Agenda • Client-Server-Modelle • Allgemein zum Client-Server-Modell • Aktualisierung der Umwelt • Bearbeitung der Anfragen • Berechnung der Bewegungen • Berechnung der Position • Positionen an den Monitor weiterleiten • Verschicken der Sensordaten