Seminar F

Aufgabe B:Ball-Interception

DRAXL Wolfgang

HALLER Andreas

Aufgabenstellung

Der Roboter soll einen rollenden Ball, der sich irgendwo am Spielfeld befindet, unter Kontrolle bringen und so in Ballbesitz gelangen. (Interception)

Ohne Berücksichtigung von Hindernissen und Gegner.

Realisierung

Splitten der Aufgabe in 2 Teilaufgaben: 1.) Der Roboter positioniert sich in der

Bewegungsrichtung des Balles 2.) Der Roboter versucht, den nun auf sich

zurollenden Ball zu stoppen

Begründung: Kleinere und besser angepaßte Lernmodelle möglich

Ball stoppen

Von uns nicht implementiert!Begründung:

Probleme mit der Geschwindigkeitsmessung

Positionsupdate vom Supervisor dauert zu lange (Teilweise werden Zustände übersprungen)

Keksi ist für Ballsimulation ein Zylinder Von anderer Gruppe schon gelöst (am

Khepera)

InterceptionRealisierungsmethoden

REGLER Ausprogrammierte Lösung

LERNALGORITHMUS Reinforcement Learning

Regler

Eingabegrößen: Ballposition (umgerechnet auf absolute Position)

Wahlweise aus Kamerabild oder vom Supervisor

Roboterposition (vom Supervisor)

Berechnet: Ballbewegungsvektor (Geschwindigkeit und Richtung)

berechnet aus den aufeinanderfolgenden Ballpositionen

Roboter-Ball-Vektoraus den Positionen von Roboter und Ball

Regler

Berechnet: Winkel

Winkel zwischen Roboter-Ball-und Ball-Bewegungsvektor

Zeit zum Ball aus Roboter-Ball-Vektor und einer

maximalen Robotergeschwindigkeit

Ballbewegung aus Zeit zum Ball und der Ballgeschwindigkeit Vorhaltewert wird dazuaddiert

Neue Roboterbewegung aus Ballbewegung, Winkel und Roboter-Ball-Vektor

über Cosinussatz Roboter-Ball-Vektor

Ball BewegungsvektorVorhaltefaktor

Neue Roboter-Bewegung

Regler

Berechnet: Winkel

aus Winkel , neue Roboterbewegungund Ball-Bewegungsvektor über den Sinussatz

neue Fahrtrichtung () aus Winkel und Winkel (Winkel des Roboter-

Ball-Vektors)

neue Geschwindigkeit aus neue Roboterbewegung und der Zeit zum Ball

Drehgeschwindigkeit über die Position des Balles im Bild

Roboter-Ball-Vektor

Ball BewegungsvektorVorhaltefaktor

Neue Roboter-Bewegung

Regler

Verhalten: Der Roboter versucht ausgehend von der

Ballbewegung und der Entfernung zum Ball, in eine Position vor dem Ball zu kommen.

Durch gleichzeitiges Drehen beim Fahren wird der Ball im Bild gehalten.

Drehung wenn kein Ball im Bild Beim Nachfahren kann der Roboter wegen der

kleinen Winkel nicht gut überholen.

Regler

Grafik: Ballpositionsermittlung mit der Kamera vom

Tormannproblem übernommen. Für die Ballgeschwindigkeit werden mehrere

Positionsdifferenzen gemittelt und durch die Zeit seit der letzten Änderung dividiert.

Da nicht jeden Roboter-Step eine Positionsänderung von Ball oder Roboter vom Supervisor kommt, wird der Regler nur alle 5 Schritte aufgerufen.

Wenn keine Änderung werden die alten Werte behalten. Um die Probleme mit der Kamera zu umgehen kann

alternativ die Ballposition vom Supervisor herangezogen werden.

Regler

Probleme: Ungenaue Positionsbestimmung mit der Kamera (-

>Roboter fährt oft in die falsche Richtung weg). Drehgeschwindigkeit schwer dossierbar. Abstoppen des Balles war mit diesem Ansatz auch nicht

realisierbar.

Lernalgorithmus

Schlechte Lernerfolge mit der normalen Kamera-Optik

Daten von der Kamera relativ ungenau und sprunghaft

Probleme mit zusätzlichem Task “Ball im Bild halten” (Roboter fährt vom Ball weg, kontraproduktives Lernverhalten für Haupttask)

Enge Kurvenradien nur schwer realisierbar • Richtungsgeschwindigkeit wirkt stärker als

Rotationsgeschwindigkeit• zu viele Geschwindigkeitsstufen blähen Modell auf

Lernalgorithmus

Umstellung auf “omnidirectionale Optik”:

um Probleme mit der konventionellen Optik zu umgehen

um die Aktionsanzahl für den Roboter zu reduzieren (Drehungen)

um die Aufgabe zu vereinfachen (Ball im Kamerabild halten fällt weg)

näher am zukünftigen Verhalten des Roboters

Lernalgorithmus

Ermittlung der Inputdaten:Ball-Roboter-Entfernung, Ball-Bewegungsrichtung und

Roboter-Ball-Richtung werden aus der Ball- und Roboterposition vom Supervisor ermittelt

Findet keine Positionsänderung statt, werden die alten Werte weiterverwendet.

Ballgeschwindigkeit:• Ermittlung der Zeitdifferenz seit der letzten

Positionsänderung(Ermittelte Zeit stimmt vermutlich nicht mit dem Zeitpunkt der

Positionsbestimmung überein)

• Speed ausrechnen• 7-fach Median bilden• 10-fach Mittelwert (Queue)

Lernalgorithmus

Realisierung in 2 verschiedenen Modellen: Modell 1:

• Berücksichtigung der Ballgeschwindigkeit• Weniger Entfernungsklassen• Einfacheres Rewardmodell

Modell 2:• keine Ballgeschwindigkeit• Mehr Entfernungsklassen• Rewardmodell stärker auf Vermeidung des

Nahbereiches ausgelegt (Kollisionsvermeidung)

Modell 1:

Zustandsraum: Ballgeschwindigkeit

2 Stufen (langsam, schnell)

Ball-Roboter-Entfernung3 Diskretisierungsstufen (nah, mittel, weit)

Ball-Bewegungsrichtung8 Richtungen (45° Bereich pro Richtung)

Roboter-Ball-Richtung8 Richtungen (45° Bereich pro Richtung)

Modell 1:

Aktionsraum: 8 Bewegungsrichtungen nur eine Fahrtgeschwindigkeit keine Drehung

Eingeschränkte Aktionen: In der Entfernungsstufe “weit” ist die

Aktionsauswahl auf die 3 Bewegungs-richtungen zum Ball hin eingeschränkt.

Modell 1:

Q-Matrix: (Speed x Entf. x Ballricht. x Robot-Ball-Richt.) x Aktionen

States: 2*3*8*8 = 384Actions: 8State-Action-Paare: 384*8 = 3072Eingeschränkte Aktionen: (2*1*8*8)*5=640Endzustände: (2*1*8*1)*8=128Relevante State-Action-Paare:

3072-640-128=2304

Modell 1:

Rewards: Positive:

• 200: Für das Erreichen des Nahbereiches• 800: Für das Erreichen der Position vor dem Ball

wenn bereits 200-Reward erhalten• 1000: Für direktes Erreichen der Position vor dem

Ball

Negative:• -1: Für Verbleiben im Nahbereich• -2: In mittlerer Distanz• -50: In Ferndistanz

Modell 1:

Rewards: Episodenabbruch bei Rewards 800 und 1000

1000

800

200

-1

-2

-50

Modell 1:

Ergebnis: siehe Matlab-Präsentation

Schlußfolgerung:recht schnell lernbar (ca.500 Episoden für

Grundverhalten)zielstrebige Bewegung zum BallAnstoßen des Balles

• schlechter beim Nachfahren• Positionsupdate oft zu spät

Modell 2:

Zustandsraum: Ball-Roboter-Entfernung

5 Diskretisierungsstufen

Ball-Bewegungsrichtung8 Richtungen (45° Bereich pro Richtung)

Roboter-Ball-Richtung8 Richtungen (45° Bereich pro Richtung)

Modell 2:

Aktionsraum: 8 Bewegungsrichtungen nur eine Fahrtgeschwindigkeit keine Drehung

Eingeschränkte Aktionen: In der Entfernungsstufe “weit” ist die

Aktionsauswahl auf die 3 Bewegungs-richtungen zum Ball hin eingeschränkt.

Modell 2:

Q-Matrix: (Entf. x Ballricht. x Robot-Ball-Richt) x Aktionen

States: 5*8*8 = 320Actions: 8State-Action-Paare: 320*8 = 2560Eingeschränkte Aktionen: (1*8*8)*5=320Endzustände: (1*8*1)*8=64Relevante State-Action-Paare:

2560-320-64=2176

Modell 2:

Rewards: Positive:

50: Für das Erreichen der Entfernungszohne 3 100: Für das Erreichen der Entfernungszohne 2 150: Für das Erreichen der Position vor dem Ball in Entfernungszohne 3 aus

Entfernungszohne 3 200: Für das Erreichen der Position vor dem Ball in Entfernungszohne 3 aus

Entfernungszohne 4 700: Für das Erreichen der Position vor dem Ball in Entfernungszohne 2 aus

Entfernungszohne 2 1000: Für das Erreichen der Position vor dem Ball in Entfernungszohne 2 aus

Entfernungszohne 3

Negative: -30: Für Verbleiben in Entfernungszohne 1 -1: Für Verbleiben in Entfernungszohne 2 -2: Für Verbleiben in Entfernungszohne 3 -5: Für Verbleiben in Entfernungszohne 4 -20: Für Verbleiben in Entfernungszohne 5

Modell 2:

Rewards: Episodenabbruch bei Rewards 700 und 1000

1000

200

150

700

100

50

-30

-1

-2

-5

-20

Modell 2:

Ergebnis: siehe Matlab-Präsentation

Schlußfolgerung:recht schnell lernbar (ca.500 Episoden für

Grundverhalten)neigt oft zu Pendelbewegungen zwischen 2

ZuständenAnstoßen des Balles tritt seltener auf

Probleme

Simulation RL

Simulationsprobleme

Simulationsverlangsamung durch Webots

braucht längere Episoden, um Erfolg zu haben

Packet Error (Keksim)dadurch ältere Supervisorversion

GeschwindigkeitsberechnungSupervisor sollte zu einer Positionsangabe auch die

dazugehörige Zeit liefern

Webots StepgeschwindigkeitAuswirkungen auf Episodenlänge

RL Probleme

Modelkann das Model überhaupt funktionieren?Gewisse Aktionen unterbinden

• bringt eine Verkürzung der Trainingszeit• bessere Lernergebnisse

wenige und einfache Aktionen wählen Problem in mehrere kleinere Modelle unterteilen

Trainingsprogrammmit einfacheren Beispielen anfangenmaßgeschneidertes Training

RL Probleme

LernalgorithmusLernalgorithmus nur bei Zustandsänderung

aufrufenE-Traces bei einer Änderung des Beispieles

abschneiden (Ball prallt von der Wand ab)Bei positiven Rewards wird in einem Zustand

nur mehr eine Aktion gewählt (außer Zufall)Zufallsschritte auf Episodenlänge anpassenAnordnung der Aktionen hat auch großen

Einfluß auf das Ergebnis