soccer server robocup

Seminar: Agenten in simulierten Umgebungen 1

Soccer Server RoboCup

Vortrag im Rahmen des Seminars:Agenten in simulierten Umgebungen

13.12.2004


Agenda

1. Einleitung

2. Architektur

3. Problemstellung der Soccergruppen

4. Fazit


Agenda

1. Einleitung1. Geschichte

2. Vorstellung

3. RoboCup Leagues

4. Simulated League


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


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)


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


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)


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]


RoboCup

Rescue

Junior

Soccer


Rescue League

Simulation von Kastastrophen-Situationen

2 Varianten:Reale Roboter

Simulated Rescue League

Keine Restriktionen zur Robotergestaltung

Teilweise ferngesteuert, teilweise autonom (Funkabbruch)


Rescue League


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!“


Junior Leagues


Soccer Leagues

Humanoid League

4 legged League

Small sized League

Mid sized League

E-League

Simulated League


Humanoid League3 Robotergrößen: 40cm, 80cm, ab 120cm1-6 Spieler: Feldspieler (und Torwart)Spielfeldgröße: 7,2 x 10,4 MeterDisziplinen:

„Auf-einem-Bein-stehen“ Menschlicher Gang (um Pfosten herum)SchießenElfmeterschießen mit TorwartFussball spielen (2 Teams, 3 vs. 3)Free StylePerformance factors


Human League


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


4 legged League


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


Small sized League


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


Mid sized League


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


Simulated League

3 Wettbewerbe:2d Soccer Simulation League3d Soccer Simulation LeagueCoach League

2 Teams mit jeweils 10 Feldspielern, 1 Torwart, Coach (optional)Spiellänge: 2 x 5 Minutennormale Fußballregeln: Abseitsregel, Rückpass-Regel, …


Simulated League

Spiele häufig einseitig mit eindeutigem GewinnerBeispiel: RoboCup WM 2001 in SeattleVorrundengruppe E

Gruppe E 1 2 3 4 5 6

1 FCPortugal2001 8:0 *** 32:0 9:0 29:0

2 RoboLog2k1 0:8 *** 24:0 0:0 11:0

3 Pasargad *** *** *** *** ***

4 RMIT_Goannas 0:32 0:24 *** 0:30 0:26

5 TUT-groove 0:9 0:0 *** 30:0 4:0

6 11monkeys3 0:29 0:11 *** 26:0 0:4


Agenda

2. Architektur1. Übersicht

2. Monitor

3. Client-Server-Modelle


Übersicht

Client/Server Architektur

Kommunikation über UDP

Server überwacht Welt-Modell (inkl. Referee)

Monitor visualisiert Welt-Modell

Jeder Spieler / Coach ein autonomer Client


Übersicht

Client 1 Client 2 Client 24

Soccer ServerMonitorUDP-Pakete

UDP-Pakete UDP-Pakete

UDP-Pakete

IP-Netz

……………………...


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)


Monitor Beispiele

2 dimensionale Monitore:Soccermonitor

3 dimensionale Monitore:Magic Box 2

(offizieller RoboCup-Monitor)


Agenda

2. Architektur1. Übersicht

2. Monitor



Agenda

3. Client-Server-Modellea. Allgemein zum Client-Server-Modell

b. Aktualisierung der Umwelt

c. Positionen an den Monitor weiterleiten

d. Verschicken der Sensordaten


Client-Server Modell

Server ist eine Plattform, auf der Teams Fußballspiele austragen können

Client-Server ArchitekturClient meldet sich mit (init TeamName) beim Server an

Kommunikation über UDP/IP

Freie Gestaltung der TeamsTeam besteht aus höchstens 12 Clients

(10 Feldspieler, 1 Torwart und 1 Coach)


Anfrage nach Aktion

Sensordaten

Bearbeitet die Anfragen

Aktualisiert die Umwelt

Wertet die Sensordaten aus

Entscheidet über nächste Aktion


AktionenDash – RennenMove – BeamenKick – SchießenTurn – Körper drehenTurnNeck – Kopf drehenCatch – Ball fangenSay – RedenChangeView – Sicht ändernSenseBody – SenseBody Nachricht anfragenScore – Punktestand anfragen


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

1. Aktualisierung der Umwelt (1) (Reihenfolge, in der die Anfragen bearbeitet werden ist zufällig)

a) Bearbeitung der Anfragen (Beschleunigung, Drehung, Info)

b) Berechnung der Bewegungen


Simulation Step (2)

1. Aktualisierung der Umwelt (2)c) Berechnung der Position

i. Berechnung der vorläufigen Position

ii. Kollisionsbehandlung

iii. Behandlung von Regelverstößen

2. Positionen an den Monitor weiterleiten

3. Verschicken der Sensordaten


Agenda


a. Allgemein zum Client-Server-Modell

b. Aktualisierung der Umwelti. Bearbeitung der Anfragen

ii. Berechnung der Bewegungen

iii. Berechnung der Position




AktionenDash – RennenMove – BeamenKick – SchießenTurn – Körper drehenTurnNeck – Kopf drehenCatch – Ball fangenSay – RedenChangeView – Sicht ändernSenseBody – SenseBody Nachricht anfragenScore – Punktestand anfragen

} Können nur einmal im

Zyklus

Ausgeführt werden


Dash (power)Effektive Power hängt von

dem power–Parameter (zwischen –100 und 100), der Leistung und der dashPowerRate [default 0.006] ab.

atedashPowerReffortpowereffPower **

Richtung, in die die Power ausgeübt wird, hängt vonder bodyDirection des Spielers ab.

ionbodyDirectt

))sin(),(cos(*),( ttty

tx effPoweraa Beschleunigung


Stamina (Ausdauer / Durchhaltevermögen)

Maximal am Anfang und nach der Halbzeit

Dash reduziert StaminaVorwärtslaufen: Stamina – Power

Rückwärtslaufen: Stamina – 2*Power

In jedem Zyklus wird etwas von der Stamina zurückgewonnen

Die Stamina bestimmt den Effort


Move (X, Y)

Spieler kann exakt an eine Position gestellt werdenKostet keine Stamina Unterliegt keinen Unschärfen

FeldspielerVoraussetzung: Play-Mode = beforeKickOff, goalKann so lange ausgeführt werden, bis sich der Play-Mode ändert

TorwartVoraussetzung: Ball im Strafraum gefangenKann maximal goalieMaxMoves ausgeführt werden


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

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

atekickPowerRkickableM

distdirDiffpowereffPower *)*25.0

180*25.01(*


Kick (power,direction) (2)

directiontplayer

t

Richtung, in die die Power ausgeübt wird, hängt vondem direction-Parameter (zwischen –180 und 180) und

dem relativen Winkel des Spielers zum Ball ab.

))sin(),(cos(*),( ttty

tx effPoweraa Beschleunigung

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


Turn (moment)

Effektive Drehung hängt von dem moment–Parameter (zwischen –180 und 180),

dem Trägheitsmoment [default 5] und

der aktuellen Geschwindigkeit des Spielers ab.

dplayerSpeeentinertiaMom

momenteffMoment

*1


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


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


Agenda









Berechnung der Bewegung

),(**),(),( 1111 ty

tx

ty

tx

ty

tx aaranddecayvvvv

Geschwindigkeit = alte Geschwindigkeit* Dämpfungsfaktor

* zufällige Verfälschung + Beschleunigung


Agenda









Berechnung der Position

Kollisionsbehandlung:wenn am Ende der Berechnung zwei Objekte überlappen

1. Objekte so positioniert, dass sie sich nicht überlappen

2. Bewegung mit – 0.1 multipliziert

Behandlung von Regelverstößen:wenn die Position gegen eine Regel verstößt

Schiedsrichter weist eine neue Position zu

),(),(),( 11 ty

tx

ty

tx

ty

tx vvpppp

Position = alte Position + Geschwindigkeit

Vorläufigen Position:

),( 11 ty

tx pp

),( ty

tx pp

),( ty

tx vv


Agenda







Agenda






i. Body Sensor Modell

ii. Visual Sensor Modell

iii. Aural Sensor Modell


SenseBody(sense body Time

(view mode ViewQuality ViewWidth)

(stamina Stamina Effort)(speed AmountOfSpeed

DirectionOfSpeed)(head angle HeadDirection)(kick KickCount)(dash DashCount)(turn TurnCount)(say SayCount)(turn neck TurnNeckCount)(catch CatchCount)(move MoveCount)(change view ChangeViewCount))

SenseBody – Nachrichten werden

a) in jedem Zyklus

b) nach Anfrage empfangen


Agenda










Visual Sensor

Visual Sensor des Spielers erfasst visuelle Informationen über das Spielfeld

z.B. Distanz und Richtung zu verschiedenen Objekten

im aktuellen Sichtfeld des Spielers (Agenten)

fungiert zusätzlich als „Umgebungssensor“, indem er Objekte erkennt, die nicht im Sichtbereich, aber direkt am Spieler stehen

hierbei aber: nur unvollständige Informationen!

Das Spielfeld

x := -52,5 ~ +52,5 (105 m)

y := -34 ~ +34 (68 m)

5 m

f g r b


Visual Sensor Model

visuelle Informationen werden dem Spieler automatisch mit Hilfe von see-Nachrichten jeden sense_step geschickt (default: 150 ms)

Nachrichten für die visuellen Informationen haben das Standardformat:(see ObjName Distance Direction DistChng

DirChng BodyDir HeadDir)


Parameter der see-Nachricht

(see ObjName Distance Direction [DistChng DirChng [BodyDir HeadDir]])ObjName: (g [l|r]) | (f [l|c|r] [t|b]) | (p („Teamname“ UniformNumber …)) |…

Distance: euklidische Distanz

Direction: Richtung des Objekts relativ zur Blickrichtung

Wenn es ein bewegliches Objekt ist, zusätzlich:DistChng: Distanzveränderung

DirChng:Richtungsveränderung

Wenn das bewegliche Objekt ein anderer Spieler ist, zusätzlich:BodyDir: Richtung des Körpers relativ zum eigenen Körper

HeadDir:Richtung des Kopfes relativ zum eigenen Kopf


Beispiel einer see-Message(see 0 ((f r t) 90 -39) ((f r b) 73.7 9)

((f g r b) 73.7 -12) ((g r) 75.2 -17)…)

[***DebugMsg*** flag: time:0 name:f r t distance:90.0 direction:-39.0]

[***DebugMsg*** flag: time:0 name:f r b distance:73.7 direction:9.0]

[***DebugMsg*** flag: time:0 name:f g r b distance:73.7 direction:-12.0]

[***DebugMsg*** Tor: time:0 name:g r distance:75.2 direction:-17.0]

…


Wahrnehmung des Spielers

Sichtfeld (view_angle) und Wahrnehmungsfrequenz (view_frequency) können beeinflusst werden durch:

(change_view Width Quality)Width: narrow | normal | wide

Quality: high | low

Sichtfeld: 45° | 90° | 180°

Wahrnehmungsfrequenz steigt mit niedrigerer Qualität und kleinerem Sichtfeld


InformationsmengeDie Informationsmenge über andere Spieler hängt von der Entfernung (und dem Sichtfeld;-) ab:

dist unum_far_length [default: 20] Trikotnummer und Teamname sichtbarunum_far_lenght dist unum_too_far_lenght [default: 40] Teamname immer sichtbar, Wahrscheinlichkeit der

Trikotnummer-Sichtbarkeit nimmt bei steigender dist linear abdist unum_too_far_length Trikotnummer nicht sichtbardist team_far_length…

Beispiel zur Informationsmenge


Visual Sensor Noise Model (Störungsmodell)

Spieler weiß die Entfernung eines gesehenen Objektes nie genau

Störung wird mit zunehmender Entfernung größer

bis zu 10% Fehler bei der übermittelten Entfernung

tendenzielle Überschätzung


Agenda










Aural Sensor

empfängt Nachrichten vom Schiedsrichter, den Trainern und den anderen Spielern

Nachrichten werden durch den say-Befehl gebroadcastet

Nachrichten werden sofort empfangen


hear-Message

(hear Time Sender „Message“)time: aktueller Zyklus

Sender: relative Richtung des Senders

| self

| referee

| online_coach_left

| online_coach_right

„Message“: String mit maximale Länge say_msg_size [default: 512 bytes]


Nachrichten der Spieler/Coaches (1)

ReichweiteÜbermittlung einer Nachricht nur an Spieler innerhalb von audio_cut_dist [default: 50.0] Meter

Aufnahmekapazität [hear_max, default: 2]Aufnahme, wenn Kapazität „Empfangskosten“ hear_decay [default: 2]

jede Runde wird hear_inc [default: 1] Kapazität regeneriert

alle zwei Runden eine Nachricht pro Team


Nachrichten der Spieler/Coaches (2)

separate Kapazitäten für jedes Team, um Überladen der Kapazitäten durch das andere Team zu vermeiden

erreichen mehr Nachrichten zur gleichen Zeit einen Spieler, als er aufnehmen kann, ist der Inhalt undefiniert


Nachrichten des Schiedsrichters – Play Modesbefore_kick_offplay_ontime_overkick_off_Sidekick_in_Sidefree_kick_Sidegoal_Sidecorner_kick_Sideoffside_Side …


Nachrichten des Schiedsrichters –Messages

goal_Side_n kick_off_OSide

foul_Side free_kick_OSide

time_up time_over

half_time before_kick_off

…

Nachrichten des Schiedsrichters kommen immer bei allen Spielern an


Agenda

3. Problemstellung der Soccer-Gruppen1. Herausforderungen

2. Vorführung eines SimpleClients


Herausforderungen

Entwicklung der „Intelligenz“ einer SoccerServer-Mannschaft

Unterteilung der Herausforderungen in vier Teilprobleme:

Wahrnehmung„Aktionsrunden“ParallelitätPlanung/Taktik


Teilproblem „Wahrnehmung“

Analyse der Sensordaten:Parsen der Nachrichten und die damit verbunden Folgeinterpretationprogramminterne Repräsentation der Informationen

größte Teilprobleme: wo bin ich? (eigene Position auf dem Spielfeld ist dem Spieler nicht bekannt)Ballbesitz unbekannt


Teilproblem „Aktionsrunde“

generieren der Kommandos unter Berücksichtung möglichst aktueller Umweltinformationen (Synchronisation)

Vermeiden von „holes“ (Nichtnutzung einer Handlungsmöglichkeit)

Vermeidung von „clashes“(serverseitige zufällige Auswahl aus den erhaltenen

Kommandos des letzten Zyklus)


Teilproblem „Parallelität“

serverseitige asynchrone Berechnung von Sensordaten und Kommandosdeshalb: parallele Ausführung von

Wahrnehmungsprozess(Verarbeitung des Sensornachrichten)

Aktionsprozess(Vorbereiten der nächsten Aktion)


Teilproblem „Planung/Taktik“

die Kür!!!

Entwicklung eines Gesamtkonzeptes für das Team (mehr als: „Ball rund muss in Tor eckig!“)

Antizipation nachfolgender Spielsituationen

Unterprobleme:Optimale Nutzung der 100ms-Zyklen

Heuristiken für z.B. Schussverhalten aufstellen


Agenda

3. Problemstellung der Soccer-Gruppen1. Herausforderungen

2. Vorführung eines SimpleClients


Vorführung eines SimpleClients

Implementierung des SimpleClients:Ball und Tor suchen (und hoffentlich finden)

in Richtung des Balles drehen

zum Ball hinrennen

auf das rechte Tor schießen


Agenda

3. Problemstellung der Soccer-Gruppen

4. Fazit


Fazit

Probleme:Performance

Konkurrierende Entwicklergemeinde

Schlechte Dokumentation

Noch geringes Interesse der Öffentlichkeit (Deadlinks, fehlende Aktualität)

Fehlersuche (Debugging)


Fazit

Chancen:Möglichkeit, spielerisch komplexe Gebiete der Informatik zu erschließen

Wachsendes Interesse in der Öffentlichkeit

Agenten-Implementierung programmiersprachen-unabhängig

Gute Verzahnung von Forschung und Wirtschaft (z.B. Sony, sgi, …)


Fragen?

Und nicht vergessen...

13. - 19. Juli 2005: RoboCup in Osaka

13. - 19. Juni 2006:RoboCup in Bremen(!)

soccer server robocup

Documents