AEP - Autonomes Einparken: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
 
(375 dazwischenliegende Versionen von 15 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:


=='''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.
Dieser Artikel dient der Dokumentation der entwickelten Software und der für den Einparkvorgang benötigten Harwdare.


'''Weiterführende Artikel
*[[AEP - Einparkalgorithmus| AEP - Einparkalgorithmus]]
*[[AEP - Einparksensorik| AEP - Einparksensorik]]


# 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.
== Grundlagen ==
# Das Einparkmanöver muss durch einen Taster am Fahrzeug gestartet werden können
# Das Fahrzeug fährt an den rechts stehenden Hindernissen, auf der Suche nach einer ausreichend großen Parklücke, vorbei.
# Sobald die erstmögliche Parklücke gefunden ist, muss das Einparken mit dem rechten Blinker signalisiert werden.
# Nach Beendigung des Manövers, muss das Fahrzeug zwischen zwei Hindernissen mit einer maximalen Winkelabweichung von 10° zum Stehen kommen.
 
 
Während des Einparkvorgangs sind eventuelle Kollisionen mit den Hindernissen erlaubt und es ist kein Zeitfenster vorgegeben (so schnell wie möglich).
 
Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:23, 3. Feb. 2014 (CET)


=== Auswahl der Sensoren ===
=== Auswahl der Sensoren ===
Die Sensoren wurden in Anlehnung an die Literaturrecherche der Lösungen anderer Carolo Cup Teilnehmer bereits vom Vorjahr ausgewählt. Für den Einparkvorgang werden zwei Infrarotsensoren (nachfolgend: IR) vom Typ [[Fahrzeughardware#Infrarot Sensor|Sharp GP2D120]] 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.


Einer davon 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.
'''Infrarotsensoren:'''


Die Positionen der IR sind im Artikel [[Infrarotsensoren|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.


Um die Winkellage des Fahrzeugs vermessen zu können, wird ein [[Fahrzeughardware#Gyro Sensor|Gyro Sensor]] verwendet. Die Änderung von Rechts- auf Linkseinschlag während des Einparkens wird damit 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, wenn der Winkel des Gyroskops um 0 rad (0°) liegt.
'''Gierratensensor:'''
Die zurückgelegte Strecke wird mit einem [[Fahrzeughardware#Hall Sensor|Hallsensor]] ermittelt. Diese Streckenmessung dient dem Zweck, die Parklücke zu vermessen und bestimmte Kurzstrecken, wie z.B. das Weiterfahren nach Lückenfindung, definiert zurückzulegen.


Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:23, 3. Feb. 2014 (CET)
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.  


== '''Der Einparkalgorithmus''' ==
'''Hallsensoren:'''


=== Auswahl der geeigneten Geschwindigkeit ===
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 ===


[[Datei:InfrarotMesszeit.PNG|500px|Messzeiten des Infrarotsensors]]
'''Autoren:''' [[Benutzer:Martin Theine|Martin Theine]] und [[Benutzer:Patrick Schumann|Patrick Schumann]]
<br />
'''Stand:''' 12.02.2021
<br />


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


<math>t= 38,3\,ms + 9,6\,ms + 5\,ms = 52,9\,ms</math>.
[[Datei:CCF offline AEP markierung.png|700px|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:


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
[[Datei:Online-Modell.png|700px|AEP-Block eingebunden im Online-Modell]]


=== Schnittstellen zu anderen Softwaremodulen ===
'''Autoren:''' [[Benutzer:Martin Theine|Martin Theine]] und [[Benutzer:Patrick Schumann|Patrick Schumann]]
<br />
'''Stand:''' 12.02.2021
<br />


<math>t=3\cdot 52,9\,ms = 158,7\,ms.</math>


''' Bibliothek "bib_Fahrtmodus.mdl" '''


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
Der Zustandsautomat des Einparkalgorithmus gibt ausgangsseitig die Variablen ...


{| 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
|}


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




Wird die größte verfügbare Parklücke von 0,7m für das Einparken verwendet, so findet das Fahrzeug diese Parklücke bei oben genannter Geschwindigkeit in 1,1s (mit der Annahme, es wird vor dieser Lücke gestartet). Die Geschwindigkeit beim Einparken wurde vorerst mit [[Fahrzeugsoftware#param_AEP.m|-0,1m/s]] angenommen.
... auf den CCF-Bus. Diese beiden Werte werden vom "FAMO"-Block verwendet, um die Lenkwinkel- und Geschwindigkeitsvorgabe für BSF oder AEP zu konfigurieren.


Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:24, 3. Feb. 2014 (CET)
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).


=== Berechnung nötiger Größen ===


Das Fahrzeug besitzt einen maximalen Lenkeinschlag in eine Richtung von [[Fahrzeugsoftware#param_CAR.m|alpha = 25°]]. Kombiniert mit dem Radstand [[Fahrzeugsoftware#param_CAR.m|L = 0,265m]] ergibt dies einen Wendekreisradius um die Mitte der Hinterachse von
''' Bibliothek "bib_Sensoren_Aktoren_offline.mdl" '''


<math>r= \frac{L}{tan(\alpha)} = \frac{0,265\,m}{tan(25^\circ)} = 0,5683\,m.</math>
Im Offline-Modell (Simulation) bekommt der Zustandsautomat des Einparkalgorithmus eingangsseitig simulierte Sensorsignale aus dem Block "SEN" (Sensoren) über den CCF-Bus:


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 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.
{| 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
|-
|}




[[Datei:Berechnung der Parklückengröße.png|700px|Skizze zur Berechnung der notwendigen Parklücke]]
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.  




Notwendige Größen für den Vorgang des Einparkens sind:
''' Bibliothek "bib_Sensoren_Aktoren_online.mdl" '''


;Die allgemeinen Maße des Fahrzeugs
Im Online-Modell (reales Fahrzeug) bekommt der Zustandsautomat des Einparkalgorithmus eingangsseitig die realen Sensorsignale aus dem Block "SEN" (Sensoren) über den CCF-Bus:
: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 = 0,568m
;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:


{| 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
|-
|}


<math>g1 = \sqrt[]{r^2-(r-\frac{w}{2}-\frac{p}{2})^2}</math>


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


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:
[[Bild:Grafik IR Sensoren.svg|300px|mini|Skizze der Sensorpositionen der Infrarotsensoren [https://wiki.hshl.de/wiki/index.php/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.


<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>
=== Auswahl des Einparkmodus ===
 
 
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 [[Fahrzeughardware#Infrarot Sensor|GP2D120]]), setzt einen angenommenen Mindestabstand zur Berechnung vorraus. In unserem Fall wird ein Abstand p = 8cm vorausgesetzt. Diese Annahme führt zu einer Mindestgröße der Parklücke von g = 0,69m, 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 <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.
Um das Einparkmanöver zu starten, muss zu Beginn das Simulink-Modell [[Fahrzeugsoftware#Hauptdatei start.m|start.m Datei]] in MATLAB geöffnet werden.
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:
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.


<math>k = \sqrt[]{(r-\frac{w}{2})^2-(r-\frac{w}{2}-p)^2}</math>
Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:24, 3. Feb. 2014 (CET)
=== 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 [[Fahrzeugsoftware#bib_AutonomesEinparken.mdl|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 [[Fahrzeugsoftware#bib_AutonomesEinparken.mdl|Link]] wieder.
[[Datei:CCF offline AEP markierung.png|700px|AEP-Block Positionierung im Simulinkmodell]]
Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:24, 3. Feb. 2014 (CET)
=== Auswahl des Einparkmodus ===
Zu Beginn der Arbeit mit dem Simulink-Modell muss die [[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 einfach stehen zu bleiben (Simulinkmodus = 2).
Für den Einparkvorgang ist es dringend notwendig, die Geschwindigkeit und den Solllenkwinkel automatische ermitteln zu lassen!
Alle weiteren Einstellungen sind optional und werden in diesem [[Fahrzeugsoftware#Hauptdatei start.m|Link]] erläutert.
Alle weiteren Einstellungen sind optional und werden in diesem [[Fahrzeugsoftware#Hauptdatei start.m|Link]] erläutert.


Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 18:24, 3. Feb. 2014 (CET)
= Offline-Modell =
 
'''Autoren:''' [[Benutzer:Martin Theine|Martin Theine]] und [[Benutzer:Patrick Schumann|Patrick Schumann]]
== '''Übertragung des Algorithmus auf das reale Fahrzeug''' ==
<br />
 
'''Stand:''' 12.02.2021
Der aktuelle Stand ist, dass der Einparkvorgang an sich in der Simulation insofern funktioniert, dass das Fahrzeug am Ende zwischen zwei Hindernissen zum Stehen kommt. Allerdings stimmt anscheinend etwas an dem Kinematikmodell nicht, sodass das Einlenken und Rückwärtsfahren nicht dem Fahrstil eines richtigen Autos entspricht.
<br />  
 
Der Algorithmus wurde desweiteren auf das Fahrzeug übertragen, konnte aber nicht getestet werden, da die Längs- und Querregelung die vorgegenbene Geschwindigkeit des Algorithmus nicht in reale Geschwindigkeiten am Fahrzeug umsetzt.
Mit dem [[Fahrzeughardware#Taster|Tastendruck des roten Taster]] ist es aber möglich, den Einparkvorgang zu starten, was daran zu erkennen ist, dass die Sollgeschwindigkeit übergeben wird (in [[Fahrzeugsoftware#Sensorinbetriebnahme|Controldesk]] überwacht), sobald der Taster gedrückt und der [[Fahrzeugsoftware#bib_Signalaufbereitung|Gierratensensor]] kalibriert ist.
 
Sollte das Problem in den nächsten Semestern gelöst werden, muss noch auf die Werte des Gyrosensors geachtet werden. Den Rückgabewerten nach zu urteilen kann es aufgrund schnellem Anstieg ohne Einlenken zu Problemen führen.
 
Autor: [[Benutzer:Sascha Dienwiebel|Sascha Dienwiebel]] ([[Benutzer Diskussion:Sascha Dienwiebel|Diskussion]]) 23:43, 7. Feb. 2014 (CET)
--[[Benutzer:Mirekgoebel|Prof. Dr. Mirek Göbel]] ([[Benutzer Diskussion:Mirekgoebel|Diskussion]]) 13:44, 8. Aug. 2014 (CEST)
 
== '''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
 
[[Datei:Lastenheft AEP 01.PNG]]
 
--[[Benutzer:Ulrich Schneider|Ulrich Schneider]] ([[Benutzer Diskussion:Ulrich Schneider|Diskussion]]) 20:28, 30. Jul. 2014 (CEST)
Ich verstehe Ihre Pflichtenhefteinträge nicht. Es gibt weder Meilenstein 0 noch 3.
 
=== Projektplan ===
 
[[Bild:Projektplan AEP 02.PNG |1000px ]]
 
[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:Zoom Draufsicht AEP 03.PNG|700px]]
 
[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:Plots offline AEP 04.PNG |700px ]]
 
[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 [http://193.175.248.171/wiki/index.php/Datei:Kollisionskonzept_01.pdf] 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[http://193.175.248.52/usvn/svn/MTR_SDE_Praktikum/trunk/Workshops/08%20-%20Einparken%20II%20-%20Schneider/Aufgabe/SDE_P1_WS_08.pdf] ) 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 [http://193.175.248.171/wiki/index.php/AEP_-_Autonomes_Einparken#Projektplan]
 
3.6    Siehe offene Punkte [[http://193.175.248.171/wiki/index.php/Datei:Offene_Punkte_AEP_02.pdf]] 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
'''Konfiguration in der "start.m"-Datei zum Starten der Einparksimulation:'''


4.3 AEP Status: Einfügen einer Zustandsvariable In welchem Zustand des State-Flow Diagramm befindet er sich?
{| 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
|-
|
|-


4.4 Debug -> Was geht schief?
|}




''Ergebnisse''
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.


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 [http://193.175.248.171/wiki/index.php/AEP_-_Autonomes_Einparken#Projekt-St.C3.B6rungen]
*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.


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.
*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.


[[Bild:AEP Controldesk 06.JPG |700px]]
*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.


[Bild 5]
*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.


4.4   
'''Simulation starten'''


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


Soll-Lenkwinkel wird nicht richtig in Ist-Lenkwinkel umgewandelt.
'''Letzter lauffähiger Stand der Offline-Simulation des Einparkvorgangs (10.07.2020):'''


Sollgeschwindigkeit wird nicht richtig in Ist-Geschwindigkeit umgewandelt.
SVN -> SDE Praktikum -> Software -> CaroloCupFahrzeug -> Update to '''Revision: 5502'''


Gierrate wird nicht korrekt bestimmt.
Probleme in aktueller Head-Revision:


Entsprechende Folgefehler:
*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)


Die gefahrene Strecke, wird entsprechend der falschen IST-Geschwindigkeit  berechnet.
'''Bearbeiten der Parklücken:'''


Parklückengröße wird durch die falsche Streckenmessung  falsch berechnet.
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.


Die „Parallel“ End-Parkposition wird durch die falschen Gierraten Werte falsch berechnet.
= Online-Modell =
'''Autoren:''' [[Benutzer:Martin Theine|Martin Theine]] und [[Benutzer:Patrick Schumann|Patrick Schumann]]
<br />
'''Stand:''' 12.02.2021
<br />


'''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'''


Autoren : [[Benutzer:Martin Berysztak|Martin Berysztak]] [[Benutzer:Adem Hadziric|Adem Hadziric]] ([[Benutzer Diskussion:Martin Berysztak|Diskussion]]) 21:00, 11. Jul. 2014 (CET)
* 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


=== Projekt-Störungen  ===
'''Der aktuelle Einparkalgorithmus konnte bislang noch nicht vollständig auf dem Fahrzeug getestet werden (Stand 12.02.2021).'''


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.
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.


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.
'''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<br /> (ignorierte Fehlermeldung: siehe [[AEP - Einparksensorik]] -> 7.2 "Behebung des Absturzes im Online-Modell")


Autoren : [[Benutzer:Martin Berysztak|Martin Berysztak]] [[Benutzer:Adem Hadziric|Adem Hadziric]] ([[Benutzer Diskussion:Martin Berysztak|Diskussion]]) 21:00, 11. Jul. 2014 (CET)
* 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).


=== Ausblick ===
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.'''


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.
-> 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").'''


Autoren : [[Benutzer:Martin Berysztak|Martin Berysztak]] [[Benutzer:Adem Hadziric|Adem Hadziric]] ([[Benutzer Diskussion:Martin Berysztak|Diskussion]]) 21:00, 11. Jul. 2014 (CET)
= Weiterführende Artikel =


→ 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“