Seminar F Aufgabe B: Ball-Interception DRAXL Wolfgang HALLER Andreas

Aufgabenstellung zDer Roboter soll einen rollenden Ball, der sich irgendwo am Spielfeld befindet, unter Kontrolle bringen und so in Ballbesitz gelangen. (Interception) zOhne Berücksichtigung von Hindernissen und Gegner.

Realisierung zSplitten der Aufgabe in 2 Teilaufgaben: y1.) Der Roboter positioniert sich in der Bewegungsrichtung des Balles y2.) Der Roboter versucht, den nun auf sich zurollenden Ball zu stoppen zBegründung: Kleinere und besser angepaßte Lernmodelle möglich

Ball stoppen zVon uns nicht implementiert! zBegründung: yProbleme mit der Geschwindigkeitsmessung yPositionsupdate vom Supervisor dauert zu lange (Teilweise werden Zustände übersprungen) yKeksi ist für Ballsimulation ein Zylinder yVon anderer Gruppe schon gelöst (am Khepera)

Interception Realisierungsmethoden zREGLER yAusprogrammierte Lösung zLERNALGORITHMUS yReinforcement Learning

Regler zEingabegrößen : yBallposition (umgerechnet auf absolute Position) xWahlweise aus Kamerabild oder vom Supervisor yRoboterposition (vom Supervisor) zBerechnet: yBallbewegungsvektor (Geschwindigkeit und Richtung) xberechnet aus den aufeinanderfolgenden Ballpositionen yRoboter-Ball-Vektor xaus den Positionen von Roboter und Ball

Regler zBerechnet: yWinkel xWinkel zwischen Roboter-Ball- und Ball-Bewegungsvektor yZeit zum Ball xaus Roboter-Ball-Vektor und einer maximalen Robotergeschwindigkeit yBallbewegung xaus Zeit zum Ball und der Ballgeschwindigkeit xVorhaltewert wird dazuaddiert yNeue Roboterbewegung xaus Ballbewegung, Winkel und Roboter-Ball-Vektor über Cosinussatz Roboter-Ball-Vektor Ball Bewegungsvektor Vorhaltefaktor Neue Roboter- Bewegung

Regler zBerechnet: yWinkel xaus Winkel, neue Roboterbewegung und Ball-Bewegungsvektor über den Sinussatz yneue Fahrtrichtung ( ) xaus Winkel und Winkel (Winkel des Roboter- Ball-Vektors) yneue Geschwindigkeit xaus neue Roboterbewegung und der Zeit zum Ball yDrehgeschwindigkeit xüber die Position des Balles im Bild Roboter-Ball-Vektor Ball Bewegungsvektor Vorhaltefaktor Neue Roboter- Bewegung

Regler zVerhalten: yDer Roboter versucht ausgehend von der Ballbewegung und der Entfernung zum Ball, in eine Position vor dem Ball zu kommen. yDurch gleichzeitiges Drehen beim Fahren wird der Ball im Bild gehalten. yDrehung wenn kein Ball im Bild yBeim Nachfahren kann der Roboter wegen der kleinen Winkel nicht gut überholen.

Regler zGrafik: yBallpositionsermittlung mit der Kamera vom Tormannproblem übernommen. yFür die Ballgeschwindigkeit werden mehrere Positionsdifferenzen gemittelt und durch die Zeit seit der letzten Änderung dividiert. yDa nicht jeden Roboter-Step eine Positionsänderung von Ball oder Roboter vom Supervisor kommt, wird der Regler nur alle 5 Schritte aufgerufen. yWenn keine Änderung werden die alten Werte behalten. yUm die Probleme mit der Kamera zu umgehen kann alternativ die Ballposition vom Supervisor herangezogen werden.

Regler zProbleme: yUngenaue Positionsbestimmung mit der Kamera (->Roboter fährt oft in die falsche Richtung weg). yDrehgeschwindigkeit schwer dossierbar. yAbstoppen des Balles war mit diesem Ansatz auch nicht realisierbar.

Lernalgorithmus zSchlechte Lernerfolge mit der normalen Kamera-Optik xDaten von der Kamera relativ ungenau und sprunghaft xProbleme mit zusätzlichem Task Ball im Bild halten (Roboter fährt vom Ball weg, kontraproduktives Lernverhalten für Haupttask) xEnge Kurvenradien nur schwer realisierbar Richtungsgeschwindigkeit wirkt stärker als Rotationsgeschwindigkeit zu viele Geschwindigkeitsstufen blähen Modell auf

Lernalgorithmus zUmstellung auf omnidirectionale Optik: xum Probleme mit der konventionellen Optik zu umgehen xum die Aktionsanzahl für den Roboter zu reduzieren (Drehungen) xum die Aufgabe zu vereinfachen (Ball im Kamerabild halten fällt weg) xnäher am zukünftigen Verhalten des Roboters

Lernalgorithmus zErmittlung der Inputdaten: xBall-Roboter-Entfernung, Ball-Bewegungsrichtung und Roboter-Ball-Richtung werden aus der Ball- und Roboterposition vom Supervisor ermittelt xFindet keine Positionsänderung statt, werden die alten Werte weiterverwendet. xBallgeschwindigkeit: 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 zRealisierung in 2 verschiedenen Modellen: yModell 1: Berücksichtigung der Ballgeschwindigkeit Weniger Entfernungsklassen Einfacheres Rewardmodell yModell 2: keine Ballgeschwindigkeit Mehr Entfernungsklassen Rewardmodell stärker auf Vermeidung des Nahbereiches ausgelegt (Kollisionsvermeidung)

Modell 1: zZustandsraum: yBallgeschwindigkeit x2 Stufen (langsam, schnell) yBall-Roboter-Entfernung x3 Diskretisierungsstufen (nah, mittel, weit) yBall-Bewegungsrichtung x8 Richtungen (45° Bereich pro Richtung) yRoboter-Ball-Richtung x8 Richtungen (45° Bereich pro Richtung)

Modell 1: zAktionsraum: y8 Bewegungsrichtungen ynur eine Fahrtgeschwindigkeit ykeine Drehung zEingeschränkte Aktionen: yIn der Entfernungsstufe weit ist die Aktionsauswahl auf die 3 Bewegungs- richtungen zum Ball hin eingeschränkt.

Modell 1: zQ-Matrix: (Speed x Entf. x Ballricht. x Robot-Ball-Richt.) x Aktionen xStates: 2*3*8*8 = 384 xActions: 8 xState-Action-Paare: 384*8 = 3072 xEingeschränkte Aktionen: (2*1*8*8)*5=640 xEndzustände: (2*1*8*1)*8=128 xRelevante State-Action-Paare: =2304

Modell 1: zRewards: yPositive: 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 yNegative: -1: Für Verbleiben im Nahbereich -2: In mittlerer Distanz -50: In Ferndistanz

Modell 1: zRewards: Episodenabbruch bei Rewards 800 und

Modell 1: zErgebnis: xsiehe Matlab-Präsentation zSchlußfolgerung: xrecht schnell lernbar (ca.500 Episoden für Grundverhalten) xzielstrebige Bewegung zum Ball xAnstoßen des Balles schlechter beim Nachfahren Positionsupdate oft zu spät

Modell 2: zZustandsraum: yBall-Roboter-Entfernung x5 Diskretisierungsstufen yBall-Bewegungsrichtung x8 Richtungen (45° Bereich pro Richtung) yRoboter-Ball-Richtung x8 Richtungen (45° Bereich pro Richtung)

Modell 2: zAktionsraum: y8 Bewegungsrichtungen ynur eine Fahrtgeschwindigkeit ykeine Drehung zEingeschränkte Aktionen: yIn der Entfernungsstufe weit ist die Aktionsauswahl auf die 3 Bewegungs- richtungen zum Ball hin eingeschränkt.

Modell 2: zQ-Matrix: (Entf. x Ballricht. x Robot-Ball-Richt) x Aktionen xStates: 5*8*8 = 320 xActions: 8 xState-Action-Paare: 320*8 = 2560 xEingeschränkte Aktionen: (1*8*8)*5=320 xEndzustände: (1*8*1)*8=64 xRelevante State-Action-Paare: =2176

Modell 2: zRewards: yPositive: x50: Für das Erreichen der Entfernungszohne 3 x100: Für das Erreichen der Entfernungszohne 2 x150: Für das Erreichen der Position vor dem Ball in Entfernungszohne 3 aus Entfernungszohne 3 x200: Für das Erreichen der Position vor dem Ball in Entfernungszohne 3 aus Entfernungszohne 4 x700: Für das Erreichen der Position vor dem Ball in Entfernungszohne 2 aus Entfernungszohne 2 x1000: Für das Erreichen der Position vor dem Ball in Entfernungszohne 2 aus Entfernungszohne 3 yNegative: x-30: Für Verbleiben in Entfernungszohne 1 x-1: Für Verbleiben in Entfernungszohne 2 x-2: Für Verbleiben in Entfernungszohne 3 x-5: Für Verbleiben in Entfernungszohne 4 x-20: Für Verbleiben in Entfernungszohne 5

Modell 2: zRewards: Episodenabbruch bei Rewards 700 und

Modell 2: zErgebnis: xsiehe Matlab-Präsentation zSchlußfolgerung: xrecht schnell lernbar (ca.500 Episoden für Grundverhalten) xneigt oft zu Pendelbewegungen zwischen 2 Zuständen xAnstoßen des Balles tritt seltener auf

Probleme z Simulation z RL

Simulationsprobleme ySimulationsverlangsamung durch Webots braucht längere Episoden, um Erfolg zu haben yPacket Error (Keksim) dadurch ältere Supervisorversion yGeschwindigkeitsberechnung Supervisor sollte zu einer Positionsangabe auch die dazugehörige Zeit liefern yWebots Stepgeschwindigkeit Auswirkungen auf Episodenlänge

RL Probleme yModel xkann das Model überhaupt funktionieren? xGewisse Aktionen unterbinden bringt eine Verkürzung der Trainingszeit bessere Lernergebnisse xwenige und einfache Aktionen wählen xProblem in mehrere kleinere Modelle unterteilen yTrainingsprogramm xmit einfacheren Beispielen anfangen xmaßgeschneidertes Training

RL Probleme yLernalgorithmus xLernalgorithmus nur bei Zustandsänderung aufrufen xE-Traces bei einer Änderung des Beispieles abschneiden (Ball prallt von der Wand ab) xBei positiven Rewards wird in einem Zustand nur mehr eine Aktion gewählt (außer Zufall) xZufallsschritte auf Episodenlänge anpassen xAnordnung der Aktionen hat auch großen Einfluß auf das Ergebnis