Vorstellung des Roboterfußball-TeamsTORF

Johannes Diemke

Carl von Ossietzky Universitat OldenburgDepartment fur Informatik

Abteilung Lehr- und Lernsysteme26111 Oldenburg, Deutschland

Zusammenfassung Diese Ausarbeitung stellt das Oldenburger Robo-terfußball-Team TORF vor. In einem Grundlagenteil wird zunachst dieDomane des Roboterfußballs vorgestellt und das notwendige Grundla-genwissen vermittelt. Daraufhin folgt der eigentliche Schwerpunkt dieserAusarbeitung in dem die grundlegende Architektur und dessen Kompo-nenten vorgestellt werden. In einzelnen Abschnitten wird der Entwurfund die Funktionsweise der Komponenten vorgestellt. Die Ausarbeitungschließt mit einem Fazit in dem mogliche Erweiterungen diskutiert wer-den.

1 Einleitung

Zielsetzung der im WS 2009/2010 angebotenen Projektgruppe Oldenburger Ro-bot Soccer Team der Abteilung Lernende und Kognitive Systeme des Depart-ments fur Informatik ist die Verbesserung des bestehenden Roboterfußball--Teams TORF fur die 2D-Simulationsliga und die Teilnahme an der RoboCupGerman Open 2010. Dazu kann und soll auf die Vorarbeiten der ProjektgruppeTORF (Team Oldenburger Robo-Fußball) zuruckgegriffen werden, die uber denZeitraum 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 konnen, mussenzum einen unterschiedliche KI-Techniken (Bayes-Netze, Planung, ReinforcementLearning usw.) angewendet und evaluiert werden, andererseits muss daruberhinaus zunachst die Architektur und Funktionsweise des vorhandenen Teamsverstanden werden, um dessen Fahigkeiten aber auch dessen Restriktionen imHinblick auf eventuelle zukunftige Erweiterungen oder Anpassungen bewertenzu konnen. Ohne dieses Wissen wird es nur schwer moglich sein, Schwachen desvorhandenen Teams zu identifizieren und Verbesserungspotential zu erkennen.

In dieser Ausarbeitung soll daher die Projektgruppe TORF vorgestellt undeine Ubersicht uber deren Vorarbeiten gegeben werden.

2 Grundlagen

Das folgende Kapitel beschreibt die Grundlagen fur diese Arbeit. Zunachst sollbegrundet werden, weshalb der Roboterfußball einen besonderen Prufstein fur

die Methoden der Kunstlichen Intelligenz darstellt. Daraufhin wird die 2D-Simulationsliga des RoboCup vorgestellt. Weiterhin findet eine Klassifikationder Arbeitsumgebung statt aus der sich viele der spateren Anforderungen an dieSpieler-Agenten ergeben.

2.1 Vom Computerschach zum Roboterfußball

Claude E. Shannon, ein amerikanischer Mathematiker und Begrunder der In-formationstheorie, 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 Prufstein fur neu entwickelte Verfahren und beschaftigteWissenschaftler auf der ganzen Welt. Aus der Motivation des schachspielendenComputers entstanden in der Kunstlichen Intelligenz Spielstrategien mit leis-tungsfahigen Lernstrategien und Suchverfahren.

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 fur dieLeistung der aus der Kunstlichen Intelligenz hervorgehenden Verfahren war [2].Daher entwickelte sich 1995 Roboterfußball zu einem der Standardprobleme derKunstlichen Intelligenz. Dieser erlaubte es insbesondere auch neuere Entwick-lungstendenzen, bei denen der Robotik ein hoherer Stellenwert zukam, zu be-rucksichtigen [6].

Roboterfußball stellt eine Herausforderung fur die Robotik sowie die Kunst-liche Intelligenz dar. Beim Roboterfußball treten im Gegensatz zum Computer-schach vollig andere Aspekte in den Vordergrund. So muss in einer realen odersimulierten und dynamischen Umgebung agiert werden. Insbesondere mussenauf Grundlage haufig unvollstandiger Informationen Entscheidungen in Echtzeitgetroffen werden und auf unvorhersehbare Ereignisse reagiert werden.

Roboterfußball besitzt zudem neben den fur die Forschung interessanten Ei-genschaften noch weitere Vorteile. Fußball ist eine populare Sportart die vieleMenschen begeistert. Er erlaubt es somit Ergebnisse aus der KI-Forschung auchLaien nahe zu bringen. Weiterhin ist das Regelwerk einem großen Bevolkerungs-teil gelaufig und es lassen sich die Leistungen unterschiedlicher Forschungsgrup-pen 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-kampfe eingegangen werden: dem RoboCup.

2.2 Der RoboCup

Die in den 90er Jahren gegrundete internationale RoboCup-Initiative veranstal-tet seit 1997 den RoboCup, eine jahrlich ausgetragene Weltmeisterschaft im Ro-boterfußball. In dieser messen sich die Roboterfußball-Teams diverser Forscher-gruppen und Studenten aus der ganzen Welt im Roboterfußball in verschiede-

nen Ligen [6]. In Deutschland findet zudem jahrlich die RoboCup German Openstatt an der die Projektgruppe Oldenburger Robot Soccer Team eine Teilnah-me anstrebt. Die Motivation hinter solchen Wettkampfen ist es die Entwicklungstetig voranzutreiben mit dem Ziel bis zum Jahr 2050 den amtierenden mensch-lichen Weltmeister in einem gewohnlichen Fußball-Spiel zu besiegen. Neben die-sen Wettkampfen werden parallel auf einem Kongress Erfahrungen und wissen-schaftliche Erkenntnisse aus den Bereichen Kunstliche Intelligenz und Robotikausgetauscht.

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-Simulationsliga

In der RoboCup 2D-Simulationsliga treten zwei Teams mit jeweils 11 autonomenSpielern in einem Fußballspiel gegeneinander an. Zudem kann jedes Team wah-rend des Spiels von genau einem ebenfalls autonomen Coach und im Trainings-modus von einem autonomen Trainer unterstutzt werden. Dies alles geschiehtdabei 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 erfullt. Ein Software-Agent ist dabei nach Russell und Norvigwie 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 losen handelt es sich um ein Multiagentensystem.Die autonomen Spieler versuchen dabei durch ein moglichst gezieltes Zusammen-spiel 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 eingeschrankten Wahrneh-mung und einer eingeschrankten Kommunikation mit anderen Spielern zurecht-finden mussen. Konkret bedeutet dies, dass in der Simulation berucksichtigtwird, dass Spieler bei hoheren Entfernungen Distanzen ungenauer abschatzen,ein Spieler nur ein beschranktes Sichtfeld besitzt und die Energiereserven einesSpielers von seinen Aktivitaten auf dem Spielfeld abhangen.

Die 2D-Simulationsliga hat aber auch einige Vorteile gegenuber den ande-ren Ligen. Da es sich um eine reine Simulation handelt wird hier von mogli-chen Problemen der Robotik, Mechanik und Sensorik abstrahiert. So kann derSchwerpunkt auf der Anwendung und Evaluation der Methoden der KunstlichenIntelligenz gelegt werden [5].

2.4 Der RoboCup Soccer Simulator

Der RoboCup Soccer Simulator stellt gemaß der Client-Server-Architektur einenServer 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 mussen sich die Agentenzunachst bei dem Server anmelden. Nach einer erfolgreichen Anmeldung erhal-ten alle Agenten vom Server Informationen uber die von ihnen wahrgenommeneUmgebung. Fur die Spieler-Agenten ist die Umgebung nur partiell beobacht-bar, wahrend fur Trainer- und Coach-Agenten diese jedoch vollstandig beob-achtbar ist. Der Soccer Simulator simuliert diese Beschrankungen indem er demSpieler-Agenten nicht alle Informationen zusendet und zusatzlich Daten kunst-lich verrauscht. Auf Grundlage der so erhaltenen Informationen entscheiden dieSpieler-Agenten welche Aktion als nachstes ausgefuhrt werden soll und teilendiese dem Server mit. Dazu stehen den Agenten diverse Kommandos zur Verfu-gung mit denen diese dem Server mitteilen konnen, welche Aktion auszufuhrenist. Allerdings werden auch an dieser Stelle die Aktionen des Spielers nicht exaktausgefuhrt sondern wieder kunstlich mit einer Ungenauigkeit versehen [5].

Die Kommunikation der Agenten mit dem RoboCup Soccer Simulator findetuber sogenannte S-Expressions statt. Dabei kommt das UDP/IP-Protokoll zumEinsatz. Das Protokoll dieser Kommunikation und weitere Details lassen sichdem RoboCup Soccer Simulator Manual [1] entnehmen.

2.5 Klassifikation der Arbeitsumgebung

Im Folgenden soll die Arbeitsumgebung der verschiedenen Agenten-Typen derRoboCup 2D-Simulationsliga zunachst nach der von Russell und Norvig ent-wickelten PEAS-Beschreibung klassifiziert werden. PEAS ist ein Akronym furLeistungsbewertung (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 vollstandige Beschreibung derArbeitsumgebung und stellt eine Moglichkeit dar Agenten zu charakterisieren[4].

Nachdem die Arbeitsumgebung vollstandig beschrieben wurde, kann anschlie-ßend eine Umgebungsklassifikation anhand der folgenden Eigenschaften erfolgen:

– vollstandig vs. teilweise beobachtbar– deterministisch vs. stochastisch– episodisch vs. sequentiell– statisch vs. dynamisch– diskret vs. stetig

– Einzelagenten vs. Multiagenten-Umgebung

Die 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 fur die Spieler-Agenten nur partiell beobachtbar und teilweise ver-rauscht, wahrend fur den Trainer- und Coach-Agenten die Umgebung vollstandigbeobachtbar ist. Dies resultiert dann auch in unterschiedlichen Anforderungen,die an diese Agenten-Typen gestellt werden. In Tabelle 1 wird die Beschreibungder Arbeitsumgebungen fur die in der 2D-Simulationsliga beteiligten Agenten-Typen tabellarisch dargestellt.

Agententyp Leistungsbewer-tung

Umgebung Aktuatoren Sensoren

Spieler Stabilitat, Ge-schwindigkeit,kongruentesVerhalten

RoboCupSoccer Server

Spielerkomman-dos (dash, turn,say, . . . )

Sehen undHoren

Trainer Stabilitat,Geschwindigkeit

RoboCupSoccer Server(im Trainings-modus)

change mode,move, start, say,. . .

Spielfelduber-sicht

Coach Stabilitat,Geschwindigkeit

RoboCupSoccer Server

say, look, eyes,team names,. . .

Spielfelduber-sicht

Tabelle 1. Beschreibung der Agenten-Typen anhand ihrer Arbeitsumgebungen nachdem PEAS-Ansatz von Russell und Norvig [5].

Die Umgebungsklassifikation soll nun fur den Spieler-Agenten exemplarischvorgenommen werden. Da diesem die Arbeitsumgebung (das Fußballfeld und al-le beteiligten Agenten) aufgrund seines beschrankten Sichtfeldes und ungenauenAbschatzungen von Entfernungen (simuliert durch das Verrauschen der Datendurch den RoboCup Soccer Simulator) nur teilweise bekannt ist handelt es sichum eine partiell beobachtbare Umgebung. Weiterhin hangt der Folgezustandder 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 konnen. Die Arbeitsumgebung kann sichandern, wahrend der Agent eine Entscheidung trifft, was sie dynamisch macht.Weiterhin versucht der RoboCup Soccer Simulator mit diskreten Werten einekontinuierliche Arbeitsumgebung zu simulieren, so dass diese als simuliert ste-

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 lasst nun schon erste Schlusse bezuglich der Anforderun-gen 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 konnen. Da die Arbeit-sumgebung weiterhin stochastisch ist, konnen keine absoluten Aussagen ubermogliche Folgezustande der Umgebung nach Ausfuhrung einer Aktion getrof-fen werden. Aussagen uber zukunftige Zustande basieren dadurch vielmehr aufWahrscheinlichkeiten. Weiterhin ist die Arbeitsumgebung sequentiell was dazufuhrt, dass der Spieler-Agent auch vorausdenken konnen muss. Die dynamischeArbeitsumgebung bedingt, dass sich diese andern kann noch wahrend der Spieler-Agent eine Entscheidung trifft. Es handelt sich also um eine außerst schwierigeHandlungsumgebung die der Komplexitat der realen Welt sehr nahe kommt.

2.6 Der Spieler als modellbasierter Reflex-Agent

Wie bereits in Abschnitt 2.5 angefuhrt, macht die nur teilweise Beobachtbarkeitder Arbeitsumgebung die Verwaltung eines Zustandes (Weltmodells) fur denSpieler-Agenten notwendig. Fur ein solches Szenario eignet sich nach Russell undNorvig [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.

Dieses Weltmodell verwaltet sowohl den eigenen Zustand als auch den der Um-gebung. Die Auswahl der auszufuhrenden Aktionen kann so in Abhangigkeit vondem aktuellen Perzept sowie dem Zustand des Weltmodells geschehen. Da dieSensoren des Agenten immer nur Ausschnitte der Umgebung zuganglich machen,mussen diese so in das Weltmodell eingepflegt werden, dass ein konsistentes Ge-samtbild der Umgebung entsteht. Daher muss ein Agenten auch dazu in der Lagesein, die Entwicklung der Umgebung abzuschatzen, selbst wenn diese fur ihn nurteilweise beobachtbar ist. Weiterhin muss der Agent auch die Auswirkungen sei-ner eigenen Aktionen auf die Umgebung abschatzen konnen [4].

Die grundlegende Funktionsweise eines solchen Agenten ist denkbar einfach.Zunachst wird das uber die Sensorik des Spieler-Agenten erhaltene Perzept indas Weltmodell eingepflegt. Anschließend wird auf Grundlage des so erhaltenenWeltmodells ein Entscheidungsfindungsprozess angestoßen der die auszufuhrendeAktion 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 -Regeln4

5 state ← UPDATE -STATE(state , percept)6 rule ← RULE -MATCH(state , rules)7 action ← RULE -ACTION[rule]8 state ← UPDATE -STATE(state , action)9

10 return action

Listing 1.1. Programm eines modellbasierten Reflex-Agenten nach Russell undNorvig [4]

Im Verlauf der Projektgruppe TORF wurde zunachst von einem modellba-sierten Reflex-Agenten ausgegangen der sich jedoch mit der Zeit in seiner Be-schaffenheit einem ziel- und nutzenbasierten Agenten annaherte.

3 Vorarbeiten der PG TORF

In den vorangegangenen Abschnitten wurden zunachst die fur die Entwicklung ei-nes Roboterfußball-Teams der 2D-Simulationsliga relevanten Grundlagen behan-delt. In diesem Abschnitt sollen nun die Vorarbeiten der Projektgruppe TORFvorgestellt werden. Dazu soll zunachst das Komponentenmodell der Spieler-Agenten vorgestellt werden. Darauf aufbauend folgt dann die Vorstellung dereinzelnen 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] fur die Spieler-Agenten verwendete Komponen-tenmodell, welches eine erste Grobarchitektur darstellt, vorgestellt und ein ersterUberblick uber dessen Komponenten gegeben werden. Abbildung 2 zeigt die inihm enthalten Komponenten und deren Datenfluss.

!""#-$"-!! /!!Projektgruppe TORF – Universität Oldenburg • Fakultät II • Department für Informatik • Abteilung LLS

Architektur des Spieler-Agenten

%

RoboCupSoccer

Simulator(RCSS)

Spieler-Agent

Kommun

ikation

UDP

Parser Message-Broker

PlannerWorld-Model

Gene-rator

SkillManager& Skills

Wm-Facade

Datenfluss

Com-Ponent

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 erhalt, andererseits aber auch selbst Kommandos an diesen sendet.Die UDP-Komponente dient dazu diese Kommunikation zu kapseln, so dass di-rekt mit S-Expressions gearbeitet werden kann. Die uber die UDP-Komponentenempfangenen S-Expressions werden an die Parser-Komponente weitergeleitet de-ren Zweck die Uberfuhrung der S-Expressions in eine interne Reprasentation(Message-Objekte) der Nachrichten ist. Ausgehende Nachrichten werden uber dieGenerator-Komponente zunachst in S-Expressions uberfuhrt bevor sie uber dieUDP-Komponente an den Simulator gesendet werden. Alle vom Server eingehen-den Nachrichten werden nach ihrer Umwandlung in Message-Objekte zunachstvon 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 uberdas Weltmodell nachteilig auswirken wurde, werden einige wenige sehr dringen-de 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 durchzufuhrende Aktionen, im Folgenden auch Skills ge-nannt, ausgewahlt und an die Skill-Manager-Komponente weitergereicht werden.Die Skill-Manager-Komponente sorgt dafur, dass die Skills ausgefuhrt werdenund ubergibt sie an die Generator-Komponente, die sie in S-Expressions uber-fuhrt und anschließend mittels der UDP-Komponente an den Simulator sendet.Die Bezeichnung

”Com-Ponent“ ist ein Wortspiel und steht fur Kommunikations-

Komponente. Sie ermoglicht es den Spieler-Agenten untereinander zu kommuni-zieren um so komplexe Taktiken abzusprechen.

Ein in diesem Komponentenmodell haufig verwendetes Konzept ist das einesTransformators. Ein Transformator befindet sich jeweils zwischen zwei Kompo-nenten und fuhrt notwendige Transformationen der Daten durch. Ein in derAbbildung explizit hervorgehobener Transformator ist die Wm-Facade uber dieandere Komponenten auf das Weltmodell zugreifen konnen.

Weiterhin ist anzumerken, dass es von Vorteil ist den Agenten in parallel lau-fende Prozesse aufzuteilen. Bspw. sollte es moglich sein Nachrichten asynchronuber 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-Broker

Der Message-Broker ist fur die Verteilung der vom Server eingehenden Message-Objekte zustandig. Jede Nachricht besitzt dabei einen Typ. Komponenten diesich fur spezielle Nachrichtentypen interessieren, konnen sich fur diese bei demMessage-Broker registrieren und werden fortan uber neu eingehende Nachrichtendiesen Typs informiert. Konkret wird dies umgesetzt, indem Objekte die Nach-richten erhalten wollen das MessageBrokerListener-Interface implementieren undsich dann beim MessageBroker fur einen oder alle Nachrichtentypen registrieren[5].

3.3 Das Weltmodell

Das Weltmodell ist eine wichtige Komponente des Spieler-Agenten auf dessenGrundlage im Entscheidungsfindungsprozess die vom Agenten auszufuhrendenAktionen ausgewahlt werden. Dabei muss das Weltmodell nicht nur den Ist-Zustand der Arbeitsumgebung kennen sondern auch Dynamikwissen besitzenanhand dessen sich das Verhalten von transient nicht beobachtbaren Objektenabschatzen lasst. Weicht das Weltmodell zu sehr von der tatsachlichen Arbeit-sumgebung des Agenten ab, so werden falsche Entscheidungen getroffen. Dahermuss die Arbeitsumgebung des Agenten im Weltmodell moglichst korrekt ab-gebildet werden. Es mussen insbesondere Strategien gefunden werden, die esermoglichen aus den verrauschten Sensordaten des RoboCup Soccer Simulatorsmoglichst exakte Schatzungen der tatsachlichen Werte zu erhalten [5].

Grundlegende Anforderungen an das Weltmodell sind zunachst das Erfas-sen der eigenen Position sowie die Erfassung der anderen Spieler und des Balls.Dazu wurden zunachst die unterschiedlichen Entitaten (Spieler, Spielfeld, Ballusw.) des Weltmodells als Klassen modelliert. Die Instanzen dieser Entitaten imWeltmodell mussen standig anhand der vom Simulator ubermittelten Informa-tionen uber die wahrgenommene Umgebung aktualisiert werden. Daher meldetsich zunachst ein MessageBrokerListener fur alle relevanten Nachrichten bei dem

Message-Broker an. Dieser MessageBrokerListener teilt sich mit dem Weltmo-dell eine Warteschlange mit Message-Objekten, so dass diese vom Weltmodellverarbeitet werden konnen.

Das Weltmodell modelliert sowohl statische als auch dynamische Objekte. Zuden statischen Objekten gehoren bspw. Flaggen anhand derer die eigene Positionlokalisiert werden kann. Diese sind entlang der Spiefeldbegrenzung aufgestellt.Dynamische Objekte sind die Spieler und der Ball. Diese unterliegen einer Veran-derung und lassen sich durch eine gerichtete Geschwindigkeit und eine Positionbeschreiben. Weiterhin werden von dem Weltmodell Spielinformationen wie derPunktestand oder die Spielphase erfasst. Andere Komponenten konnen dabeiuber eine Fassade Zustande des Weltmodells elegant abfragen.

Die Bestimmung der eigenen Position geschieht anhand der Winkel und Ent-fernungen der fur den Spieler sichtbaren Flaggen. Da Flaggen statische Objektesind, konnen aus ihnen Ruckschlusse uber die eigene Position gezogen werden.Dabei wird zwischen zwei Fallen unterschieden. Im ersten Fall ist genau eineFlagge sichtbar wahrend im zweiten Fall mindestens zwei Flaggen sichtbar seinmussen. Die so erhaltenen Positionen sind aufgrund der verrauschten Sensorda-ten des RoboCup Soccer Simulators verfalscht. Die Entfernungen zu statischensowie dynamischen Objekte werden vom Simulator namlich wie Abbildung 3.3verdeutlicht mit einem Entfernungsrauschen versehen.

Abbildung 3. Ideale und verrauschte Entfernungsangaben vom Server [5].

Um die Verfalschung zu verringern, werden im Fall von mindestens zwei Flag-gen moglichst viele unterschiedliche Flaggenpaare zusammengestellt um aus die-sen mehrere Positions-Samples zu bestimmen. Um jetzt eine moglichst exak-te Schatzung der tatsachlichen Positionen zu erhalten, werden diese Positions-

Samples durch das [sic] Kalman-Filter geglattet. Sieht der Agent gar keine Flag-ge, so wird die aktuelle Position rein uber die Dynamik des Kalman Filtersbestimmt.

Speziell fur Debugging-Zwecke wurde eine grafische Darstellung der im Welt-modell abgebildeten Informationen entwickelt. Mit dieser lasst sich in Echtzeitdie Genauigkeit der vom Weltmodell erfassten Informationen mit denen der tat-sachlich simulierten Arbeitsumgebung des RoboCup Simulators vergleichen. Solassen sich schnell große Abweichungen zwischen diesen erkennen. Es hat sichwahrend der Entwicklung gezeigt, dass eine grafische Darstellung ein einfachesund effektives Hilfsmittel ist, um Fehlinterpretationen fruhzeitig zu erkennen.

3.4 Planer

Der Planer ist eine weitere zentrale Komponente des Spieler-Agenten, welche denEntscheidungsfindungsprozess umsetzt und so fur die Festlegung der Strategieund das Starten geeigneter Skills zustandig ist. Der Planer ist dabei die Umset-zung 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.benotigt er Informationen von dem Weltmodell, auf dessen Grundlage Entschei-dungen bzgl. des Planungsvorganges getroffen werden. Weiterhin muss der Pla-ner dem Skillmanager Skills ubergeben und ihn dazu veranlassen konnen, diesezu starten. Der Planer benotigt fur die hierarchische Dekomposition komplexerAufgaben Domanenwissen, das in einer Planerdatenbank vorliegt. Dazu wurdeein Werkzeug entwickelt, das es ermoglicht Planerdatenbanken zu erstellen undzu editieren. Eine wichtige Zielsetzung des Planers war es auch, dass er dazuin der Lage ist, Strategien, die koordinierte Handlungsablaufe mehrerer Spielererfordern, 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. Wahrend des Plan-vorgangs wird uber eine Facade auf das Weltmodell zugegriffen um so auf dessenGrundlage Entscheidungen zu treffen. Er greift weiterhin auf das in der Planer-datenbank enthaltende Domanenmodell zu, das in Form eines Baumes vorliegtund 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 erfullt ist. Stimmen die Vorbedingungen mehrerer Zerlegungen, so wirdeine zufallige Zerlegung vom Planer gewahlt. Die zu einer Zerlegung gehorendenTeilaufgaben werden anschließend auf dem Planstack abgelegt. Ist eine solcheTeilaufgabe primitiv so wird sie direkt vom Planer ausgefuhrt. Zusammengesetz-te Aufgaben werden stattdessen weiter vom Planer zerlegt. Das Ausfuhren einer

play soccer

offensiv

set piece

free kick

start Skill

Messages

state (via literals)

select methodstatus

push /

pop

play soccer

offensiv

defensive normal play

Planner

Com

Worldmodel

Database

Stack

Abbildung 4. Ubersicht uber die Planer-Architektur [5].

primitiven Aufgabe geschieht uber den Skill-Manager der den zu ihr gehoren-den Skill direkt ausfuhrt. Aufgaben die abgearbeitet wurden oder fehlgeschlagensind werden vom Stack geloscht. Weiterhin uberpruft der Planer in regelmaßigenZeitabstanden, ob die Invarianten der einzelnen Aufgaben erfullt sind. Ist diesnicht der Fall, so werden alle Aufgaben ab der Aufgabe deren Invariante nichterfullt ist, vom Stack entfernt und der Planungsvorgang beginnt von neuem [5].

3.5 Skills

Die 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 wahrend eines Spiels. DerSpieler-Agent nimmt aktiv am Spielgeschehen teil indem er hintereinander oderauch parallel eine Folge von Skills ausfuhrt. Die Planung dieser Abfolge und dasStarten der Skills ubernimmt wie bereits aus Abschnitt 3.4 bekannt der Planer.Dieser ermoglicht es insbesondere Skills auf Teamebene, die komplexe Inter-aktionen zwischen den Spielern umfassen und sich nicht nur auf einen Spielerbeschranken, umzusetzen.

Skills werden von dem sogenannten Skill-Manager verwaltet. Dieser kummertsich um das Erzeugen, Ausfuhren, Stoppen und Loschen der Skills. Der Planerinitiiert das Ausfuhren der Skills indem er dem Skill-Manager mitteilt wann undin welcher Reihenfolge von diesem die Skills ausgefuhrt werden sollen. Außerdemkann dieser den Skill-Manager anweisen einen laufenden Skill abzubrechen. Eswerden zwei Arten von Skills unterschieden: Primitive und komplexe Skills. Pri-mitive Skills sind Skills fur die es direkt ein Pendant in Form eines Kommandosan den RoboCup Soccer Simulator gibt. Sie lassen sich nicht weiter zerlegen undkonnen auch nicht direkt vom Planer aufgerufen werden. Skills die andere Skillsaufrufen heißen komplexe Skills und konnen im Gegensatz zu primitiven Skillsdirekt von Planer ausgefuhrt werden.

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 konnen. Sie beinhalten daher keinespezielle Ausfuhrungslogik und ihre Hauptaufgabe ist die Kapselung der zuge-horigen S-Expression. Daher sind sie auch nicht weiter zerlegbar. Beispielsweiseveranlasst 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 handisch implementiert. Darunterfallt bspw. der Kick2Pos-Skill dessen Aufgabe es ist den Ball mit einer bestimm-ten Geschwindigkeit an eine Position zu schießen. Seine generische Implementie-rung erlaubt es den Skill sowohl fur harte Torschusse als auch zum Passen desBalls einzusetzen.

Es hat sich gezeigt, dass es haufig nicht trivial ist komplexe Skills handischzu implementieren. Daher bietet es sich insbesondere bei Skills an Lernverfahreneinzusetzen. So wurde der Torwart bspw. mittels eines Bayes-Netzes modelliertund trainiert [5].

3.6 Kommunikation

Fur die Anwendung komplexer Taktiken auf Teamebene mussen Absprachenzwischen Spieler-Agenten wahrend des Spielgeschehens ermoglicht werden. Diesist 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 Rollenbenotigt die kooperativ handeln. Daher muss in einem solchen Fall der ballfuh-rende Spieler dem gewunschten Empfanger zuvor mitteilen, dass ein Pass statt-finden soll. Dies bedingt die Notwendigkeit einer Kommunikations-Komponente.Da das Kommunikationsmodell des RoboCup Soccer Simulators jedoch einigenBeschrankungen unterliegt mussen sinnvolle Strategien gefunden werden um mitdiesen umgehen zu konnen.

Spieler-Agenten konnen Nachrichten von den Online-Coaches, vom Schieds-richter oder einem anderen Spieler-Agenten erhalten. Allerdings empfangt einSpieler nicht jede Nachricht. So beschrankt der Simulator die Kommunikati-on indem es bspw. eine maximale Entfernung zwischen Sender und Empfangergibt bis zu der eine Nachricht noch wahrgenommen werden kann. Dem Spieler-Agenten selbst stehen spezielle Kommandos fur die Kommunikation zur Verfu-gung. So kann der Spieler Nachrichten eingeschrankter Lange versenden. Diesemussen jedoch uber einem vorgegebenem Alphabet gebildet werden damit sienicht 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

kann und so das Spielgeschehen negativ beeinflussen konnen. Es muss also einKommunikations-Protokoll entwickelt werden, das diese Restriktionen beruck-sichtigt [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 vollstandig funktions-fahigen Status erreicht hat, soll im Folgenden nicht naher auf dessen Imple-mentierung eingegangen werden. Eine Aufgabe wird es daher sein mussen dasbestehende Protokoll auf dessen Korrektheit zu uberprufen und gegebenenfallsalternative Protokolle zu entwerfen die anschließend implementiert und bzgl.ihrer Leistungsfahigkeit evaluiert werden.

3.7 Das Trainer- und Coach-Framework

Da sich der Trainer und der Coach nur durch ihr Verhalten wahrend eines Spielsbzw. 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 fur sie vollstandig beobachtbarenUmgebung 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 konnen sich bei ihm verschiedene Spieler-Agenten anmelden, zum Anderen aber auch Lerntechniken (KI-Module) uberwelche die angemeldeten Spieler-Agenten trainiert werden sollen. Weiterhin ist

der Trainer mit dem RoboCup Soccer Simulator verbunden. Von diesem erhalt erunverfalschte Umgebungsdaten und kann direkt Einfluss auf die Simulation neh-men, 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.

!""#-$"-!! /!%Projektgruppe TORF – Universität Oldenburg • Fakultät II • Department für Informatik • Abteilung LLS

Architektur des Trainer-Agenten

$#

Trainer-Agent

Spieler-AgentTrainee/LT

Learning-Technique

XML-Situation

Coach-Agent

BasicCoach

RCSS-Server WorldModel

Message-Broker

Controller

Player-Types …

DatenflussVererbung

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 fur die Kommunikation mit dem RoboCup SoccerSimulator zustandig. Das Weltmodell ist fur die Verwaltung der vollstandig be-obachtbaren Umgebung zustandig. Von besonderer Bedeutung ist die Controller-Komponente. 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 konnen. Weiterhin ist der Abbildung zu ent-nehmen, dass auch die Spieler-Agenten eine Komponente fur die entsprechendeLerntechnik implementieren mussen, uber die der Trainer direkt Einfluss auf denPlanvorgang des Spielers nehmen kann um so bspw. gewisse Trainingssituationengezielt zu wiederholen [5].

Zur Durchfuhrung eines Trainings verbindet sich der Trainer zunachst uberden Message-Broker zum RoboCup Soccer Simulator. Danach initialisiert er diegewunschte Lerntechnik und wartet bis sich fur die entsprechende Lernart undTechnik ausreichend viele Spieler registriert haben. Das Training lauft so ab, dasszunachst Instruktionen an die teilnehmenden Spieler-Agenten gesendet werden.Der Trainer beobachtet wahrend des Trainings die Spieler und deren Verhal-ten. Am Ende einer Trainingsrunde empfangt dieser dann die von den Spieler-

Agenten gesammelten Daten und wertet diese anhand seiner eigenen unverfalsch-ten Daten aus. Aufgrund dieser Ergebnisse konnen anschließend in weiteren Trai-ningsrunden 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 abhangig von der konkretverwendeten 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-dardmaßig einen von 18 zufalligen generierten Spielertypen zu. Die so zugewie-senen Spielertypen sind allerdings i. d. R. nicht optimal auf die Rollen der Spielerzugeschnitten. Daher hat der Coach die Moglichkeit vor Spielbeginn den Spie-lertypen eines jeden Spielers entsprechend seiner Rolle zu andern. Es wurde einData-Mining durchgefuhrt um so eine optimale Heuristik fur die Verteilung derSpielertypen auf die verschiedenen Rollen durchzufuhren. Dazu wurde die Wahlder Spielertypen bei erfolgreichen Mannschaften durchgefuhrt.

3.8 Hilfsprogramme

Im Verlauf der Projektgruppe wurden einige entwicklungsunterstutzende Werk-zeuge erstellt. Zu diesen zahlt das TORF Strategy Tool sowie eine Sammlungkleinerer Skripte und Programme die unter dem Namen LogfileAnalysis zusam-mengefasst werden.

Trotz des fur Menschen lesbaren XML-Formats ist die manuelle Erstellungder Planerdatenbank annahernd unmoglich und unkomfortabel. Dies liegt un-ter anderem daran, dass die Serialisierung mittels der Boost-Bibliothek fur denSerialisierungsprozess benotigte Metadaten hinzufugt. Weiterhin lassen sich um-fangreiche Planerdatenbanken textuell nur schwer erfassen. Da das Verhalten unddie Effizienz eines Spieler-Agenten aber maßgeblich von dem Umfang des mo-dellierten Domanenwissens abhangt, muss diesem besonders Rechnung getragenwerden. Daher wurde das TORF Strategy Tool entwickelt mit dem Planerda-tenbanken schnell, komfortabel und ubersichtlich erstellt und gewartet werdensollen. Die hierarchischen Abhangigkeiten einer Zerlegung der Planerdatenbanksollten dementsprechend intuitiv durch eine entsprechende visuelle Darstellungaufbereitet sein und dessen Bearbeitung erlauben. Aus Zeitgrunden wurde dasWerkzeug mittels der NetBeans Platform 6.1 entwickelt. Daraus ergab sich je-doch die besondere Herausforderung der Interoperabilitat zwischen dem von Javagenerierten Bytecode und dem vom C++ Compiler erzeugten Maschinencode [5].

Das TORF Strategy Tool erlaubt es Tasks, Zerlegungen und die zugehorigenVorbedingungen und Invarianten in einer grafischen Oberflache zu spezifizie-ren. Dies umfasst auch die die Auswahl von Skills fur primitive Tasks und dasSpezifizieren ihrer Parameter. Auch die Fahigkeit des Planers komplexe Tasksauszufuhren muss durch das Werkzeug entsprechend unterstutzt werden. Zurgrafischen Darstellung der Planerdatenbank wurde ein baumartige Struktur ge-wahlt um moglichst nah bei der fur den Planer verwendeten Datenstruktur zu

bleiben. Die so erstellte Planerdaten werden anschließend uber das JNI (JavaNative 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 umstandlich bewertet wurde. Aus dieserEntwurfsentscheidung resultieren jedoch einige Probleme die bisher nicht immerzufriedenstellend gelost werden konnten. Dazu zahlt unter anderem das Problem,dass Objekte die auf C++-Seite konstruiert werden, nicht destruiert werden, umso die Stabilitat des TORF Strategie Tools zu gewahrleisten. Abbildung 7 zeigtdas Hauptfenster des Torf Strategy Tools.

Abbildung 7. Das Hauptfenster mit der Baumansicht am linken Rand [5].

Eine Idee die allerdings aus Zeitgrunden nicht mehr realisiert werden konnte,war die grafische Spezifikation von Situationen. Dies bedeutet, dass die Situatio-nen, welche spater durch Zerlegungen und Vorbedingungen beschrieben werden,durch ein grafisches Spielfeld und die Anordnung der Spieler auf diesem spezi-fiziert werden. Fur spatere Implementierungen wurde daher bereits der rechteBereich 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-

fiziellen Spiele ab dem Jahr 1997 sind in Form dieser Logdateien im Internetzuganglich. Daher sind diese Logdateien pradestiniert fur Analysezwecke mittelsData-Mining. So eignen sich diese Daten fur Lernverfahren oder die Analyse desVerhaltens 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 fur unterschiedlich Analysemethoden. Dazu zah-len Datenbank-Statistiken, Feldabdeckunsgsanalysen, Torschussanalysen sowiedie Analyse der Spielertypen. Das Skript fur die Datenbank-Statistiken gibt un-ter 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 wahrend eines Spiels aufhalten. Aus dieser In-formation lassen sich bspw. Aussagen uber den Aufenthaltsort einzelner Spieleroder 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 fur die Torschussanalyse wertet aus in welchen Situationen Tor-schusse erfolgreich sind. Die so erhaltenen Daten konnen selbst wieder fur dieOptimierung des eigenen Torschussverhaltens bzw. fur die Verbesserung des Tor-warts genutzt werden.

Die Analyse der Spielertypen wurde bereits in Abschnitt 3.7 angesprochen.Mittels dieses Skripts lassen sich die Spielertypen andere Mannschaften analysie-

ren und so die Aufstellung einer Mannschaft ableiten. Aus diesen Daten lassensich wiederum mittels Data-Mining Heuristiken zu Auswahl der Spielertypenableiten [5].

Abschließend lasst sich sagen, dass die Logfile-Analyse zum Einen fur dieEntwickler erste Anhaltspunkte uber typische Spielsituationen liefern kann aberauch fur Lernverfahren wie Bayes-Netze Evidenzen liefert. Insofern stellt dieLogfile-Analyse ein machtiges Werkzeug dar dem auch zukunftig Aufmerksam-keit gewidmet werden sollte.

4 Fazit

Das 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 zunachst auf das dazu notige Grundla-genwissen eingegangen. Unter anderem wurde der RoboCup und dessen 2D-Simulationsliga vorgestellt und anschließend eine Klassifikation der Arbeitsumge-bung der Spieler-Agenten durchgefuhrt. Dabei wurde festgestellt, dass die Kom-plexitat der Handlungsumgebung der Spieler-Agenten annahernd der Komplexi-tat der realen Welt entspricht.

Im Hauptteil wurden die Vorarbeiten der Projektgruppe TORF vorgestellt.Zunachst wurde auf die Architektur der Spieler-Agenten eingegangen welche ei-ne Grobarchitektur darstellt und Ausgangspunkt der weiteren Betrachtungenwar. Der Planer ist bereits voll funktionsfahig, allerdings wird sein volles Leis-tungspotenzial aufgrund von fehlendem Domanenwissen in der Planerdatenbanknicht vollstandig ausgeschopft. Die im Anschluss vorgestellten Skills stellen dieGrundfertigkeiten eines jeden Spielers dar und sind zum großen Teil handisch im-plementiert. Bei der Entwicklung neuer Skills sollten insbesondere Lernverfahreneingesetzt werden. Die Kommunikations-Komponente spielt eine entscheidendeRolle bei der Umsetzung von Teams-Skills. So mussen mehrere Agenten bspw.bei einem Passspiel kooperativ Handeln. Zur Absprache wird ein Kommunika-tionsmodell benotigt das mit den Limitationen des RoboCup Soccer Simulatorsumgehen kann. Die Kommunikationskomponente ist derzeit nicht vollstandigfunktionsfahig. Sie ist allerdings essentiell fur die Realisierung von Team-Skills,daher sollte ihr vermehrt Aufmerksamkeit gewidmet werden. Insbesondere kannan dieser Stelle auf die theoretischen Voruberlegungen der vorangehenden PGzuruckgegriffen werden. Das Trainer- und Coach Framework ist ein einfach gehal-tenes 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 umstandliche Bearbeitung der Planerdatenbank wasletztendlich auch dazu fuhrt, dass das in der Planerdatenbank vorhandene Doma-nenwissen nur einen geringen Umfang besitzt. Hinzu kommt, dass die Entwurfs-

entscheidung fur die Planerdatenbank, die Serialisierung der Boost-Bibliothekzu nutzen, zu einigen Problemen fuhrt. Abschließend wurde die Logfile-Analysevorgestellt. Diese stellt ein machtiges Werkzeug dar, dass zum Einen fur eineHeuristik der Spielertyp Zuordnung genutzt wurde aber auch potentiell unter-stutzend bei Lernverfahren wie Bayes-Netzen sein kann.

Literatur

[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 MultiagentTeam Behavior Using HTN Planning. In: RoboCup, 2005, S. 521–528

[4] Russell, S. ; Norvig, P.: Kunstliche Intelligenz – Ein moderner Ansatz. 2.Auflage. Pearson Studium, 2004

[5] Schafer, Andreas ; Ellen, Christian ; Steen, Enno-Edzard ; Jelschen,Jan ; Lenk, Jan C. ; Stover, Lena ; Sommer, Nils ; Massow, Robertvon ; Eiterig, Simon ; Scherfke, Stefan: Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe / Carl von Ossietzky Universi-tat Oldenburg. Version: 2008. http://torf.uni-oldenburg.de/content/

publications/Abschlussbericht.pdf. 2008. – Forschungsbericht[6] The RoboCup Federation: RoboCup. Version: April 2008. http://www.

robocup.org, Abruf: 2009-11-15