Your SlideShare is downloading. ×
Vorstellung des Roboterfußball-Teams TORF (Ausarbeitung)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Vorstellung des Roboterfußball-Teams TORF (Ausarbeitung)

298

Published on

Diese Ausarbeitung stellt das Oldenburger Roboterfußball-Team TORF vor. In einem Grundlagenteil wird zunächst die Domäne des Roboterfußballs vorgestellt und das notwendige Grundlagenwissen vermittelt. …

Diese Ausarbeitung stellt das Oldenburger Roboterfußball-Team TORF vor. In einem Grundlagenteil wird zunächst die Domäne des Roboterfußballs vorgestellt und das notwendige Grundlagenwissen vermittelt. Daraufhin folgt der eigentliche Schwerpunkt dieser Ausarbeitung in dem die grundlegende Architektur und dessen Komponenten vorgestellt werden. In einzelnen Abschnitten wird der Entwurf und die Funktionsweise der Komponenten vorgestellt. Die Ausarbeitung schließt mit einem Fazit in dem mögliche Erweiterungen diskutiert werden.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
298
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Vorstellung des Roboterfußball-Teams TORF Johannes Diemke Carl von Ossietzky Universit¨t Oldenburg a Department f¨r Informatik u Abteilung Lehr- und Lernsysteme 26111 Oldenburg, Deutschland Zusammenfassung Diese Ausarbeitung stellt das Oldenburger Robo- terfußball-Team TORF vor. In einem Grundlagenteil wird zun¨chst die a Dom¨ne des Roboterfußballs vorgestellt und das notwendige Grundla- a genwissen vermittelt. Daraufhin folgt der eigentliche Schwerpunkt dieser Ausarbeitung in dem die grundlegende Architektur und dessen Kompo- nenten vorgestellt werden. In einzelnen Abschnitten wird der Entwurf und die Funktionsweise der Komponenten vorgestellt. Die Ausarbeitung schließt mit einem Fazit in dem m¨gliche Erweiterungen diskutiert wer- o den.1 EinleitungZielsetzung der im WS 2009/2010 angebotenen Projektgruppe Oldenburger Ro-bot Soccer Team der Abteilung Lernende und Kognitive Systeme des Depart-ments f¨r Informatik ist die Verbesserung des bestehenden Roboterfußball-- uTeams TORF f¨r die 2D-Simulationsliga und die Teilnahme an der RoboCup uGerman Open 2010. Dazu kann und soll auf die Vorarbeiten der ProjektgruppeTORF (Team Oldenburger Robo-Fußball) zur¨ckgegriffen werden, die uber den u ¨Zeitraum von Anfang Oktober 2007 bis Ende September 2008 stattfand und mitdem Preis Beste PG des Jahres“ ausgezeichnet wurde [5]. ” Um das vorhandene Roboterfußball-Team verbessern zu k¨nnen, m¨ssen o uzum einen unterschiedliche KI-Techniken (Bayes-Netze, Planung, ReinforcementLearning usw.) angewendet und evaluiert werden, andererseits muss dar¨beruhinaus zun¨chst die Architektur und Funktionsweise des vorhandenen Teams averstanden werden, um dessen F¨higkeiten aber auch dessen Restriktionen im aHinblick auf eventuelle zuk¨nftige Erweiterungen oder Anpassungen bewerten uzu k¨nnen. Ohne dieses Wissen wird es nur schwer m¨glich sein, Schw¨chen des o o avorhandenen Teams zu identifizieren und Verbesserungspotential zu erkennen. In dieser Ausarbeitung soll daher die Projektgruppe TORF vorgestellt und ¨eine Ubersicht uber deren Vorarbeiten gegeben werden. ¨2 GrundlagenDas folgende Kapitel beschreibt die Grundlagen f¨r diese Arbeit. Zun¨chst soll u abegr¨ndet werden, weshalb der Roboterfußball einen besonderen Pr¨fstein f¨r u u u
  • 2. die Methoden der K¨nstlichen Intelligenz darstellt. Daraufhin wird die 2D- uSimulationsliga des RoboCup vorgestellt. Weiterhin findet eine Klassifikationder Arbeitsumgebung statt aus der sich viele der sp¨teren Anforderungen an die aSpieler-Agenten ergeben.2.1 Vom Computerschach zum RoboterfußballClaude E. Shannon, ein amerikanischer Mathematiker und Begr¨nder der In- uformationstheorie, schlug 1950 in seinem Artikel Programming a Computer for ”Playing Chess“ im Philosophical Magazine vor, einen Automaten zu program-mieren der in der Lage ist, einen Menschen im Schach zu schlagen. Dieses Pro-blem galt fortan als Pr¨fstein f¨r neu entwickelte Verfahren und besch¨ftigte u u aWissenschaftler auf der ganzen Welt. Aus der Motivation des schachspielendenComputers entstanden in der K¨nstlichen Intelligenz Spielstrategien mit leis- utungsf¨higen Lernstrategien und Suchverfahren. a Doch schon bevor im Jahr 1996 der von IBM entwickelte SupercomputerDeep Blue gegen den damals amtierenden Schachweltmeister Garri Kasparovgewann wurde schnell klar, dass Computerschach kein Richtmaß mehr f¨r die uLeistung der aus der K¨nstlichen Intelligenz hervorgehenden Verfahren war [2]. uDaher entwickelte sich 1995 Roboterfußball zu einem der Standardprobleme derK¨nstlichen Intelligenz. Dieser erlaubte es insbesondere auch neuere Entwick- ulungstendenzen, bei denen der Robotik ein h¨herer Stellenwert zukam, zu be- or¨cksichtigen [6]. u Roboterfußball stellt eine Herausforderung f¨r die Robotik sowie die K¨nst- u uliche Intelligenz dar. Beim Roboterfußball treten im Gegensatz zum Computer-schach v¨llig andere Aspekte in den Vordergrund. So muss in einer realen oder osimulierten und dynamischen Umgebung agiert werden. Insbesondere m¨ssen uauf Grundlage h¨ufig unvollst¨ndiger Informationen Entscheidungen in Echtzeit a agetroffen werden und auf unvorhersehbare Ereignisse reagiert werden. Roboterfußball besitzt zudem neben den f¨r die Forschung interessanten Ei- ugenschaften noch weitere Vorteile. Fußball ist eine popul¨re Sportart die viele aMenschen begeistert. Er erlaubt es somit Ergebnisse aus der KI-Forschung auchLaien nahe zu bringen. Weiterhin ist das Regelwerk einem großen Bev¨lkerungs- oteil gel¨ufig und es lassen sich die Leistungen unterschiedlicher Forschungsgrup- apen durch einfache Metriken wie die Platzierung in einem Wettbewerb oder dieAnzahl der geschossenen Tore messen [5]. Durch den Wettkampf verschiedener Teams wird die Evolution der verschie-denen Teams vorangetrieben. Im Folgenden soll genauer auf einen dieser Wett-k¨mpfe eingegangen werden: dem RoboCup. a2.2 Der RoboCupDie in den 90er Jahren gegr¨ndete internationale RoboCup-Initiative veranstal- utet seit 1997 den RoboCup, eine j¨hrlich ausgetragene Weltmeisterschaft im Ro- aboterfußball. In dieser messen sich die Roboterfußball-Teams diverser Forscher-gruppen und Studenten aus der ganzen Welt im Roboterfußball in verschiede-
  • 3. nen Ligen [6]. In Deutschland findet zudem j¨hrlich die RoboCup German Open astatt an der die Projektgruppe Oldenburger Robot Soccer Team eine Teilnah-me anstrebt. Die Motivation hinter solchen Wettk¨mpfen ist es die Entwicklung astetig voranzutreiben mit dem Ziel bis zum Jahr 2050 den amtierenden mensch-lichen Weltmeister in einem gew¨hnlichen Fußball-Spiel zu besiegen. Neben die- osen Wettk¨mpfen werden parallel auf einem Kongress Erfahrungen und wissen- aschaftliche Erkenntnisse aus den Bereichen K¨nstliche Intelligenz und Robotik uausgetauscht. Da die Zielsetzung der Projektgruppe Oldenburger Robot Soccer Team dieVerbesserung des bestehenden Roboterfußball-Teams ist, wird im folgenden Ka-pitel nur die RoboCup 2D-Simulationsliga vorgestellt.2.3 Die 2D-SimulationsligaIn der RoboCup 2D-Simulationsliga treten zwei Teams mit jeweils 11 autonomenSpielern in einem Fußballspiel gegeneinander an. Zudem kann jedes Team w¨h- arend des Spiels von genau einem ebenfalls autonomen Coach und im Trainings-modus von einem autonomen Trainer unterst¨tzt werden. Dies alles geschieht udabei rein virtuell auf dem sogenannten RoboCup Soccer Simulator Server, wel-cher die Umgebung simuliert und mit dem alle Spieler kommunizieren. Jederder Spieler sowie der Coach und Trainer sind dabei ein Computerprogramm,das in einem jeweils eigenen Prozess gestartet wird und die Eigenschaften einesSoftware-Agenten erf¨llt. Ein Software-Agent ist dabei nach Russell und Norvig uwie folgt definiert: [6].Definition 1. Als Agent kann alles angesehen werden, was seine Umwelt durchSensoren wahrnimmt und durch Effektoren beeinflusst.Da bei einem RoboCup Soccer Team der 2D-Simulationsliga mehrere Software-Agenten kollektiv ein Problem l¨sen handelt es sich um ein Multiagentensystem. oDie autonomen Spieler versuchen dabei durch ein m¨glichst gezieltes Zusammen- ospiel das Fußballspiel zu gewinnen. Die 2D-Simulationsliga zeichnet sich dabei durch eine hoch dynamische Um-gebung aus, in der sich Spieler mit einer lokal stark eingeschr¨nkten Wahrneh- amung und einer eingeschr¨nkten Kommunikation mit anderen Spielern zurecht- afinden m¨ssen. Konkret bedeutet dies, dass in der Simulation ber¨cksichtigt u uwird, dass Spieler bei h¨heren Entfernungen Distanzen ungenauer absch¨tzen, o aein Spieler nur ein beschr¨nktes Sichtfeld besitzt und die Energiereserven eines aSpielers von seinen Aktivit¨ten auf dem Spielfeld abh¨ngen. a a Die 2D-Simulationsliga hat aber auch einige Vorteile gegen¨ber den ande- uren Ligen. Da es sich um eine reine Simulation handelt wird hier von m¨gli- ochen Problemen der Robotik, Mechanik und Sensorik abstrahiert. So kann derSchwerpunkt auf der Anwendung und Evaluation der Methoden der K¨nstlichen uIntelligenz gelegt werden [5].
  • 4. 2.4 Der RoboCup Soccer SimulatorDer RoboCup Soccer Simulator stellt gem¨ß der Client-Server-Architektur einen aServer dar, der als Dienst die Simulation der Umgebung der 2D-Simulationsligaanbietet. In diesem Kontext sind die Spieler-Agenten sowie der Coach- undTrainer-Agent die Clients. Teil des Simulations-Dienstes ist bspw. die Verwal-tung aller Spieler, des Balls und deren Positionen auf dem Spielfeld sowie dieSimulation einer einfachen Physik. Weiterhin simuliert er die visuelle und audi-tive Wahrnehmung eines jeden Spieler-Agenten. Dazu m¨ssen sich die Agenten uzun¨chst bei dem Server anmelden. Nach einer erfolgreichen Anmeldung erhal- aten alle Agenten vom Server Informationen uber die von ihnen wahrgenommene ¨Umgebung. F¨r die Spieler-Agenten ist die Umgebung nur partiell beobacht- ubar, w¨hrend f¨r Trainer- und Coach-Agenten diese jedoch vollst¨ndig beob- a u aachtbar ist. Der Soccer Simulator simuliert diese Beschr¨nkungen indem er dem aSpieler-Agenten nicht alle Informationen zusendet und zus¨tzlich Daten k¨nst- a ulich verrauscht. Auf Grundlage der so erhaltenen Informationen entscheiden dieSpieler-Agenten welche Aktion als n¨chstes ausgef¨hrt werden soll und teilen a udiese dem Server mit. Dazu stehen den Agenten diverse Kommandos zur Verf¨- ugung mit denen diese dem Server mitteilen k¨nnen, welche Aktion auszuf¨hren o uist. Allerdings werden auch an dieser Stelle die Aktionen des Spielers nicht exaktausgef¨hrt sondern wieder k¨nstlich mit einer Ungenauigkeit versehen [5]. u u Die Kommunikation der Agenten mit dem RoboCup Soccer Simulator findetuber sogenannte S-Expressions statt. Dabei kommt das UDP/IP-Protokoll zum¨Einsatz. Das Protokoll dieser Kommunikation und weitere Details lassen sichdem RoboCup Soccer Simulator Manual [1] entnehmen.2.5 Klassifikation der ArbeitsumgebungIm Folgenden soll die Arbeitsumgebung der verschiedenen Agenten-Typen derRoboCup 2D-Simulationsliga zun¨chst nach der von Russell und Norvig ent- awickelten PEAS-Beschreibung klassifiziert werden. PEAS ist ein Akronym f¨r uLeistungsbewertung (Performance), Umgebung (Environment), Aktuatoren (Ac-tuators) und Sensoren (Sensors). Die dieser Beschreibung zugrundeliegende Ideeist, dass ein Agent immer im Kontext einer Arbeitsumgebung existiert. Die Be-schreibung der Umgebung zusammen mit der Beschreibung der Sensoren, Ak-tuatoren und der Leistungsbewertung ergibt eine vollst¨ndige Beschreibung der aArbeitsumgebung und stellt eine M¨glichkeit dar Agenten zu charakterisieren o[4]. Nachdem die Arbeitsumgebung vollst¨ndig beschrieben wurde, kann anschlie- aßend eine Umgebungsklassifikation anhand der folgenden Eigenschaften erfolgen: – vollst¨ndig vs. teilweise beobachtbar a – deterministisch vs. stochastisch – episodisch vs. sequentiell – statisch vs. dynamisch – diskret vs. stetig
  • 5. – Einzelagenten vs. Multiagenten-UmgebungDie Beschreibung der Arbeitsumgebung sowie deren Klassifikation dient der Ab-leitung erste Anforderungen die an einen Software-Agenten gestellt werden. Da gravierende Unterschiede zwischen Spieler, Coach und Trainer bzgl. ihrerArbeitsumgebung bestehen, muss deren Beschreibung der Arbeitsumgebung undanschließende Umgebungsklassifikation getrennt vorgenommen werden. Bspw. istdie Umgebung f¨r die Spieler-Agenten nur partiell beobachtbar und teilweise ver- urauscht, w¨hrend f¨r den Trainer- und Coach-Agenten die Umgebung vollst¨ndig a u abeobachtbar ist. Dies resultiert dann auch in unterschiedlichen Anforderungen,die an diese Agenten-Typen gestellt werden. In Tabelle 1 wird die Beschreibungder Arbeitsumgebungen f¨r die in der 2D-Simulationsliga beteiligten Agenten- uTypen tabellarisch dargestellt.Agententyp Leistungsbewer- Umgebung Aktuatoren Sensoren tungSpieler Stabilit¨t, Ge- a RoboCup Spielerkomman- Sehen und schwindigkeit, Soccer Server dos (dash, turn, H¨ren o kongruentes say, . . . ) VerhaltenTrainer Stabilit¨t, a RoboCup change mode, Spielfeld¨ber- u Geschwindigkeit Soccer Server move, start, say, sicht (im Trainings- ... modus)Coach Stabilit¨t, a RoboCup say, look, eyes, Spielfeld¨ber- u Geschwindigkeit Soccer Server team names, sicht ...Tabelle 1. Beschreibung der Agenten-Typen anhand ihrer Arbeitsumgebungen nachdem PEAS-Ansatz von Russell und Norvig [5]. Die Umgebungsklassifikation soll nun f¨r den Spieler-Agenten exemplarisch uvorgenommen werden. Da diesem die Arbeitsumgebung (das Fußballfeld und al-le beteiligten Agenten) aufgrund seines beschr¨nkten Sichtfeldes und ungenauen aAbsch¨tzungen von Entfernungen (simuliert durch das Verrauschen der Daten adurch den RoboCup Soccer Simulator) nur teilweise bekannt ist handelt es sichum eine partiell beobachtbare Umgebung. Weiterhin h¨ngt der Folgezustand ader Umgebung nicht nur vom momentanen Zustand und der Aktion des Agen-ten ab. Daher ist die Umgebung nicht deterministisch sondern stochastisch. DieUmgebung ist zudem sequentiell, da aktuelle Entscheidungen eines Agenten alleweiteren Entscheidungen beeinflussen k¨nnen. Die Arbeitsumgebung kann sich oa¨ndern, w¨hrend der Agent eine Entscheidung trifft, was sie dynamisch macht. aWeiterhin versucht der RoboCup Soccer Simulator mit diskreten Werten einekontinuierliche Arbeitsumgebung zu simulieren, so dass diese als simuliert ste-
  • 6. tig aufgefasst werden kann. Da die Spieler-Agenten mit allen weiteren Agentenihres Teams in Interaktion stehen, handelt es sich um eine Multiagentenumge-bung. Abschließend kann also zusammengefasst werden, dass der Spieler-Agentsich in einer teilweise beobachtbaren, stochastischen, sequentiellen, dynamischenund simuliert stetigen Multiagenten-Umgebung befindet [5]. Diese Klassifikation l¨sst nun schon erste Schl¨sse bez¨glich der Anforderun- a u ugen an einen Spieler-Agenten zu. So bedingt die nur teilweise Beobachtbarkeitder Arbeitsumgebung die Verwaltung eines inneren Zustandes (Weltmodells) auf-grund dessen fehlend Informationen abgeleitet werden k¨nnen. Da die Arbeit- osumgebung weiterhin stochastisch ist, k¨nnen keine absoluten Aussagen uber o ¨m¨gliche Folgezust¨nde der Umgebung nach Ausf¨hrung einer Aktion getrof- o a ufen werden. Aussagen uber zuk¨nftige Zust¨nde basieren dadurch vielmehr auf ¨ u aWahrscheinlichkeiten. Weiterhin ist die Arbeitsumgebung sequentiell was dazuf¨hrt, dass der Spieler-Agent auch vorausdenken k¨nnen muss. Die dynamische u oArbeitsumgebung bedingt, dass sich diese ¨ndern kann noch w¨hrend der Spieler- a aAgent eine Entscheidung trifft. Es handelt sich also um eine ¨ußerst schwierige aHandlungsumgebung die der Komplexit¨t der realen Welt sehr nahe kommt. a2.6 Der Spieler als modellbasierter Reflex-AgentWie bereits in Abschnitt 2.5 angef¨hrt, macht die nur teilweise Beobachtbarkeit uder Arbeitsumgebung die Verwaltung eines Zustandes (Weltmodells) f¨r den uSpieler-Agenten notwendig. F¨r ein solches Szenario eignet sich nach Russell und uNorvig [4] ein wie in Abbildung 1 dargestellter modellbasierter Reflex-Agent.Abbildung 1. Die schematische Darstellung eines modellbasierten Reflex-Agentennach Russell und Norvig [4]. Wie der Abbildung zu entnehmen ist, besitzt ein modellbasierter Reflex-Agent einen internen Zustand, der im Folgenden als Weltmodell bezeichnet wird.
  • 7. Dieses Weltmodell verwaltet sowohl den eigenen Zustand als auch den der Um- gebung. Die Auswahl der auszuf¨hrenden Aktionen kann so in Abh¨ngigkeit von u a dem aktuellen Perzept sowie dem Zustand des Weltmodells geschehen. Da die Sensoren des Agenten immer nur Ausschnitte der Umgebung zug¨nglich machen, a m¨ssen diese so in das Weltmodell eingepflegt werden, dass ein konsistentes Ge- u samtbild der Umgebung entsteht. Daher muss ein Agenten auch dazu in der Lage sein, die Entwicklung der Umgebung abzusch¨tzen, selbst wenn diese f¨r ihn nur a u teilweise beobachtbar ist. Weiterhin muss der Agent auch die Auswirkungen sei- ner eigenen Aktionen auf die Umgebung absch¨tzen k¨nnen [4]. a o Die grundlegende Funktionsweise eines solchen Agenten ist denkbar einfach. Zun¨chst wird das uber die Sensorik des Spieler-Agenten erhaltene Perzept in a ¨ das Weltmodell eingepflegt. Anschließend wird auf Grundlage des so erhaltenen Weltmodells ein Entscheidungsfindungsprozess angestoßen der die auszuf¨hrende u Aktion bestimmt. Listing 1.1 verdeutlicht dies mittels Pseudocode.1 function REFLEX - AGENT - WITH - STATE ( percept ) returns action2 static : state , Beschreibung des aktuellen Zustands der Welt3 rules , Menge von Bedingung / Aktion - Regeln45 state ← UPDATE - STATE ( state , percept )6 rule ← RULE - MATCH ( state , rules )7 action ← RULE - ACTION [ rule ]8 state ← UPDATE - STATE ( state , action )910 return action Listing 1.1. Programm eines modellbasierten Reflex-Agenten nach Russell und Norvig [4] Im Verlauf der Projektgruppe TORF wurde zun¨chst von einem modellba- a sierten Reflex-Agenten ausgegangen der sich jedoch mit der Zeit in seiner Be- schaffenheit einem ziel- und nutzenbasierten Agenten ann¨herte. a 3 Vorarbeiten der PG TORF In den vorangegangenen Abschnitten wurden zun¨chst die f¨r die Entwicklung ei- a u nes Roboterfußball-Teams der 2D-Simulationsliga relevanten Grundlagen behan- delt. In diesem Abschnitt sollen nun die Vorarbeiten der Projektgruppe TORF vorgestellt werden. Dazu soll zun¨chst das Komponentenmodell der Spieler- a Agenten vorgestellt werden. Darauf aufbauend folgt dann die Vorstellung der einzelnen Komponenten. Wie sich zeigen wird, lassen sich viele der Entwurfsent- scheidungen aus den zuvor behandelten Grundlagen ableiten. 3.1 Das Komponentenmodell Im Folgenden soll das nach [5] f¨r die Spieler-Agenten verwendete Komponen- u tenmodell, welches eine erste Grobarchitektur darstellt, vorgestellt und ein erster ¨ Uberblick uber dessen Komponenten gegeben werden. Abbildung 2 zeigt die in ¨ ihm enthalten Komponenten und deren Datenfluss.
  • 8. Architektur des Spieler-Agenten RoboCup Spieler-Agent Soccer Message- Simulator Parser Broker (RCSS) Kommunikation Com- World- UDP Planner Ponent Model Wm- Facade Gene- SkillManager rator & Skills Datenfluss -- Projektgruppe TORF – Universität Oldenburg • Fakultät II • Department für Informatik • Abteilung LLS  / Abbildung 2. Die Komponenten eines Spieler-Agenten und deren Datenfluss [5]. Wie der Abbildung zu entnehmen ist, kommuniziert ein Spieler-Agent mitdem RoboCup Soccer Simulator welcher dessen Arbeitsumgebung simuliert. DieKommunikation ist bidirektional, da der Agent zum einen Sensordaten von demSimulator erh¨lt, andererseits aber auch selbst Kommandos an diesen sendet. aDie UDP-Komponente dient dazu diese Kommunikation zu kapseln, so dass di-rekt mit S-Expressions gearbeitet werden kann. Die uber die UDP-Komponenten ¨empfangenen S-Expressions werden an die Parser-Komponente weitergeleitet de- ¨ren Zweck die Uberf¨hrung der S-Expressions in eine interne Repr¨sentation u a(Message-Objekte) der Nachrichten ist. Ausgehende Nachrichten werden uber die ¨Generator-Komponente zun¨chst in S-Expressions uberf¨hrt bevor sie uber die a ¨ u ¨UDP-Komponente an den Simulator gesendet werden. Alle vom Server eingehen-den Nachrichten werden nach ihrer Umwandlung in Message-Objekte zun¨chst avon der Message-Broker-Komponente entgegengenommen und von dort aus ver-teilt. Da es sich bei den meisten Nachrichten um Perzepte der Sensoren handelt,werden Nachrichten-Objekte i.d.R. an die Weltmodell-Komponenten weiterge-leitet, wo sie dann eingepflegt werden. In dem Fall, dass sich der Umweg uber ¨das Weltmodell nachteilig auswirken w¨rde, werden einige wenige sehr dringen- ude Nachrichten vom Message-Broker direkt an die Planer-Komponente weiterge-reicht. Die Weltmodell-Komponente kapselt den Zustand des Spielers und dessenUmgebung wie in Kapitel 2.6 beschrieben. Die Planer-Komponente kapselt denebenfalls aus Kapitel 2.6 bekannten Entscheidungsfindungsprozess in dem aufBasis des Weltmodells durchzuf¨hrende Aktionen, im Folgenden auch Skills ge- unannt, ausgew¨hlt und an die Skill-Manager-Komponente weitergereicht werden. aDie Skill-Manager-Komponente sorgt daf¨r, dass die Skills ausgef¨hrt werden u uund ubergibt sie an die Generator-Komponente, die sie in S-Expressions uber- ¨ ¨f¨hrt und anschließend mittels der UDP-Komponente an den Simulator sendet. uDie Bezeichnung Com-Ponent“ ist ein Wortspiel und steht f¨r Kommunikations- u ”
  • 9. Komponente. Sie erm¨glicht es den Spieler-Agenten untereinander zu kommuni- ozieren um so komplexe Taktiken abzusprechen. Ein in diesem Komponentenmodell h¨ufig verwendetes Konzept ist das eines aTransformators. Ein Transformator befindet sich jeweils zwischen zwei Kompo-nenten und f¨hrt notwendige Transformationen der Daten durch. Ein in der uAbbildung explizit hervorgehobener Transformator ist die Wm-Facade uber die ¨andere Komponenten auf das Weltmodell zugreifen k¨nnen.o Weiterhin ist anzumerken, dass es von Vorteil ist den Agenten in parallel lau-fende Prozesse aufzuteilen. Bspw. sollte es m¨glich sein Nachrichten asynchron ouber die UDP-Komponente zu empfangen und zu versenden. Daher wurden be-¨reits einige Komponenten so entworfen, dass sie parallel in eigenen Threads ar-beiten.3.2 Der Message-BrokerDer Message-Broker ist f¨r die Verteilung der vom Server eingehenden Message- uObjekte zust¨ndig. Jede Nachricht besitzt dabei einen Typ. Komponenten die asich f¨r spezielle Nachrichtentypen interessieren, k¨nnen sich f¨r diese bei dem u o uMessage-Broker registrieren und werden fortan uber neu eingehende Nachrichten ¨diesen Typs informiert. Konkret wird dies umgesetzt, indem Objekte die Nach-richten erhalten wollen das MessageBrokerListener-Interface implementieren undsich dann beim MessageBroker f¨r einen oder alle Nachrichtentypen registrieren u[5].3.3 Das WeltmodellDas Weltmodell ist eine wichtige Komponente des Spieler-Agenten auf dessenGrundlage im Entscheidungsfindungsprozess die vom Agenten auszuf¨hrenden uAktionen ausgew¨hlt werden. Dabei muss das Weltmodell nicht nur den Ist- aZustand der Arbeitsumgebung kennen sondern auch Dynamikwissen besitzenanhand dessen sich das Verhalten von transient nicht beobachtbaren Objektenabsch¨tzen l¨sst. Weicht das Weltmodell zu sehr von der tats¨chlichen Arbeit- a a asumgebung des Agenten ab, so werden falsche Entscheidungen getroffen. Dahermuss die Arbeitsumgebung des Agenten im Weltmodell m¨glichst korrekt ab- ogebildet werden. Es m¨ssen insbesondere Strategien gefunden werden, die es uerm¨glichen aus den verrauschten Sensordaten des RoboCup Soccer Simulators om¨glichst exakte Sch¨tzungen der tats¨chlichen Werte zu erhalten [5]. o a a Grundlegende Anforderungen an das Weltmodell sind zun¨chst das Erfas- asen der eigenen Position sowie die Erfassung der anderen Spieler und des Balls.Dazu wurden zun¨chst die unterschiedlichen Entit¨ten (Spieler, Spielfeld, Ball a ausw.) des Weltmodells als Klassen modelliert. Die Instanzen dieser Entit¨ten im aWeltmodell m¨ssen st¨ndig anhand der vom Simulator ubermittelten Informa- u a ¨tionen uber die wahrgenommene Umgebung aktualisiert werden. Daher meldet ¨sich zun¨chst ein MessageBrokerListener f¨r alle relevanten Nachrichten bei dem a u
  • 10. Message-Broker an. Dieser MessageBrokerListener teilt sich mit dem Weltmo-dell eine Warteschlange mit Message-Objekten, so dass diese vom Weltmodellverarbeitet werden k¨nnen. o Das Weltmodell modelliert sowohl statische als auch dynamische Objekte. Zuden statischen Objekten geh¨ren bspw. Flaggen anhand derer die eigene Position olokalisiert werden kann. Diese sind entlang der Spiefeldbegrenzung aufgestellt.Dynamische Objekte sind die Spieler und der Ball. Diese unterliegen einer Ver¨n- aderung und lassen sich durch eine gerichtete Geschwindigkeit und eine Positionbeschreiben. Weiterhin werden von dem Weltmodell Spielinformationen wie derPunktestand oder die Spielphase erfasst. Andere Komponenten k¨nnen dabei ouber eine Fassade Zust¨nde des Weltmodells elegant abfragen.¨ a Die Bestimmung der eigenen Position geschieht anhand der Winkel und Ent-fernungen der f¨r den Spieler sichtbaren Flaggen. Da Flaggen statische Objekte usind, k¨nnen aus ihnen R¨ckschl¨sse uber die eigene Position gezogen werden. o u u ¨Dabei wird zwischen zwei F¨llen unterschieden. Im ersten Fall ist genau eine aFlagge sichtbar w¨hrend im zweiten Fall mindestens zwei Flaggen sichtbar sein am¨ssen. Die so erhaltenen Positionen sind aufgrund der verrauschten Sensorda- uten des RoboCup Soccer Simulators verf¨lscht. Die Entfernungen zu statischen asowie dynamischen Objekte werden vom Simulator n¨mlich wie Abbildung 3.3 averdeutlicht mit einem Entfernungsrauschen versehen. Abbildung 3. Ideale und verrauschte Entfernungsangaben vom Server [5]. Um die Verf¨lschung zu verringern, werden im Fall von mindestens zwei Flag- agen m¨glichst viele unterschiedliche Flaggenpaare zusammengestellt um aus die- osen mehrere Positions-Samples zu bestimmen. Um jetzt eine m¨glichst exak- ote Sch¨tzung der tats¨chlichen Positionen zu erhalten, werden diese Positions- a a
  • 11. Samples durch das [sic] Kalman-Filter gegl¨ttet. Sieht der Agent gar keine Flag- age, so wird die aktuelle Position rein uber die Dynamik des Kalman Filters ¨bestimmt. Speziell f¨r Debugging-Zwecke wurde eine grafische Darstellung der im Welt- umodell abgebildeten Informationen entwickelt. Mit dieser l¨sst sich in Echtzeit adie Genauigkeit der vom Weltmodell erfassten Informationen mit denen der tat-s¨chlich simulierten Arbeitsumgebung des RoboCup Simulators vergleichen. So alassen sich schnell große Abweichungen zwischen diesen erkennen. Es hat sichw¨hrend der Entwicklung gezeigt, dass eine grafische Darstellung ein einfaches aund effektives Hilfsmittel ist, um Fehlinterpretationen fr¨hzeitig zu erkennen. u3.4 PlanerDer Planer ist eine weitere zentrale Komponente des Spieler-Agenten, welche denEntscheidungsfindungsprozess umsetzt und so f¨r die Festlegung der Strategie uund das Starten geeigneter Skills zust¨ndig ist. Der Planer ist dabei die Umset- azung eines hierarchischen Planers der dazu in der Lage ist, komplexe Aufgaben inkleinschrittiger zu zerlegen und diese dadurch besser handhabbar macht. Dabeimuss der Planer mit vielen der anderen Komponenten kommunizieren. Bspw.ben¨tigt er Informationen von dem Weltmodell, auf dessen Grundlage Entschei- odungen bzgl. des Planungsvorganges getroffen werden. Weiterhin muss der Pla-ner dem Skillmanager Skills ubergeben und ihn dazu veranlassen k¨nnen, diese ¨ ozu starten. Der Planer ben¨tigt f¨r die hierarchische Dekomposition komplexer o uAufgaben Dom¨nenwissen, das in einer Planerdatenbank vorliegt. Dazu wurde aein Werkzeug entwickelt, das es erm¨glicht Planerdatenbanken zu erstellen und ozu editieren. Eine wichtige Zielsetzung des Planers war es auch, dass er dazuin der Lage ist, Strategien, die koordinierte Handlungsabl¨ufe mehrerer Spieler aerfordern, umzusetzen [5]. Die Umsetzung des Planalgorithmus orientiert sich weitestgehend an dem in[3] vorgestellten Verfahren. Abbildung 4 zeigt die Architektur des Planers sowiean dem Planvorgang beteiligte Komponenten. Im Planer findet der eigentliche Planungsvorgang statt. W¨hrend des Plan- avorgangs wird uber eine Facade auf das Weltmodell zugegriffen um so auf dessen ¨Grundlage Entscheidungen zu treffen. Er greift weiterhin auf das in der Planer-datenbank enthaltende Dom¨nenmodell zu, das in Form eines Baumes vorliegt aund startet an dessen Wurzel, indem er diese auf dem Planerstack ablegt. An-hand der vom Weltmodell bekannten Literale entscheidet der Planer nun wie mitdem obersten Element des Planerstacks weiter verfahren werden soll. Ist dieseAufgabe wie im beschriebenen Fall eine zusammengesetzte Aufgabe, so findeteine Zerlegung mittels des Kindknotens dieser Aufgabe statt deren Vorbedin-gung erf¨llt ist. Stimmen die Vorbedingungen mehrerer Zerlegungen, so wird ueine zuf¨llige Zerlegung vom Planer gew¨hlt. Die zu einer Zerlegung geh¨renden a a oTeilaufgaben werden anschließend auf dem Planstack abgelegt. Ist eine solcheTeilaufgabe primitiv so wird sie direkt vom Planer ausgef¨hrt. Zusammengesetz- ute Aufgaben werden stattdessen weiter vom Planer zerlegt. Das Ausf¨hren einer u
  • 12. Messages Com start Skill state (via literals) Planner Worldmodel push / status select method pop play soccer free kick offensiv defensive normal play set piece Database offensiv play soccer Stack ¨ Abbildung 4. Ubersicht uber die Planer-Architektur [5]. ¨primitiven Aufgabe geschieht uber den Skill-Manager der den zu ihr geh¨ren- ¨ oden Skill direkt ausf¨hrt. Aufgaben die abgearbeitet wurden oder fehlgeschlagen usind werden vom Stack gel¨scht. Weiterhin uberpr¨ft der Planer in regelm¨ßigen o ¨ u aZeitabst¨nden, ob die Invarianten der einzelnen Aufgaben erf¨llt sind. Ist dies a unicht der Fall, so werden alle Aufgaben ab der Aufgabe deren Invariante nichterf¨llt ist, vom Stack entfernt und der Planungsvorgang beginnt von neuem [5]. u3.5 SkillsDie Skill-Komponente realisiert die grundlegenden spielerischen Fertigkeiten ei-nes Spieler-Agenten. Diese Fertigkeiten werden auch Skills genannt. Sie bestim-men den Handlungsspielraum eines Spieler-Agenten w¨hrend eines Spiels. Der aSpieler-Agent nimmt aktiv am Spielgeschehen teil indem er hintereinander oderauch parallel eine Folge von Skills ausf¨hrt. Die Planung dieser Abfolge und das uStarten der Skills ubernimmt wie bereits aus Abschnitt 3.4 bekannt der Planer. ¨Dieser erm¨glicht es insbesondere Skills auf Teamebene, die komplexe Inter- oaktionen zwischen den Spielern umfassen und sich nicht nur auf einen Spielerbeschr¨nken, umzusetzen. a Skills werden von dem sogenannten Skill-Manager verwaltet. Dieser k¨mmert usich um das Erzeugen, Ausf¨hren, Stoppen und L¨schen der Skills. Der Planer u oinitiiert das Ausf¨hren der Skills indem er dem Skill-Manager mitteilt wann und uin welcher Reihenfolge von diesem die Skills ausgef¨hrt werden sollen. Außerdem ukann dieser den Skill-Manager anweisen einen laufenden Skill abzubrechen. Eswerden zwei Arten von Skills unterschieden: Primitive und komplexe Skills. Pri-mitive Skills sind Skills f¨r die es direkt ein Pendant in Form eines Kommandos uan den RoboCup Soccer Simulator gibt. Sie lassen sich nicht weiter zerlegen undk¨nnen auch nicht direkt vom Planer aufgerufen werden. Skills die andere Skills oaufrufen heißen komplexe Skills und k¨nnen im Gegensatz zu primitiven Skills odirekt von Planer ausgef¨hrt werden. u
  • 13. Jeder Skill muss eine doAction() Methode implementieren in der das Ver-halten des Skills implementiert wird. Die primitiven Skills dienen lediglich alsContainer-Klassen um die vom RoboCup Soccer Simulator angebotenen atoma-ren Kommandos mit denen das Spielerverhalten gesteuert werden kann in derWarteschlange des Generators einreihen zu k¨nnen. Sie beinhalten daher keine ospezielle Ausf¨hrungslogik und ihre Hauptaufgabe ist die Kapselung der zuge- uh¨rigen S-Expression. Daher sind sie auch nicht weiter zerlegbar. Beispielsweise overanlasst der primitive Kick-Skill den Spieler den Ball mit einer bestimmtenKraft und Richtung zu schießen. Die Menge der komplexen Skills ist weitaus umfangreicher als die der primiti-ven Skills. Die komplexen Skills sind zumeist h¨ndisch implementiert. Darunter af¨llt bspw. der Kick2Pos-Skill dessen Aufgabe es ist den Ball mit einer bestimm- aten Geschwindigkeit an eine Position zu schießen. Seine generische Implementie-rung erlaubt es den Skill sowohl f¨r harte Torsch¨sse als auch zum Passen des u uBalls einzusetzen. Es hat sich gezeigt, dass es h¨ufig nicht trivial ist komplexe Skills h¨ndisch a azu implementieren. Daher bietet es sich insbesondere bei Skills an Lernverfahreneinzusetzen. So wurde der Torwart bspw. mittels eines Bayes-Netzes modelliertund trainiert [5].3.6 KommunikationF¨r die Anwendung komplexer Taktiken auf Teamebene m¨ssen Absprachen u uzwischen Spieler-Agenten w¨hrend des Spielgeschehens erm¨glicht werden. Dies a oist daher notwendig, da jeder Spieler-Agent aufgrund der nur teilweise beobacht-baren Umgebung ein eigenes Weltmodell besitzt und einer daraus resultierendenanderen Planung. Bei bspw. einem Passspiel werden aber ganz bestimme Rollenben¨tigt die kooperativ handeln. Daher muss in einem solchen Fall der ballf¨h- o urende Spieler dem gew¨nschten Empf¨nger zuvor mitteilen, dass ein Pass statt- u afinden soll. Dies bedingt die Notwendigkeit einer Kommunikations-Komponente.Da das Kommunikationsmodell des RoboCup Soccer Simulators jedoch einigenBeschr¨nkungen unterliegt m¨ssen sinnvolle Strategien gefunden werden um mit a udiesen umgehen zu k¨nnen. o Spieler-Agenten k¨nnen Nachrichten von den Online-Coaches, vom Schieds- orichter oder einem anderen Spieler-Agenten erhalten. Allerdings empf¨ngt ein aSpieler nicht jede Nachricht. So beschr¨nkt der Simulator die Kommunikati- aon indem es bspw. eine maximale Entfernung zwischen Sender und Empf¨nger agibt bis zu der eine Nachricht noch wahrgenommen werden kann. Dem Spieler-Agenten selbst stehen spezielle Kommandos f¨r die Kommunikation zur Verf¨- u ugung. So kann der Spieler Nachrichten eingeschr¨nkter L¨nge versenden. Diese a am¨ssen jedoch uber einem vorgegebenem Alphabet gebildet werden damit sie u ¨nicht verworfen werden. Mittels eines weiteren Kommandos kann der Spieler sei-ne Aufmerksamkeit bzgl. der auditiven Wahrnehmung auf einen anderen Spielerfokussieren. Dies ist notwendig, da ein Spieler-Agent pro Simulations-Zyklus nurdie jeweils erste an ihn versendete Nachricht wahrnimmt. Es existieren somitverschiedene Situation in denen es zu einem Verlust von Nachrichten kommen
  • 14. kann und so das Spielgeschehen negativ beeinflussen k¨nnen. Es muss also ein oKommunikations-Protokoll entwickelt werden, das diese Restriktionen ber¨ck- usichtigt [1]. Das letztendlich implementierte Verfahren teilt das Kommunikationsnetz inCluster mit jeweils einem Router auf und versucht durch Zeitmultiplexing Kol-lisionen zwischen Nachrichten zu vermeiden [5]. Da die Kommunikations-Kom-ponente im Verlauf der Projektgruppe allerdings keinen vollst¨ndig funktions- af¨higen Status erreicht hat, soll im Folgenden nicht n¨her auf dessen Imple- a amentierung eingegangen werden. Eine Aufgabe wird es daher sein m¨ssen das ubestehende Protokoll auf dessen Korrektheit zu uberpr¨fen und gegebenenfalls ¨ ualternative Protokolle zu entwerfen die anschließend implementiert und bzgl.ihrer Leistungsf¨higkeit evaluiert werden. a3.7 Das Trainer- und Coach-FrameworkDa sich der Trainer und der Coach nur durch ihr Verhalten w¨hrend eines Spiels abzw. Trainings unterscheiden ansonsten aber architektonisch gleichen sind sieals eine einzige Applikation implementiert. Das Trainerprogramm kann sich beidem RoboCup Soccer Simulator als Trainer oder Coach anmelden. Gemeinsamhaben beide die Art und Weise wie sie mit dem RoboCup Soccer Simulator kom-munizieren, ein gemeinsames Weltmodell der f¨r sie vollst¨ndig beobachtbaren u aUmgebung sowie ein spezielles Kommunikationsprotokoll zur Kommunikationmit den Spieler-Agenten [5]. Abbildung 5 zeigt die Grobarchitektur des Trai-ners. Abbildung 5. Die Grobarchitektur des Trainers nach einer Sternarchitektur [5]. Wie der Abbildung zu entnehmen ist, stellt der Trainer das Zentrum ei-ner Sternarchitektur dar. Zum Einen k¨nnen sich bei ihm verschiedene Spieler- oAgenten anmelden, zum Anderen aber auch Lerntechniken (KI-Module) uber ¨welche die angemeldeten Spieler-Agenten trainiert werden sollen. Weiterhin ist
  • 15. der Trainer mit dem RoboCup Soccer Simulator verbunden. Von diesem erh¨lt er aunverf¨lschte Umgebungsdaten und kann direkt Einfluss auf die Simulation neh- amen, um gezielt Trainingssituationen hervorzurufen. Am Training unbeteiligteSpieler-Agenten sind lediglich am Simulations-Server angemeldet. Eine wichtigeEigenschaft ist die Austauschbarkeit von Lerntechniken. Abbildung 6 zeigt dasKomponentenmodell des Trainers und des Coaches. Architektur des Trainer-Agenten BasicCoach RCSS-Server WorldModel Controller Message- Broker Trainer-Agent Coach-Agent Learning- XML-Situation Player-Types … Technique Spieler-Agent Trainee/LT Datenfluss Vererbung -- Projektgruppe TORF – Universität Oldenburg • Fakultät II • Department für Informatik • Abteilung LLS  / Abbildung 6. Komponentenmodell des Trainers und des Coaches. Diesem ist zu entnehmen, dass beide dem Aufbau eines Spieler-Agenten ah- ¨neln. Beide besitzen einen Message-Broker, ein Weltmodell sowie einen Control-ler. Der Message-Broker ist f¨r die Kommunikation mit dem RoboCup Soccer uSimulator zust¨ndig. Das Weltmodell ist f¨r die Verwaltung der vollst¨ndig be- a u aobachtbaren Umgebung zust¨ndig. Von besonderer Bedeutung ist die Controller- aKomponente. Sie initialisiert und verwaltet die anderen Komponenten und im-plementiert das Verhalten von Trainer und Coach. Der Trainer erweitert die-se gemeinsamen Komponenten um eine spezielle Lerntechnik-Komponente mitwelcher die Spieler trainiert werden k¨nnen. Weiterhin ist der Abbildung zu ent- onehmen, dass auch die Spieler-Agenten eine Komponente f¨r die entsprechende uLerntechnik implementieren m¨ssen, uber die der Trainer direkt Einfluss auf den u ¨Planvorgang des Spielers nehmen kann um so bspw. gewisse Trainingssituationengezielt zu wiederholen [5]. Zur Durchf¨hrung eines Trainings verbindet sich der Trainer zun¨chst uber u a ¨den Message-Broker zum RoboCup Soccer Simulator. Danach initialisiert er diegew¨nschte Lerntechnik und wartet bis sich f¨r die entsprechende Lernart und u uTechnik ausreichend viele Spieler registriert haben. Das Training l¨uft so ab, dass azun¨chst Instruktionen an die teilnehmenden Spieler-Agenten gesendet werden. aDer Trainer beobachtet w¨hrend des Trainings die Spieler und deren Verhal- aten. Am Ende einer Trainingsrunde empf¨ngt dieser dann die von den Spieler- a
  • 16. Agenten gesammelten Daten und wertet diese anhand seiner eigenen unverf¨lsch- aten Daten aus. Aufgrund dieser Ergebnisse k¨nnen anschließend in weiteren Trai- oningsrunden neue Instruktionen erzeugt werden. Sobald ein Training beendetwurde werden die so erhaltenen Daten gesichert. Die in einem Training an dieSpieler-Agenten gesendeten Instruktionen sind dabei abh¨ngig von der konkret averwendeten Lerntechnik. Weiterhin ist der Trainer in der Lage im XML-Formatgespeicherte Spielsituationen zu Trainingszwecken zu laden und Spieler und Ballentsprechend zu positionieren [5]. Die Aufgabe des Coaches ist momentan einzig und allein die Vergabe derSpielertypen. Der RoboCup Soccer Simulator weist den Spieler-Agenten stan-dardm¨ßig einen von 18 zuf¨lligen generierten Spielertypen zu. Die so zugewie- a asenen Spielertypen sind allerdings i. d. R. nicht optimal auf die Rollen der Spielerzugeschnitten. Daher hat der Coach die M¨glichkeit vor Spielbeginn den Spie- olertypen eines jeden Spielers entsprechend seiner Rolle zu ¨ndern. Es wurde ein aData-Mining durchgef¨hrt um so eine optimale Heuristik f¨r die Verteilung der u uSpielertypen auf die verschiedenen Rollen durchzuf¨hren. Dazu wurde die Wahl uder Spielertypen bei erfolgreichen Mannschaften durchgef¨hrt. u3.8 HilfsprogrammeIm Verlauf der Projektgruppe wurden einige entwicklungsunterst¨tzende Werk- uzeuge erstellt. Zu diesen z¨hlt das TORF Strategy Tool sowie eine Sammlung akleinerer Skripte und Programme die unter dem Namen LogfileAnalysis zusam-mengefasst werden. Trotz des f¨r Menschen lesbaren XML-Formats ist die manuelle Erstellung uder Planerdatenbank ann¨hernd unm¨glich und unkomfortabel. Dies liegt un- a oter anderem daran, dass die Serialisierung mittels der Boost-Bibliothek f¨r den uSerialisierungsprozess ben¨tigte Metadaten hinzuf¨gt. Weiterhin lassen sich um- o ufangreiche Planerdatenbanken textuell nur schwer erfassen. Da das Verhalten unddie Effizienz eines Spieler-Agenten aber maßgeblich von dem Umfang des mo-dellierten Dom¨nenwissens abh¨ngt, muss diesem besonders Rechnung getragen a awerden. Daher wurde das TORF Strategy Tool entwickelt mit dem Planerda-tenbanken schnell, komfortabel und ubersichtlich erstellt und gewartet werden ¨sollen. Die hierarchischen Abh¨ngigkeiten einer Zerlegung der Planerdatenbank asollten dementsprechend intuitiv durch eine entsprechende visuelle Darstellungaufbereitet sein und dessen Bearbeitung erlauben. Aus Zeitgr¨nden wurde das uWerkzeug mittels der NetBeans Platform 6.1 entwickelt. Daraus ergab sich je-doch die besondere Herausforderung der Interoperabilit¨t zwischen dem von Java agenerierten Bytecode und dem vom C++ Compiler erzeugten Maschinencode [5]. Das TORF Strategy Tool erlaubt es Tasks, Zerlegungen und die zugeh¨rigen oVorbedingungen und Invarianten in einer grafischen Oberfl¨che zu spezifizie- aren. Dies umfasst auch die die Auswahl von Skills f¨r primitive Tasks und das uSpezifizieren ihrer Parameter. Auch die F¨higkeit des Planers komplexe Tasks aauszuf¨hren muss durch das Werkzeug entsprechend unterst¨tzt werden. Zur u ugrafischen Darstellung der Planerdatenbank wurde ein baumartige Struktur ge-w¨hlt um m¨glichst nah bei der f¨r den Planer verwendeten Datenstruktur zu a o u
  • 17. bleiben. Die so erstellte Planerdaten werden anschließend uber das JNI (Java ¨Native Interface), mittels des Hilfsprogramms SWIG (Simplified Wrapper andInterface Generator), der in C++ implementierten Planerdatenbank ubergeben. ¨Dieser Weg wurde eingeschlagen da das Parsen der durch die Boost-Bibliothekserialisierten Planerdatenbank als zu umst¨ndlich bewertet wurde. Aus dieser aEntwurfsentscheidung resultieren jedoch einige Probleme die bisher nicht immerzufriedenstellend gel¨st werden konnten. Dazu z¨hlt unter anderem das Problem, o adass Objekte die auf C++-Seite konstruiert werden, nicht destruiert werden, umso die Stabilit¨t des TORF Strategie Tools zu gew¨hrleisten. Abbildung 7 zeigt a adas Hauptfenster des Torf Strategy Tools. Abbildung 7. Das Hauptfenster mit der Baumansicht am linken Rand [5]. Eine Idee die allerdings aus Zeitgr¨nden nicht mehr realisiert werden konnte, uwar die grafische Spezifikation von Situationen. Dies bedeutet, dass die Situatio-nen, welche sp¨ter durch Zerlegungen und Vorbedingungen beschrieben werden, adurch ein grafisches Spielfeld und die Anordnung der Spieler auf diesem spezi-fiziert werden. F¨r sp¨tere Implementierungen wurde daher bereits der rechte u aBereich des Hauptfensters freigehalten. Die Machbarkeit dieses Ansatzes sowiedessen Nutzen sollten daher evaluiert werden. Die LogfileAnalyisis genannte Sammlung von kleinen Programmen und Skrip-ten dient dem Einlesen und Auswerten der serverseitig vom RoboCup SoccerSimulator generierten Logdateien. Diese werden vom Simulator automatisch ge-neriert und enthalten den kompletten Spielverlauf eines Spiels. Auch alle of-
  • 18. fiziellen Spiele ab dem Jahr 1997 sind in Form dieser Logdateien im Internetzug¨nglich. Daher sind diese Logdateien pr¨destiniert f¨r Analysezwecke mittels a a uData-Mining. So eignen sich diese Daten f¨r Lernverfahren oder die Analyse des uVerhaltens andere Teams. Daher wurden Python-Skripte entwickelt die unterdem Namen LogfileAnalysis zusammengefasst werden. Diese Skripte umfassendas Einlesen in eine PostgreSQL-Datenbank sowie das Auswerten der Daten. Es existieren diverse Skripte f¨r unterschiedlich Analysemethoden. Dazu z¨h- u alen Datenbank-Statistiken, Feldabdeckunsgsanalysen, Torschussanalysen sowiedie Analyse der Spielertypen. Das Skript f¨r die Datenbank-Statistiken gibt un- uter anderem die Anzahl der gespeicherten Spiele, eine Liste aller Mannschaftenund das Spiel mit maximaler Torzahl aus. Die Feldabdeckungsanalyse dient hingegen dazu herauszuarbeiten wo sichObjekte wie Spieler oder Ball w¨hrend eines Spiels aufhalten. Aus dieser In- aformation lassen sich bspw. Aussagen uber den Aufenthaltsort einzelner Spieler ¨oder Spieltaktiken ableiten. Abbildung 8 zeigt das Ergebnis der Analyse derAufenthaltsorte der Spieler des Teams AT-Humboldt. Abbildung 8. Aufenthaltsorte der Spieler des Teams AT-Humboldt [5]. Die Skript f¨r die Torschussanalyse wertet aus in welchen Situationen Tor- usch¨sse erfolgreich sind. Die so erhaltenen Daten k¨nnen selbst wieder f¨r die u o uOptimierung des eigenen Torschussverhaltens bzw. f¨r die Verbesserung des Tor- uwarts genutzt werden. Die Analyse der Spielertypen wurde bereits in Abschnitt 3.7 angesprochen.Mittels dieses Skripts lassen sich die Spielertypen andere Mannschaften analysie-
  • 19. ren und so die Aufstellung einer Mannschaft ableiten. Aus diesen Daten lassensich wiederum mittels Data-Mining Heuristiken zu Auswahl der Spielertypenableiten [5]. Abschließend l¨sst sich sagen, dass die Logfile-Analyse zum Einen f¨r die a uEntwickler erste Anhaltspunkte uber typische Spielsituationen liefern kann aber ¨auch f¨r Lernverfahren wie Bayes-Netze Evidenzen liefert. Insofern stellt die uLogfile-Analyse ein m¨chtiges Werkzeug dar dem auch zuk¨nftig Aufmerksam- a ukeit gewidmet werden sollte.4 FazitDas Ziel der Projektgruppe Oldenburger Robot Soccer Team ist die Verbesserungdes bestehenden Roboterfußball-Teams TORF. Dabei kann auf den umfangrei-chen Vorarbeiten der Projektgruppe TORF aufgebaut werden. Es wurde in dieser Ausarbeitung zun¨chst auf das dazu n¨tige Grundla- a ogenwissen eingegangen. Unter anderem wurde der RoboCup und dessen 2D-Simulationsliga vorgestellt und anschließend eine Klassifikation der Arbeitsumge-bung der Spieler-Agenten durchgef¨hrt. Dabei wurde festgestellt, dass die Kom- uplexit¨t der Handlungsumgebung der Spieler-Agenten ann¨hernd der Komplexi- a at¨t der realen Welt entspricht. a Im Hauptteil wurden die Vorarbeiten der Projektgruppe TORF vorgestellt.Zun¨chst wurde auf die Architektur der Spieler-Agenten eingegangen welche ei- ane Grobarchitektur darstellt und Ausgangspunkt der weiteren Betrachtungenwar. Der Planer ist bereits voll funktionsf¨hig, allerdings wird sein volles Leis- atungspotenzial aufgrund von fehlendem Dom¨nenwissen in der Planerdatenbank anicht vollst¨ndig ausgesch¨pft. Die im Anschluss vorgestellten Skills stellen die a oGrundfertigkeiten eines jeden Spielers dar und sind zum großen Teil h¨ndisch im- aplementiert. Bei der Entwicklung neuer Skills sollten insbesondere Lernverfahreneingesetzt werden. Die Kommunikations-Komponente spielt eine entscheidendeRolle bei der Umsetzung von Teams-Skills. So m¨ssen mehrere Agenten bspw. ubei einem Passspiel kooperativ Handeln. Zur Absprache wird ein Kommunika-tionsmodell ben¨tigt das mit den Limitationen des RoboCup Soccer Simulators oumgehen kann. Die Kommunikationskomponente ist derzeit nicht vollst¨ndig afunktionsf¨hig. Sie ist allerdings essentiell f¨r die Realisierung von Team-Skills, a udaher sollte ihr vermehrt Aufmerksamkeit gewidmet werden. Insbesondere kannan dieser Stelle auf die theoretischen Vor¨berlegungen der vorangehenden PG uzur¨ckgegriffen werden. Das Trainer- und Coach Framework ist ein einfach gehal- utenes Framework auf dessen Grundlage das Trainerprogramm entwickelt wurde.Mit ihm lassen sich KI-Module zum Trainieren der Spieler entwickeln und nutzen.Weiterhin wurden mehrere Hilfsprogramme und Skripte entwickelt. Das TORFStrategy Tool dient beispielsweise der Erstellung von Planerdatenbanken. Da esallerdings unter enormem Termindruck erstellt wurde ist es sehr einfach gehalten.Daraus resultiert eine noch umst¨ndliche Bearbeitung der Planerdatenbank was aletztendlich auch dazu f¨hrt, dass das in der Planerdatenbank vorhandene Dom¨- u anenwissen nur einen geringen Umfang besitzt. Hinzu kommt, dass die Entwurfs-
  • 20. entscheidung f¨r die Planerdatenbank, die Serialisierung der Boost-Bibliothek uzu nutzen, zu einigen Problemen f¨hrt. Abschließend wurde die Logfile-Analyse uvorgestellt. Diese stellt ein m¨chtiges Werkzeug dar, dass zum Einen f¨r eine a uHeuristik der Spielertyp Zuordnung genutzt wurde aber auch potentiell unter-st¨tzend bei Lernverfahren wie Bayes-Netzen sein kann. uLiteratur[1] Chen, M. ; Forounghi, E. ; Heintz, F. ; Huang, Z. X. ; Kapetanakis, S. ; Kostiadis, K. ; Kummeneje, J. ; Noda, I. ; Obst, O. ; Riley, P. ; Steffens, T. ; Wang, Y. ; Yin, X.: User Manual – RoboCup Soccer Server, for Soccer Server Version 7.07 and later, August 2002. http://sserver. sourceforge.net/docs/manual.pdf, Abruf: 2009-11-15[2] IBM Corporation: Deep Blue. http://www-03.ibm.com/ibm/history/ exhibits/vintage/vintage_4506VV1001.html. Version: 2009, Abruf: 2009-11-15[3] Obst, Oliver ; Boedecker, Joschka: Flexible Coordination of Multiagent Team Behavior Using HTN Planning. In: RoboCup, 2005, S. 521–528[4] Russell, S. ; Norvig, P.: K¨nstliche Intelligenz – Ein moderner Ansatz. 2. u Auflage. Pearson Studium, 2004[5] Sch¨ fer, Andreas ; Ellen, Christian ; Steen, Enno-Edzard ; Jelschen, a Jan ; Lenk, Jan C. ; St¨ ver, Lena ; Sommer, Nils ; Massow, Robert o von ; Eiterig, Simon ; Scherfke, Stefan: Team Oldenburger Robo- Fußball – Abschlussbericht der Projektgruppe / Carl von Ossietzky Universi- t¨t Oldenburg. Version: 2008. http://torf.uni-oldenburg.de/content/ a publications/Abschlussbericht.pdf. 2008. – Forschungsbericht[6] The RoboCup Federation: RoboCup. Version: April 2008. http://www. robocup.org, Abruf: 2009-11-15

×