POWER OVERWHELMING - ChallP1 @ HSR

(Update) Implementieren eines Kalman-Filters

Fri, 08 Jan 2016 00:00:00 +0000

Das bestimmen der eigenen Position zur Entscheidung, wie in Zukunft gas gegeben werden soll, ist nicht ganz einfach. Insbesondere ist es schwierig, herauszufinden, wie sich die Strecke verändert. Ein Mitstudent hat uns einen spannenden Artikel zukommen lassen.

Nach einigen Stunden Einlesen waren wir uns immer noch nicht sicher, wie gut sich ein Kalman-Filter auf unser Problem anwenden lässt. Vor allem das bestimmen der Daten, die durch den Filter gelassen werden. Die einfachen Beispiele, warfen zwei Dinge in den Filter: Geschwindigkeit und Position. Des weiteren sind uns noch andere Kandidaten in den Sinn gekommen, hier eine kurze Auflistung:

Geschwindigkeit: Eigentlich die ideale Grösse für unsere Rechnungen - Leider haben wir keinen Geschwindigkeitssensor, und die Berechnung aufgrund der Motorpower ist recht unverlässlich.
Position: Zu wissen, wo auf der Strecke wir uns befinden klingt super. Jedoch haben wir auch keinen Positionssensor und müssen uns deshalb die Position anhand der onehin schon unzuverlässigen Geschwindigkeit orientieren
Gyro-Z: Der einzige verlässliche Sensorwert. Wie genau dieser sich im Filter verwerten lässt ist jedoch unklar, da der Einfluss auf Geschwindigkeit und Position mathematisch nicht so einfach darzustellen ist.
Beschleunigung: Lässt sich auch aus dem Sensor ziehen, aber auch nach ausführlicher Analyse mit R lassen sich neben dem Rauschen kaum Schlüsse zur Strecke ziehen.
Motorpower: Ist nicht wirklich ein Sensorwert, gehört wahrscheinlich in die Kontrollmatrix?

Das generelle Problem: Wir haben eigentlich keine brauchbaren Sensordaten, und müssen eigentlich alles selbst berechnen. Wir waren uns dann nicht mehr sicher, ob es sich überhaupt lohnt, solch einen Filter zu implementieren. Auch war es nicht klar, wie genau die 3 Dimensionen der Sensordaten verwendet werden sollen.

Parallel zum ChallP1 kam in Prof. Müllers Vorlesung “Wahrscheinlichkeitsrechnung und Statistik” der Kalmanfilter im Unterrichtsstoff vor. Eine Diskussion mit Herrn Műller ergab, dass es sich durchaus lohnen würde, einen Kalman-Filter auf unser Problem anzuwenden. Die Daten für den Filter wären Geschwindigkeit und die zurückgelegte Distanz.

Aus Zeitmangel und Unsicherheit, wie genau wir die Korrelationsmatrizen ermitteln sollen, sind wir leider nicht mehr dauzgekommen, einen solchen Filter anzuwenden.

Kalibrierung des physischen Models während der Lernphase

Wed, 11 Nov 2015 00:00:00 +0000

Während des ersten Testlaufs auf der echten Bahn wurde uns bewusst, dass konstante Werte in unserem Physikmodel(Motor-Efficency, Reibungskoeffizienten) nicht akurat genug sind um eine Geschwindigkeit oder Distanz zu berechnen. Der Simulator verhält sich relativ konstant, im Gegensatz zum echten Modell, wo jedes Auto unterschiedliche Reibung mit sich bringt und die Berechnung extrem beinflusst. Unser Ziel ist es nun mit den Daten, die wir während der Lernphase sammeln, Reibungskoeffizienten für Gerade und Kurven zu berechnen.

Vorgehen:
- Aufstellung einer Gleichung zur Berechnung der Reibungskoeffizienten
- Anpassung der Gleichung durch Annäherung
Endgültiges Gleichungssystem
Genauigkeit

Testfahrt auf der echten Bahn

Fri, 06 Nov 2015 00:00:00 +0000

Nachdem wir Vormittags noch kurz einen Logger zusammengebaut haben, der unsere Fahrtergebnisse als JSON abspeichern kann, konnten wir heute unsere ersten Testfahrten auf der echten Carrerabahn durchführen. Dabei haben wir einige Dinge gelernt.

Allgemein

Runden Start/Ende-Event abfangen und Zustand entsprechend anpassen (z.B beim Rundenanfang loeschen)
Konstanten entfernen - Werte sollen gelernt werden (z.B Reibungskoeffizienten für Kurven und Geraden in der Lernphase berechnen)

Trackanalyzer(Phase 1)

Funktionioniert im Moment mit RoundEndMessage - Stattdessen sollte er mit Cycle Detection arbeiten
Autos haben verschiedene physikalische Eigenschafften; Motorstaerke und Reibung unterscheiden sich. Physische Eigenschafften sollen während der Lernphase approximiert werden.

SpeedOptimizer(Phase 2)

Auf Penalties muss reagiert werden
History von vergangenen Runden soll auf aktuelle Fahrstrategie mit einwirken
- Ein Historyelement pro TrackSection sollte beinhalten
  - Eingangsgeschwindigkeit
  - Verwendete Power
  - Punkt (Prozentual), ab dem gebremst wird
  - Durchquerungszeit
  - Wurde ein Penalty kassiert?

Daten Visualisierung

Thu, 15 Oct 2015 00:00:00 +0000

Bis anhin haben wir alle möglichen Daten, welche wir irgendwie bekommen konnten, in unsere erstellten Datenstrukturen gespeichert. Damit man bei dieser Unmenge an Daten davon verschohnt werden den Wald voller Bäume nicht mehr zusehen, stellen wir die wichtigsten Informationen visuell dar.

Nach einem kurzen Proof-of-Concept viel die Technologiewahl auf ein Java Swing Framework(JFreeChart). Somit müssen wir keine weitere Sprache einführen und halten unseren Technologie-Zoo möglichst kompakt.

Zu Begin versuchten wir das DataChart-Objekt im JavaPilotActor zu instanzieren, da wir dort sehr nah bei den darzustellenden Daten waren. Anfangs liefen wir in eine HeadlessException, welche grundsätzlich bedeutet, dass man im momentanen Kontext kein Java Swing Frame erstellen kann. Als Workaround setzten wir das System-Property headless auf false, anschliessend konnte ein erstes DataChart(Gyro-Z) erstellt werden.

Das Swing Fenster dem JavaPilotActor anzuhängen, war längerfristig gesehen ein schlechter Entscheid! Es könnte ein Situation enstehen in welcher der Pilot auf die Swing Applikation warten müsste, was fatal wäre in einer Applikation, welche zu Runtime schnelle Berechnungen und Entscheidungen erledigen muss! Mit dieser Erkenntnis starteten wir ein Refactoring um eine möglichst asynchrone Verbindung zu initialisieren. Da wir nur in eine Richtung Daten senden müssen (JavaPilotActor -> DataChart), können wir auf einen Callback Mechanismus verzichten.

Aufbau der Schnittstelle Pilot / Visualizer:

DataVisService: -Wird vom Spring Framework Injected bei der Erstellung des Pilots -instanziert das DataChart Objekt -Hat die Permission Swing Fenster zu zeichnen
PilotToVisualConnector: -Implementiert das Interface PilotToVisualConnection -Gibt dem Pilot die Möglichkeit dem DataChart Updates zu senden
DataChart: -Darstellung der Gyro-Z Werte(XY-Chart) -Darstellung der Velocity Werte(XY-Chart) -Tabellendarstellung der erkannten TrackSections -Positiosanzeige des Pilots auf der Strecke(Streckentabelle) Mit diesem Setup kann der Pilot seine Berechnungen dem DataVisService mitteilen, welcher diese dann dem DataChart zur Darstellung weitergibt. Somit erreichen wir eine saubere Trennung von Datenverarbeitung und Darstellung und verhindern eine Blockade des Pilots!

TrackAnalyzer und Kurvenerkennung

Thu, 08 Oct 2015 00:00:00 +0000

Eine einfache Idee zur Streckenerkennung hatten wir relativ schnell: Sobald der Z-Gyro-Sensor einen gewissen Wert positiv/negativ überschreitet, befinden wir uns in einer Links- bzw. Rechtskurve. Es war schon recht befriedigend, dem Piloten bei der Kurvenerkennung zuzuschauen, aber noch weit weg vom eigentlichen Erlernen der Strecke.

Die Strecke wird folgendermassen gespeichert: Jede Kurve und jedes Geradensegment dazwischen wird als einzelnes Objekt, eine TrackSection, gespeichert. Dieses enthält die Durchfahrungszeit, Richtung (Links/Rechts/Gerade), eventuell eine Bewertung der Kurvenschärfe und einen Zeiger auf die nächste TrackSection. Die geschwindigkeitsmessenden Checkpoints sowie die Position des Autos enthalten einen Zeiger auf das TrackSection, in dem sie sich befinden, sowie einen zeitlichen Offset vom Start des Abschnitts.

Gelernt wird die Strecke in einer sogenannten Kennenlernphase, wo das Auto mit einer konstanten Geschwindigkeit um die Bahn kurvt, um all diese Abschnitte zu analysieren. Aus den mehreren Runden wird für eine höhere Verlässlichkeit dann ein Durchschnitt berechnet. Dies bringt mehrere Problemstellungen mit sich:

Der Beginn der ersten Runde ist nicht wirklich repräsentativ, da das Auto zuerst beschleunigen muss. Hier bieten sich verschiedene Lösungen an, wovon keine so wirklich toll klingt:
- Ignorieren des Problems
- Ignorieren der ersten Runde
- Versuchen, die Beschleunigungsphase irgendwie herauszurechnen
Wie oft soll die Strecke umfahren werden? Ist die Geschwindigkeit zu hoch, fliegt das Auto aus der Bahn (bzw. erhält es Penalties), was die Daten der Umfahrung wesentlich weniger nützlich macht.
- Diese Frage steht noch offen, es soll ja möglichst viel Zeit für die eigentliche Fahrphase zur Verfügung stehen. Momentan experimentieren Wir mit 1-3 Runden.
Wie werden die Daten von mehreren Runden zusammengeführt? Theoretisch sollten mit derselben konstanten Geschwindigkeit in jeder Runde gleich viele TrackSections vorkommen. Die Praxis zeigt aber, dass durch das Rauschen der Sensoren insbesondere in schnellen Abfolgen von kurzen Kurven gerne einmal ein Zwischenstück einfach als Gerade erkannt wird.
- Unsere neue Idee plant die Vereinfachung von mehreren, kurz aufeinanderfolgenden Kurvensegmenten in ein langes. Dies führt auch dazu, dass die Kurvenrichtung verlorengeht, was aber eigentlich nicht so wichtig ist. Das Ziel ist ja einfach, in Kurven vorsichtiger zu fahren. Stimmen die Daten von mehreren Runden nicht überein, so wird einfach die Lösung mit weniger Abschnitten genommen.

Schlachtplan

Thu, 01 Oct 2015 00:00:00 +0000

Heute haben wir uns hingesetzt und festgestellt, dass wir gar nicht so recht wissen, wo anzufangen. Dies brachte uns dazu, eine Übersicht unser nächsten Aufgaben aufzustellen.

Algorithmus

2 Phasen
- Kennenlernen
  - Konstante geschwindigkeit (verschiedene)
  - Aufteilen in Segmente (Geraden, Kurven, Geschwindigkeit, Rundenzeit)
- Optimieren
  - Geschwindigkeit anpassen (Anhand gelernter Strecke)
  - Streckenveraenderung Modellieren
  - Aktuelle Position tracken
    - Berechnung
    - An Checkpoints/Rundenende abgleichen

Visualisierung

Was wird Visualisiert?
- Sensordaten
- Gelerntes Rundenmodell
Wie wird Visualisiert?
Realtime Visualisierungstools
Statistkisoftware wie R

Fahrstil

Verhalten der des Autos ermitteln
- Manuelle Geschwindigkeitseinstellung implementieren
- Mit Brute Force verschiedene Kurvenstrategien evaluieren

Willkommen

Mon, 21 Sep 2015 00:00:00 +0000

Dies ist das Lablog Gruppe POWER OVERWHELMING für das Challengeprojekt 1 an der Hochschule Rapperswil.

Folgende Erfolge lassen sich bereits festhalten:

Kickoff-Event überstanden
Entwicklungsumgebung eingerichtet
Lablog mit Jekyll auf die Beine gestellt