AEP - Autonomes Einparken

Allgemeines

Anforderungen an die Disziplin

Die Anforderungen an das autonome Einparken in diesem Projekt wurden mit den Dozenten abgesprochen und richten sich teilweise an den Carolo Cup.

1. Das Fahrzeug muss auf einer geraden Straße - fahrend auf der rechten Straßenseite - eine passende Parklücke finden und in diese mit eventueller Berührung der Hindernisse parallel zur Straße einparken.
2. Das Einparkmanöver muss durch einen Taster am Fahrzeug gestartet werden können
3. Das Fahrzeug fährt an den rechts stehenden Hindernissen, auf der Suche nach einer ausreichend großen Parklücke, vorbei.
4. Sobald die erstmögliche Parklücke gefunden ist, muss das Einparken mit dem rechten Blinker signalisiert werden.
5. Während des Einparkmanövers darf die äußere weiße Linie nicht Überfahren werden.
6. Während des Einparkmanövers sind Kollisionen mit Hindernissen nicht erlaubt.
7. Der Abstand zum vorderen und hinteren Hindernis muss nach dem Einparkmanöver jeweils mindestens 10mm betragen.
8. Nach Beendigung des Manövers, muss das Fahrzeug zwischen zwei Hindernissen mit einer maximalen Winkelabweichung von 5° zum Stehen kommen. Zusätzlich müssen die Fahrtrichtungsanzeiger aufleuchten.
9. Das Einparkmanöver sollte innerhalb von 30 Sekunden durchgeführt werden.

Autor: Sascha Dienwiebel (Diskussion) 18:23, 3. Feb. 2014 (CET)

Autor: Martin Berysztak (Diskussion) & Adem Hadziric (Diskussion) 14:39, 22. Jan. 2015 (CET)

Auswahl der Sensoren

Die Sensoren wurden in Anlehnung an gängige Lösungen des Carolo Cups ausgewählt. Für den Einparkvorgang werden zwei Infrarotsensoren (nachfolgend: IR) vom Typ Sharp GP2D120, der Gierratensensor vom Typ LPR510AL und Hallsensoren zur Geschwindigkeitsermittlung verwendet

Infrarotsensoren:

Die Positionen der IR sind im Artikel () definiert und beschrieben. Der erste IR ist seitlich vorne am Fahrzeug montiert und wird dafür verwendet, die Parklücke zu finden und den Abstand zum seitlich parkenden Hindernis zu messen. Der zweite IR ist hinten-rechts angebrachte und misst den Abstand zum hinteren Hindernis, sobald sich das Fahrzeug zwischen den beiden Hindernissen befindet. Anhand des Abstandes wird entschieden, ob es noch ein Stück vorfahren muss oder nicht, um dem hinteren Fahrzeug noch Platz zum Ausparken zu lassen und aus Platzgründen so nah wie möglich am vorderen Hindernis vorbei zu fahren.

Gierratensensor:

Um die Winkellage des Fahrzeugs vermessen zu können, wird ein Gierratensensor verwendet. Die Änderung von Rechts- auf Linkseinschlag während des Einparkens wird damit durch eine vorher berechnete Winkellage β (siehe Berechnung nötiger Größen) gesteuert. Außerdem wird der Sensor dafür eingesetzt, das Anhalten des Fahrzeugs zu erreichen, wenn der Winkel des Gyroskops um 0 rad (0°) liegt.

Hallsensor(Geschwindigkeitsmessung):

Die Geschwindigkeit wird über Hallsensoren ermittelt. Über die Ableitung der Geschwindigkeit wird die Streckenmessung durchgeführt. Diese dient dem Zweck, die Parklücke zu vermessen und bestimmte Kurzstrecken, wie z.B. das Weiterfahren nach Lückenfindung, definiert zurückzulegen.

Autor: Sascha Dienwiebel (Diskussion) 18:23, 3. Feb. 2014 (CET)

Autor: Martin Berysztak (Diskussion) & Adem Hadziric (Diskussion) 14:39, 22. Jan. 2015 (CET)

Der Einparkalgorithmus

Einbindung des Einparkalgorithmus in die Simulink Umgebung

Das Hauptmodell für die Offline Simulation ist in der folgenden Abbildung dargestellt. Das Einparken wurde im Block AEP - Autonomes Einparken implementiert (orange hinterlegt dargestellt) und besitzt in der Online-Umgebung auf der Dspace Box den selben Aufbau, mit dem Unterschied, dass dort die Sensorwerte und Fahrbahn nicht simuliert werden müssen. Der gesamte Bus steht ihm zur Verfügung. Der Aufbau des Blocks und dessen internen Funktionen zur Umsetzung des Einparkalgorithmus findet sich in diesem Link wieder.

Autor: Sascha Dienwiebel (Diskussion) 18:24, 3. Feb. 2014 (CET)

Auswahl des Einparkmodus

Wenn das Einparkmanöver gestartet werden soll, muss zu Beginn das Simulink-Modell start.m Datei in MATLAB geöffnet werden. Für den Einparkmodus bestehen die Möglichkeiten, nach der Lückenfindung direkt einzuparken (Simulinkmodus = 3) oder einfach stehen zu bleiben (Simulinkmodus = 2). Beim online Model sollte beachtet werden, dass vor der Beträtigung des AEP-Tasters, die Aktuatoren ausgeschaltet werden. Hierzu muss der Hebel, der sich hinten am Fahrzeug befindet, in die Mittelstellung gebracht werden.

Alle weiteren Einstellungen sind optional und werden in diesem Link erläutert.

Autor: Sascha Dienwiebel (Diskussion) 18:24, 3. Feb. 2014 (CET)

Autor: Martin Berysztak (Diskussion) & Adem Hadziric (Diskussion) 14:39, 22. Jan. 2015 (CET)

Auswahl der geeigneten Geschwindigkeit

Der vorangegangenen Abbildung aus dem Datenblatt "Sharp-GP2D120.pdf" (siehe Infrarot Sensor) ist zu entnehmen, dass maximal eine Zeit für eine Messung benötigt wird von:

$t= 38,3\,ms + 9,6\,ms + 5\,ms = 52,9\,ms$.

Sicherheitshalber wird davon ausgegangen, dass sich in der größten Lücke ein weiteres Hindernis mit den Maßen 10cm x 10cm befindet. Um diese erkennen zu können, sollten mindestens drei Messungen im Bereich des Hindernisses stattfinden. Die benötigte Zeit für diese drei Messungen beträgt demnach

$t=3\cdot 52,9\,ms = 158,7\,ms.$

Da sich die Geschwindigkeit aus dem Weg (s) geteilt durch die Zeit (t) berechnet und der Weg in diesem Fall der Länge des Hindernisses entspricht, resultiert daraus eine maximale Geschwindigkeit von

$v= \frac{0,1\,m}{158,7\cdot10^{-3}\,s} =0,63\,\frac{m}{s}.$

Zu beachten ist jedoch, dass aktuell (Stand WS 14/15) die Geschwindigkeit für das Einparkmanöver +/- 0,8m/s beträgt. Aufgrund der Haftreibung war zur Zeit der Tests eine niedrigere Geschwindigkeit nicht möglich.

Autor: Sascha Dienwiebel (Diskussion) 18:24, 3. Feb. 2014 (CET)

Autor: Martin Berysztak (Diskussion) & Adem Hadziric (Diskussion) 15:17, 22. Jan. 2015 (CET)

Berechnung nötiger Größen

Das Fahrzeug besitzt einen maximalen Lenkeinschlag in eine Richtung von alpha = 23°. Kombiniert mit dem Radstand L = 0,265m ergibt dies einen Wendekreisradius um die Mitte der Hinterachse von

$r= \frac{L}{tan(\alpha)} = \frac{0,265\,m}{tan(25^\circ)} = 0,5683\,m.$

Die folgende Abbildung zeigt eine Skizze zur Herleitung der Wendekreisradiusberechnung.

Für die Berechnung der notwendigen Parklücke spielt der Wendekreisradius (r), die Breite des Fahrzeuges (w), die Länge des Fahrzeugs von der Mitte der hineren Achse bis zum Heck (b) und der seitliche Abstand zum Hindernis (p) eine wichtige Rolle. Die nachfolgende Abbildung zeigt eine Skizze des Fahrzeugs und dessen Einparkmanövers.

Notwendige Größen für den Vorgang des Einparkens sind:

Die allgemeinen Maße des Fahrzeugs

Breite w = 0,290m

Radstand L = 0,265m

Abstand Mitte Vorderachse nach Vorne v = 0,065m

Abstand Mitte Hinterachse zum Heck b = 0,100m

Wendekreisradius r = 1,1318m

Der seitliche Abstand zum Hindernis p = variabel

Wird der Einparkvorgang gestartet, sobald die Mitte der Hinterachse des Fahrzeugs auf Höhe der Heckkante des vorderen Hindernisses liegt, müsste die Parklücke, wie der vorangegangenen Abbildung zu entnehmen ist, die Summe aus b, g1 und g2 sein. Die Abstände g1 und g2 sind dabei gleich groß und berechnen sich nach dem Satz des Pythagoras wie folgt:

$g1 = \sqrt[]{r^2-(r-\frac{w}{2}-\frac{p}{2})^2}$

Dies würde aber zu einer größeren Lücke führen, als eigentlich nötig, da die Möglichkeit vorhanden ist, nach Findung des vorderen Hindernisses eine weitere Strecke k nach vorne zu fahren. Dadurch wird gewährleistet, das kein Platz verschenkt und während des Einparkvorgangs so nah wie möglich am Hindernis vorbeigefahren wird. Demnach wird für die Größe der nötigen Parklücke (g) folgende Formel verwendet:

$g = 2\cdot \sqrt[]{r^2-(r-\frac{w}{2}-\frac{p}{2})^2}+b-\sqrt[]{(r-\frac{w}{2})^2-(r-\frac{w}{2}-p)^2}$

Anhand dieser Formel wird deutlich, dass sich die nötige Parklücke danach richtet, wie groß der Abstand zum Hindernis ist. In der Regel ist der Abstand p nicht gleich 0. Dies würde bedeuten, dass das einparkende Fahrzeug bereits am schon stehenden Fahrzeug klebt. Der Punkt, dass das Fahrzeug mittig der Straße fahren soll und die Tatsache, dass der Infrarotsensor erst ab einem Abstand von 4cm zuverlässige Werte zurückgibt (siehe GP2D120), setzt einen angenommenen Mindestabstand zur Berechnung vorraus. In unserem Fall wird ein Abstand p = 15cm vorausgesetzt. Diese Annahme führt zu einer Mindestgröße der Parklücke von g = 1m, was bedeutet, dass die größte zur Verfügung stehende Lücke von 0,7m reichen müsste. Durch geringer Vergrößerung des Abstandes p, Kürzung des Fahrzeugs oder Erhöhung des Einschlagwinkels würde auch eine kleinere Parklücke ausreichen. Der seitliche Abstand zum Hindernis darf allerdings nicht größer als die Hälfte des Wendekreisradius sein. Bei diesem Fall werden sämtliche oben genannten Berechnungen außer Kraft gesetzt.

Die Berechnung des Umschlagwinkels $\beta$ ist ebenfalls vom Abstand p abhängig und wird erst berechnet, wenn die Lücke gefunden und das Fahrzeug neben dem vorderen Hindernis steht.

$\beta = \arccos(\frac{r-\frac{w}{2}-\frac{p}{2}}{r})$

Ebenso wird an dieser Stelle der Weg berechnet, den das Fahrzeug noch vorwärts fahren soll, um den vorhandenen Platz so effizient wie möglich zu nutzen. Je näher beim Einparken an dem vorderen Hindernis vorbeigefahren wird, desto weniger Platz wird während des gesamten Einparkvorgangs benötigt. Da sich beim Finden des vorderen Hindernisses die Vorderachse des RC Fahrzeuges auf höhe dessen Hecks befindet, und der Einparkvorgang so kalkuliert wird, dass sich erstmal die Mitte der Hinterachse des RC Fahrzeuges auf Höhe des Hecks des vorderen Fahrzeugs befindet, muss auf jeden Fall die Strecke der Summe aus Radstand (L) und Mitte der Hinterachse zur Front (v) gefahren werden. Auf diesen Wert wird dann noch der Parameter k addiert, welcher sich wie folgt berechnet und bereits Teil der Parklückenberechnung ist:

$k = \sqrt[]{(r-\frac{w}{2})^2-(r-\frac{w}{2}-p)^2}$

Da bei allen Parkmanövern (offline- und online-Modus), dass Fahrzeug eine zu weite Strecke nach vorne gefahren ist, ist die benötigte Länge der Vorausfahrt reduziert worden. Hier ist überTest rausgekommen, dass der Abzug der Größe k weggelassen werden kann.

Autor: Sascha Dienwiebel (Diskussion) 18:24, 3. Feb. 2014 (CET)

Autor: Martin Berysztak (Diskussion) & Adem Hadziric (Diskussion) 14:39, 22. Jan. 2015 (CET)

Ausblick

Aktuell ist der Einparkmanöver am Fahrzeug möglich. Im nächsten Schritt könnte nun die Verknüpfung zwischen der Reglung für die Geradeausfahrt, mit der Geradeausfahrt für den Einparkmanöver gemacht werden. Aktuell wird die Geradeausfahrt beim Einparken über die Vorgabe eines 0 rad (0°) Lenkwinkels durchgeführt.

Zusätzlich ist die Lösung für die Berechnung des Umschlag Lenkwinkels über einen zusätzlichen Parameter realisiert worden. Hier muss folgend geprüft werden warum genau dieser Wert ohne der Reduzirung zu groß war.

Aktuell ist keine Funktion für die Verhinderung von Zusammenstößen mit Hindernissen vorhanden. Hierzu könnte der erste Ansatz eines Konzeptes verwendet werden, welches hier | Kollisionskontrolle abgelegt ist.

Aktuell sthet das Fahrzeug nach dem Parkmanöver, relativ Parallel zu Fahrbahn (< 5°). Da das Fahrzeug vorher dauerhaft einen schrägen Schlusslenkwinkel hatte, wurde dem geforderten Endwinkel (siehe Fahrzeugsoftware#param_AEP) der Wert von 9 Grad zugeteilt. Dieser Wert ist anhand von mehrfachen Tests als optimal ermittel worden.

Autor: Martin Berysztak (Diskussion) & Adem Hadziric (Diskussion) 16:39, 22. Jan. 2015 (CET)

Projektergebnisse SS14

Einleitung

In diesem Artikel werden Arbeiten dokumentiert, welche im Rahmen des SDE Praktikums im SS2014, des MTR Studienganges, durchgeführt wurden. Im Speziellen wird am vorhandenen Einparkalgorithmus gearbeitet. Dieser ermöglicht es dem Fahrzeug, eine Parklücke zu erkennen und in diese autonom einzuparken. Das Team "AEP" besteht aus den Studenten Martin Berysztak und Adem Hadziric.

Anforderungen des Lastenheftes

Im Folgenden befinden sich die Requirements, welche sich aus dem Pflichtenheft für das Team AEP ergeben. Diese spiegeln die zu bewältigenden Aufgaben für das Semester wieder. Die Priorität gibt die Wichtigkeit der Aufgabe wieder, diese ist vom Team festgelegt. Priorität: 1 = hoch; 3 = niedrig

--Ulrich Schneider (Diskussion) 20:28, 30. Jul. 2014 (CEST) Ich verstehe Ihre Pflichtenhefteinträge nicht. Es gibt weder Meilenstein 0 noch 3.

Projektplan

[Bild 2]

Wochenaufgaben/-ergebnisse

Da sich die gesamte Aufgabe um ein Projekt handelt, sind dementsprechend wie aus dem Projektplan zu entnehmen, mehrere Teilaufgaben als Wochenziele festgelegt worden. Im Folgenden werden die Wochenziele und deren Ergebnisse beschrieben.

KW 18

Aufgaben:

Für die erste Woche nach den Workshops sind folgende Aufgaben als Lastenheft festgelegt worden. Diese Aufgaben beziehen sich im Wesentlichen auf die Bearbeitung des Offline-Models und der Ausgegebene Plots in Matlab.

Die Aufgaben lauten:

1.1 Nicht Gesamte Strecke zeigen, Point of Interest in den Vordergrund

1.2 Analyse/Auswertung der Parklückenvermessung -> plot

1.3 Titel der Figure hinzufügen

1.4 Diagramme die relevant fürs Einparken sind, beibehalten (siehe Bild 4)

1.5 Konzept Kollisionskontrolle

Ergebnisse:

1.1 Der Autozoom wurde in den Plot des Offline-Models eingeführt.

[Bild 3]

1.2 In Plot 1 (Bild 4) wird eine Zoom-Darstellung des Einparkmanövers aus der Draufsicht angezeigt. In Plot 2 wird die Geschwindigkeit dargestellt. In Plot 3 wird der Radeinschlag/Lenkwinkel angezeigt. Im Plot 4 wird der Fahrzeug Drehwinkel dargestellt. Im Plot 5 werden die Parklücken ausgegeben. In Plot 6 werden die Rohdaten des Gierratensensors ausgegeben. In Plot 1 wird das Ergebnis über die Strecke dargestellt. In den Plots 2-6 werden die Ergebnisse über die Zeit dargestellt.

1.3 Den ausgegebenen Plots wurde ein Titel hinzugefügt.

[Bild 4]

1.4 Irrelevante Plots wurden entfernt. Die wichtigsten Plots sind erhalten geblieben. (siehe Bild 4)

1.5 Die ersten Ideen zum Kollisionskonzept befinden sich in dem Folgenden PDF-Dokument [1] Abruf: 11.07.2014

KW 19

Aufgaben:

In der zweiten Woche sind zum Termin, Aufgaben zum Thema Sensorik gekommen. Diese Aufgaben sind zur Bearbeitung des „neuen“ Gyrosensors Gyrosensor (LPR510AL) durchgeführt worden.

2.1 Kenndaten des Signals ermitteln und mit dem Datenblatt vergleichen:

2.2.1 Erreichbare Auflösung im Zusammenspiel mit der DS1104

2.2.2 Drift = über Zeit

2.2.3 Empfindlichkeit = Eingang / Ausgang

2.2.4 Unsicherheit

2.3 Dokumentation

2.4 Schaltplan zum Testen des Gyrosensors mit ControlDesk

2.5 Projektplan anpassen

Ergebnisse

Die Ergebnisse zur KW 19 und zum Charakterisieren des Gierratensensors sind auf der Seite Gyrosensor (LPR510AL) abgelegt.

KW 20

Aufgaben:

In der dritten Woche fand der Workshop: AEP - Autonomes Einparken statt. Zusätzlich wurden folgende Punkte bearbeitet.

3.1 Hausaufgaben des Praktikums (Workshop: AEP[2] ) vorbereiten (Tipp: VPN Verbindung zum Auto)

3.2 Praktisch parken

3.3 Skalierungsfaktor für Giro einbauen (mV zu °/s)

3.4 Offene Punkte nachbessern

3.4.1 Unsicherheit

3.4.2 Dokumentation

3.4.3 Schaltplan zum Testen des Gyrosensors mit ControlDesk

3.5 Projektplan anpassen

3.6 Alle offenen Punkte bis Projektende notieren, Punkte Zeitschätzungen zuweisen (angefangen)

Ergebnisse

3.1 Siehe Workshop AEP (Verbindung über VPN ist nur am „Haupt“-Rechner vorhanden)

3.2 Parken ist nur in der Theorie möglich, im Stateflow-Modell werden alle wesentlichen Abschnitte durchlaufen. Die Berechnung der Geschwindigkeit ist fehlerhaft, weswegen die darauf aufbauenden Abschnitte ebenfalls fehlerhaft sind.

3.3/3.4 Die Ergebnisse zu 3.3/3.4 sind auf der Seite Gyrosensor (LPR510AL) abgelegt.

3.5 Siehe Projektplan [3]

3.6 Siehe offene Punkte [[4]] Abruf: 11.07.2014

KW 22

Aufgaben:

4.1 Reset des AEP-Modus -> auf Anfang (durch Knopfdruck)

4.1.1 x=0

4.1.2 v=0

4.1.3 Gyro -> kalibrieren

4.1.4 Modul -> Reset

4.2 AEP_Lenkung & AEP_Gas sollvorgaben & Ist in Diagramm zeigen

4.3 AEP Status: Einfügen einer Zustandsvariable In welchem Zustand des State-Flow Diagramm befindet er sich?

4.4 Debug -> Was geht schief?

Ergebnisse

4.1 Der Taster für den Reset kann angesprochen werden. Jedoch können die Informationen nicht an die Aktuatorik weiter gegeben werden ( Siehe Projekt-Störungen [5]

4.2/3 Im Folgendem Bild 5 befindet sich die im ControlDesk erstellte Seite für den AEP-Modus. Die Informationen zur AEP_Geschwindigkeit befinden sich unten links im Bild. Die Informationen zur AEP_Lenkung befinden sich unten rechts im Bild. Oben im Bild befinden sich die Informationen über den aktuellen Zustand im Stateflow-Modell. Im Stateflow-Modell werden die Zustände während des Einparkvorgangs ausgegeben.

[Bild 5]

4.4

Parameter:

Soll-Lenkwinkel wird nicht richtig in Ist-Lenkwinkel umgewandelt.

Sollgeschwindigkeit wird nicht richtig in Ist-Geschwindigkeit umgewandelt.

Gierrate wird nicht korrekt bestimmt.

Entsprechende Folgefehler:

Die gefahrene Strecke, wird entsprechend der falschen IST-Geschwindigkeit berechnet.

Parklückengröße wird durch die falsche Streckenmessung falsch berechnet.

Die „Parallel“ End-Parkposition wird durch die falschen Gierraten Werte falsch berechnet.

Autoren : Martin Berysztak Adem Hadziric (Diskussion) 21:00, 11. Jul. 2014 (CET)

Projekt-Störungen

Das größte Problem bei der Bearbeitung der Aufgaben war, dass die Geschwindigkeitsmessung nicht korrekt war. Darauf aufbauend konnte beispielhaft die nötige Streckenmessung vollzogen werden. Diese wiederum ist für die Parklücken Vermessung nötig.

Ein weiteres Problem war, dass zu Beginn des Projekts der Gierratensensor ebenfalls nicht immer korrekte Informationen übergeben hat. Dies wurde durch den neuen Gierratensensor behoben.

Autoren : Martin Berysztak Adem Hadziric (Diskussion) 21:00, 11. Jul. 2014 (CET)

Ausblick

Da mit der neuen Platine ebenfalls neue Hall-Sensoren für die Geschwindigkeitsmessung eingebaut worden sind, kann im folgendem Semester der AEP-Algorithmus neu bearbeitet werden. Zusätzlich sind die Informationen des Gierratensensors verbessert worden. Mit dem alten Sensoren wurde bereits der AEP-Algorithmus passend durchlaufen, jeodch ist das Ergbenis fehlerbehaftet. Nun kann im folgendem Semester der AEP-Allgoritmus neu getestet werden.

Autoren : Martin Berysztak Adem Hadziric (Diskussion) 21:00, 11. Jul. 2014 (CET)

Verbesserungsvorschläge zum Artikel

--Prof. Dr. Mirek Göbel (Diskussion) 13:45, 8. Aug. 2014 (CEST) Abbildung der Regelstrecken als PT1 fehlt Zuviel Fließtext --> mehr Aufzählungen, Formeln etc., Reduktion aufs Wesentliche!