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.

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 Einleitung
Zielsetzung 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--
u
Teams TORF f¨r die 2D-Simulationsliga und die Teilnahme an der RoboCup
u
German Open 2010. Dazu kann und soll auf die Vorarbeiten der Projektgruppe
TORF (Team Oldenburger Robo-Fußball) zur¨ckgegriffen werden, die uber den
u ¨
Zeitraum von Anfang Oktober 2007 bis Ende September 2008 stattfand und mit
dem Preis Beste PG des Jahres“ ausgezeichnet wurde [5].
”
Um das vorhandene Roboterfußball-Team verbessern zu k¨nnen, m¨ssen
o u
zum einen unterschiedliche KI-Techniken (Bayes-Netze, Planung, Reinforcement
Learning usw.) angewendet und evaluiert werden, andererseits muss dar¨beru
hinaus zun¨chst die Architektur und Funktionsweise des vorhandenen Teams
a
verstanden werden, um dessen F¨higkeiten aber auch dessen Restriktionen im
a
Hinblick auf eventuelle zuk¨nftige Erweiterungen oder Anpassungen bewerten
u
zu k¨nnen. Ohne dieses Wissen wird es nur schwer m¨glich sein, Schw¨chen des
o o a
vorhandenen 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 Grundlagen
Das folgende Kapitel beschreibt die Grundlagen f¨r diese Arbeit. Zun¨chst soll
u a
begr¨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-
u
Simulationsliga des RoboCup vorgestellt. Weiterhin findet eine Klassifikation
der Arbeitsumgebung statt aus der sich viele der sp¨teren Anforderungen an die
a
Spieler-Agenten ergeben.
2.1 Vom Computerschach zum Roboterfußball
Claude E. Shannon, ein amerikanischer Mathematiker und Begr¨nder der In-
u
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 Pr¨fstein f¨r neu entwickelte Verfahren und besch¨ftigte
u u a
Wissenschaftler auf der ganzen Welt. Aus der Motivation des schachspielenden
Computers entstanden in der K¨nstlichen Intelligenz Spielstrategien mit leis-
u
tungsf¨higen Lernstrategien und Suchverfahren.
a
Doch schon bevor im Jahr 1996 der von IBM entwickelte Supercomputer
Deep Blue gegen den damals amtierenden Schachweltmeister Garri Kasparov
gewann wurde schnell klar, dass Computerschach kein Richtmaß mehr f¨r die u
Leistung der aus der K¨nstlichen Intelligenz hervorgehenden Verfahren war [2].
u
Daher entwickelte sich 1995 Roboterfußball zu einem der Standardprobleme der
K¨nstlichen Intelligenz. Dieser erlaubte es insbesondere auch neuere Entwick-
u
lungstendenzen, bei denen der Robotik ein h¨herer Stellenwert zukam, zu be-
o
r¨cksichtigen [6].
u
Roboterfußball stellt eine Herausforderung f¨r die Robotik sowie die K¨nst-
u u
liche Intelligenz dar. Beim Roboterfußball treten im Gegensatz zum Computer-
schach v¨llig andere Aspekte in den Vordergrund. So muss in einer realen oder
o
simulierten und dynamischen Umgebung agiert werden. Insbesondere m¨ssen u
auf Grundlage h¨ufig unvollst¨ndiger Informationen Entscheidungen in Echtzeit
a a
getroffen werden und auf unvorhersehbare Ereignisse reagiert werden.
Roboterfußball besitzt zudem neben den f¨r die Forschung interessanten Ei-
u
genschaften noch weitere Vorteile. Fußball ist eine popul¨re Sportart die viele
a
Menschen begeistert. Er erlaubt es somit Ergebnisse aus der KI-Forschung auch
Laien nahe zu bringen. Weiterhin ist das Regelwerk einem großen Bev¨lkerungs-
o
teil gel¨ufig und es lassen sich die Leistungen unterschiedlicher Forschungsgrup-
a
pen durch einfache Metriken wie die Platzierung in einem Wettbewerb oder die
Anzahl 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.
a
2.2 Der RoboCup
Die in den 90er Jahren gegr¨ndete internationale RoboCup-Initiative veranstal-
u
tet seit 1997 den RoboCup, eine j¨hrlich ausgetragene Weltmeisterschaft im Ro-
a
boterfuß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
a
statt an der die Projektgruppe Oldenburger Robot Soccer Team eine Teilnah-
me anstrebt. Die Motivation hinter solchen Wettk¨mpfen ist es die Entwicklung
a
stetig voranzutreiben mit dem Ziel bis zum Jahr 2050 den amtierenden mensch-
lichen Weltmeister in einem gew¨hnlichen Fußball-Spiel zu besiegen. Neben die-
o
sen Wettk¨mpfen werden parallel auf einem Kongress Erfahrungen und wissen-
a
schaftliche Erkenntnisse aus den Bereichen K¨nstliche Intelligenz und Robotik
u
ausgetauscht.
Da die Zielsetzung der Projektgruppe Oldenburger Robot Soccer Team die
Verbesserung 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 autonomen
Spielern in einem Fußballspiel gegeneinander an. Zudem kann jedes Team w¨h- a
rend des Spiels von genau einem ebenfalls autonomen Coach und im Trainings-
modus von einem autonomen Trainer unterst¨tzt werden. Dies alles geschieht
u
dabei rein virtuell auf dem sogenannten RoboCup Soccer Simulator Server, wel-
cher die Umgebung simuliert und mit dem alle Spieler kommunizieren. Jeder
der Spieler sowie der Coach und Trainer sind dabei ein Computerprogramm,
das in einem jeweils eigenen Prozess gestartet wird und die Eigenschaften eines
Software-Agenten erf¨llt. Ein Software-Agent ist dabei nach Russell und Norvig
u
wie folgt definiert: [6].
Definition 1. Als Agent kann alles angesehen werden, was seine Umwelt durch
Sensoren 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.
o
Die autonomen Spieler versuchen dabei durch ein m¨glichst gezieltes Zusammen-
o
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 eingeschr¨nkten Wahrneh-
a
mung und einer eingeschr¨nkten Kommunikation mit anderen Spielern zurecht-
a
finden m¨ssen. Konkret bedeutet dies, dass in der Simulation ber¨cksichtigt
u u
wird, dass Spieler bei h¨heren Entfernungen Distanzen ungenauer absch¨tzen,
o a
ein Spieler nur ein beschr¨nktes Sichtfeld besitzt und die Energiereserven eines
a
Spielers von seinen Aktivit¨ten auf dem Spielfeld abh¨ngen.
a a
Die 2D-Simulationsliga hat aber auch einige Vorteile gegen¨ber den ande-
u
ren Ligen. Da es sich um eine reine Simulation handelt wird hier von m¨gli- o
chen Problemen der Robotik, Mechanik und Sensorik abstrahiert. So kann der
Schwerpunkt auf der Anwendung und Evaluation der Methoden der K¨nstlichen
u
Intelligenz gelegt werden [5].

4. 2.4 Der RoboCup Soccer Simulator
Der RoboCup Soccer Simulator stellt gem¨ß der Client-Server-Architektur einen
a
Server dar, der als Dienst die Simulation der Umgebung der 2D-Simulationsliga
anbietet. In diesem Kontext sind die Spieler-Agenten sowie der Coach- und
Trainer-Agent die Clients. Teil des Simulations-Dienstes ist bspw. die Verwal-
tung aller Spieler, des Balls und deren Positionen auf dem Spielfeld sowie die
Simulation einer einfachen Physik. Weiterhin simuliert er die visuelle und audi-
tive Wahrnehmung eines jeden Spieler-Agenten. Dazu m¨ssen sich die Agenten
u
zun¨chst bei dem Server anmelden. Nach einer erfolgreichen Anmeldung erhal-
a
ten alle Agenten vom Server Informationen uber die von ihnen wahrgenommene
¨
Umgebung. F¨r die Spieler-Agenten ist die Umgebung nur partiell beobacht-
u
bar, w¨hrend f¨r Trainer- und Coach-Agenten diese jedoch vollst¨ndig beob-
a u a
achtbar ist. Der Soccer Simulator simuliert diese Beschr¨nkungen indem er dem
a
Spieler-Agenten nicht alle Informationen zusendet und zus¨tzlich Daten k¨nst-
a u
lich verrauscht. Auf Grundlage der so erhaltenen Informationen entscheiden die
Spieler-Agenten welche Aktion als n¨chstes ausgef¨hrt werden soll und teilen
a u
diese dem Server mit. Dazu stehen den Agenten diverse Kommandos zur Verf¨- u
gung mit denen diese dem Server mitteilen k¨nnen, welche Aktion auszuf¨hren
o u
ist. Allerdings werden auch an dieser Stelle die Aktionen des Spielers nicht exakt
ausgef¨hrt sondern wieder k¨nstlich mit einer Ungenauigkeit versehen [5].
u u
Die Kommunikation der Agenten mit dem RoboCup Soccer Simulator findet
uber sogenannte S-Expressions statt. Dabei kommt das UDP/IP-Protokoll zum
¨
Einsatz. Das Protokoll dieser Kommunikation und weitere Details lassen sich
dem RoboCup Soccer Simulator Manual [1] entnehmen.
2.5 Klassifikation der Arbeitsumgebung
Im Folgenden soll die Arbeitsumgebung der verschiedenen Agenten-Typen der
RoboCup 2D-Simulationsliga zun¨chst nach der von Russell und Norvig ent-
a
wickelten PEAS-Beschreibung klassifiziert werden. PEAS ist ein Akronym f¨r u
Leistungsbewertung (Performance), Umgebung (Environment), Aktuatoren (Ac-
tuators) und Sensoren (Sensors). Die dieser Beschreibung zugrundeliegende Idee
ist, 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
a
Arbeitsumgebung 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-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. ihrer
Arbeitsumgebung bestehen, muss deren Beschreibung der Arbeitsumgebung und
anschließende Umgebungsklassifikation getrennt vorgenommen werden. Bspw. ist
die Umgebung f¨r die Spieler-Agenten nur partiell beobachtbar und teilweise ver-
u
rauscht, w¨hrend f¨r den Trainer- und Coach-Agenten die Umgebung vollst¨ndig
a u a
beobachtbar ist. Dies resultiert dann auch in unterschiedlichen Anforderungen,
die an diese Agenten-Typen gestellt werden. In Tabelle 1 wird die Beschreibung
der Arbeitsumgebungen f¨r die in der 2D-Simulationsliga beteiligten Agenten-
u
Typen tabellarisch dargestellt.
Agententyp Leistungsbewer- Umgebung Aktuatoren Sensoren
tung
Spieler Stabilit¨t, Ge-
a RoboCup Spielerkomman- Sehen und
schwindigkeit, Soccer Server dos (dash, turn, H¨ren
o
kongruentes say, . . . )
Verhalten
Trainer 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 nach
dem PEAS-Ansatz von Russell und Norvig [5].
Die Umgebungsklassifikation soll nun f¨r den Spieler-Agenten exemplarisch
u
vorgenommen werden. Da diesem die Arbeitsumgebung (das Fußballfeld und al-
le beteiligten Agenten) aufgrund seines beschr¨nkten Sichtfeldes und ungenauen
a
Absch¨tzungen von Entfernungen (simuliert durch das Verrauschen der Daten
a
durch den RoboCup Soccer Simulator) nur teilweise bekannt ist handelt es sich
um eine partiell beobachtbare Umgebung. Weiterhin h¨ngt der Folgezustand
a
der Umgebung nicht nur vom momentanen Zustand und der Aktion des Agen-
ten ab. Daher ist die Umgebung nicht deterministisch sondern stochastisch. Die
Umgebung ist zudem sequentiell, da aktuelle Entscheidungen eines Agenten alle
weiteren Entscheidungen beeinflussen k¨nnen. Die Arbeitsumgebung kann sich
o
a
¨ndern, w¨hrend der Agent eine Entscheidung trifft, was sie dynamisch macht.
a
Weiterhin versucht der RoboCup Soccer Simulator mit diskreten Werten eine
kontinuierliche Arbeitsumgebung zu simulieren, so dass diese als simuliert ste-

6. tig aufgefasst werden kann. Da die Spieler-Agenten mit allen weiteren Agenten
ihres Teams in Interaktion stehen, handelt es sich um eine Multiagentenumge-
bung. Abschließend kann also zusammengefasst werden, dass der Spieler-Agent
sich in einer teilweise beobachtbaren, stochastischen, sequentiellen, dynamischen
und simuliert stetigen Multiagenten-Umgebung befindet [5].
Diese Klassifikation l¨sst nun schon erste Schl¨sse bez¨glich der Anforderun-
a u u
gen an einen Spieler-Agenten zu. So bedingt die nur teilweise Beobachtbarkeit
der Arbeitsumgebung die Verwaltung eines inneren Zustandes (Weltmodells) auf-
grund dessen fehlend Informationen abgeleitet werden k¨nnen. Da die Arbeit-
o
sumgebung weiterhin stochastisch ist, k¨nnen keine absoluten Aussagen uber
o ¨
m¨gliche Folgezust¨nde der Umgebung nach Ausf¨hrung einer Aktion getrof-
o a u
fen werden. Aussagen uber zuk¨nftige Zust¨nde basieren dadurch vielmehr auf
¨ u a
Wahrscheinlichkeiten. Weiterhin ist die Arbeitsumgebung sequentiell was dazu
f¨hrt, dass der Spieler-Agent auch vorausdenken k¨nnen muss. Die dynamische
u o
Arbeitsumgebung bedingt, dass sich diese ¨ndern kann noch w¨hrend der Spieler-
a a
Agent eine Entscheidung trifft. Es handelt sich also um eine ¨ußerst schwierige
a
Handlungsumgebung die der Komplexit¨t der realen Welt sehr nahe kommt.
a
2.6 Der Spieler als modellbasierter Reflex-Agent
Wie bereits in Abschnitt 2.5 angef¨hrt, macht die nur teilweise Beobachtbarkeit
u
der Arbeitsumgebung die Verwaltung eines Zustandes (Weltmodells) f¨r den u
Spieler-Agenten notwendig. F¨r ein solches Szenario eignet sich nach Russell und
u
Norvig [4] ein wie in Abbildung 1 dargestellter modellbasierter Reflex-Agent.
Abbildung 1. Die schematische Darstellung eines modellbasierten Reflex-Agenten
nach 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 action
2 static : state , Beschreibung des aktuellen Zustands der Welt
3 rules , Menge von Bedingung / Aktion - Regeln
4
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 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 mit
dem RoboCup Soccer Simulator welcher dessen Arbeitsumgebung simuliert. Die
Kommunikation ist bidirektional, da der Agent zum einen Sensordaten von dem
Simulator erh¨lt, andererseits aber auch selbst Kommandos an diesen sendet.
a
Die 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 a
von 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-
u
de Nachrichten vom Message-Broker direkt an die Planer-Komponente weiterge-
reicht. Die Weltmodell-Komponente kapselt den Zustand des Spielers und dessen
Umgebung wie in Kapitel 2.6 beschrieben. Die Planer-Komponente kapselt den
ebenfalls aus Kapitel 2.6 bekannten Entscheidungsfindungsprozess in dem auf
Basis des Weltmodells durchzuf¨hrende Aktionen, im Folgenden auch Skills ge-
u
nannt, ausgew¨hlt und an die Skill-Manager-Komponente weitergereicht werden.
a
Die Skill-Manager-Komponente sorgt daf¨r, dass die Skills ausgef¨hrt werden
u u
und 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.
u
Die Bezeichnung Com-Ponent“ ist ein Wortspiel und steht f¨r Kommunikations-
u
”

9. Komponente. Sie erm¨glicht es den Spieler-Agenten untereinander zu kommuni-
o
zieren um so komplexe Taktiken abzusprechen.
Ein in diesem Komponentenmodell h¨ufig verwendetes Konzept ist das eines
a
Transformators. Ein Transformator befindet sich jeweils zwischen zwei Kompo-
nenten und f¨hrt notwendige Transformationen der Daten durch. Ein in der
u
Abbildung 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
o
uber 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 f¨r die Verteilung der vom Server eingehenden Message-
u
Objekte zust¨ndig. Jede Nachricht besitzt dabei einen Typ. Komponenten die
a
sich f¨r spezielle Nachrichtentypen interessieren, k¨nnen sich f¨r diese bei dem
u o u
Message-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 und
sich dann beim MessageBroker f¨r einen oder alle Nachrichtentypen registrieren
u
[5].
3.3 Das Weltmodell
Das Weltmodell ist eine wichtige Komponente des Spieler-Agenten auf dessen
Grundlage im Entscheidungsfindungsprozess die vom Agenten auszuf¨hrenden
u
Aktionen ausgew¨hlt werden. Dabei muss das Weltmodell nicht nur den Ist-
a
Zustand der Arbeitsumgebung kennen sondern auch Dynamikwissen besitzen
anhand dessen sich das Verhalten von transient nicht beobachtbaren Objekten
absch¨tzen l¨sst. Weicht das Weltmodell zu sehr von der tats¨chlichen Arbeit-
a a a
sumgebung des Agenten ab, so werden falsche Entscheidungen getroffen. Daher
muss die Arbeitsumgebung des Agenten im Weltmodell m¨glichst korrekt ab-
o
gebildet werden. Es m¨ssen insbesondere Strategien gefunden werden, die es
u
erm¨glichen aus den verrauschten Sensordaten des RoboCup Soccer Simulators
o
m¨glichst exakte Sch¨tzungen der tats¨chlichen Werte zu erhalten [5].
o a a
Grundlegende Anforderungen an das Weltmodell sind zun¨chst das Erfas-
a
sen der eigenen Position sowie die Erfassung der anderen Spieler und des Balls.
Dazu wurden zun¨chst die unterschiedlichen Entit¨ten (Spieler, Spielfeld, Ball
a a
usw.) des Weltmodells als Klassen modelliert. Die Instanzen dieser Entit¨ten im
a
Weltmodell 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 Weltmodell
verarbeitet werden k¨nnen.
o
Das Weltmodell modelliert sowohl statische als auch dynamische Objekte. Zu
den statischen Objekten geh¨ren bspw. Flaggen anhand derer die eigene Position
o
lokalisiert werden kann. Diese sind entlang der Spiefeldbegrenzung aufgestellt.
Dynamische Objekte sind die Spieler und der Ball. Diese unterliegen einer Ver¨n-
a
derung und lassen sich durch eine gerichtete Geschwindigkeit und eine Position
beschreiben. Weiterhin werden von dem Weltmodell Spielinformationen wie der
Punktestand oder die Spielphase erfasst. Andere Komponenten k¨nnen dabei
o
uber 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
u
sind, 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
a
Flagge sichtbar w¨hrend im zweiten Fall mindestens zwei Flaggen sichtbar sein
a
m¨ssen. Die so erhaltenen Positionen sind aufgrund der verrauschten Sensorda-
u
ten des RoboCup Soccer Simulators verf¨lscht. Die Entfernungen zu statischen
a
sowie dynamischen Objekte werden vom Simulator n¨mlich wie Abbildung 3.3
a
verdeutlicht 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-
a
gen m¨glichst viele unterschiedliche Flaggenpaare zusammengestellt um aus die-
o
sen mehrere Positions-Samples zu bestimmen. Um jetzt eine m¨glichst exak-
o
te 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-
a
ge, 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-
u
modell abgebildeten Informationen entwickelt. Mit dieser l¨sst sich in Echtzeit
a
die Genauigkeit der vom Weltmodell erfassten Informationen mit denen der tat-
s¨chlich simulierten Arbeitsumgebung des RoboCup Simulators vergleichen. So
a
lassen sich schnell große Abweichungen zwischen diesen erkennen. Es hat sich
w¨hrend der Entwicklung gezeigt, dass eine grafische Darstellung ein einfaches
a
und effektives Hilfsmittel ist, um Fehlinterpretationen fr¨hzeitig zu erkennen.
u
3.4 Planer
Der Planer ist eine weitere zentrale Komponente des Spieler-Agenten, welche den
Entscheidungsfindungsprozess umsetzt und so f¨r die Festlegung der Strategie
u
und das Starten geeigneter Skills zust¨ndig ist. Der Planer ist dabei die Umset-
a
zung eines hierarchischen Planers der dazu in der Lage ist, komplexe Aufgaben in
kleinschrittiger zu zerlegen und diese dadurch besser handhabbar macht. Dabei
muss der Planer mit vielen der anderen Komponenten kommunizieren. Bspw.
ben¨tigt er Informationen von dem Weltmodell, auf dessen Grundlage Entschei-
o
dungen bzgl. des Planungsvorganges getroffen werden. Weiterhin muss der Pla-
ner dem Skillmanager Skills ubergeben und ihn dazu veranlassen k¨nnen, diese
¨ o
zu starten. Der Planer ben¨tigt f¨r die hierarchische Dekomposition komplexer
o u
Aufgaben Dom¨nenwissen, das in einer Planerdatenbank vorliegt. Dazu wurde
a
ein Werkzeug entwickelt, das es erm¨glicht Planerdatenbanken zu erstellen und
o
zu editieren. Eine wichtige Zielsetzung des Planers war es auch, dass er dazu
in der Lage ist, Strategien, die koordinierte Handlungsabl¨ufe mehrerer Spieler
a
erfordern, umzusetzen [5].
Die Umsetzung des Planalgorithmus orientiert sich weitestgehend an dem in
[3] vorgestellten Verfahren. Abbildung 4 zeigt die Architektur des Planers sowie
an dem Planvorgang beteiligte Komponenten.
Im Planer findet der eigentliche Planungsvorgang statt. W¨hrend des Plan-
a
vorgangs 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
a
und startet an dessen Wurzel, indem er diese auf dem Planerstack ablegt. An-
hand der vom Weltmodell bekannten Literale entscheidet der Planer nun wie mit
dem obersten Element des Planerstacks weiter verfahren werden soll. Ist diese
Aufgabe wie im beschriebenen Fall eine zusammengesetzte Aufgabe, so findet
eine Zerlegung mittels des Kindknotens dieser Aufgabe statt deren Vorbedin-
gung erf¨llt ist. Stimmen die Vorbedingungen mehrerer Zerlegungen, so wird
u
eine zuf¨llige Zerlegung vom Planer gew¨hlt. Die zu einer Zerlegung geh¨renden
a a o
Teilaufgaben werden anschließend auf dem Planstack abgelegt. Ist eine solche
Teilaufgabe primitiv so wird sie direkt vom Planer ausgef¨hrt. Zusammengesetz-
u
te 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-
¨ o
den Skill direkt ausf¨hrt. Aufgaben die abgearbeitet wurden oder fehlgeschlagen
u
sind werden vom Stack gel¨scht. Weiterhin uberpr¨ft der Planer in regelm¨ßigen
o ¨ u a
Zeitabst¨nden, ob die Invarianten der einzelnen Aufgaben erf¨llt sind. Ist dies
a u
nicht der Fall, so werden alle Aufgaben ab der Aufgabe deren Invariante nicht
erf¨llt ist, vom Stack entfernt und der Planungsvorgang beginnt von neuem [5].
u
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 w¨hrend eines Spiels. Der
a
Spieler-Agent nimmt aktiv am Spielgeschehen teil indem er hintereinander oder
auch parallel eine Folge von Skills ausf¨hrt. Die Planung dieser Abfolge und das
u
Starten der Skills ubernimmt wie bereits aus Abschnitt 3.4 bekannt der Planer.
¨
Dieser erm¨glicht es insbesondere Skills auf Teamebene, die komplexe Inter-
o
aktionen zwischen den Spielern umfassen und sich nicht nur auf einen Spieler
beschr¨nken, umzusetzen.
a
Skills werden von dem sogenannten Skill-Manager verwaltet. Dieser k¨mmert
u
sich um das Erzeugen, Ausf¨hren, Stoppen und L¨schen der Skills. Der Planer
u o
initiiert das Ausf¨hren der Skills indem er dem Skill-Manager mitteilt wann und
u
in welcher Reihenfolge von diesem die Skills ausgef¨hrt werden sollen. Außerdem
u
kann dieser den Skill-Manager anweisen einen laufenden Skill abzubrechen. Es
werden 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
u
an den RoboCup Soccer Simulator gibt. Sie lassen sich nicht weiter zerlegen und
k¨nnen auch nicht direkt vom Planer aufgerufen werden. Skills die andere Skills
o
aufrufen heißen komplexe Skills und k¨nnen im Gegensatz zu primitiven Skills
o
direkt 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 als
Container-Klassen um die vom RoboCup Soccer Simulator angebotenen atoma-
ren Kommandos mit denen das Spielerverhalten gesteuert werden kann in der
Warteschlange des Generators einreihen zu k¨nnen. Sie beinhalten daher keine
o
spezielle Ausf¨hrungslogik und ihre Hauptaufgabe ist die Kapselung der zuge-
u
h¨rigen S-Expression. Daher sind sie auch nicht weiter zerlegbar. Beispielsweise
o
veranlasst der primitive Kick-Skill den Spieler den Ball mit einer bestimmten
Kraft 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
a
f¨llt bspw. der Kick2Pos-Skill dessen Aufgabe es ist den Ball mit einer bestimm-
a
ten 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 u
Balls einzusetzen.
Es hat sich gezeigt, dass es h¨ufig nicht trivial ist komplexe Skills h¨ndisch
a a
zu implementieren. Daher bietet es sich insbesondere bei Skills an Lernverfahren
einzusetzen. So wurde der Torwart bspw. mittels eines Bayes-Netzes modelliert
und trainiert [5].
3.6 Kommunikation
F¨r die Anwendung komplexer Taktiken auf Teamebene m¨ssen Absprachen
u u
zwischen Spieler-Agenten w¨hrend des Spielgeschehens erm¨glicht werden. Dies
a o
ist daher notwendig, da jeder Spieler-Agent aufgrund der nur teilweise beobacht-
baren Umgebung ein eigenes Weltmodell besitzt und einer daraus resultierenden
anderen Planung. Bei bspw. einem Passspiel werden aber ganz bestimme Rollen
ben¨tigt die kooperativ handeln. Daher muss in einem solchen Fall der ballf¨h-
o u
rende Spieler dem gew¨nschten Empf¨nger zuvor mitteilen, dass ein Pass statt-
u a
finden soll. Dies bedingt die Notwendigkeit einer Kommunikations-Komponente.
Da das Kommunikationsmodell des RoboCup Soccer Simulators jedoch einigen
Beschr¨nkungen unterliegt m¨ssen sinnvolle Strategien gefunden werden um mit
a u
diesen umgehen zu k¨nnen.
o
Spieler-Agenten k¨nnen Nachrichten von den Online-Coaches, vom Schieds-
o
richter oder einem anderen Spieler-Agenten erhalten. Allerdings empf¨ngt ein
a
Spieler nicht jede Nachricht. So beschr¨nkt der Simulator die Kommunikati-
a
on indem es bspw. eine maximale Entfernung zwischen Sender und Empf¨nger a
gibt bis zu der eine Nachricht noch wahrgenommen werden kann. Dem Spieler-
Agenten selbst stehen spezielle Kommandos f¨r die Kommunikation zur Verf¨-
u u
gung. So kann der Spieler Nachrichten eingeschr¨nkter L¨nge versenden. Diese
a a
m¨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 Spieler
fokussieren. Dies ist notwendig, da ein Spieler-Agent pro Simulations-Zyklus nur
die jeweils erste an ihn versendete Nachricht wahrnimmt. Es existieren somit
verschiedene Situation in denen es zu einem Verlust von Nachrichten kommen

14. kann und so das Spielgeschehen negativ beeinflussen k¨nnen. Es muss also ein
o
Kommunikations-Protokoll entwickelt werden, das diese Restriktionen ber¨ck-
u
sichtigt [1].
Das letztendlich implementierte Verfahren teilt das Kommunikationsnetz in
Cluster 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-
a
f¨higen Status erreicht hat, soll im Folgenden nicht n¨her auf dessen Imple-
a a
mentierung eingegangen werden. Eine Aufgabe wird es daher sein m¨ssen das
u
bestehende Protokoll auf dessen Korrektheit zu uberpr¨fen und gegebenenfalls
¨ u
alternative Protokolle zu entwerfen die anschließend implementiert und bzgl.
ihrer Leistungsf¨higkeit evaluiert werden.
a
3.7 Das Trainer- und Coach-Framework
Da sich der Trainer und der Coach nur durch ihr Verhalten w¨hrend eines Spiels
a
bzw. Trainings unterscheiden ansonsten aber architektonisch gleichen sind sie
als eine einzige Applikation implementiert. Das Trainerprogramm kann sich bei
dem RoboCup Soccer Simulator als Trainer oder Coach anmelden. Gemeinsam
haben 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 a
Umgebung sowie ein spezielles Kommunikationsprotokoll zur Kommunikation
mit 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-
o
Agenten 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
a
unverf¨lschte Umgebungsdaten und kann direkt Einfluss auf die Simulation neh-
a
men, um gezielt Trainingssituationen hervorzurufen. Am Training unbeteiligte
Spieler-Agenten sind lediglich am Simulations-Server angemeldet. Eine wichtige
Eigenschaft ist die Austauschbarkeit von Lerntechniken. Abbildung 6 zeigt das
Komponentenmodell 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
u
Simulator zust¨ndig. Das Weltmodell ist f¨r die Verwaltung der vollst¨ndig be-
a u a
obachtbaren Umgebung zust¨ndig. Von besonderer Bedeutung ist die Controller-
a
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 mit
welcher die Spieler trainiert werden k¨nnen. Weiterhin ist der Abbildung zu ent-
o
nehmen, dass auch die Spieler-Agenten eine Komponente f¨r die entsprechende
u
Lerntechnik implementieren m¨ssen, uber die der Trainer direkt Einfluss auf den
u ¨
Planvorgang des Spielers nehmen kann um so bspw. gewisse Trainingssituationen
gezielt 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 die
gew¨nschte Lerntechnik und wartet bis sich f¨r die entsprechende Lernart und
u u
Technik ausreichend viele Spieler registriert haben. Das Training l¨uft so ab, dass
a
zun¨chst Instruktionen an die teilnehmenden Spieler-Agenten gesendet werden.
a
Der Trainer beobachtet w¨hrend des Trainings die Spieler und deren Verhal-
a
ten. 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- a
ten Daten aus. Aufgrund dieser Ergebnisse k¨nnen anschließend in weiteren Trai-
o
ningsrunden neue Instruktionen erzeugt werden. Sobald ein Training beendet
wurde werden die so erhaltenen Daten gesichert. Die in einem Training an die
Spieler-Agenten gesendeten Instruktionen sind dabei abh¨ngig von der konkret
a
verwendeten Lerntechnik. Weiterhin ist der Trainer in der Lage im XML-Format
gespeicherte Spielsituationen zu Trainingszwecken zu laden und Spieler und Ball
entsprechend zu positionieren [5].
Die Aufgabe des Coaches ist momentan einzig und allein die Vergabe der
Spielertypen. Der RoboCup Soccer Simulator weist den Spieler-Agenten stan-
dardm¨ßig einen von 18 zuf¨lligen generierten Spielertypen zu. Die so zugewie-
a a
senen Spielertypen sind allerdings i. d. R. nicht optimal auf die Rollen der Spieler
zugeschnitten. Daher hat der Coach die M¨glichkeit vor Spielbeginn den Spie-
o
lertypen eines jeden Spielers entsprechend seiner Rolle zu ¨ndern. Es wurde ein
a
Data-Mining durchgef¨hrt um so eine optimale Heuristik f¨r die Verteilung der
u u
Spielertypen auf die verschiedenen Rollen durchzuf¨hren. Dazu wurde die Wahl
u
der Spielertypen bei erfolgreichen Mannschaften durchgef¨hrt.
u
3.8 Hilfsprogramme
Im Verlauf der Projektgruppe wurden einige entwicklungsunterst¨tzende Werk-
u
zeuge erstellt. Zu diesen z¨hlt das TORF Strategy Tool sowie eine Sammlung
a
kleinerer Skripte und Programme die unter dem Namen LogfileAnalysis zusam-
mengefasst werden.
Trotz des f¨r Menschen lesbaren XML-Formats ist die manuelle Erstellung
u
der Planerdatenbank ann¨hernd unm¨glich und unkomfortabel. Dies liegt un-
a o
ter anderem daran, dass die Serialisierung mittels der Boost-Bibliothek f¨r den
u
Serialisierungsprozess ben¨tigte Metadaten hinzuf¨gt. Weiterhin lassen sich um-
o u
fangreiche Planerdatenbanken textuell nur schwer erfassen. Da das Verhalten und
die Effizienz eines Spieler-Agenten aber maßgeblich von dem Umfang des mo-
dellierten Dom¨nenwissens abh¨ngt, muss diesem besonders Rechnung getragen
a a
werden. 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
a
sollten dementsprechend intuitiv durch eine entsprechende visuelle Darstellung
aufbereitet sein und dessen Bearbeitung erlauben. Aus Zeitgr¨nden wurde das
u
Werkzeug mittels der NetBeans Platform 6.1 entwickelt. Daraus ergab sich je-
doch die besondere Herausforderung der Interoperabilit¨t zwischen dem von Java
a
generierten Bytecode und dem vom C++ Compiler erzeugten Maschinencode [5].
Das TORF Strategy Tool erlaubt es Tasks, Zerlegungen und die zugeh¨rigen
o
Vorbedingungen und Invarianten in einer grafischen Oberfl¨che zu spezifizie-
a
ren. Dies umfasst auch die die Auswahl von Skills f¨r primitive Tasks und das
u
Spezifizieren ihrer Parameter. Auch die F¨higkeit des Planers komplexe Tasks
a
auszuf¨hren muss durch das Werkzeug entsprechend unterst¨tzt werden. Zur
u u
grafischen 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 and
Interface Generator), der in C++ implementierten Planerdatenbank ubergeben.
¨
Dieser Weg wurde eingeschlagen da das Parsen der durch die Boost-Bibliothek
serialisierten Planerdatenbank als zu umst¨ndlich bewertet wurde. Aus dieser
a
Entwurfsentscheidung resultieren jedoch einige Probleme die bisher nicht immer
zufriedenstellend gel¨st werden konnten. Dazu z¨hlt unter anderem das Problem,
o a
dass Objekte die auf C++-Seite konstruiert werden, nicht destruiert werden, um
so die Stabilit¨t des TORF Strategie Tools zu gew¨hrleisten. Abbildung 7 zeigt
a a
das 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,
u
war die grafische Spezifikation von Situationen. Dies bedeutet, dass die Situatio-
nen, welche sp¨ter durch Zerlegungen und Vorbedingungen beschrieben werden,
a
durch ein grafisches Spielfeld und die Anordnung der Spieler auf diesem spezi-
fiziert werden. F¨r sp¨tere Implementierungen wurde daher bereits der rechte
u a
Bereich des Hauptfensters freigehalten. Die Machbarkeit dieses Ansatzes sowie
dessen Nutzen sollten daher evaluiert werden.
Die LogfileAnalyisis genannte Sammlung von kleinen Programmen und Skrip-
ten dient dem Einlesen und Auswerten der serverseitig vom RoboCup Soccer
Simulator 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 Internet
zug¨nglich. Daher sind diese Logdateien pr¨destiniert f¨r Analysezwecke mittels
a a u
Data-Mining. So eignen sich diese Daten f¨r Lernverfahren oder die Analyse des
u
Verhaltens andere Teams. Daher wurden Python-Skripte entwickelt die unter
dem Namen LogfileAnalysis zusammengefasst werden. Diese Skripte umfassen
das Einlesen in eine PostgreSQL-Datenbank sowie das Auswerten der Daten.
Es existieren diverse Skripte f¨r unterschiedlich Analysemethoden. Dazu z¨h-
u a
len Datenbank-Statistiken, Feldabdeckunsgsanalysen, Torschussanalysen sowie
die Analyse der Spielertypen. Das Skript f¨r die Datenbank-Statistiken gibt un-
u
ter anderem die Anzahl der gespeicherten Spiele, eine Liste aller Mannschaften
und das Spiel mit maximaler Torzahl aus.
Die Feldabdeckungsanalyse dient hingegen dazu herauszuarbeiten wo sich
Objekte wie Spieler oder Ball w¨hrend eines Spiels aufhalten. Aus dieser In-
a
formation lassen sich bspw. Aussagen uber den Aufenthaltsort einzelner Spieler
¨
oder Spieltaktiken ableiten. Abbildung 8 zeigt das Ergebnis der Analyse der
Aufenthaltsorte 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-
u
sch¨sse erfolgreich sind. Die so erhaltenen Daten k¨nnen selbst wieder f¨r die
u o u
Optimierung des eigenen Torschussverhaltens bzw. f¨r die Verbesserung des Tor-
u
warts 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 lassen
sich wiederum mittels Data-Mining Heuristiken zu Auswahl der Spielertypen
ableiten [5].
Abschließend l¨sst sich sagen, dass die Logfile-Analyse zum Einen f¨r die
a u
Entwickler erste Anhaltspunkte uber typische Spielsituationen liefern kann aber
¨
auch f¨r Lernverfahren wie Bayes-Netze Evidenzen liefert. Insofern stellt die
u
Logfile-Analyse ein m¨chtiges Werkzeug dar dem auch zuk¨nftig Aufmerksam-
a u
keit gewidmet werden sollte.
4 Fazit
Das Ziel der Projektgruppe Oldenburger Robot Soccer Team ist die Verbesserung
des 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 o
genwissen 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-
u
plexit¨t der Handlungsumgebung der Spieler-Agenten ann¨hernd der Komplexi-
a a
t¨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-
a
ne Grobarchitektur darstellt und Ausgangspunkt der weiteren Betrachtungen
war. Der Planer ist bereits voll funktionsf¨hig, allerdings wird sein volles Leis-
a
tungspotenzial aufgrund von fehlendem Dom¨nenwissen in der Planerdatenbank
a
nicht vollst¨ndig ausgesch¨pft. Die im Anschluss vorgestellten Skills stellen die
a o
Grundfertigkeiten eines jeden Spielers dar und sind zum großen Teil h¨ndisch im-
a
plementiert. Bei der Entwicklung neuer Skills sollten insbesondere Lernverfahren
eingesetzt werden. Die Kommunikations-Komponente spielt eine entscheidende
Rolle bei der Umsetzung von Teams-Skills. So m¨ssen mehrere Agenten bspw.
u
bei einem Passspiel kooperativ Handeln. Zur Absprache wird ein Kommunika-
tionsmodell ben¨tigt das mit den Limitationen des RoboCup Soccer Simulators
o
umgehen kann. Die Kommunikationskomponente ist derzeit nicht vollst¨ndig a
funktionsf¨hig. Sie ist allerdings essentiell f¨r die Realisierung von Team-Skills,
a u
daher sollte ihr vermehrt Aufmerksamkeit gewidmet werden. Insbesondere kann
an dieser Stelle auf die theoretischen Vor¨berlegungen der vorangehenden PG
u
zur¨ckgegriffen werden. Das Trainer- und Coach Framework ist ein einfach gehal-
u
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 TORF
Strategy Tool dient beispielsweise der Erstellung von Planerdatenbanken. Da es
allerdings unter enormem Termindruck erstellt wurde ist es sehr einfach gehalten.
Daraus resultiert eine noch umst¨ndliche Bearbeitung der Planerdatenbank was
a
letztendlich auch dazu f¨hrt, dass das in der Planerdatenbank vorhandene Dom¨-
u a
nenwissen nur einen geringen Umfang besitzt. Hinzu kommt, dass die Entwurfs-

20. entscheidung f¨r die Planerdatenbank, die Serialisierung der Boost-Bibliothek
u
zu nutzen, zu einigen Problemen f¨hrt. Abschließend wurde die Logfile-Analyse
u
vorgestellt. Diese stellt ein m¨chtiges Werkzeug dar, dass zum Einen f¨r eine
a u
Heuristik der Spielertyp Zuordnung genutzt wurde aber auch potentiell unter-
st¨tzend bei Lernverfahren wie Bayes-Netzen sein kann.
u
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 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