seminar: agenten in simulierten umgebungen 1 soccer server robocup vortrag im rahmen des seminars:...

Seminar: Agenten in simulierten Umgebungen 1

Soccer Server RoboCup

Vortrag im Rahmen des Seminars:Agenten in simulierten Umgebungen

13.12.2004


Agenda1. Einleitung2. Architektur3. Problemstellung der Soccergruppen4. Fazit


Agenda1. Einleitung

1. Geschichte2. Vorstellung3. RoboCup Leagues4. Simulated League


Einleitung1997:

IBMs Deep Blue gewinnt gegen Schachweltmeister Garry KasparovAutonom gesteuerter Roboter erkundet MarsErste 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


Geschichte1997 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]


RoboCupRescue

Junior

Soccer


Rescue LeagueSimulation von Kastastrophen-Situationen2 Varianten:

Reale RoboterSimulated Rescue League

Keine Restriktionen zur RobotergestaltungTeilweise ferngesteuert, teilweise autonom (Funkabbruch)


Rescue League


Junior LeaguesVerschiedene Ligen:

Soccer, Rescue, Dance

Dient Schülern und Studenten als Einstieg in den RoboCupKaum Restriktionen

„It is not whether you win or lose, but how much you learn that counts!“


Junior Leagues


Soccer LeaguesHumanoid League4 legged LeagueSmall sized LeagueMid sized LeagueE-LeagueSimulated 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 LeagueNur ein Roboter-Typ:Spieleranzahl: 4 gegen 4Spielfeldgröße: 3 x 4,5 MeterHardware darf nicht verändert werdenKommunikation über TCP/IP (W-LAN)Programmierung über Open-R Schnittstelle

http://www.world.sony.com/robot/index.html

http://www.aibo.com/


4 legged League


Small sized LeagueRoboteranzahl: 5 gegen 5Robotergröße:

Grundfläche: max. 18 x 18 cmHöhe: max. 22,5 cm

Spielfeldgröße: 2,4 x 2,9 MeterEine gemeinsame Kamera über dem SpielfeldSchussapparat: schnell rotierende RolleRemote Control über einen zentralen Rechner


Small sized League


Mid sized LeagueRobotergröße:

Grundfläche: mind. 30 x 30 cm, höchstens 50 x 50 cmHöhe: 40 – 80 cm

Roboteranzahl: 4 gegen 4Spielfeldgröße: 5 x 8 MeterEigene Kamera, Rechner an Bord (autonom)Externer Rechner ohne menschlichen Eingriff erlaubt


Mid sized League


E-LeagueSeit 2004 im ProgrammEinstiegsliga als Brücke zwischen Junior-League und der professionellen Soccer-LeagueRoboter entsprechen denen der Small sized LeagueLeichte Modifikationen und Restriktionen bezüglich der Komplexität um Einstieg zu erleichtern


Simulated League3 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 LeagueSpiele 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


Agenda2. Architektur

1. Übersicht2. Monitor3. Client-Server-Modelle


ÜbersichtClient/Server ArchitekturKommunikation über UDPServer überwacht Welt-Modell (inkl. Referee)Monitor visualisiert Welt-ModellJeder Spieler / Coach ein autonomer Client


Übersicht

Client 1 Client 2 Client 24

Soccer ServerMonitorUDP-Pakete

UDP-Pakete UDP-Pakete

UDP-Pakete

IP-Netz

……………………...


MonitorMonitor stellt visuelles Interface zur VerfügungNachrichtenaustausch über UDPAlle 100ms Nachricht vom ServerLog-File-Player (meistens) integriertZusatzinformationen zu Spieler, BallAuswertungsmöglichkeiten (Debugging)


Monitor Beispiele2 dimensionale Monitore:Soccermonitor

3 dimensionale Monitore:Magic Box 2(offizieller RoboCup-Monitor)


Agenda2. Architektur

1. Übersicht2. Monitor3. Client-Server-Modelle


Agenda3. Client-Server-Modelle

a. Allgemein zum Client-Server-Modellb. Aktualisierung der Umweltc. Positionen an den Monitor weiterleitend. Verschicken der Sensordaten


Client-Server ModellServer ist eine Plattform, auf der Teams Fußballspiele austragen könnenClient-Server Architektur

Client meldet sich mit (init TeamName) beim Server anKommunikation ü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 Positioni. Berechnung der vorläufigen Positionii. Kollisionsbehandlungiii. Behandlung von Regelverstößen

2. Positionen an den Monitor weiterleiten3. Verschicken der Sensordaten



a. Allgemein zum Client-Server-Modellb. Aktualisierung der Umwelt

i. Bearbeitung der Anfragen ii. Berechnung der Bewegungen iii. Berechnung der Position

c. Positionen an den Monitor weiterleitend. Verschicken der Sensordaten


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 HalbzeitDash reduziert Stamina

Vorwärtslaufen: Stamina – PowerRückwärtslaufen: Stamina – 2*Power

In jedem Zyklus wird etwas von der Stamina zurückgewonnenDie 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 undder kickPowerRate [default 0.027] ab

atekickPowerRkickableMdistdirDiffpowereffPower *)*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) unddem 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. 1Nach 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] undder aktuellen Geschwindigkeit des Spielers ab.

dplayerSpeeentinertiaMommomenteffMoment

*1


TurnNeck (angle)HeadDirection ist relativ zum KörperSichtwinkel 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 fangenVoraussetzung: Ball ist in der catchableArea und

Torwart ist im StrafraumFangversuch 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


Berechnung der Bewegung

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

tx

ty

tx

ty

tx aaranddecayvvvv

Geschwindigkeit = alte Geschwindigkeit* Dämpfungsfaktor

* zufällige Verfälschung + Beschleunigung


Berechnung der Position

Kollisionsbehandlung:wenn am Ende der Berechnung zwei Objekte überlappen1. Objekte so positioniert, dass sie sich nicht überlappen2. 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




i. Body Sensor Modellii. Visual Sensor Modelliii. 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


Visual SensorVisual Sensor des Spielers erfasst visuelle Informationen über das Spielfeld

z.B. Distanz und Richtung zu verschiedenen Objektenim 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 Modelvisuelle 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 DistanzDirection: Richtung des Objekts relativ zur Blickrichtung

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

Wenn das bewegliche Objekt ein anderer Spieler ist, zusätzlich:BodyDir: Richtung des Körpers relativ zum eigenen KörperHeadDir: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 SpielersSichtfeld (view_angle) und Wahrnehmungsfrequenz (view_frequency) können beeinflusst werden durch:

(change_view Width Quality)Width: narrow | normal | wideQuality: 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 genauStörung wird mit zunehmender Entfernung größerbis zu 10% Fehler bei der übermittelten Entfernungtendenzielle Überschätzung


Aural Sensorempfängt Nachrichten vom Schiedsrichter, den Trainern und den anderen SpielernNachrichten werden durch den say-Befehl gebroadcastetNachrichten werden sofort empfangen


hear-Message(hear Time Sender „Message“)

time: aktueller ZyklusSender: 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 vermeidenerreichen 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 –Messagesgoal_Side_n kick_off_OSidefoul_Side free_kick_OSidetime_up time_overhalf_time before_kick_off…

Nachrichten des Schiedsrichters kommen immer bei allen Spielern an


Agenda

3. Problemstellung der Soccer-Gruppen1. Herausforderungen2. Vorführung eines SimpleClients


HerausforderungenEntwicklung 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 erhaltenenKommandos 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 SpielsituationenUnterprobleme:

Optimale Nutzung der 100ms-ZyklenHeuristiken für z.B. Schussverhalten aufstellen


Agenda

3. Problemstellung der Soccer-Gruppen1. Herausforderungen2. Vorführung eines SimpleClients


Vorführung eines SimpleClientsImplementierung des SimpleClients:

Ball und Tor suchen (und hoffentlich finden)in Richtung des Balles drehenzum Ball hinrennenauf das rechte Tor schießen


Agenda

3. Problemstellung der Soccer-Gruppen4. Fazit


FazitProbleme:

PerformanceKonkurrierende EntwicklergemeindeSchlechte DokumentationNoch geringes Interesse der Öffentlichkeit (Deadlinks, fehlende Aktualität)Fehlersuche (Debugging)


FazitChancen:

Möglichkeit, spielerisch komplexe Gebiete der Informatik zu erschließenWachsendes Interesse in der ÖffentlichkeitAgenten-Implementierung programmiersprachen-unabhängigGute Verzahnung von Forschung und Wirtschaft (z.B. Sony, sgi, …)


Fragen?Und nicht vergessen...13. - 19. Juli 2005: RoboCup in Osaka13. - 19. Juni 2006:RoboCup in Bremen(!)

http://www.robocup.org/games/31.html

http://www.robocup2005.jp/

seminar: agenten in simulierten umgebungen 1 soccer server robocup vortrag im rahmen des seminars:...

Documents