AEP - Autonomes Einparken: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
 
(280 dazwischenliegende Versionen von 9 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
Im Rahmen des Praktikums SDE, wurde das Teil-Projekt: AEP-Autonomes Einparken durchgeführt. In diesem Artikel, werden die [[AEP_-_Autonomes_Einparken#Anforderungen an die Disziplin|''Anforderungen an die Disziplin'']], die [[AEP_-_Autonomes_Einparken#Auswahl der Sensoren |''Auswahl der Sensoren'']], sowie verschiedene [[AEP_-_Autonomes_Einparken#Grundlagen |''Grundlagen'']] für den [[Fahrzeugsoftware#bib_AutonomesEinparken.mdl|Einparkalgorithmus]] beschrieben.
Die Autoren, die diesen Artikel verfasst haben sind: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]], [[Benutzer:Martin_Berysztak|Martin Berysztak]] und [[Benutzer:Adem_Hadziric|Adem Hadziric]].
[[Kategorie:Autonom]]


=='''Allgemeines'''==
== Allgemeines ==
=== Anforderungen an die Disziplin ===
Innerhalb des Projektes SDE - Autonomes Fahrzeug arbeiten im SoSe 2020 sowie im WiSe 2020/2021 zwei Teams an dem Thema 'Autonomes Einparken' (AEP). Das Teilteam [[AEP - Einparkalgorithmus| AEP - Einparkalgorithmus]] an der Implementierung des Parkvorgangs und das Teilteam [[AEP - Einparksensorik| AEP - Einparksensorik]] an der zugehörigen Fahrzeughardware (Sensoren für den Einparkvorgang).
Die Anforderungen an das autonome Einparken in diesem Projekt wurden mit den Dozenten abgesprochen und richten sich teilweise an den Carolo Cup <ref> "Lastheft für das Projekt Autonomes Fahrzeug" von Prof. Dr. M. Göbel & Prof. Dr. U. Schneider, Hochschule Hamm-Lippstadt, Department Lippstadt.</ref>.
Dieser Artikel dient der Dokumentation der entwickelten Software und der für den Einparkvorgang benötigten Harwdare.


# Das Fahrzeug muss auf einer geraden Straße - fahrend auf der rechten Straßenseite - eine passende Parklücke finden und in diese parallel zur Straße einparken.
'''Weiterführende Artikel
# Das Einparkmanöver muss durch einen Taster am Fahrzeug gestartet werden können.
*[[AEP - Einparkalgorithmus| AEP - Einparkalgorithmus]]
# Das Fahrzeug muss an rechts stehenden Hindernissen, auf der Suche nach einer ausreichend großen Parklücke, vorbeifahren.
*[[AEP - Einparksensorik| AEP - Einparksensorik]]
# Sobald die erstmögliche Parklücke gefunden ist, muss das Einparken mit dem rechten Blinker signalisiert werden.
# Während des Einparkmanövers darf die äußere weiße Linie nicht überfahren werden.
# Während des Einparkmanövers sind Kollisionen mit Hindernissen nicht erlaubt.
# Der Abstand zum vorderen und hinteren Hindernis muss nach dem Einparkmanöver jeweils mindestens 0,1m betragen.
# 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.
# Das Einparkmanöver muss innerhalb von 30 Sekunden durchgeführt werden.


 
== Grundlagen ==
Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:23, 3. Feb. 2014 (CET)
 
Autor: [[Benutzer:Martin_Berysztak|Martin Berysztak]] ([[Benutzer Diskussion:Martin Berysztak|Diskussion]]) & [[Benutzer:Adem_Hadziric|Adem Hadziric]] ([[Benutzer Diskussion:Adem Hadziric|Diskussion]]) 14:39, 5. Feb. 2015 (CET)


=== Auswahl der Sensoren ===
=== 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 [[Fahrzeughardware#Infrarot Sensor|Sharp GP2D120]], der Gierratensensor vom Typ [[Gyrosensor (LPR510AL)|LPR510AL]] und Hallsensoren zur [[Geschwindigkeitsermittlung|Geschwindigkeitsermittlung]] verwendet.
Die Sensoren wurden in Anlehnung an gängige Lösungen des Carolo Cups ausgewählt. Für den Einparkvorgang werden vier Infrarotsensoren (nachfolgend: IR), ein Gierratensensor und mehrere Hallsensoren zur [[Geschwindigkeitsermittlung|Geschwindigkeitsermittlung]] eingesetzt. Eine Übersicht der Hardware des Fahrzeugs ist in dem Artikel [[Fahrzeughardware|Fahrzeughardware]] zu finden.


'''Infrarotsensoren:'''
'''Infrarotsensoren:'''


Die Positionen der IR sind im Artikel [[Fahrzeughardware#Infrarot Sensor|Sharp GP2D120]] definiert und beschrieben.
Die Positionen der IR sind im Artikel [[Infrarotsensoren|Infrarotsensoren]] festgehalten.
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.  
Die IR werden während des Einparkvorgangs zur Entfernungsmessung verwendet. Mit Hilfe der Messungen der seitlich montierten IR werden Parklücken erfasst und ausgemessen und der seitliche Abstand zu den am Straßenrand parkenden Fahrzeugen ermittelt. Die hinten am Fahrzeug montierten IR dienen zur Kollisionsvermeidung und der Positionierung innerhalb der Parklücke.  
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 das Fahrzeug noch ein Stück vorfahren muss oder nicht, um dem hinteren Fahrzeug Platz zum Ausparken zu lassen.


'''Gierratensensor:'''
'''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 durch eine vorher berechnete Winkellage β (siehe [[#Berechnung nötiger Größen|Berechnung nötiger Größen]]) gesteuert. Außerdem wird der Sensor dafür eingesetzt, das Anhalten des Fahrzeugs zu erreichen, sobald der Winkel des Gyroskops 0 rad (0°) erreicht.
Um geregelt an den parkenden Fahrzeugen vorbeifahren zu können und um erfolgreich ein eine Parklücke einparken zu können, wird die aktuelle Winkellage des Fahrzeugs benötigt. Zur Bestimmung dieser wird ein [[Gyrosensor (LPR510AL)|Gierratensensor]] eingesetzt.  


'''Hallsensor (Geschwindigkeitsmessung):'''
'''Hallsensoren:'''


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.
Die Geschwindigkeitsermittlung erfolgt durch die Auswertung der im Motor verbauten Hallsensoren. Die Streckenmessung erfolgt über die Ableitung der Geschwindigkeit. Die bereits zurückgelegte Strecke wird hauptsächlich für das Vermessen der Parklücken benötigt. Die weiteren Details der Hardware, sowie das physikalische Messprinzip sind in dem Artikel [[Hall-Sensor|Hall-Sensor]] beschrieben.


=== Einbindung der AEP-Bibliothek in die Simulink Umgebung ===


Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:23, 3. Feb. 2014 (CET)
'''Autoren:''' [[Benutzer:Martin Theine|Martin Theine]] und [[Benutzer:Patrick Schumann|Patrick Schumann]]
<br />
'''Stand:''' 12.02.2021
<br />


Autor: [[Benutzer:Martin_Berysztak|Martin Berysztak]] ([[Benutzer Diskussion:Martin Berysztak|Diskussion]]) & [[Benutzer:Adem_Hadziric|Adem Hadziric]] ([[Benutzer Diskussion:Adem Hadziric|Diskussion]]) 14:39, 5. Feb. 2015 (CET)
Die Umsetzung des Einparkvorgangs erfolgt in einer eigenen Bibliothek (bib_AutonomesEinparken.mdl) der Fahrzeugsoftware.  


== '''Grundlagen''' ==
Die Einbindung des AEP Blocks (gelb umrandet) im Offline-Modell (Simulation) ist in der folgenen Abbildung dargestellt:


=== Einbindung des Einparkalgorithmus in die Simulink Umgebung ===
[[Datei:CCF offline AEP markierung.png|700px|AEP-Block eingebunden im Offline-Modell]]


Das Hauptmodell für die Offline Simulation ist in der folgenden Abbildung dargestellt. Das Einparken wurde im Block [[Fahrzeugsoftware#bib_AutonomesEinparken.mdl|AEP - Autonomes Einparken]] implementiert (orange hinterlegt dargestellt) und besitzt in der Online-Umgebung auf der Dspace Box denselben Aufbau, mit dem Unterschied, dass dort die Sensorwerte und Fahrbahn nicht simuliert werden müssen. Der gesamte Bus steht der Software zur Verfügung. Der Aufbau des Blocks und dessen internen Funktionen zur Umsetzung des Einparkalgorithmus findet sich in diesem [[Fahrzeugsoftware#bib_AutonomesEinparken.mdl|Link]] wieder.
Die Einbindung des AEP Blocks (gelb umrandet) im Online-Modell (Carolo-Cup-Fahrzeug) ist in der folgenen Abbildung dargestellt:


[[Datei:Online-Modell.png|700px|AEP-Block eingebunden im Online-Modell]]


[[Datei:CCF offline AEP markierung.png|700px|AEP-Block Positionierung im Simulinkmodell]]
=== Schnittstellen zu anderen Softwaremodulen ===
'''Autoren:''' [[Benutzer:Martin Theine|Martin Theine]] und [[Benutzer:Patrick Schumann|Patrick Schumann]]
<br />
'''Stand:''' 12.02.2021
<br />


Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:24, 3. Feb. 2014 (CET)


=== Auswahl des Einparkmodus ===
''' Bibliothek "bib_Fahrtmodus.mdl" '''


Um das Einparkmanöver zu starten, muss zu Beginn das Simulink-Modell [[Fahrzeugsoftware#Hauptdatei start.m|start.m Datei]] in MATLAB geöffnet werden.
Der Zustandsautomat des Einparkalgorithmus gibt ausgangsseitig die Variablen ...
Für den Einparkmodus bestehen die Möglichkeiten, nach der Lückenfindung direkt einzuparken (Simulinkmodus = 3) oder stehen zu bleiben (Simulinkmodus = 2).
Beim Online-Model muss beachtet werden, dass vor der Betätigung des AEP-Tasters, die Aktuatoren ausgeschaltet werden, damit die Kalibrierung des Gierratensensors gemacht wird. Hierzu muss der Hebel, der sich hinten am Fahrzeug befindet, in die Mittelstellung gebracht werden.


Alle weiteren Einstellungen sind optional und werden in diesem [[Fahrzeugsoftware#Hauptdatei start.m|Link]] erläutert.
{| class="mw-datatable"
! Parameter !! Beschreibung
|-
|
|-
|rowspan="2" |Famo_Modi_Schalter_Lw_int ||1 = Lenkwinkelvorgabe durch BSF-Querregelung
|-
|| 2 = Lenkwinkelvorgabe durch AEP
|-
|
|-
|rowspan="2" |Famo_Modi_Schalter_Vx_int ||1 = Geschwindigkeitsvorgabe durch BSF-Längsregelung
|-
|| 2 = Geschwindigkeitsvorgabe durch AEP
|}


Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:24, 3. Feb. 2014 (CET)


Autor: [[Benutzer:Martin_Berysztak|Martin Berysztak]] ([[Benutzer Diskussion:Martin Berysztak|Diskussion]]) & [[Benutzer:Adem_Hadziric|Adem Hadziric]] ([[Benutzer Diskussion:Adem Hadziric|Diskussion]]) 14:39, 5. Feb. 2015 (CET)


=== Auswahl der geeigneten Geschwindigkeit ===
... auf den CCF-Bus. Diese beiden Werte werden vom "FAMO"-Block verwendet, um die Lenkwinkel- und Geschwindigkeitsvorgabe für BSF oder AEP zu konfigurieren.


Im Fall AEP, wird der Lenkwinkel zunächst über den "BSF"-Block vorgegeben (geregelt geradeaus fahren: Famo_Modi_Schalter_Lw_int = 1) bis eine Parklücke
gefunden wurde. Daraufhin wird im Zustandsautomaten des Einparkalgorithmus auf die AEP-Vorgabe gewechselt (Famo_Modi_Schalter_Lw_int = 2), um die Kurven
des Einparkvorgangs fahren zu können. Die Geschwindigkeitsvorgabe erfolgt im Fall AEP dauerhaft durch den Zustandsautomaten des Einparkalgorithmus
(Famo_Modi_Schalter_Vx_int = 2).


[[Datei:InfrarotMesszeit.PNG|500px|Messzeiten des Infrarotsensors]] <ref> "Sharp-GP2D120" von Sharp, Sharp.</ref>


Der vorangegangenen Abbildung aus dem Datenblatt "Sharp-GP2D120.pdf"<ref> "Sharp-GP2D120" von Sharp, Sharp.</ref> (siehe [[Fahrzeughardware#Infrarot Sensor|Infrarot Sensor]]) ist zu entnehmen, dass maximal eine Zeit für eine Messung benötigt wird, von:
''' Bibliothek "bib_Sensoren_Aktoren_offline.mdl" '''


Im Offline-Modell (Simulation) bekommt der Zustandsautomat des Einparkalgorithmus eingangsseitig simulierte Sensorsignale aus dem Block "SEN" (Sensoren) über den CCF-Bus:


<math>t= 38,3\,ms + 9,6\,ms + 5\,ms = 52,9\,ms</math>.




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:
{| class="mw-datatable"
! Parameter !! Beschreibung
|-
||SenVx_sx_K_f64 ||berechnete gefahrene Strecke des simulierten Fahrzeugs aus dem Kinematikmodell
|-
||SenGier_psi_filt_K_f64 ||simulierter Gierwinkel des Fahrzeugs
|-
||SenAbs_xVR_K_f64 ||simulierter Abstandswert des vorderen rechten IR-Sensors
|-
||SenAbs_xHR_K_f64 ||simulierter Abstandswert des rechten hinteren IR-Sensors
|-
||SenAbs_yHR_K_f64 ||simulierter Abstandswert des rechten hinteren IR-Sensors
|-
||SenAbs_yHL_K_f64 ||simulierter Abstandswert des linken hinteren IR-Sensors
|-
|}




<math>t=3\cdot 52,9\,ms = 158,7\,ms.</math>
Ausgangsseitig wird der Solllenkwinkel (AEP_LwSoll_f64) und die Sollgeschwindigkeit (AEP_vx_K_soll_f64) auf den CCF-Bus gelegt. Durch o.g. Konfiguration
mittels "FAMO"-Block wird initial die Lenkwinkelvorgabe aus dem Block "BSFQuer - Querfuehrung" an den Block "AKT" (Aktoren) weitergegeben (Lücke suchen).
Beim Einparken wird die Lenkwinkelvorgabe des AEP-Blocks direkt an den Block "AKT" (Aktoren) weitergegeben. Die Geschwindigkeitsvorgabe erfolgt während
AEP dauerhaft durch den "AEP"-Block via "FAMO" -> "BSFLaengs - Laengsfuehrung" an den Block "AKT" (Aktoren). Der Block "AKT" (Aktoren) gibt die Vorgaben
für den Lenkwinkel und die Geschwindigkeit an das Kinematikmodell weiter.  




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:
''' Bibliothek "bib_Sensoren_Aktoren_online.mdl" '''


Im Online-Modell (reales Fahrzeug) bekommt der Zustandsautomat des Einparkalgorithmus eingangsseitig die realen Sensorsignale aus dem Block "SEN" (Sensoren) über den CCF-Bus:


<math>v= \frac{0,1\,m}{158,7\cdot10^{-3}\,s} =0,63\,\frac{m}{s}.</math>


{| class="mw-datatable"
! Parameter !! Beschreibung
|-
||SenVx_sx_K_f64 ||gefahrene Strecke des Fahrzeugs
|-
||SenGier_psi_filt_K_f64 ||Gierwinkel des Fahrzeugs
|-
||SenAbs_xVR_K_f64 ||Abstandswert des vorderen rechten IR-Sensors
|-
||SenAbs_xHR_K_f64 ||Abstandswert des hinteren rechten IR-Sensors
|-
||SenAbs_yHR_K_f64 ||Abstandswert des rechten hinteren IR-Sensors
|-
||SenAbs_yHL_K_f64 ||Abstandswert des linken hinteren IR-Sensors
|-
|}


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


[https://wiki.hshl.de/wiki/index.php/Infrarotsensoren Position und Beschreibung der Infrarot Sensoren]


[[Bild:Grafik IR Sensoren.svg|300px|mini|Skizze der Sensorpositionen der Infrarotsensoren [https://wiki.hshl.de/wiki/index.php/Infrarotsensoren Beschreibung der Infrarot Sensoren]]]


Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:24, 3. Feb. 2014 (CET)
Ausgangsseitig wird der Solllenkwinkel (AEP_LwSoll_f64) und die Sollgeschwindigkeit (AEP_vx_K_soll_f64) auf den CCF-Bus gelegt. Durch o.g. Konfiguration
mittels "FAMO"-Block wird initial die Lenkwinkelvorgabe aus dem Block "BSFQuer - Querfuehrung" an den Block "AKT" (Aktoren) weitergegeben (Lücke suchen).
Beim Einparken wird die Lenkwinkelvorgabe des AEP-Blocks direkt an den Block "AKT" (Aktoren) weitergegeben. Die Geschwindigkeitsvorgabe erfolgt während
AEP dauerhaft durch den "AEP"-Block via "FAMO" -> "BSFLaengs - Laengsfuehrung" an den Block "AKT" (Aktoren). Der Block "AKT" (Aktoren) gibt die Vorgabe
für den Lenkwinkel an den Lenkservo des Fahrzeugs weiter und die Vorgabe der Geschwindigkeit an den Fahrtenregler weiter.


Autor: [[Benutzer:Martin_Berysztak|Martin Berysztak]] ([[Benutzer Diskussion:Martin Berysztak|Diskussion]]) & [[Benutzer:Adem_Hadziric|Adem Hadziric]] ([[Benutzer Diskussion:Adem Hadziric|Diskussion]]) 15:17, 5. Feb. 2015 (CET)
=== Auswahl des Einparkmodus ===


=== Berechnung nötiger Größen ===
Um das Einparkmanöver zu starten, muss zu Beginn das Simulink-Modell [[Fahrzeugsoftware#Hauptdatei start.m|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 stehen zu bleiben (Simulinkmodus = 2).
Beim Online-Model muss beachtet werden, dass vor der Betätigung des AEP-Tasters, die Aktuatoren ausgeschaltet werden, damit die Kalibrierung des Gierratensensors gemacht wird. Hierzu muss der Hebel, der sich hinten am Fahrzeug befindet, in die Mittelstellung gebracht werden.


Das Fahrzeug besitzt einen maximalen Lenkeinschlag in eine Richtung von [[Fahrzeugsoftware#param_CAR.m|alpha = 23°]]. Kombiniert mit dem Radstand [[Fahrzeugsoftware#param_CAR.m|L = 0,265m]] ergibt dies einen Wendekreisradius um die Mitte der Hinterachse von:
Alle weiteren Einstellungen sind optional und werden in diesem [[Fahrzeugsoftware#Hauptdatei start.m|Link]] erläutert.
 
<math>r= \frac{L}{tan(\alpha)} = \frac{0,265\,m}{tan(25^\circ)} = 0,5683\,m.</math>
 
Die folgende Abbildung zeigt eine Skizze zur Herleitung der Wendekreisradiusberechnung.
 
[[Datei:Wenderadiusberechnung.jpg|200px|Skizze zur Berechnung des Wendekreisradius]]
 
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 hiteren 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.
 
 
[[Datei:Berechnung der Parklückengröße.png|700px|Skizze zur Berechnung der notwendigen Parklücke]] <ref> "Ein mathematisches Modell zum Parallelparken" von Nobert Herrmann, Univ. Hannover.</ref>
 
 
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 [http://de.wikipedia.org/wiki/Satz_des_Pythagoras Satz des Pythagoras] wie folgt:
 
 
<math>g1 = \sqrt[]{r^2-(r-\frac{w}{2}-\frac{p}{2})^2}</math>
 
 
Dies würde zu einer größeren Lücke führen, als eigentlich nötig, da die Möglichkeit besteht, nach Findung des vorderen Hindernisses eine weitere Strecke k nach vorne zu fahren. Dadurch wird gewährleistet, dass 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:
 
 
<math>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}</math>
 
 
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 sich direkt am stehenden Fahrzeug befindet. 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 [[Fahrzeughardware#Infrarot Sensor|GP2D120]]), setzt einen angenommenen Mindestabstand zur Berechnung voraus. In diesem Fall wird ein Abstand p = 15cm vorausgesetzt. Diese Annahme führt zu einer Mindestgröße der Parklücke von g = 1m. Durch geringe 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 <math>\beta</math> ist ebenfalls vom Abstand p abhängig und wird erst berechnet, wenn die Lücke gefunden und das Fahrzeug neben dem vorderen Hindernis steht.
 
 
<math>\beta = \arccos(\frac{r-\frac{w}{2}-\frac{p}{2}}{r})</math>
 
 
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 erst mal 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:
 
 
<math>k = \sqrt[]{(r-\frac{w}{2})^2-(r-\frac{w}{2}-p)^2}</math>
 
 
Da bei allen Parkmanövern (offline- und online-Modus), das Fahrzeug eine zu weite Strecke nach vorne gefahren ist, ist die benötigte Länge der Vorausfahrt reduziert worden. Hier ist über Tests rausgekommen, dass der Abzug der Größe k weggelassen werden kann.
 
 
Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:24, 3. Feb. 2014 (CET)
 
Autor: [[Benutzer:Martin_Berysztak|Martin Berysztak]] ([[Benutzer Diskussion:Martin Berysztak|Diskussion]]) & [[Benutzer:Adem_Hadziric|Adem Hadziric]] ([[Benutzer Diskussion:Adem Hadziric|Diskussion]]) 14:39, 5. Feb. 2015 (CET)
 
== '''Test der Abstandssensorik''' ==
 
=== Generierung von Testfällen ===
Um die Abstandssensorik zu testen werden Testfälle generiert und in Datenbanken gespeichert. Hierfür wurde in der Simulation eine Laufzeitvariable erstellt und an bestimmten Positionen die Simulation gestoppt. Die benötigten Variablen in den Testfällen sind folgende:
• ObjektListe
• Schalter
• stIRPosition
• x
• y
• psi
 
Zusätzlich ist zu beachten, dass die Simulation in der bibliothek 'SensorenAktoren_offline' gestoppt werden muss, da die Variablen nur lokal in der Funktion gespeichert werden und global nicht sichtbar sind. Damit Datenbanken in Matlab erstellt werden können muss der 'save' - Befehl verwendet werden. Jedoch hatte dieser in der Simulation einen Fehler ausgelöst, da dieser dort nicht verwendet werden darf. Um den Fehler zu umgehen wurden an den Stellen, an denen das Fahrzeug gestoppt werden sollte ein Breakpoint gesetzt. In einer if - Bedingung wurde bei Erreichen eines Wertes der Laufzeitvariable der Breakpoint gesetzt. Nun kann im Matlab Command Window der 'save' - Befehl manuell eingetippt werden. <br>
 
Beispiel für die Erstellung einer Datenbank:
• save('Messung1.mat','ObjektListe','stIRPosition','x','y','psi')
 
Durch Eingabe der 'Enter' - Taste wird die Datenbank im Arbeitsordner angelegt. Weiterhin ist zu beachten, dass die Variablen nicht im Workspace angezeigt werden, aber vorhanden sind. Deshalb ist das Speichern der Variablen möglich.
 
Die Ergebnisse zu der Generierung von Testfällen befinden sich im Branch [https://svn.hshl.de/svn/MTR_SDE_Praktikum/branches/Einparksensorik_SS_19/ Einparksensorik_SS_19].


=== Auswertung der Sensordaten ===
= Offline-Modell =
'''Autoren:''' [[Benutzer:Martin Theine|Martin Theine]] und [[Benutzer:Patrick Schumann|Patrick Schumann]]
<br />
'''Stand:''' 12.02.2021
<br />


Für die Auswertung gibt es eine Testumgebung für die Abstandssensorik. Diese befindet sich bei folgendem Link: [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Software/Demos/Test_der_Abstandssensorik/ Testumgebung] Um die Datenbanken der generierten Testfälle in die Testumgebung einzubinden, müssen sie zuvor in den Ordner, in dem sich die Testumgebung befindet, eingefügt werden. <br>
'''Konfiguration in der "start.m"-Datei zum Starten der Einparksimulation:'''


Anschließend kann in Matlab über den 'load' - Befehl die gewünschte Datenbank eingelesen werden.
{| class="mw-datatable"
! Parameter !! Auswahl !! Beschreibung
|-
|
|-
|rowspan="3" |"Schalter_offline" 
| style="text-align:right"| 0: || Online Modell
|-
|  style="background-color:#eee; text-align:right"| 1: || style="background-color:#eee;"| Simulation/ Offline-Modell auswählen
|-
| style="text-align:right"| 2: || PC Onlina Sensor Aktortest
|-
|
|-
|rowspan="4" style="background-color:#ccc;" | "PAR_Modi_Schalter_Fahrbahn_int"
| style="background-color:#aaa; text-align:right"| 0: ||  style="background-color:#aaa;"|Rundkurs ohne Kreuzung, Startpunkt kurz vor erster Kurve
|-
| style="background-color:#ccc; text-align:right"| 1: || style="background-color:#ccc;"| Rundkurs mit Kreuzung
|-
| style="background-color:#aaa; text-align:right"| 2: || style="background-color:#aaa;"| Rundkurs mit Kreuzung, Start direkt vor S-Kurve
|-
| style="background-color:#ccc; text-align:right"| 3: || style="background-color:#ccc;"| Rundkurs ohne Kreuzung mit Stopplinie
|-
|
|-
|rowspan="4" |"Simulinkmodus"
| style="text-align:right"| 1: || BSF
|-
| style="background-color:#eee; text-align:right"| 2: || style="background-color:#eee;"| AEP (Lücke suchen, vermessen und anschließend anhalten)
|-
| style="text-align:right"| 3: || AEP (Lücke suchen, vermessen und einparken)
|-
| style="background-color:#eee; text-align:right"| 4: || style="background-color:#eee;"| BSF incl. Objekt auf der Fahrbahn
|-
|
|-
|rowspan="2" style="background-color:#ccc;" |"Lw_Vx_Manuell"
|  style="background-color:#aaa; text-align:right"| 0: || style="background-color:#aaa;"|  Automatisch
|-
|  style="background-color:#ccc; text-align:right"| 1: || style="background-color:#ccc;"|  manuelle Vorgabe (Werte s. u. beim Fahrmanöver)
|-
|
|-
|rowspan="13" |"PAR_Modi_Schalter_Luecke_int"
| style="text-align:right"| 0: || Positionierung vorgegeben (größte Lücke vorne), feste Hindernisbreite
|-
| style="background-color:#eee; text-align:right"| 1: || style="background-color:#eee;"| Positionierung zufällig, feste Hindernisbreite
|-
| style="text-align:right"| 2: || Positionierung und Hindernisbreite zufällig
|-
| style="background-color:#eee; text-align:right"| 3: || style="background-color:#eee;"| keine passende Lücke
|-
| style="text-align:right"| 4: || kein Hindernis
|-
| style="background-color:#eee;text-align:right"| 5: || style="background-color:#eee;"| nur vorderes Hindernis und kleinstmögliche Parklücke (0.71 m)
|-
| style="text-align:right"| 6: || kleinstmögliche Parklücke (0.71 m) zuerst
|-
| style="background-color:#eee;text-align:right"| 7: || style="background-color:#eee;"| optimale Parklücke (0.9 m) zuerst
|-
| style="text-align:right"| 8: || mittlere Parklücke (1.1 m) zuerst
|-
| style="background-color:#eee;text-align:right"| 9: || style="background-color:#eee;"| größtmögliche Parklücke (1.5 m) zuerst
|-
| style="text-align:right"| 10: || schmales Hindernis hinten links
|-
| style="background-color:#eee;text-align:right"| 11: || style="background-color:#eee;"| schmales Hindernis hinten mittig
|-
| style="text-align:right"| 12: || schmales Hindernis hinten rechts
|-
|
|-


• Beispiel: load('Messung1.mat')
|}


Nachdem die Datenbank in der Testumgebung eingelesen wurde, wird diese gestartet. Anschließend kann graphisch ermittelt werden, welchen Abstand das Fahrzeug zum erkannten Objekt hat.
[[Datei:Position6 Sensor RechtsVorne.PNG|1200px]]


Dazu wird in der Grafik die Position des Sensors und die Position, an der das Objekt erkannt wurde, ausgewählt. Die y-Werte werden voneinander abgezogen und man erhält den Abstand von Fahrzeug zu Objekt. Die graphisch ermittelten Abstände wurden mit den Abständen, die von der Funktion zurückgegeben wurden verglichen. Hierzu wurde ein ausführlicher [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Testdokumente/AEP/2610_001.docx Testbericht] verfasst.
Das Fahrzeug startet nach einer kurzen Verzögerung zur Kalibrierung des Gierratensensors seine Fahrt entlang der Parklücken. Während des gesamten Suchvorgangs ist die geregelte Geradeausfahrt aktiv. Um dies zu zeigen startet das Fahrzeug im aktuellen Stand der Simulation leicht schräg und findet dann wieder auf seine Spur zurück.


Als Ergebnis kam heraus, dass die Sensordaten in Ordnung sind und übereinstimmen.
*In den Fällen, in welchen Hindernisse in der Parkbucht stehen (0,1,2,6 bis 12), fährt das Fahrzeug, nachdem es eine Parklücke gefunden hat, an dieser vorbei bis die Hinterachse auf gleicher Höhe wie das Heck des vorderen Fahrzeugs der Parklücke ist. Das Fahrzeug parkt ein und positioniert sich in der Parklücke.


Autor: [[Benutzer:David Reger|David Reger]]
*Falls keine passende Lücke in der Parkbucht existiert (Fall 3), fährt das Fahrzeug bis zum Ende der Parkbucht (mittels Streckenerfassung) und bleibt stehen.


== '''Optimierung der Software zur Aufnahme von Messwerten''' ==
*Falls kein Hindernis in der Parkbucht steht (Fall 4), fährt das Fahrzeug so lange an der Parkbucht vorbei, bis die gefahrene Strecke ausreicht, um während der Linkskurve des Einparkmanövers parallel zur Fahrbahn zu gelangen. In diesem Fall wird direkt mit der Rechtskurve des Einparkvorgangs begonnen, um ohne Orientierung an einem Hindernis (IR-Sensoren), nur mit Hilfe des Gierratensensors einzuparken.
Die eben dargestellten in den Testfällen benötigten Variablen werden teilweise mittels einer im Programm implementierten Schleife automatisch generiert. Damit lassen sich weiterhin bei einer Geradefahrt die verschiedenen Hindernisse detektieren. <br>
Die Änderung der Variable x von -10 bis -3 ermöglicht eine schrittweise Bewegung des in der Simulation modellierten Fahrzeugs. Am Ende jedes Schrittes wird der x- und der y-Wert des detektierten Hindernisses in einer Text-Datei gespeichert, welche bei jedem neuen Aufruf überschrieben wird. <br>


*Falls die erste Parklücke in der Parkbucht ausreicht, diese jedoch nur durch ein vorderes Hindernis begrenzt wird (Fall 5), so können die hinteren IR-Sensoren nicht genutzt werden, um einzuparken. Daher wird mittels festgelegter Streckenbegrenzung verhindert, dass das Fahrzeug an den "Boardstein" fährt.


== Beschleunigte Ermittlung von Sensormesswerten  ==
'''Simulation starten'''
MATLAB ist eine interpretierte Sprache. Dies bedeutet, dass jede Operation einen zusätzlichen Overhead in C oder C++ mit sich bringt. Diese Auswahl und Zuordnung der Matlab-Programmteile ist der Hauptgrund, warum MATLAB langsamer ist als kompilierte Sprachen. Der Overhead-Interpreter ist besonders wichtig, wenn Ihre Operationen mit Skalaren oder kleinen Datenmengen ausgeführt werden. Dies erklärt, warum skalarbasierte Schleifen in MATLAB notorisch langsam sind.<br>
MATLAB enthält eine Just-in-Time-Codegenerierung (JIT) oder Mex-Umstellungsmöglicchkeit, mit der dieses Problem in begrenzten Fällen behoben werden kann. Die Mex-Umstellung ermöglicht es, einen effizienten Code in C zu schreiben bzw. zu generieren (mithilfe vom Codegenerator), ohne den ursprünglichen Matlab-Code zu verlieren. <br>


Die Umsetzung dieser Technik zur Generierung der Mex-Funktion erfolgt durch folgenden Befehl: <br>
1 : Parameter Konfigurieren (s.o.) "start.m"-Datei ausführen (Run)
2 : Offline-Modell (Simulink) wird geöffnet
3 : In Simulink auf "Run" klicken


• t = coder.typeof(0, [1e6 3],1);<br>
'''Letzter lauffähiger Stand der Offline-Simulation des Einparkvorgangs (10.07.2020):'''
• C = coder.typeof(0, [1e6 3],1);<br>
• vt = coder.typeof(0, [1e6 3],1);<br>
• R = coder.typeof(0, [1e6 9],1);<br>
• EV = coder.typeof(0, [1e6 3 3],1);<br>
• '''codegen Matlab-Funktionsname -args { EV,t,vt,C,R }'''<br>


Der Einsatz im Rahmen des Simulationsprogramms zur Einparksensorik erfolgt durch den Befehl: <br>
SVN -> SDE Praktikum -> Software -> CaroloCupFahrzeug -> Update to '''Revision: 5502'''


• codegen fcn -args {} <br>
Probleme in aktueller Head-Revision:


*parkende Hindernisse werden nicht mehr dargestellt (ab Revision 5539)
*die Querregelung wurde vom "Einspurmodell" auf das "Kinematikmodell" umgestellt und der Regler neu parametriert, wodurch die geregelte Geradeausfahrt nur noch mangelhaft funktioniert (ab Revision 5516)


Nach Aufruf dieses Befehls in Matlab Command Windows kommt man im Projektordner auf eine generierte C-Version der berücksichtigten Matlab-Funktion. Diese C-Version wird automatisch mit folgendem Namen generiert: ''Matlab-Funktionsname_mex'' <br>
'''Bearbeiten der Parklücken:'''


Als nächstes wird im Hauptprogramm der Matlab-Funktionsname (fcn) durch den Namen der entsprechenden generierten Mex-Version (fcn_mex) ersetzt, wobei nach der Programmausführung die in der folgenden Tabelle dargestellten Laufzeitdifferenzen zu erkennen sind:
Die Parklücken und Objekte werden in der "param_SEN_offline.m" im Ordner "parameter" initialisiert. Diese werden anschließend in einem Vektor in "PAR_SenAbs_ObjektListe_f64" gespeichert und in der Darstellungsfunktion "funktion_simulink_simultan_draufsicht" aufgerufen.
Die einzelnen Parklücken werden in einer "switch case"-Schleife erstellt, sodass (in diesem Fall) 9 unterschliedlich lange Parklücken erstellt werden können. Dabei kann eine Lücke mehrfach verwendet werden, es wird also ein Vektor mit den gleichen Werten gefüllt.
Die Objekte werden analog dazu erstellt. Der daraus resultierende Seitenstreifen, in den das Fahrzeug einparken soll, wird mit einer Zählschleife im Vektor "x" in der Reihenfolge Objekt, dann Parklücke zusammengefasst.


= Online-Modell =
'''Autoren:''' [[Benutzer:Martin Theine|Martin Theine]] und [[Benutzer:Patrick Schumann|Patrick Schumann]]
<br />
'''Stand:''' 12.02.2021
<br />


[[Datei:Geschwindigkeitstest.PNG]]
'''Konfiguration in der "start.m"-Datei zum Starten der Einparksimulation:'''


Autoren: [[Benutzer:Yanick Christian Tchenko|Yanick Christian Tchenko]] ([[Benutzer Diskussion:Yanick Christian Tchenko|Diskussion]])18. Mär. 2019
* "Schalter_offline" = 0 (Modell für die dSPACE-Karte auswählen)
* "Simulinkmodus" = 2 -> Lücke finden und stehen bleiben ODER "Simulinkmodus" = 3 Lücke suchen und einparken
* "Lw_Vx_Manuell" = 0 -> automatische Vorgabe des Solllenkwinkels und der Sollgeschwindigkeit
* "PAR_Schleichmodus" = 0 -> Geschwindigkeitsbegrenzung bei Fernbedienungseingriff auf 0.3 m/s (Wettkampfmodus) ODER 1 -> Geschwindigkeitsbegrenzung bei Fernbedienungseingriff auf 1 m/s (Testmodus)
* "PAR_FernB_Schalter_AUS_int" = 0 -> Fernbedienungseingriff aktivieren


== '''Aktueller Stand''' ==
'''Modell auf das Fahrzeug laden'''


Bei mehrmaligen Tests mit dem Fahrzeug konnte kein erfolgreicher Durchgang aufgenommen werden. Das Fahrzeug fährt an den parkenden Hindernissen vorbei, ohne das Einparkmanöver zu starten.
* nach Konfiguration (s.o.) "start.m"-Datei ausführen (Run)
* Online-Modell (Simulink) wird geöffnet
* In Simulink auf "Build & Deploy" klicken
* Status des Builds wird im Command Window von MATLAB angezeigt
* Nach Ausrichtung des Fahrzeugs die Spannungsversorgung des Antriebs einschalten
* AEP-Starttaster betätigen


→ Das entsprechende Testprotokoll ist im SVN hinterlegt: [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Dokumentation/Testprotokolle/Autonomes_Einparken.xlsx Testprotokoll: Autonomes Einparken]
'''Der aktuelle Einparkalgorithmus konnte bislang noch nicht vollständig auf dem Fahrzeug getestet werden (Stand 12.02.2021).'''


In der Offline-Simulation wurden mit der aktuellen AEP-Bibliothek keine Fehler festgestellt. Diese lässt sich allerdings aufgrund des nicht-kompilierfähigen Online-Modells (siehe [[Starten der Online-Simulation]]) nicht auf dem Fahrzeug testen.
Während der Fehleranalyse im Wintersemester 20/21 konnte die Hardware für die Hall-Sensorik vollständig durch das Team AEP - Einparkalgorithmus überprüft und repariert werden (Link Fehlerprotokoll).
Das Fahrzeug ist aktuell trotzdem nicht autonom fahrfähig, da die gefahrene Strecke und Ist-Geschwindigkeit noch nicht korrekt erfasst werden (Link Video). Somit kann keine korrekte Längsregelung (Geschwindigkeitsregelung) stattfinden. Der Einparkalgorithmus ist sowohl von einer funktionierenden Regelung auf die vorgegebenen Sollgeschwindigkeiten als auch von einer funktionierenden Streckenerfassung abhängig.


Autoren: [[Benutzer:Steffen Topp|Steffen Topp]] ([[Benutzer Diskussion:Steffen Topp|Diskussion]])
'''Mögliche Fehlerquellen:'''


== [[Lageregelung beim Einparken]] ==
* Vermutung 1: ab einer gewissen Motordrehzahl werden zu viele Interrupts durch die Hall-Kombi-Logik ausgelöst (Task Overrun) -> nicht alle Interrupts werden verwertet -> falsche Berechnung der Geschwindigkeit und Strecke<br /> (ignorierte Fehlermeldung: siehe [[AEP - Einparksensorik]] -> 7.2 "Behebung des Absturzes im Online-Modell")
Das Spezialthema soll zur Verbesserung der Ausrichtung des Fahrzeugs in der Parklücke beitragen. Aktuell befindet sich die Erweiterung aufgrund ausstehender Tests noch in einem [https://svn.hshl.de/svn/MTR_SDE_Praktikum/branches/2018_12_14_Lageregelung/ SVN Branch].


== '''Ausblick'''  ==
* Vermutung 2: Die Getriebeübersetzung des Fahrzeugs wurde in der Vergangenheit verändert. Unter Umständen wird die Berechnung dadurch verfälscht, dass das Übersetzungsverhältnis in Software nicht darauf angepasst wurde <br /> (Messfehler scheint linear zu sein).
Aufgrund des fehlerhaften Online-Modells ist die Betrachtung des Einparkmanövers nur in der Simulation und nicht am Fahrzeug möglich (siehe [[Starten der Online-Simulation]]).  


Mögliche Erweiterungen des autonomen Einparkens sind folgende:
Der autonomen Fahrfunktion steht vermutlich nur noch die o.g. Problematik im Wege. Durch eine Hardwaresimulation mit LtSpice konnte herausgestellt werden, dass die Interrupt-Fehler vermutlich mit der Kondensatorspannung des Kondensators C2 (Schaltplan) des Tiefpassfilters der Hall-Kombi-Logik auf der Adapterplatine zur dSPACE-Karte entstehen. Die Ergebnisse dieser Simulation lassen auf eine falsche Dimensionierung des beschriebenen Bauteils bzw. des Tiefpassfilters schließen. '''Diesen Sachverhalt gilt es im Sommersemester 2021 bzw. Wintersemester 2021/22 genauer zu untersuchen.'''
* Verknüpfung mit der Regelung zur Geradeausfahrt (aktuell: Vorgabe eines 0° Lenkwinkels)
* [[Lageregelung beim Einparken]]
* [https://svn.hshl.de/svn/MTR_SDE_Praktikum/trunk/Teams/AEP/Berysztak_Hadziric/Kollisionskontrolle.docx Kollisionskontrolle]


-> Links einfügen


Autor: [[Benutzer:Steffen Topp|Steffen Topp]] ([[Benutzer Diskussion:Steffen Topp|Diskussion]])
Zusätzlich kann festgehalten werden, dass die Steuerung des Antriebs mittels Fernbedienung oder manueller Vorgabe in Control Desk einwandfrei funktioniert '''(siehe [[Analyse und Fehlersuche WS20/21]]).''' Der Fahrtenregler, welcher die Eingabe per Fernbedienung oder Control Desk in eine Motordrehzahl umsetzt, greift auf die Hall-Sensorik zurück. Würde diese fehlerhaft sein (Sensor defekt/falsche Phasenzuordnung), so wäre keine kontrollierte Fahrt auf eben genannte Weise möglich. Der dSPACE-Karte stehen die selben Hall-Signale (zur Geschwindigkeitsermittlung/Streckenerfassung/Fahrtrichtungserkennung) zur Verfügung. Diese Beobachtung stützt die Annahme, dass die aktuell noch vorhandene Antriebsproblematik lediglich auf die Interrupt-Fehler bzw. eine fehlerhafte Geschwindigkeitsberechnung in der Software zurückzuführen ist '''(siehe Online-Modell: Block "SEN - Geschwindigkeit").'''


=='''Quellen / Weiterführende Literatur'''==
= Weiterführende Artikel =


<references />
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]]
<br />→ zum Artikel Einparkalgorithmus: [[AEP - Einparkalgorithmus| AEP - Einparkalgorithmus]]
<br />→ zum Artikel Einparksensorik: [[AEP - Einparksensorik| AEP - Einparksensorik]]


----
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]]
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]]

Aktuelle Version vom 22. November 2023, 13:55 Uhr

Allgemeines

Innerhalb des Projektes SDE - Autonomes Fahrzeug arbeiten im SoSe 2020 sowie im WiSe 2020/2021 zwei Teams an dem Thema 'Autonomes Einparken' (AEP). Das Teilteam AEP - Einparkalgorithmus an der Implementierung des Parkvorgangs und das Teilteam AEP - Einparksensorik an der zugehörigen Fahrzeughardware (Sensoren für den Einparkvorgang). Dieser Artikel dient der Dokumentation der entwickelten Software und der für den Einparkvorgang benötigten Harwdare.

Weiterführende Artikel

Grundlagen

Auswahl der Sensoren

Die Sensoren wurden in Anlehnung an gängige Lösungen des Carolo Cups ausgewählt. Für den Einparkvorgang werden vier Infrarotsensoren (nachfolgend: IR), ein Gierratensensor und mehrere Hallsensoren zur Geschwindigkeitsermittlung eingesetzt. Eine Übersicht der Hardware des Fahrzeugs ist in dem Artikel Fahrzeughardware zu finden.

Infrarotsensoren:

Die Positionen der IR sind im Artikel Infrarotsensoren festgehalten. Die IR werden während des Einparkvorgangs zur Entfernungsmessung verwendet. Mit Hilfe der Messungen der seitlich montierten IR werden Parklücken erfasst und ausgemessen und der seitliche Abstand zu den am Straßenrand parkenden Fahrzeugen ermittelt. Die hinten am Fahrzeug montierten IR dienen zur Kollisionsvermeidung und der Positionierung innerhalb der Parklücke.

Gierratensensor:

Um geregelt an den parkenden Fahrzeugen vorbeifahren zu können und um erfolgreich ein eine Parklücke einparken zu können, wird die aktuelle Winkellage des Fahrzeugs benötigt. Zur Bestimmung dieser wird ein Gierratensensor eingesetzt.

Hallsensoren:

Die Geschwindigkeitsermittlung erfolgt durch die Auswertung der im Motor verbauten Hallsensoren. Die Streckenmessung erfolgt über die Ableitung der Geschwindigkeit. Die bereits zurückgelegte Strecke wird hauptsächlich für das Vermessen der Parklücken benötigt. Die weiteren Details der Hardware, sowie das physikalische Messprinzip sind in dem Artikel Hall-Sensor beschrieben.

Einbindung der AEP-Bibliothek in die Simulink Umgebung

Autoren: Martin Theine und Patrick Schumann
Stand: 12.02.2021

Die Umsetzung des Einparkvorgangs erfolgt in einer eigenen Bibliothek (bib_AutonomesEinparken.mdl) der Fahrzeugsoftware.

Die Einbindung des AEP Blocks (gelb umrandet) im Offline-Modell (Simulation) ist in der folgenen Abbildung dargestellt:

AEP-Block eingebunden im Offline-Modell

Die Einbindung des AEP Blocks (gelb umrandet) im Online-Modell (Carolo-Cup-Fahrzeug) ist in der folgenen Abbildung dargestellt:

AEP-Block eingebunden im Online-Modell

Schnittstellen zu anderen Softwaremodulen

Autoren: Martin Theine und Patrick Schumann
Stand: 12.02.2021


Bibliothek "bib_Fahrtmodus.mdl"

Der Zustandsautomat des Einparkalgorithmus gibt ausgangsseitig die Variablen ...

Parameter Beschreibung
Famo_Modi_Schalter_Lw_int 1 = Lenkwinkelvorgabe durch BSF-Querregelung
2 = Lenkwinkelvorgabe durch AEP
Famo_Modi_Schalter_Vx_int 1 = Geschwindigkeitsvorgabe durch BSF-Längsregelung
2 = Geschwindigkeitsvorgabe durch AEP


... auf den CCF-Bus. Diese beiden Werte werden vom "FAMO"-Block verwendet, um die Lenkwinkel- und Geschwindigkeitsvorgabe für BSF oder AEP zu konfigurieren.

Im Fall AEP, wird der Lenkwinkel zunächst über den "BSF"-Block vorgegeben (geregelt geradeaus fahren: Famo_Modi_Schalter_Lw_int = 1) bis eine Parklücke gefunden wurde. Daraufhin wird im Zustandsautomaten des Einparkalgorithmus auf die AEP-Vorgabe gewechselt (Famo_Modi_Schalter_Lw_int = 2), um die Kurven des Einparkvorgangs fahren zu können. Die Geschwindigkeitsvorgabe erfolgt im Fall AEP dauerhaft durch den Zustandsautomaten des Einparkalgorithmus (Famo_Modi_Schalter_Vx_int = 2).


Bibliothek "bib_Sensoren_Aktoren_offline.mdl"

Im Offline-Modell (Simulation) bekommt der Zustandsautomat des Einparkalgorithmus eingangsseitig simulierte Sensorsignale aus dem Block "SEN" (Sensoren) über den CCF-Bus:


Parameter Beschreibung
SenVx_sx_K_f64 berechnete gefahrene Strecke des simulierten Fahrzeugs aus dem Kinematikmodell
SenGier_psi_filt_K_f64 simulierter Gierwinkel des Fahrzeugs
SenAbs_xVR_K_f64 simulierter Abstandswert des vorderen rechten IR-Sensors
SenAbs_xHR_K_f64 simulierter Abstandswert des rechten hinteren IR-Sensors
SenAbs_yHR_K_f64 simulierter Abstandswert des rechten hinteren IR-Sensors
SenAbs_yHL_K_f64 simulierter Abstandswert des linken hinteren IR-Sensors


Ausgangsseitig wird der Solllenkwinkel (AEP_LwSoll_f64) und die Sollgeschwindigkeit (AEP_vx_K_soll_f64) auf den CCF-Bus gelegt. Durch o.g. Konfiguration mittels "FAMO"-Block wird initial die Lenkwinkelvorgabe aus dem Block "BSFQuer - Querfuehrung" an den Block "AKT" (Aktoren) weitergegeben (Lücke suchen). Beim Einparken wird die Lenkwinkelvorgabe des AEP-Blocks direkt an den Block "AKT" (Aktoren) weitergegeben. Die Geschwindigkeitsvorgabe erfolgt während AEP dauerhaft durch den "AEP"-Block via "FAMO" -> "BSFLaengs - Laengsfuehrung" an den Block "AKT" (Aktoren). Der Block "AKT" (Aktoren) gibt die Vorgaben für den Lenkwinkel und die Geschwindigkeit an das Kinematikmodell weiter.


Bibliothek "bib_Sensoren_Aktoren_online.mdl"

Im Online-Modell (reales Fahrzeug) bekommt der Zustandsautomat des Einparkalgorithmus eingangsseitig die realen Sensorsignale aus dem Block "SEN" (Sensoren) über den CCF-Bus:


Parameter Beschreibung
SenVx_sx_K_f64 gefahrene Strecke des Fahrzeugs
SenGier_psi_filt_K_f64 Gierwinkel des Fahrzeugs
SenAbs_xVR_K_f64 Abstandswert des vorderen rechten IR-Sensors
SenAbs_xHR_K_f64 Abstandswert des hinteren rechten IR-Sensors
SenAbs_yHR_K_f64 Abstandswert des rechten hinteren IR-Sensors
SenAbs_yHL_K_f64 Abstandswert des linken hinteren IR-Sensors


Position und Beschreibung der Infrarot Sensoren

Skizze der Sensorpositionen der Infrarotsensoren Beschreibung der Infrarot Sensoren

Ausgangsseitig wird der Solllenkwinkel (AEP_LwSoll_f64) und die Sollgeschwindigkeit (AEP_vx_K_soll_f64) auf den CCF-Bus gelegt. Durch o.g. Konfiguration mittels "FAMO"-Block wird initial die Lenkwinkelvorgabe aus dem Block "BSFQuer - Querfuehrung" an den Block "AKT" (Aktoren) weitergegeben (Lücke suchen). Beim Einparken wird die Lenkwinkelvorgabe des AEP-Blocks direkt an den Block "AKT" (Aktoren) weitergegeben. Die Geschwindigkeitsvorgabe erfolgt während AEP dauerhaft durch den "AEP"-Block via "FAMO" -> "BSFLaengs - Laengsfuehrung" an den Block "AKT" (Aktoren). Der Block "AKT" (Aktoren) gibt die Vorgabe für den Lenkwinkel an den Lenkservo des Fahrzeugs weiter und die Vorgabe der Geschwindigkeit an den Fahrtenregler weiter.

Auswahl des Einparkmodus

Um das Einparkmanöver zu starten, 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 stehen zu bleiben (Simulinkmodus = 2). Beim Online-Model muss beachtet werden, dass vor der Betätigung des AEP-Tasters, die Aktuatoren ausgeschaltet werden, damit die Kalibrierung des Gierratensensors gemacht wird. 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.

Offline-Modell

Autoren: Martin Theine und Patrick Schumann
Stand: 12.02.2021

Konfiguration in der "start.m"-Datei zum Starten der Einparksimulation:

Parameter Auswahl Beschreibung
"Schalter_offline" 0: Online Modell
1: Simulation/ Offline-Modell auswählen
2: PC Onlina Sensor Aktortest
"PAR_Modi_Schalter_Fahrbahn_int" 0: Rundkurs ohne Kreuzung, Startpunkt kurz vor erster Kurve
1: Rundkurs mit Kreuzung
2: Rundkurs mit Kreuzung, Start direkt vor S-Kurve
3: Rundkurs ohne Kreuzung mit Stopplinie
"Simulinkmodus" 1: BSF
2: AEP (Lücke suchen, vermessen und anschließend anhalten)
3: AEP (Lücke suchen, vermessen und einparken)
4: BSF incl. Objekt auf der Fahrbahn
"Lw_Vx_Manuell" 0: Automatisch
1: manuelle Vorgabe (Werte s. u. beim Fahrmanöver)
"PAR_Modi_Schalter_Luecke_int" 0: Positionierung vorgegeben (größte Lücke vorne), feste Hindernisbreite
1: Positionierung zufällig, feste Hindernisbreite
2: Positionierung und Hindernisbreite zufällig
3: keine passende Lücke
4: kein Hindernis
5: nur vorderes Hindernis und kleinstmögliche Parklücke (0.71 m)
6: kleinstmögliche Parklücke (0.71 m) zuerst
7: optimale Parklücke (0.9 m) zuerst
8: mittlere Parklücke (1.1 m) zuerst
9: größtmögliche Parklücke (1.5 m) zuerst
10: schmales Hindernis hinten links
11: schmales Hindernis hinten mittig
12: schmales Hindernis hinten rechts


Das Fahrzeug startet nach einer kurzen Verzögerung zur Kalibrierung des Gierratensensors seine Fahrt entlang der Parklücken. Während des gesamten Suchvorgangs ist die geregelte Geradeausfahrt aktiv. Um dies zu zeigen startet das Fahrzeug im aktuellen Stand der Simulation leicht schräg und findet dann wieder auf seine Spur zurück.

  • In den Fällen, in welchen Hindernisse in der Parkbucht stehen (0,1,2,6 bis 12), fährt das Fahrzeug, nachdem es eine Parklücke gefunden hat, an dieser vorbei bis die Hinterachse auf gleicher Höhe wie das Heck des vorderen Fahrzeugs der Parklücke ist. Das Fahrzeug parkt ein und positioniert sich in der Parklücke.
  • Falls keine passende Lücke in der Parkbucht existiert (Fall 3), fährt das Fahrzeug bis zum Ende der Parkbucht (mittels Streckenerfassung) und bleibt stehen.
  • Falls kein Hindernis in der Parkbucht steht (Fall 4), fährt das Fahrzeug so lange an der Parkbucht vorbei, bis die gefahrene Strecke ausreicht, um während der Linkskurve des Einparkmanövers parallel zur Fahrbahn zu gelangen. In diesem Fall wird direkt mit der Rechtskurve des Einparkvorgangs begonnen, um ohne Orientierung an einem Hindernis (IR-Sensoren), nur mit Hilfe des Gierratensensors einzuparken.
  • Falls die erste Parklücke in der Parkbucht ausreicht, diese jedoch nur durch ein vorderes Hindernis begrenzt wird (Fall 5), so können die hinteren IR-Sensoren nicht genutzt werden, um einzuparken. Daher wird mittels festgelegter Streckenbegrenzung verhindert, dass das Fahrzeug an den "Boardstein" fährt.

Simulation starten 

1 : Parameter Konfigurieren (s.o.) "start.m"-Datei ausführen (Run)
2 : Offline-Modell (Simulink) wird geöffnet
3 : In Simulink auf "Run" klicken

Letzter lauffähiger Stand der Offline-Simulation des Einparkvorgangs (10.07.2020):

SVN -> SDE Praktikum -> Software -> CaroloCupFahrzeug -> Update to Revision: 5502

Probleme in aktueller Head-Revision:

  • parkende Hindernisse werden nicht mehr dargestellt (ab Revision 5539)
  • die Querregelung wurde vom "Einspurmodell" auf das "Kinematikmodell" umgestellt und der Regler neu parametriert, wodurch die geregelte Geradeausfahrt nur noch mangelhaft funktioniert (ab Revision 5516)

Bearbeiten der Parklücken:

Die Parklücken und Objekte werden in der "param_SEN_offline.m" im Ordner "parameter" initialisiert. Diese werden anschließend in einem Vektor in "PAR_SenAbs_ObjektListe_f64" gespeichert und in der Darstellungsfunktion "funktion_simulink_simultan_draufsicht" aufgerufen. Die einzelnen Parklücken werden in einer "switch case"-Schleife erstellt, sodass (in diesem Fall) 9 unterschliedlich lange Parklücken erstellt werden können. Dabei kann eine Lücke mehrfach verwendet werden, es wird also ein Vektor mit den gleichen Werten gefüllt. Die Objekte werden analog dazu erstellt. Der daraus resultierende Seitenstreifen, in den das Fahrzeug einparken soll, wird mit einer Zählschleife im Vektor "x" in der Reihenfolge Objekt, dann Parklücke zusammengefasst.

Online-Modell

Autoren: Martin Theine und Patrick Schumann
Stand: 12.02.2021

Konfiguration in der "start.m"-Datei zum Starten der Einparksimulation:

  • "Schalter_offline" = 0 (Modell für die dSPACE-Karte auswählen)
  • "Simulinkmodus" = 2 -> Lücke finden und stehen bleiben ODER "Simulinkmodus" = 3 Lücke suchen und einparken
  • "Lw_Vx_Manuell" = 0 -> automatische Vorgabe des Solllenkwinkels und der Sollgeschwindigkeit
  • "PAR_Schleichmodus" = 0 -> Geschwindigkeitsbegrenzung bei Fernbedienungseingriff auf 0.3 m/s (Wettkampfmodus) ODER 1 -> Geschwindigkeitsbegrenzung bei Fernbedienungseingriff auf 1 m/s (Testmodus)
  • "PAR_FernB_Schalter_AUS_int" = 0 -> Fernbedienungseingriff aktivieren

Modell auf das Fahrzeug laden

  • nach Konfiguration (s.o.) "start.m"-Datei ausführen (Run)
  • Online-Modell (Simulink) wird geöffnet
  • In Simulink auf "Build & Deploy" klicken
  • Status des Builds wird im Command Window von MATLAB angezeigt
  • Nach Ausrichtung des Fahrzeugs die Spannungsversorgung des Antriebs einschalten
  • AEP-Starttaster betätigen

Der aktuelle Einparkalgorithmus konnte bislang noch nicht vollständig auf dem Fahrzeug getestet werden (Stand 12.02.2021).

Während der Fehleranalyse im Wintersemester 20/21 konnte die Hardware für die Hall-Sensorik vollständig durch das Team AEP - Einparkalgorithmus überprüft und repariert werden (Link Fehlerprotokoll). Das Fahrzeug ist aktuell trotzdem nicht autonom fahrfähig, da die gefahrene Strecke und Ist-Geschwindigkeit noch nicht korrekt erfasst werden (Link Video). Somit kann keine korrekte Längsregelung (Geschwindigkeitsregelung) stattfinden. Der Einparkalgorithmus ist sowohl von einer funktionierenden Regelung auf die vorgegebenen Sollgeschwindigkeiten als auch von einer funktionierenden Streckenerfassung abhängig.

Mögliche Fehlerquellen:

  • Vermutung 1: ab einer gewissen Motordrehzahl werden zu viele Interrupts durch die Hall-Kombi-Logik ausgelöst (Task Overrun) -> nicht alle Interrupts werden verwertet -> falsche Berechnung der Geschwindigkeit und Strecke
    (ignorierte Fehlermeldung: siehe AEP - Einparksensorik -> 7.2 "Behebung des Absturzes im Online-Modell")
  • Vermutung 2: Die Getriebeübersetzung des Fahrzeugs wurde in der Vergangenheit verändert. Unter Umständen wird die Berechnung dadurch verfälscht, dass das Übersetzungsverhältnis in Software nicht darauf angepasst wurde
    (Messfehler scheint linear zu sein).

Der autonomen Fahrfunktion steht vermutlich nur noch die o.g. Problematik im Wege. Durch eine Hardwaresimulation mit LtSpice konnte herausgestellt werden, dass die Interrupt-Fehler vermutlich mit der Kondensatorspannung des Kondensators C2 (Schaltplan) des Tiefpassfilters der Hall-Kombi-Logik auf der Adapterplatine zur dSPACE-Karte entstehen. Die Ergebnisse dieser Simulation lassen auf eine falsche Dimensionierung des beschriebenen Bauteils bzw. des Tiefpassfilters schließen. Diesen Sachverhalt gilt es im Sommersemester 2021 bzw. Wintersemester 2021/22 genauer zu untersuchen.

-> Links einfügen

Zusätzlich kann festgehalten werden, dass die Steuerung des Antriebs mittels Fernbedienung oder manueller Vorgabe in Control Desk einwandfrei funktioniert (siehe Analyse und Fehlersuche WS20/21). Der Fahrtenregler, welcher die Eingabe per Fernbedienung oder Control Desk in eine Motordrehzahl umsetzt, greift auf die Hall-Sensorik zurück. Würde diese fehlerhaft sein (Sensor defekt/falsche Phasenzuordnung), so wäre keine kontrollierte Fahrt auf eben genannte Weise möglich. Der dSPACE-Karte stehen die selben Hall-Signale (zur Geschwindigkeitsermittlung/Streckenerfassung/Fahrtrichtungserkennung) zur Verfügung. Diese Beobachtung stützt die Annahme, dass die aktuell noch vorhandene Antriebsproblematik lediglich auf die Interrupt-Fehler bzw. eine fehlerhafte Geschwindigkeitsberechnung in der Software zurückzuführen ist (siehe Online-Modell: Block "SEN - Geschwindigkeit").

Weiterführende Artikel

→ zurück zum Hauptartikel: Praktikum SDE
→ zum Artikel Einparkalgorithmus: AEP - Einparkalgorithmus
→ zum Artikel Einparksensorik: AEP - Einparksensorik

→ zurück zum Hauptartikel: Praktikum SDE

Abgerufen von „https://wiki.hshl.de/wiki/index.php?title=AEP_-_Autonomes_Einparken&oldid=114939“