Analyse domänenseitiger Optimierungen für Deep Reinforcement Learning in der RoboCup Umgebung
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Analyse domänenseitiger Optimierungen für
Deep Reinforcement Learning in der RoboCup
Umgebung
Hannes Braun
BACHELORARBEIT
zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.)
Studiengang Angewandte Informatik
Fakultät Elektrotechnik, Medizintechnik und Informatik
Hochschule für Technik, Wirtschaft und Medien Offenburg
24.02.2021
Betreuer
Prof. Dr. Klaus Dorer
Prof. Dr. Stefan Wehr
Braun, Hannes: Analyse domänenseitiger Optimierungen für Deep Reinforcement Learning in der Robo- Cup Umgebung / Hannes Braun. – BACHELORARBEIT, Ohlsbach: Hochschule für Technik, Wirtschaft und Medien Offen- burg, 2021. 78 Seiten. Braun, Hannes: Analysis of domain-side optimizations for deep reinforcement learning in the RoboCup en- vironment / Hannes Braun. – BACHELOR THESIS, Ohlsbach: Offenburg University, 2021. 78 pages.
Eidesstattliche Erklärung Hiermit versichere ich eidesstattlich, dass die vorliegende Bachelor-Thesis von mir selbstständig und ohne unerlaubte fremde Hilfe angefertigt worden ist, insbesonde- re, dass ich alle Stellen, die wörtlich oder annähernd wörtlich oder dem Gedanken nach aus Veröffentlichungen, unveröffentlichten Unterlagen und Gesprächen ent- nommen worden sind, als solche an den entsprechenden Stellen innerhalb der Arbeit durch Zitate kenntlich gemacht habe, wobei in den Zitaten jeweils der Umfang der entnommenen Originalzitate kenntlich gemacht wurde. Ich bin mir bewusst, dass eine falsche Versicherung rechtliche Folgen haben wird. Ich bin damit einverstanden, dass meine Arbeit veröffentlicht wird, d. h. dass die Arbeit elektronisch gespeichert, in andere Formate konvertiert, auf den Servern der Hochschule Mannheim öffentlich zugänglich gemacht und über das Internet ver- breitet werden darf. Ohlsbach, 24.02.2021 Hannes Braun
Zusammenfassung Analyse domänenseitiger Optimierungen für Deep Reinforcement Learning in der RoboCup Umgebung Mit dem Team „magmaOffenburg“ nimmt die Hochschule Offenburg seit 2009 am internationalen Wettbewerb „RoboCup“ in der 3D-Simulationsliga für Fußball teil. Dabei kommt es vor allem auf den Einsatz guter Lauf- und Kickverhalten an. Seit 2019 ist es dem Team magmaOffenburg möglich auch Deep Reinforcement Lear- ning für die Weiterentwicklung der Verhalten einzusetzen. Während auf diese Wei- se schon verwendbare Ergebnisse für das Kicken produziert wurden, so fehlt noch ein Fortschritt beim Laufen lernen. Diese Arbeit beschäftigt sich mit den nötigen Optimierungen auf der Domänenseite, um das gelernte Laufen zu verbessern. Das beinhaltet die Optimierung des Observation- und Actionspaces, sowie auch eine Optimierung der Rewardfunktion. Dabei wurde versucht, die einzelnen Einflüsse verschiedener Parameter und Techniken innerhalb dieser drei Bereiche zu evalu- ieren. So konnte zum Schluss eine Verbesserung in der Laufgeschwindigkeit von etwas unter einem Meter pro Sekunde auf bis zu 1,8 Metern pro Sekunde erreicht werden. Ausschlaggebend für dieses Ergebnis waren vor allem der Verbesserungen in der Rewardfunktion.
Abstract Analysis of domain-side optimizations for deep reinforcement learning in the RoboCup environment With the team ’magmaOffenburg’, the Offenburg University is participating in the international competition ’RoboCup’ in the 3D simulation league for soccer since 2009. To archieve a great result, the team heavily relies on using well-trained be- haviors for their agents (e.g. kicking or walking). Since 2019, magmaOffenburg is also able to use deep reinforcement learning in order to further develop their beha- viors. Using deep reinforcement learning, the team was already able to score usable results in kicking. However, there is still a lack of progress for learning to walk. In this thesis, the required optimizations on the domain side were tested and evaluated in order to get a better result at walking. This includes optimizing the observation space as well as the action space. Furthermore, a lot of optimizations for the reward function will also be tested and evaluated. The goal was to get a clarification of the influence of the various parameters and the applied techniques on walking in the RoboCup domain. Finally, it was possible to improve the running speed from little under a meter per second to up to 1.8 meters per second. The main reason for this improvement were the optimizations in the reward function.
Inhaltsverzeichnis
1 Einführung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen 4
2.1 RoboCup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 PPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Lernarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Initiale Referenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Observationspace 13
3.1 Evaluierung der bereits vorhandenen Inputs . . . . . . . . . . . . . 13
3.1.1 Ableitungen . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2 Ball-Observation . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3 Observations für Kopf- und Armgelenke . . . . . . . . . . . 17
3.1.4 Zähler für Simulationszyklen . . . . . . . . . . . . . . . . . 18
3.2 Problemspezifische Inputs . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Center of Mass . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Abstand zwischen den Füßen . . . . . . . . . . . . . . . . . 21
3.2.3 Zähler für linker/rechter Fuß . . . . . . . . . . . . . . . . . 22
3.2.4 Torsohöhe . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5 Abweichung von der gewünschten Richtung . . . . . . . . . 25
3.2.6 Kombination verschiedener problemspezifischer Inputs . . . 27
3.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Actionspace 30
4.1 Mapping der Ausgabewerte . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Beine versus Arme und Beine . . . . . . . . . . . . . . . . . . . . 37
4.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Rewardfunktion 40
5.1 Ist-Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
vInhaltsverzeichnis
5.2 Dynamische Rewardfunktion . . . . . . . . . . . . . . . . . . . . . 43
5.2.1 Dynamisches Aufrechthalten . . . . . . . . . . . . . . . . . 43
5.2.2 Voraussetzung: Verbessertes Logging . . . . . . . . . . . . 46
5.2.3 Dynamische Gewichtung der Rewardkomponenten . . . . . 46
5.3 Steuern des Agenten auf niedrigerer Ebene mithilfe der Reward-
funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.1 Generelle Fußbewegung und Schrittdauer . . . . . . . . . . 56
5.3.2 Fußabstand . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.3 Schrittlänge . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Cycle-Reward versus Episode-Reward . . . . . . . . . . . . . . . . 65
5.5 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6 Weiterführende Entwicklung 68
6.1 Verdopplung der Netzwerkgröße . . . . . . . . . . . . . . . . . . . 68
6.2 Morphing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.3 Einbau in ein Spiel . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7 Fazit 75
8 Ausblick 77
Abkürzungsverzeichnis
Tabellenverzeichnis i
Abbildungsverzeichnis ii
Quellcodeverzeichnis iv
Literatur v
vi1. Einführung
Mit dem Team „magmaOffenburg“ unter der Leitung von Prof. Dr. Klaus Dorer
nimmt die Hochschule Offenburg seit 2009 am internationalen Wettbewerb „Ro-
boCup“ in der 3D-Simulationsliga für Fußball teil. Dabei sind über die Jahre im-
mer mehr mögliche Verhalten für einen Roboter (im weiteren Verlauf der Arbeit
auch Agent genannt) hinzugekommen. Während das anfangs zum Beispiel noch
ein manuell programmiertes Laufen war [1], so wurde dies über die Zeit immer
mehr erweitert. Für viele Jahre wurde dann genetisches Lernen eingesetzt, um die
verschiedenen Verhalten der Agenten weiter zu verbessern. Der Hauptfokus beim
Lernen lag hierbei meistens auf dem Kicken oder dem Laufen [2]. Seit Ende 2019
ist es dem Team magmaOffenburg auch möglich, Deep Reinforcement Learning für
das Lernen verschiedener Verhalten zu nutzen. Diese Arbeit setzt sich mit den do-
mänenseitigen Optimierungen bei der Nutzung von Deep Reinforcement Learning
auseinander.
1.1 Motivation
Durch den Einsatz von Deep Reinforcement Learning gelang es anderen Teams wie
dem FC Portugal oder den IT Androids in der Vergangenheit bereits Laufverhal-
ten mit Geschwindigkeiten von fast 4 Metern pro Sekunde zu erreichen [3] [4]. Im
Vergleich dazu liegt die Geschwindigkeit des schnellsten Laufverhaltens von mag-
maOffenburg bei „nur“ rund einem Meter pro Sekunde. Da Deep Reinforcement
Learning also große Verbesserungen versprach, wurde die Verwendung dessen auch
im magmaOffenburg-Code ermöglicht.
In einer vorigen Arbeit wurden von Martin Spitznagel bereits Optimierungsmög-
lichkeiten auf der Seite des Deep Reinforcement Learning Algorithmus’ PPO2 un-
tersucht. [5] Dagegen soll sich diese Arbeit jedoch mit den Optimierungen auf der
11 Einführung
Domänenseite beschäftigen. Das heißt anstatt die Parameter des Algorithmus zu
verändern, werden in dieser Arbeit die Ein- und Ausgabeparameter versucht zu op-
timieren.
Bis zum Beginn dieser Arbeit war es bereits möglich einen Kick zu lernen, mit
welchem der Ball in der Regel um circa acht Meter weit geschossen werden konn-
te. Dieser ist inzwischen auch bereits im Einsatz bei Wettkämpfen. Beim Laufen
hingegen sind die verzeichneten Fortschritte bisher eher noch gering und es be-
steht noch ein großes Verbesserungspotential. Aus diesem Grund wurden speziell
die Möglichkeiten zur Optimierung des Laufverhaltens in dieser Arbeit untersucht.
Dabei handelt es sich um ein modellfreies Laufen (im Gegensatz zu den bisher ver-
wendeten modellbasierten Laufverhalten).
1.2 Ziel
Wie schon angedeutet soll das Ziel dieser Arbeit das Lernen eines verbesserten
Laufverhaltens sein. Im besten Fall kann dieses mit den Laufverhalten der anderen
Teams konkurrieren oder diese sogar übertreffen. Sollte dann auch noch ein stabiler
Einbau in den Agentencode glücken (der Agent fällt beim Laufen nicht hin), so wäre
magmaOffenburg das vermutlich erste Team in der 3D-Simulationsliga, welchem
dies gelingt. Dies scheint bei den anderen Teams aktuell noch eines der größten
Probleme zu sein.
Konkret werden folgende Ziele angestrebt:
• Der Observationspace soll von kontraproduktiven Inputs befreit werden.
• Hilfreiche (teilweise problemspezifische) Inputs sollen dem Observations-
pace hinzugefügt werden, falls dies eine Verbesserung hervorruft.
• Der Einfluss des Mappings von den generierten Ausgabewerten des Deep Re-
inforcement Learning Algorithmus’ zu tatsächlichen Motorbefehlen für den
Agenten soll untersucht (und möglicherweise verbessert) werden.
• Die Rewardfunktion soll mithilfe von verschiedenen Techniken optimiert wer-
den. Dazu zählt zum Beispiel der Einsatz einer dynamischen Rewardfunktion.
Es soll auch untersucht werden, welchen Einfluss der Cycle-Reward im Ver-
gleich zum Episode-Reward hat.
21 Einführung
1.3 Aufbau
Der Aufbau dieser Arbeit gliedert sich im Groben wie folgt:
• In Kapitel 2 werden zunächst die notwendigen Grundlagen über die RoboCup-
Umgebung sowie das Lernen mittels Deep Reinforcement Learning vermit-
telt.
• Kapitel 3 beschäftigt sich mit den Optimierungen im Observationspace. Da-
bei wird im Wesentlichen die Effektivität vorhandener und neuer Inputs un-
tersucht.
• Kapitel 4 bildet quasi das Gegenstück zu Kapitel 3. Hier werden die Mög-
lichkeiten zur Optimierung im Actionspace untersucht. Das Hauptaugenmerk
liegt dabei auf dem Mapping der generierten Werte des Deep Reinforcement
Learnings zurück zu Befehlen, welche für die Steuerung eines Agenten ge-
nutzt werden können.
• Kapitel 5 dreht sich dann um die Optimierung der Rewardfunktion. Mithilfe
dieser werden kurz gesagt die ausgeführten Aktionen bewertet.
• In Kapitel 6 werden schließlich noch einige weiterführende Entwicklungen
beschrieben, welche zwar teilweise nicht mehr ganz zur domänenseitigen Op-
timierung des Deep Reinforcement Learnings gehören, aber dennoch wichtig
und interessant für das Entwickeln eines neuen Laufverhaltens sind.
• Kapitel 7 fasst schließlich die Ergebnisse dieser Arbeit nochmals kurz zusam-
men und gibt einen Überblick darüber, was aus dieser Arbeit gelernt/mitge-
nommen wurde.
• Kapitel 8 zeigt dann noch die Möglichkeiten zur weiteren Entwicklung des
hier erlernten Laufverhaltens in der Zukunft auf.
32. Grundlagen
Um ein besseres Verständnis der später angewandten Optimierungen zu erhalten,
werden in diesem Kapitel die dazu nötigen Grundlagen beschrieben. Das beinhal-
tet im Wesentlichen eine Beschreibung der RoboCup Umgebung, die eingesetzten
Technologien sowie die daraus resultierende Architektur. Anschließend wird die
Durchführung eines initialen Lernlaufs zum Vergleich erläutert.
2.1 RoboCup
Der RoboCup ist ein weltweiter Wettbewerb, bei dem Roboter in unterschiedlichen
Disziplinen gegeneinander antreten. Dazu zählt unter anderem das Fußballspielen.
Dieses wird erneut in verschiedene Ligen unterteilt, wie zum Beispiel die humanoi-
de Liga oder die Simulationsliga (2D oder 3D). Diese Arbeit beschäftigt sich mit
der 3D-Simulationsliga. Das Ziel des RoboCups ist es, bis 2050 mit Robotern gegen
Menschen im Fußball mit den offiziellen FIFA-Regeln gewinnen zu können. In der
Vergangenheit waren außerhalb des RoboCups ähnliche Erfolge bereits in anderen
Disziplinen wie zum Beispiel Schach und Go zu verzeichnen.
In der 3D-Simulationsliga werden Spiele mit elf Robotern je Team gespielt. Die
simulierten Roboter entsprechen dem Roboter Nao der Firma „SoftBank Robotics“.
Es gibt verschiedene Variationen dieses Roboters wie beispielsweise den NaoToe.
Diesem wurde an jedem Fuß ein zusätzliches Zehengelenk hinzugefügt. Zu sehen ist
er in Abbildung 2.1. Während die Darstellung aus der Simulationssoftware RoboViz
die am meisten Bekannte ist, so zeigen die anderen beiden Darstellungen, wie der
Roboter auf Gelenkebene zusammengesetzt ist.
Zur Simulation wird der quelloffene Server rcssserver3d1 [7] verwendet. Ursprüng-
lich entwickelt von Oliver Obst und Markus Rollmann an der Universität Koblenz,
1
RoboCup Soccer Simulation Server 3D
42 Grundlagen
Abbildung 2.1: Schematische Darstellung der Gelenke des NaoToe (links), Drahtgittermodell (mitte) und
Darstellung in RoboViz (rechts) [6]
wird er nun in der Regel gemeinschaftlich von den verschiedenen teilnehmenden
Teams weiterentwickelt. Streng genommen teilt sich der Server in zwei Teile auf.
Das ist zum einen Spark, ein generischer Simulator für physikalische Simulatio-
nen mit mehreren Agenten [8]. Dieses Basisframework wurde dann verwendet, um
darauf aufbauend die Fußballdomäne im rcssserver3d zu implementieren. Für die
Simulation der physikalischen Eigenschaften wird die Physikengine ODE2 genutzt.
Diese soll für eine möglichst realitätsgetreue Simulation des Spiels sorgen.
Für die Benutzung des Servers verbindet sich ein sogenannter Agent mit dem Ser-
ver über das Agentenprotokoll. Welche Version des Nao-Roboters verwendet wird,
muss nach einem Verbindungsaufbau mit dem Simulationsserver bei der Initialisie-
rung angegeben werden. Der Agent kann dann Befehle für den ihm zugeordneten
Roboter senden (beispielsweise an die Jointmotoren des Roboters) und die entspre-
chenden Sensordaten empfangen. Für eine realistischere Simulation wird den Sens-
ordaten Rauschen hinzugefügt (sofern sinnvoll). Neben Steuerbefehlen für die Ge-
lenkmotoren des Roboters sind zum Beispiel auch sogenannte „Say“-Nachrichten
möglich. Dabei handelt es sich um 20 Zeichen lange Nachrichten, welche an alle
Agenten in einem Radius von 50 Metern gesendet werden.
2
Open Dynamics Engine
52 Grundlagen
Zusätzlich gibt es das Monitorprotokoll. Über dieses können einerseits Informa-
tionen über die Simulation ohne Rauschen erhalten werden (zum Beispiel für die
Visualisierung, zu sehen in Abbildung 2.2). Andererseits kann über das Monitor-
protokoll auch in die Simulation eingegriffen werden, um Roboter (oder den Ball)
an beliebige Stellen zu beamen/teleportieren oder den Spielmodus zu verändern (um
beispielsweise das Spiel zu starten). Vom Agenten darf das Protokoll während ei-
nes Spiels nicht genutzt werden. Während des Lernens besteht diese Beschränkung
jedoch nicht.
Abbildung 2.2: RoboViz-Screenshot eines Spiels der 3D-Simulationsliga
Mithilfe der Software RoboViz [9] lässt sich die Simulation durch Verwendung des
Monitorprotokolls visualisieren. Dieses Tool wurde initial von Justin Stoecker ent-
wickelt und wird nun hauptsächlich vom Team magmaOffenburg weiterentwickelt.
RoboViz beinhaltet zusätzlich eine weitere Schnittstelle, um einige weitere Infor-
mationen in die Visualisierung vom Agenten aus einzuzeichnen. [10] Auf diese
Weise können agenteninterne Werte einfach in der Visualisierung dargestellt bezie-
hungsweise repräsentiert werden.
Die gesamte Simulation läuft in Zyklen mit je einer Länge von 20 Millisekunden
ab. Ein Agent kann demnach eine Steuernachricht alle 20 Millisekunden an den
Server senden. Ebenfalls empfängt er prinzipiell alle 20 Millisekunden die Sensor-
daten sowie weitere Daten zur Wahrnehmung. Praktisch werden aber nur in jedem
62 Grundlagen
dritten Zyklus die Informationen zur visuellen Wahrnehmung des Agenten über das
Agentenprotokoll übermittelt.
2.2 PPO
Seit 2019 ist das Team magmaOffenburg in der Lage, Deep Reinforcement Lear-
ning einzusetzen. Die gewählte Algorithmenfamilie hierfür war seit Anfang an be-
reits PPO3 , welche 2017 von Schulman et.al. zum ersten Mal vorgestellt wurde.
[11] Genauer gesagt wurde für die Implementierung PPO2 aus „Stable Baselines“
[12] (Version 2.9.0), eine Sammlung verschiedener Deep Reinforcement Learning
Algorithmen, verwendet. PPO2 ist eine optimierte Version von PPO, welche zum
einen für die Verwendung mit Grafikkarten optimiert wurde. Zum anderen ist es mit
PPO2 möglich parallele Umgebungen zu verwenden. Konkret heißt das in diesem
Fall, dass in verschiedenen Threads dann mehrere Agenten gestartet werden, wel-
che dann in der Lage sind gleichzeitig zu lernen. Das soll die Lerngeschwindigkeit
enorm verbessern.
Vereinfacht gesagt funktioniert PPO2 folgendermaßen: eine sogenannte Observa-
tion wird als Eingabe für den Algorithmus verwendet. Dabei handelt es sich um
nichts weiter als eine geordnete Menge von Werten im Bereich -1 bis 1. Diese die-
nen als Wahrnehmung beziehungsweise Beschreibung der Umgebung. PPO2 ent-
scheidet basierend auf der Observation dann, welche Aktion(en) ausgeführt werden
soll(en). Diese werden ebenfalls wieder als geordnete Menge von Werten von -1 bis
1 beschrieben.
Das Mapping für die Observations und die Actions könnte für einen Agenten in
der 3D-Simulationsliga im einfachsten Fall ungefähr so aussehen: die Positionen
beziehungsweise die Winkel der Gelenkmotoren können jeweils als Observation
verwendet werden. -1 repräsentiert dabei den minimal möglichen Winkel und 1 den
maximal möglichen Winkel des Gelenks. Der Actionspace wiederum könnte einen
Wert pro Gelenkmotor beinhalten. Jeder Wert repräsentiert dabei die Geschwindig-
keit eines Gelenks. -1 und 1 repräsentieren die beiden maximalen Geschwindigkei-
ten für jede Richtung.
Wurde eine Aktion ausgeführt, so muss diese mittels eines sogenannten Rewards
bewertet werden. Dies ist ein numerischer Wert. Ein Wertebereich ist nicht definiert
3
Proximal Policy Optimization
72 Grundlagen
(ausgenommen von den Grenzen des für den Reward verwendeten Datentyps). Ein
höherer Rewardwert steht für eine bessere Bewertung. Im Laufe des Lernens wird
dann ein möglichst hoher Rewardwert angestrebt. Das soll die ausgeführten Aktio-
nen möglichst verbessern.
Die Kombination aus dem Senden einer Observation, dem Ausführen einer Acti-
on sowie dem Bewerten der ausgeführten Action mittels Reward ist ein Schritt.
Ein Schritt enthält somit auch immer genau einen Simulationszyklus. Das Lernen
von verschiedenen Verhaltensweisen lässt sich dann wieder in sogenannte Episo-
den zeitlich aufteilen. Eine Episode beinhaltet mehrere Schritte/Simulationszyklen.
Sie erstreckt sich in der Regel über die Dauer eines einmaligen Ausführens des zu
lernenden Verhaltens.
In dieser Arbeit liegt der Fokus auf der domänenseitigen Optimierung, bei der PPO
im Wesentlichen als Blackbox verwendet wurde. Eine genauere Beschreibung von
PPO findet sich in [5].
2.3 Lernarchitektur
Zum Lernen mittels PPO bzw. Deep Reinforcement Learning wird im „norma-
len“ magmaOffenburg-Code (geschrieben in Java) eine TCP-Verbindung zu einem
Python-Prozess hergestellt. Dieser ist im Wesentlichen dafür zuständig, mit dem
Java-Prozess zu kommunizieren und den PPO2-Algorithmus von Stable Baselines
auszuführen.
Nach jedem Simulationszyklus werden vom Java-Prozess die Observations an den
Python-Prozess gesendet. Dieser gibt diese als Inputs an PPO2 weiter. Die resul-
tierenden Aktionen werden dann an den Java-Prozess zurückgesendet und in der
Simulation ausgeführt. Anschließend wird der aus der Aktion resultierende Reward
berechnet und zusammen mit der neuen Observation an den Python-Prozess zu-
rückgesendet. Die dabei zu übertragenden Daten werden als JSON4 -Dokument mit
führendem Header für die Länge des JSON-Dokuments codiert.
Sobald die Verbindung zum Python-Prozess besteht, verbindet sich der Agent ganz
normal mit dem Simulationsserver und bringt sich in die Startposition. Ab hier wird
die Steuerung der Motoren dem Deep Reinforcement Learning Algorithmus über-
4
JavaScript Object Notation
82 Grundlagen
lassen und die Episode beginnt. Sobald der Agent hinfällt wird die Episode beendet.
Passiert dies nicht, so wird die Episode nach 10 Sekunden Laufzeit alternativ been-
det.
Zum Monitoring kann die Software Tensorboard eingesetzt werden, welche auch
offiziell von Stable Baselines unterstützt wird. Mithilfe dieser lässt sich der Re-
wardgraph des bisherigen Lernvorgangs (sowie die Graphen einiger weiterer Werte)
ansehen. Das macht es einfacher zu entscheiden, wann ein Lernlauf beendet wer-
den kann. Oft steigt ein Reward nach einer Zeit nicht mehr (signifikant) weiter an.
In diesem Fall kann man davon ausgehen, dass das gelernte Ergebnis sich ebenfalls
nicht mehr verbessert und ein Abbruch ist entsprechend sinnvoll.
Vom Python-Prozess beziehungsweise Stable Baselines wird in regelmäßigen Ab-
ständen das generierte Modell in einer ZIP-Datei abgespeichert/aktualisiert. Möchte
man das Lernen abbrechen, so kann der Prozess ohne Weiteres beendet werden. Es
ist ebenfalls möglich, dieses Modell später wieder zu laden, um von diesem Stand
aus das Lernen fortzuführen. Vor allem im Falle eines Absturzes kann das sehr hilf-
reich sein, da man den Fortschritt der letzten Tage nicht verliert und nicht wieder
von vorne beginnen muss. Eine Übersicht über diese Architektur ist in Abbildung
2.3 dargestellt.
Abbildung 2.3: Grundlegende Architektur während des Lernens mit Deep Reinforcement Learning
Im Falle dieser Arbeit wird jedoch bei jedem Lernlauf von Null gestartet, das heißt
es wird nicht von einem bestehenden Modell aus gelernt. Das hat zum einen den
Grund, dass sich immer wieder der Observation- sowie Actionspace ändert. Nach
solch einer Änderung ist die Verwendung eines bestehenden Modells nicht mehr
möglich. Außerdem kann man so bessere Vergleiche zwischen verschiedenen Lern-
läufen durchführen.
92 Grundlagen
Neben dem aktuellen Modell wird auch immer das beste Modell beibehalten, falls
sich das Ergebnis mit der Zeit wieder verschlechtert haben sollte. Dazu wird bei
jedem Speichervorgang der Mittelwert des Rewards von den aktuell letzten 100
Episoden gebildet. Sollte dieser Wert besser sein als der Wert des bisherigen besten
Modells, so wird dieses Modell als bestes Modell zusätzlich abgespeichert.
Zur Laufzeit wird später kein Python-Prozess mehr benötigt. Stattdessen wird das
generierte Modell in ein anderes Format konvertiert. Dieses kann dann einfach wie-
der vom Magma- beziehungsweise Agentencode gelesen/verwendet werden.
2.4 Initiale Referenz
Um die Ergebnisse der ersten Lernläufe überhaupt bewerten zu können, muss zu-
nächst eine initiale Referenz (Baseline) existieren. Dazu wurde ohne jegliche Än-
derungen vorzunehmen, ein (synchroner) Lernlauf gestartet. Dieser lief über eine
Dauer von circa sieben Tagen. Solch eine lange Lerndauer ist allerdings eher un-
praktikabel.
Statt synchronem Lernen wurde ab hier stattdessen auf asynchrones Lernen ge-
wechselt. Dabei muss nur ein festgelegter Prozentsatz der Threads fertig mit der
Ausführung des Laufens sein, um eine Episode abzuschließen/zu beenden. Dieser
wird im weiteren Verlauf als Threshold bezeichnet. Auf diese Weise konnte eine
deutliche Beschleunigung des Lernvorgangs erreicht werden. So hat das asynchro-
ne Lernen pro Versuch „nur“ noch circa drei bis vier Tage in Anspruch genommen.
Dabei wurden auch circa doppelt so viele Episoden durchgeführt als beim synchro-
nen Lernen in sieben Tagen.
Zur Ermittlung des Thresholds beim asynchronen Lernen wurden in einer Vorun-
tersuchung drei verschiedene Prozentsätze ausprobiert (wie in Abbildung 2.4 zu
sehen). Es ist zu erkennen, dass der Unterschied im Reward zwischen den einzel-
nen Ergebnissen relativ gering ist. Für den weiteren Verlauf der Arbeit wurde ein
Threshold von 80% gewählt, da dieser den Lernvorgang im Vergleich zu einem
Threshold von 90% nochmals leicht beschleunigt. Ein Threshold von 70% bringt
im Vergleich zu einem Threshold von 80% kaum mehr einen Geschwindigkeitsvor-
teil. Eher überwiegt hier dann die Sorge, dass zu viele Daten verloren gehen, da die
Ergebnisse von nicht fertigen Threads mit Nullwerten aufgefüllt werden.
102 Grundlagen
Abbildung 2.4: Rewards der Referenzlernläufe
Anschließend wurden zwei weitere Lernläufe mit einem Threshold von 80% aus-
geführt, um zu ermitteln wie stark das Ergebnis beziehungsweise der Reward über
mehrere identische Lernläufe hinweg variiert. In Abbildung 2.4 ist zu erkennen,
dass diese Varianz leider relativ groß ist. Aus diesem Grund sollte ein Ergebnis spä-
ter einen entsprechend deutlichen Unterschied zum vorherigen Stand aufweisen um
diesem Ergebnis dann auch Bedeutung zusprechen zu können.
Ebenfalls wichtig zu erwähnen ist an dieser Stelle, dass die in Abbildung 2.4 dar-
gestellten Lernläufe mit einer Ausnahme alle mit 24 Threads durchgeführt wurden.
Der Lernlauf mit 12 Threads hat einige Besonderheiten, welche für den weiteren
Verlauf der Arbeit durchaus relevant sind zu erwähnen. Es wurden hier 12 Threads
gewählt, da der Lernlauf auf einer schwächeren Hardware als die anderen Lernläu-
fe ausgeführt wurde. Im Verlauf der Arbeit stellte sich jedoch heraus, dass auch auf
dieser Instanz das Verwenden von 24 Threads kein Problem darstellt. Ebenfalls lie-
ferten 12 Threads ein bedeutend schlechteres Ergebnis als 24 Threads. Das heißt,
dass einige Lernergebnisse im Verlauf dieser Arbeit schlechter waren als das theo-
retisch erzielbare Ergebnis mit 24 Threads.
112 Grundlagen
Zudem befand sich der gerade erwähnte Server zunächst ungewollt beziehungswei-
se unbewusst im sogenannten Realtimemodus. Dieser sorgt dafür, dass eine Simula-
tion maximal so schnell ablaufen kann, wie sie in der echten Welt ablaufen würde.
Das Deaktivieren dieses Modus führt in der Regel zu einer deutlichen Beschleu-
nigung der Simulation und somit auch zu einer Beschleunigung des Lernens, da
der Simulationsserver dann die meiste Rechenzeit beansprucht. Das bedeutet im
Umkehrschluss, dass durch den aktivierten Realtimemodus einige Lernläufe stark
verlangsamt wurden. Ein Beispiel dafür ist, wie bereits erwähnt, in Abbildung 2.4
sowie auch in späteren Plots (zum Beispiel Abbildung 3.1) zu sehen. Diese Lernläu-
fe wurden meist nach circa 7 Tagen abgebrochen und erreichten deutlich weniger
Episoden in der gleichen Zeit wie vergleichbare Lernläufe.
123. Observationspace
Zunächst sollte der Observationspace für PPO2 untersucht beziehungsweise opti-
miert werden. Dafür wurde versucht, manche dieser Observations zu entfernen und
einige Neue hinzuzufügen, um deren Wirksamkeit zu testen. Das Vergleichen von
Lernläufen lässt sich hierbei relativ gut mit dem Vergleich der Rewards realisieren.
3.1 Evaluierung der bereits vorhandenen Inputs
Zum Start dieser Untersuchungen waren logischerweise bereits Observationinputs
vorhanden. Im folgenden Abschnitt wird die Effektivität dieser untersucht. Auf die-
se Weise sollen die möglicherweise unnötigen oder kontraproduktiven Inputs ent-
fernt werden, um im Umkehrschluss ein besseres Ergebnis/Laufen zu erhalten.
Doch zunächst ist eine Übersicht über die Parameter notwendig, welche überhaupt
initial als Observation vorhanden waren. Diese sind in Tabelle 3.1 aufgelistet.
Parameter Anzahl
Winkel der Jointmotoren 24
Geschwindigkeit der Jointmotoren (Ableitung der Winkel) 24
Zähler für Simulationszyklen 1
Ballposition 3
Foot-Force-Informationen 48
Beschleunigungssensordaten 3
Gyroskopdaten 3
Torsoinformationen 3
Parameter zum Lenken 2
Summe 111
Tabelle 3.1: Initialer Inhalt des Observationspaces
133 Observationspace
Als Basis werden die aktuellen Positionen/Winkel der Jointmotoren des Agenten
genutzt. Daraus lässt sich durch Speichern des Werts im vorherigen Simulationszy-
klus eine Ableitung bilden, diese repräsentiert die aktuellen Geschwindigkeiten der
Motorgelenke.
Zur Codierung eines dreidimensionalen Vektors werden die x-, y- sowie z-Werte als
einzelne Werte für die Observation verwendet. Diese Codierung wurde zum Bei-
spiel bei der Übermittlung der Ballposition oder der Beschleunigungssensordaten
verwendet.
Die sogenannten Foot-Force-Informationen geben an wie viel Kraft auf eine der
Fußflächen wirkt. Hierfür gibt es vier Sensoren: links und rechts existiert jeweils
ein Sensor für die Kraft, welche auf den Fuß wirkt sowie ein Sensor, welcher die
Kraft misst, welche auf den Zeh des NaoToe wirkt. Es kann pro Sensor jeweils ein
Vektor für die Kraft sowie dem Punkt auf der Fußfläche ausgelesen werden. Davon
werden jeweils noch die Ableitungen gebildet.
Die restlichen Parameter sollten entweder selbsterklärend sein oder werden in den
folgenden Abschnitten näher erläutert.
3.1.1 Ableitungen
Um zum Beispiel Informationen über die Geschwindigkeit zu erhalten, wurden, wie
zuvor erwähnt, in der Vergangenheit verschiedene Inputs des Observationspaces
abgeleitet und ebenfalls als eigene Observation Inputs verwendet.
Zunächst wurde versucht, diese Ableitungen gänzlich aus den Observations zu ent-
fernen. Dies hat sich jedoch im ersten Moment augenscheinlich als eher unpraktisch
erwiesen. Ebenfalls wurde schon im Voraus ein schlechteres Ergebnis erwartet, da
nun viele Informationen über Geschwindigkeiten fehlen, welche aber als relativ
wichtig für das Lernergebnis eingeschätzt wurden. Im Code war es dank einer guten
Strukturierung glücklicherweise lediglich nötig, eine einzige Zeile auszukommen-
tieren, um einen Lernlauf ohne Ableitungen durchzuführen.
Dieser Lernlauf war allerdings von dem in Abschnitt 2.4 beschriebenen Problem
(falsche Threadanzahl sowie aktivierter Realtimemodus) betroffen und erzielte so-
mit ein vermutlich schlechteres Ergebnis als eigentlich möglich gewesen wäre. Zu
sehen ist das Ergebnis in Abbildung 3.1. Aus Zeitgründen konnte dieser Versuch
leider nicht wiederholt werden.
143 Observationspace
Abbildung 3.1: Rewards der Lernläufe mit Veränderungen der Ableitungen im Observationspace
Ebenfalls wurden zwei weitere Versuche durchgeführt, um herauszufinden, was pas-
siert, wenn nur manche Ableitungen verwendet werden. Bei einem dieser Lernläufe
wurden nur Ableitungen für den Beschleunigungssensor und das Gyroskop verwen-
det. Bei einem weiteren Lernlauf wurde nur die Ableitung der Foot-Force-Sensoren
verwendet. In beiden Fällen waren die Ergebnisse etwa ähnlich, welche auch in
Abbildung 3.1 zu sehen sind.
Trotz eines eher nicht interpretierbaren Versuches war aber absehbar, dass die Ab-
leitungen in gewisser Weise hilfreich sind oder sie zumindest den Lernprozess nicht
behindern. Auch wenn die beiden Rewardkurven mit nur einem Teil der Ableitun-
gen besser abgeschnitten haben, so ist trotzdem zu bedenken, dass diese Ergebnisse
durch ein Rauschen zustande gekommen sein könnten. Deshalb wurde die Annah-
me gemacht, dass die Ableitungen grundlegend hilfreich sind und soweit beibehal-
ten werden sollten.
153 Observationspace
3.1.2 Ball-Observation
Bei jedem der zuvor genannten Versuche, bei welchen Ableitungen entfernt wurden,
wurde auch in jedem Fall die Ableitung für die Ballposition mit entfernt. Da der Ball
für das Laufen lernen an eine Position außerhalb des Spielfeldes gebeamt wird, ist
dessen Position (sowie auch dessen Ableitung) statisch und somit eigentlich nicht
weiter relevant. Aus diesem Grund wurde ebenfalls versucht, die Observation für
die Ballposition sowie dessen Ableitung zu entfernen.
Leider war auch dieser Lernlauf von dem zuvor erwähnten Problem mit der falschen
Threadanzahl und dem aktivieren Realtimemodus betroffen und erzielte somit ein
relativ schlechtes Ergebnis (siehe Abbildung 3.2). Trotzdem scheint es nur logisch,
dass die Observation des Balls in diesem Fall keinerlei Vorteile mit sich bringen
dürfte. Der Lernlauf wurde deshalb nochmals mit der Verwendung von 24 Threads
und deaktiviertem Realtimemodus wiederholt. In Abbildung 3.2 sieht man nun die
doch relativ deutliche Verbesserung dieser Änderung. Deshalb wurde das Entfer-
nen dieses Inputs als eine Verbesserung gewertet. Die Ball-Observation wurde für
spätere Versuche dann auch nicht mehr weiterverwendet.
Abbildung 3.2: Reward des Lernlaufs ohne Ball-Observation
163 Observationspace
3.1.3 Observations für Kopf- und Armgelenke
Bisher waren zusammen mit den anderen Werten der Gelenke des Agenten ebenfalls
die Werte der Kopf- und Armgelenke in der Observation enthalten. Vor allem der
Kopf wird eher als irrelevant für das Laufen angesehen, da sich dieser während des
Laufens unabhängig vom Laufen bewegen kann. Das passiert in der Regel durch
das Fokussieren des Kopfs (beziehungsweise der Kamera im Kopf) auf den Ball.
Aufgrund der hohen Lerndauer wurden aber lediglich zwei Lernläufe durchgeführt,
in welchen jedes Mal sowohl Kopf- als auch Arm-Observations entfernt wurden. Es
wurde dabei zwei Mal ein gleicher Lauf durchgeführt, um die „zufälligen“ Ergeb-
nisse des Lernens ein wenig zu kompensieren.
Das Experiment bringt leider erneut keine sehr deutlichen Ergebnisse. Ein Lernlauf
deckt sich ziemlich genau mit der Referenzversion, welche die Observations noch
enthält. Der andere Lauf lieferte ein leicht schlechteres Ergebnis. Es wird gerade
hier auch nochmals deutlich wie viel Rauschen diese Lernläufe beinhalten können.
Eine Interpretation der Ergebnisse muss stets damit im Hinterkopf durchgeführt
werden.
Abbildung 3.3: Reward der Lernläufe mit und ohne Kopf- und Arm-Observation
173 Observationspace
Somit konnte nun also noch kein wirklich signifikanter Unterschied festgestellt wer-
den. Darum wurde auch für diese Observations die Annahme gemacht, dass sie oh-
ne weitere Probleme entfernt werden können. Damit wurde die Hoffnung verfolgt,
dass sich dadurch auch die Lerndauer etwas verbessern könnte, da der Suchraum
dadurch verkleinert wird. Gleichzeitig scheint es aber auch mehr oder weniger lo-
gisch, dass der Kopf eigentlich nicht als Input benötigt werden sollte. Gleiches gilt
auch für die Arme, vorausgesetzt man möchte deren Bewegung nicht auch noch mit
lernen (siehe Abschnitt 4.2).
3.1.4 Zähler für Simulationszyklen
Um eine zeitliche Wahrnehmung bereitzustellen, war bisher ein Zähler für Simula-
tionszyklen als Observationinput vorhanden. Dieser zählt die vergangenen Zyklen
des Simulationsservers seit Beginn der Ausführung des Laufens. Wird eine Episode
beendet, so wird auch dieser Zähler wieder zurückgesetzt. Die vergangenen Zyklen
während der Initialisierung des Agenten vor einer Episode werden von diesem Zäh-
ler nicht berücksichtigt, da diese für das Lernen nicht relevant sind.
Es liegt nahe, dass dieser Zähler relativ wichtig zum Lernen ist, da ein zeitlicher Be-
zug ansonsten fehlen würde. Dieser könnte beispielsweise benötigt werden, um zu
Beginn erst langsam anzulaufen, sodass der Agent durch die Beschleunigung nicht
direkt umfällt. Später könnte er sich dann erst schneller fortbewegen. Zur Verifizie-
rung der Annahme, dass der Input wirklich benötigt wird, wurde zum Vergleich ein
Lernlauf ohne diesen Input durchgeführt.
Das Ergebnis ist in Abbildung 3.4 zu sehen. Während der Reward des Lernlaufs
ohne Zähler für die Simulationszyklen in der ersten Million Episoden gleich auf ist
(beziehungsweise sogar minimal besser), so lässt sich aber auch relativ deutlich er-
kennen, dass das Laufen ohne den Zähler ab circa 1,5 Millionen Episoden merkbar
schlechter wird als das Laufen mit Zähler für die vergangenen Simulationszyklen.
Auch beim Ansehen des daraus gelernten Laufens fiel auf, dass das Laufen bei feh-
lendem Zähler unkoordinierter aussieht als bei dem Vergleichslauf. Es ist deshalb
ziemlich klar, dass dieser Zähler als Observationinput beibehalten werden sollte.
183 Observationspace
Abbildung 3.4: Reward der Lernläufe mit und ohne Zähler für Simulationszyklen als Observation
3.2 Problemspezifische Inputs
Die bisher evaluierten Observationinputs sind generelle Inputs und können für jedes
beliebige Problem beim Lernen verwendet werden (zum Beispiel laufen, dribbeln
oder kicken). Je nach Problem kann es jedoch nötig sein, einige spezielle Inputs zu
verwenden, deren Einsatz nur für ein bestimmtes Problem sinnvoll ist. Die Wirk-
samkeit einiger möglicher problemspezifischer Inputs für das Laufen wird im Fol-
genden untersucht.
3.2.1 Center of Mass
Aus einer Publikation von Luckeciano C. Melo und Marcos R. O. A. Máximo des
Teams „IT Androids“ war bereits bekannt, dass der „Center of Mass“ (dt. Massen-
schwerpunkt) eine hilfreiche Observation sei. So soll diese dabei geholfen haben,
einerseits den Lernvorgang zu beschleunigen. Andererseits seien durch diese Ob-
servation aber auch schnellere Bewegungen des Roboters zustande gekommen.[4]
193 Observationspace
Bei dem Center of Mass handelt es sich um einen Wert, welcher berechnet wird
durch das Gewichten der Koordinaten der einzelnen Körperteile des Roboters (Mul-
tiplikation der Koordinaten mit der zugehörigen Masse). Diese gewichteten Koor-
dinaten werden anschließend summiert und durch die Gesamtmasse des Roboters
dividiert. Damit erhält man zum Schluss eine 3D-Koordinate, welche wiederum als
Observation verwendet werden kann.
Das Verwenden dieses Inputs könnte dazu beitragen, dass der Agent ein Umfal-
len besser ermitteln und verhindern kann. Das würde auch der Beschreibung von
Melo und Máximo entsprechen. Trotz der vielversprechenden Aussage des Team
IT Androids war jedoch keine wirklich messbare Verbesserung festzustellen. Auch
optisch lässt sich kaum eine Verbesserung zu den vorherigen Versuchen feststellen.
Ein Video des hierbei gelernten „Laufens“ ist online verfügbar1 .
Abbildung 3.5: Reward des Lernlaufs mit dem Center of Mass als Observation
Der Rewardgraph in Abbildung 3.5 zeigt, dass das Ergebnis genau zwischen den
beiden Vergleichslernläufen ohne dem Center of Mass als Input liegt. Man kann
also davon ausgehen, dass sich aktuell durch die Verwendung dieses Inputs nichts
1
https://www.youtube.com/watch?v=hlFPVoR7bbw
203 Observationspace
wirklich ändert. Das war der Grund, weshalb es auch nicht als Problem angese-
hen wurde, diesen Input für die Zukunft beizubehalten. Die Idee dabei war, dass
der Input sich aktuell noch nicht auf das Ergebnis auswirkt. Bei besseren Ergebnis-
sen in der Zukunft könnte jedoch ein (hoffentlich positiver) Unterschied hierdurch
hervorgerufen werden.
3.2.2 Abstand zwischen den Füßen
Ebenfalls wichtig für ein gutes und stabiles Laufen könnte der Abstand zwischen
den Füßen (orthogonal zur Laufrichtung) des Roboters sein. Diese Vermutung wur-
de zumindest zu Beginn der Untersuchungen aufgestellt. Besonders dann, wenn
der Fußabstand zu klein wird, könnte das Laufen instabiler werden, da es für den
Agenten viel einfacher ist, zur Seite zu kippen. Aber auch ein zu großer Abstand
zwischen den Füßen ist nicht unbedingt hilfreich und könnte das Laufen negativ
beeinflussen.
Des Weiteren ist bezüglich des Abstandes zwischen den Füßen problematisch, dass
seit 2019 auch Selbstkollisionen in der Simulation existieren. Dabei handelt es sich
um eine Situation in der zwei (oder mehr) der Körperteile des Agenten miteinan-
der kollidieren. Das ist bis zu einem gewissen Grad in der Simulation grundsätzlich
möglich. Seit 2019 wurde jedoch eine Überprüfung für Selbstkollisionen einge-
führt. Dabei gibt es noch eine Toleranzgrenze von 4 cm. [13]
Das bedeutet, dass Körperteile sich bis zu 4 cm ineinander überschneiden dürfen.
Wird dieser Wert überschritten, so zählt dies als Foul und der Agent wird bestraft
indem seine Gelenke für dieses Körperteil in die nächste Sekunde eingefroren wer-
den. Der verringerte Abstand zwischen den Füßen kann eben zu genau solch einer
Selbstkollision und einem darauf folgenden Foul führen. Ein Einfrieren der Gelenke
hat beim Laufen (abhängig von der aktuellen Körperpose des Agenten) wiederum
die mögliche Folge, dass der Agent umfällt.
Um diese beiden Probleme möglicherweise etwas zu umgehen, wurde versucht den
Abstand zwischen den Füßen als Observationinput zu verwenden. Das Ziel bezie-
hungsweise die Hoffnung bei diesem Versuch war, dass der Agent eigenständig er-
kennt, dass bei einem zu geringem Fußabstand die Stabilität des Laufens abnimmt
und die Fallrate zunimmt.
213 Observationspace
Auch dabei stellte sich allerdings wieder heraus, dass das Ergebnis zwischen den
beiden Lernläufen ohne den neu hinzugefügten Input liegt (siehe Abbildung 3.6).
Abbildung 3.6: Reward des Lernlaufs mit dem Abstand zwischen den Füßen als Observation
Wie zuvor wurde auch dieser Input wieder beibehalten, da man sich später eine
möglicherweise positive Auswirkung davon versprach und er aktuell nicht zu ei-
ner spürbaren Verschlechterung beiträgt. Tatsächlich stellte sich auch in Abschnitt
3.6) heraus, dass der Fußabstand korrigiert/vergrößert werden muss. Zur Erreichung
dieses Ziels ist dieser Input mit Sicherheit keine schlechte Idee.
3.2.3 Zähler für linker/rechter Fuß
Eine weitere Erkenntnis aus der Veröffentlichung von Melo und Máximo war, dass
ein Zähler für den linken beziehungsweise rechten Fuß als Input nützlich sein kön-
ne, um die Symmetrie zwischen beiden Beinen/Füßen aufrecht zu erhalten. [4]
Dieser beschriebene Zähler zählt im Prinzip ähnlich wie auch der normale Zäh-
ler für die vergangenen Simulationszyklen. Allerdings wird er zusätzlich zurückge-
setzt, sobald der Roboter das Standbein wechselt. Konkret heißt das, dass wenn der
223 Observationspace
Roboter im letzten Zyklus auf dem linken Fuß stand und im aktuellen Zyklus auf
dem rechten Fuß steht, so wird der Zähler auf 0 zurückgesetzt.
Auf welchem Bein beziehungsweise Fuß der Roboter aktuell steht kann relativ ein-
fach über die beiden Foot Force Sensoren ermittelt werden. Geben diese einen Wert
von mehr als 0 Newton zurück, so wird der zugehörige Fuß aktuell belastet. Der
mögliche Wertebereich für das Mapping in den Observation wurde dabei auf 0 bis
50 gesetzt. Es wird davon ausgegangen, dass eine Schrittdauer von mehr als 50 Si-
mulationszyklen (was einer Sekunde entspricht) nicht vorkommen sollte. Passiert
dies dennoch, so ist lediglich dieser Input nicht mehr ganz korrekt. Dies sollte in
diesem Fall aber auch kein Problem mehr sein, da die Vermutung nahe liegt, dass
der Agent dann sowieso unvorhergesehene Probleme beim Laufen haben sollte, die
hier nicht weiter beachtet werden sollten.
Abbildung 3.7: Reward des Lernlaufs mit dem Zähler die Füße als Observation
Der Rewardgraph in Abbildung 3.7 zeigt wieder eine nahezu deckungsgleiche Kur-
ve (bezogen auf den Vergleichslernlauf). Auffällig ist lediglich, dass anfänglich der
Reward für eine Zeit lang etwas schlechter ausfällt. Zum Ende hin ist die Tendenz
zum weiteren Anstieg der Kurve etwas geringer bei der Version mit dem Zähler für
233 Observationspace
die Füße als Input. Dennoch handelt es sich dabei nur um marginale Abweichungen,
welche mit sehr hoher Wahrscheinlichkeit dem Rauschen zu verdanken sind. Wie
auch bei den anderen Ergebnissen wird dieses in der Hoffnung auf einen späteren
Profit daraus zunächst beibehalten.
3.2.4 Torsohöhe
Die Torsoorientierung war bereits in der Observation vorhanden. Allerdings wurde
für die Versuche von Melo und Máximo auch die Torsohöhe als Input verwendet.
[4]
Die Torsohöhe lässt sich relativ einfach bestimmen. Da die Position eines Roboters
streng genommen der Position seines Torsos entspricht, konnte aus der globalen
Position des Roboters die z-Koordinate für diesen Input verwendet werden. Von der
Verwendung einer globalen Position sollte normalerweise im Bezug auf Observa-
tioninputs abgesehen werden. Diese bergen die Gefahr, dass das gelernte Modell
später im Spiel nicht mehr einsetzbar ist, da nun abweichende globale Positionen
als Input verwendet werden. Im Fall der z-Koordinate ist das jedoch nicht weiter
ein Problem, da das Fußballfeld eine ebene Fläche ist.
Die Verwendung dieses Inputs könnte hilfreich sein, um die Bestimmung der Kör-
perlage des Agenten weiter zu vereinfachen. Besonders zur Verhinderung des Um-
fallens könnte dieser Input beitragen, da ein niedriger Wert logischerweise oft auch
zu einem Umfallen führt. Eine Ausnahme wäre dabei, wenn der Agent zum Beispiel
lernt sich hinzusetzen.
Wie auch in den vorigen Versuchen ist weder ein signifikanter Fortschritt noch ein
signifikanter Rückschritt zu erkennen. Das Gleiche spiegelte sich auch beim Ver-
gleich der beiden Laufverhalten mittels RoboViz wider. Auch wenn bei der Ver-
wendung der Torsohöhe als Input ein etwas besserer Reward erzielt werden konnte,
so ist dies vermutlich erneut dem Rauschen der Umgebung zuzuschreiben. Es war
jedoch abzusehen, dass auch hiermit kein Rückschritt unternommen wurde. Des-
halb wurde der Input für weitere Versuche ebenfalls beibehalten.
243 Observationspace
Abbildung 3.8: Reward des Lernlaufs mit Torsohöhe als Observation
3.2.5 Abweichung von der gewünschten Richtung
Im Verlauf der Arbeit, nach einigen Versuchen mit der Rewardfunktion, zeigte sich
ein immer schwerwiegenderes Problem: während des Laufens wich der Agent von
seiner eigentlichen Bahn ab. Eigentlich ist das Ziel, möglichst geradeaus in der
Mitte des Feldes zu laufen. Durch das erlernte Laufen zeigte sich jedoch nun ein
Abdriften des Agenten um oft bis zu acht Meter zur Seite. Das ist vor allem auch
beim Einsatz im Spiel sehr ungünstig, da der Agent nun schlussendlich nicht mehr
an der eigentlichen Position landet, zu welcher er sich hinbewegen wollte.
Um dieser Entwicklung entgegenzuwirken, wurde genau diese Abweichung ver-
sucht mittels eines Observationinputs darzustellen. Da das Abdriften zur Seite in
der Rewardfunktion negativ bewertet wird, kann beim Lernen so möglicherweise
diesem Abdriften einfacher entgegengesteuert werden.
1 double deviationDirection = 0.0;
2 if (previousPose != null) {
3 Vector2D actualDiff = getWorldModel().getThisPlayer().getPose2D().getPosition().
subtract(previousPose.getPosition());
4 if (!actualDiff.equals(Vector2D.ZERO)) {
253 Observationspace
5 deviationDirection = Angle.to(actualDiff).subtract(previousPose.getAngle()).
degrees();
6 }
7 }
8 observation.add(deviationDirection, -180, 180);
9 previousPose = getWorldModel().getThisPlayer().getPose2D();
Listing 3.1: Rewardberechnung für eine relative Abweichung
Der erste Ansatz war die Verwendung einer relativen Abweichung (bezogen auf
den vorherigen Simulationszyklus). Dafür wurde der in Listing 3.1 gezeigte Code
verwendet. Dabei wird der Winkel der Bewegung zwischen dem letzten und aktu-
ellen Zyklus errechnet. Die Abweichung ist dann die Differenz der so errechneten
Richtung und der Richtung, zu welcher der Agent im vorigen Zyklus zugewandt
war. Nach einem ersten lokal ausgeführten Versuch schien die Verwendung einer
Begrenzung auf 10 Grad sinnvoll, da sich der Agent innerhalb von einem Simulati-
onszyklus normalerweise nicht mehr bewegt.
Das Ergebnis in Abbildung 3.9 zeigt nun die zurückgelegte Distanz. Der Grund
für diese Änderung wird später im Abschnitt 5.2 erläutert. Wieder ist kaum eine
Auswirkung im Graphen zu erkennen, es handelt sich lediglich um eine minimale
Verschlechterung. Sieht man sich das Laufen jedoch mit RoboViz an, so fällt auf,
dass der Agent zwar manchmal die Richtung (meistens beim Start) ändert. Aller-
dings schwankt er nun nicht mehr so stark beim Laufen und behält die Richtung
bei. Die Aufzeichnung ist online verfügbar2 .
Das Problem dabei ist, dass eine einmal eingeschlagene Richtung nicht mehr so
einfach korrigiert werden kann und der Agent läuft (halbwegs) geradeaus in die
falsche Richtung weiter. Dieses Problem lässt sich lösen, wenn man statt einer re-
lativen Abweichung zum letzten Simulationszyklus eine absolute Abweichung ver-
wendet. Diese gibt die Entfernung an zwischen dem Agenten und der „Ideallinie“,
auf welcher der Agent sich fortbewegen soll. Der Verlauf dieses Lernlaufs ist eben-
falls in Abbildung 3.9 zu sehen. Auch dabei zeigt sich in der zurückgelegten Distanz
kein signifikanter Unterschied. Beim Ansehen der Visualisierung stellte man jedoch
fest, dass das ursprüngliche Schwanken der Richtung zur Seite nun etwas reduziert
wurde. So kann es zwar immer noch vorkommen, dass der Agent um ein paar Meter
zur Seite abweicht. Die Abweichungen sollten jedoch nicht mehr so extrem sein wie
zu Beginn des Versuchs. Der Ansatz der Verwendung einer absoluten Abweichung
wurde dann auch für die Zukunft beibehalten, auch wenn sich die zurückgelegte Di-
2
https://www.youtube.com/watch?v=zecRb19%5Fye0
263 Observationspace
Abbildung 3.9: Zurückgelegte Distanz mit Richtungsabweichung als Observation
stanz nicht verbessert hat. Stattdessen hat man eine erhöhte Präzision erreicht, was
beim Laufen ebenso wichtig ist.
3.2.6 Kombination verschiedener problemspezifischer Inputs
Um das Zusammenspiel der neuen problemspezifischen Rewards zu testen, wurde
ein Vergleich durchgeführt, welcher den Unterschied zeigen soll zwischen der Ver-
wendung aller dieser Inputs und keiner dieser Inputs. Davon ausgenommen ist der
in Abschnitt 3.2.5 diskutierte Observationinput (Abweichung von der gewünschten
Richtung), da dieser zu einem späteren Zeitpunkt erst hinzugefügt wurde.
Dieser Lernlauf wurde länger als die bisherigen Lernläufe ausgeführt (knapp 11 Ta-
ge). Aus dem Rewardgraphen in Abbildung 3.10 lässt sich dies erkennen. Vor allem
aber sieht man zum Ende hin eine immense Verbesserung. Es scheint also, als hät-
ten diese Inputs kombiniert doch einen Einfluss auf das gelernte Laufen. Interessant
ist, dass der Anstieg des Rewards anfangs eher abflacht. Zum Ende hin steigt er je-
doch nochmals extrem. Eine Aufzeichnung des zum Ende gelernten Laufverhaltens
273 Observationspace
Abbildung 3.10: Reward des Lernlaufs mit verschiedenen problemspezifischen Inputs
ist online abrufbar3 . Natürlich wäre es spannend gewesen zu sehen, was bei noch
längerer Auführungsdauer passieren würde. Allerdings wurde auch die Serverkapa-
zität wieder für andere Versuche benötigt, weshalb trotzdem unterbrochen werden
musste.
3.3 Bewertung
Abgesehen von einigen problematischen beziehungsweise fehlerhaften Lernläufen,
welche durch eine falsche Threadanzahl und den aktivierten Realtimemodus hervor-
gerufen wurden, ließ sich zunächst keine enorme Verbesserung zum Ausgangspunkt
durch einzelne Inputs feststellen. Lediglich die Verwendung der Kombination ver-
schiedener problemspezifischer Inputs hat zu einem deutlicheren Ergebnis geführt.
Grund für diese geringen Veränderungen könnte sein, dass allgemein noch kein
gutes Laufen hierbei zustande gekommen ist. Wäre als Basis bereits ein funktionie-
3
https://www.youtube.com/watch?v=OdMdWqir7jc
283 Observationspace
rendes Laufen vorhanden gewesen, so hätten die hier durchgeführten Änderungen
möglicherweise auch mehr Auswirkungen gehabt und die Ergebnisse wären deut-
licher zu interpretieren gewesen. Aus diesem Grund sollten die hier errungenen
Kenntnisse nicht überinterpretiert werden.
Es erschien dennoch auch bei dem später durchgeführten Versuch aus Abschnitt
3.2.5 als hätten die Observations keinen so starken Einfluss auf das Ergebnis. Vor
allem im Vergleich zu dem Einfluss der später untersuchten Rewardfunktion waren
die Änderungen am Observationspace kaum spürbar.
Allerdings konnte zumindest durch das Entfernen der Ballposition (inklusive deren
Ableitung) sowie der Kopf- und Armgelenke ein wenig überflüssige/unnötige In-
formation aus dem Observationspace entfernt werden. Das könnte bei den späteren
Versuchen zu einem Geschwindigkeitsvorteil geführt haben, auch wenn er vermut-
lich eher klein war.
294. Actionspace
Der Actionspace beschreibt, welche Parameter vom neuronalen Netz zurückgege-
ben werden. Im Fall des zuvor gelernten Laufens waren das die mehr oder weniger
direkten Werte zur Steuerung der Jointmotoren des Nao-Roboters. Im Folgenden
wird die Optimierung dieser Parameter beschrieben.
4.1 Mapping der Ausgabewerte
Im Wesentlichen gibt es drei Möglichkeiten einen Motor beziehungsweise ein Ge-
lenk zu steuern. Einerseits ist es möglich den gewünschten Zielwinkel eines Gelenks
anzugeben. Es wird dann versucht, diesen Winkel schnellstmöglich zu erreichen. Ei-
ne weitere Möglichkeit ist, stattdessen eine Geschwindigkeit für den Gelenkmotor
anzugeben, mit der dieser sich bewegen soll. Die dritte Möglichkeit ist die Verwen-
dung einer Kombination aus beiden der gerade genannten Möglichkeiten. Das heißt
man gibt einen gewünschten Zielwinkel an sowie die maximale Geschwindigkeit,
mit der sich der Motor zu diesem Zielwinkel hinbewegen darf.
Letztere Methode wurde bei den bisher durchgeführten Versuchen stets verwendet.
Der Grund dafür war lediglich, dass alte genetisch gelernte Verhalten (wie zum Bei-
spiel Kicken oder Laufen) mit diesem Ansatz trainiert wurden. Für den Einsatz des
sogenannten „Pre-trainings“ war es dann notwendig, diese Methodik weiterzuver-
wenden. Beim Pre-training handelt es sich kurz gesagt um eine Möglichkeit, ein
bereits vorhandenes Verhalten als Vorgabe/Basis zu liefern, von welchem aus dann
weiter gelernt werden kann. Das ist hilfreich, wenn noch kein mit Deep Reinforce-
ment Learning erzeugtes Modell vorhanden ist. Allerdings soll darauf nicht weiter
eingegangen werden, da das Pre-training für diese Arbeit nicht wirklich relevant ist.
Um dem Simulationsserver die gelernten Bewegungen zu übermitteln, müssen diese
allerdings als Motorgeschwindigkeiten in der Einheit Grad pro Simulationszyklus
30Sie können auch lesen
