AEP: Einparken: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
 
(52 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 4: Zeile 4:
=Einleitung=
=Einleitung=
In diesem Kapitel wird der Ist-Zustand des Fahrzeugs zu Beginn des Wintersemesters 23/24 ermittelt. Des Weiteren werden alle Änderungen beschrieben, die zu einem lauffähigen Einparkalgorithmus führen.
In diesem Kapitel wird der Ist-Zustand des Fahrzeugs zu Beginn des Wintersemesters 23/24 ermittelt. Des Weiteren werden alle Änderungen beschrieben, die zu einem lauffähigen Einparkalgorithmus führen.
=Funktionsweise des AEP=
Die Funktionsweise ist sowohl in CCF_Online als auch im CCF_Offline identisch. In der Datei "start.m" können zwei Varianten ausgewählt werden. Zum einen wird lediglich die Parklücke gesucht und das Fahrzeug wird bei erfolgreicher Lokalisierung der Parklücke gestoppt. Die andere Variante hingegen parkt das Fahrzeug nach Auffinden einer Parklücke eigenständig ein.
Das Fahrzeug durchläuft einen Stateflow, der mehrere Zustände enthält und durch Bedingungen gesteuert wird. Diese Bedingungen werden mithilfe von Sensorwerten und Berechnungen erfüllt, um den Ablauf zu steuern.<br>
'''Für eine genauen Einblick in die Funktionsweise und Zustände des Simulink-Stateflows steht der Artikel [[AEP - Einparkalgorithmus| AEP - Einparkalgorithmus]] zur Verfügung.
'''
= Projektplanung =
Hier werden sämtliche Sprint Ordner verlinkt, in denen die A3 Blätter und andere relevante Daten enthalten:
*[https://svn.hshl.de/svn/MTR%20SDE%20Praktikum/trunk/%20Semesterordner/WS2023/Sprint%201/AEP%20Einparken/ '''Sprint 1''']
*[https://svn.hshl.de/svn/MTR%20SDE%20Praktikum/trunk/%20Semesterordner/WS2023/Sprint%202/AEP%20Einparken/ '''Sprint 2''']
*[https://svn.hshl.de/svn/MTR%20SDE%20Praktikum/trunk/%20Semesterordner/WS2023/Sprint%203/ '''Sprint 3''']


= Inbetriebnahme =
= Inbetriebnahme =
* [[Sensor-/Aktortest AEP: Einparken]]
* [[Sensor-/Aktortest AEP: Einparken]]
= Ziel-Zustand =
Die AEP ist wieder in einen lauffähigen Zustand versetzt. Sowohl Simulation als auch das online-Modell sind funktionsfähig.
Der angestrebte Soll-Zustand muss klar spezifiert werden. Ausgehend vom angestrebten Ziel führt das Rückwärts-Denken in der Regel zu besseren Lösungen als die Suche ohne klares Ziel. Bei der Bestimmung des Ziel-Zustands muss auch geklärt werden, wie sich feststellen lässt, dass der Ziel-Zustand erreicht ist. Wie messen wir, ob die Problemlösungen erfolgreich sind? Welche Basis oder Kennzahl dient als Vergleichsmaßstab?
== Ziel-Zustand - Sprint1 ==
In dem ersten Sprint sollen die Parameter überprüft und neu berechnet werden. Des Weiteren soll das Problem genau festgelegt werden, weshalb das AEP nicht funktionsfähig ist. Genaue Maßnahmen sind in dem A3 Lösungsblatt zu finden.
== Ziel-Zustand - Sprint2 ==
Das Ziel des Sprintes und das messbare Kriterium, welches das Ziel definiert, ist das Autonome Einparken des Fahrzeugs auf
der Testtrecke in einer großen Parklücke. Ergänzend dazu wird der Wiki-Artikel weitergeführt, Versuche und Debugging der Software für autonome Einparken durchgeführt.
== Ziel-Zustand - Sprint3 ==
Das Ziel des dritten Sprints besteht darin, das autonome Einparken auf der Teststrecke zu realisieren und der Stateflow korrekt arbeitet. Als Nachweis sollen zwei Videos des Einparkvorgangs dienen, welches im Ordner Sprint 3 des AEP abgelegt wird.<br><br>
Zu diesem Zweck werden zwei Ziele festgelegt, da das AEP zwei Durchführungsversionen bereitstellt. Diese können im Startprogramm ausgewählt werden. Die erste Version führt ein vollständiges seitliches Einparken durch, während die zweite Version die Parklücke sucht und bei Auffinden einer geeigneten Parklücke anhält.


= AEP - Parameter=
= AEP - Parameter=
Zeile 29: Zeile 60:
| Niklas Reeker
| Niklas Reeker
| 17.10.2023
| 17.10.2023
|  
| - 2 m
|  
| 2 m
| <span style="color:red;"> n.i.O.
| <span style="color:green;"> i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Strecke ist negativ
|-
|-
| 2
| 2
Zeile 51: Zeile 82:
| Niklas Reeker
| Niklas Reeker
| 17.10.2023
| 17.10.2023
|  
| / cm
|  
| 15 cm 
| <span style="color:red;"> n.i.O.
| <span style="color:green;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Lookup-table Parameter müssen aktualisiert werden (siehe [[AF:_Abstandssensorik_(SenAbs)]])
|-
|-
| 4
| 4
Zeile 62: Zeile 93:
| Niklas Reeker
| Niklas Reeker
| 17.10.2023
| 17.10.2023
|  
| / cm
|  
| 15 cm 
| <span style="color:red;"> n.i.O.
| <span style="color:green;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Lookup-table Parameter müssen aktualisiert werden (siehe [[AF:_Abstandssensorik_(SenAbs)]])
|-
|-
| 5
| 5
Zeile 73: Zeile 104:
| Niklas Reeker
| Niklas Reeker
| 17.10.2023
| 17.10.2023
|  
| / cm
|  
| 15 cm
| <span style="color:red;"> n.i.O.
| <span style="color:green;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Lookup-table Parameter müssen aktualisiert werden (siehe [[AF:_Abstandssensorik_(SenAbs)]])
|-
|-
| 6
| 6
Zeile 84: Zeile 115:
| Niklas Reeker
| Niklas Reeker
| 17.10.2023
| 17.10.2023
|  
| / cm
|  
| 15 cm
| <span style="color:red;"> n.i.O.
| <span style="color:green;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Lookup-table Parameter müssen aktualisiert werden (siehe [[AF:_Abstandssensorik_(SenAbs)]])
|-
|-
|}
|}
Zeile 111: Zeile 142:
|-
|-
|}
|}
Für ein einheitlichen Verständnis für die Abmessung des Fahrzeugs, wird die folgende Abbildung aufgeführt. Darauf wird das Fahrzeug abgebildet, sowie relevante Parameter für die pram.CAR.m Datei eingezeichnet.
[[Datei:Abbildung Fahrzeug Parameter Datei.png|650px|]]<br>
{| class="wikitable"
{| class="wikitable"
! style="font-weight: bold;" | Testfall ID
! style="font-weight: bold;" | Testfall ID
Zeile 182: Zeile 215:
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Parameter muss am Fahrzeug getestet werden
|  
|  
|-
|-
Zeile 218: Zeile 251:
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
| Entspricht -23°
|  
|  
| <span style="color:green;"> i.O.
|-
|-
| 9
| 9
Zeile 242: Zeile 275:
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
| Entspricht 23°
|  
|  
| <span style="color:green;"> i.O.
|-
|-
| 11
| 11
Zeile 279: Zeile 312:
| 17.10.2023
| 17.10.2023
| Ist entspricht 32,88° und soll entspricht 39,86°, Fahrzeugbreite ist von 0,2m auf 0,29m gestiegen durch Bumper
| Ist entspricht 32,88° und soll entspricht 39,86°, Fahrzeugbreite ist von 0,2m auf 0,29m gestiegen durch Bumper
|  
| <span style="color:green;"> i.O.
|-
|-
| 14
| 14
Zeile 291: Zeile 324:
| 17.10.2023
| 17.10.2023
| Da sich Fahrzeuglänge durch hinzufügen von Bumper verlängert hat.
| Da sich Fahrzeuglänge durch hinzufügen von Bumper verlängert hat.
|  
| <span style="color:green;"> i.O.
|-
|-
| 15
| 15
Zeile 298: Zeile 331:
| 17.10.2023
| 17.10.2023
| 0,03m
| 0,03m
|  
| undefiniert
| <span style="color:red;"> n.i.O.
| <span style="color:red;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Parameter muss am Fahrzeug getestet werden
|  
| <span style="color:green;"> i.O.
|-
|-
| 16
| 16
Zeile 310: Zeile 343:
| 17.10.2023
| 17.10.2023
| 0,3%
| 0,3%
|  
| undefiniert
| <span style="color:red;"> n.i.O.
| <span style="color:red;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Parameter muss am Fahrzeug getestet werden
|  
| <span style="color:green;"> i.O.
|-
|-
| 17
| 17
Zeile 322: Zeile 355:
| 17.10.2023
| 17.10.2023
| 0,2075m
| 0,2075m
|  
| undefiniert
| <span style="color:red;"> n.i.O.
| <span style="color:red;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Parameter muss am Fahrzeug getestet werden
|  
| <span style="color:green;"> i.O.
|-
|-
| 18
| 18
Zeile 334: Zeile 367:
| 17.10.2023
| 17.10.2023
| 0,95m
| 0,95m
|  
| undefiniert
| <span style="color:red;"> n.i.O.
| <span style="color:red;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Parameter muss am Fahrzeug getestet werden
|  
| <span style="color:green;"> i.O.
|-
|-
| 19
| 19
Zeile 346: Zeile 379:
| 17.10.2023
| 17.10.2023
| 0,225m
| 0,225m
|  
| undefiniert
| <span style="color:red;"> n.i.O.
| <span style="color:red;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
|  
| Parameter muss am Fahrzeug getestet werden
|  
| <span style="color:green;"> i.O.
|-
|-
| 20
| 20
Zeile 358: Zeile 391:
| 17.10.2023
| 17.10.2023
| 0,0255rad
| 0,0255rad
|  
| -0,0087rad
| <span style="color:red;"> n.i.O.
| <span style="color:red;"> n.i.O.
| Oliver Scholze
| Oliver Scholze
| 17.10.2023
| 17.10.2023
| Entspricht -0,5° parallel zur Fahrbahn(in SW notiert)
| Entspricht -0,5° parallel zur Fahrbahn(in SW notiert)
|  
| <span style="color:green;"> i.O.
|-
|-
| 21
| 21
Zeile 375: Zeile 408:
| 17.10.2023
| 17.10.2023
|  
|  
|  
| <span style="color:green;"> i.O.
|-
|-
| 22
| 22
Zeile 387: Zeile 420:
| 17.10.2023
| 17.10.2023
|  
|  
|  
| <span style="color:green;"> i.O.
|-
|-
| 23
| 23
Zeile 399: Zeile 432:
| 17.10.2023
| 17.10.2023
| Entspricht 4,9°
| Entspricht 4,9°
|  
| <span style="color:green;"> i.O.
|-
|-
|}
|}
= Endzustand des AEP vom Carolocup-Fahrzeugs =
Dieses Kapitel widmet sich dem Endzustand sowohl des Offline- als auch des Online-Modells im Rahmen des SDE 2-Praktikums. Es bietet eine detaillierte Darstellung der aktuellen Funktionalitäten sowie kritische Betrachtungen, um Schwachstellen und Bereiche für Verbesserungen zu identifizieren.<br>
Darüber hinaus werden in diesem Abschnitt nicht nur die bestehenden Erfolge erörtert, sondern auch aufgezeigt, an welchen Stellen Optimierungen und Weiterentwicklungen notwendig sind. Das Ziel besteht darin, dass zukünftige Semester auf diesen Erkenntnissen aufbauen können, um ihre Ziele effizienter zu erreichen.
== Offline-Modell ==
Das CCF_Offline ermöglichte das automatische Einparken des Fahrzeugs in Simulation ab dem Sprint 2 Termin. Die Integration der Schaltereinheit zur Unterstützung neuer Fahrzeugerweiterungen führte jedoch zu verschiedenen Problemen und Fehlermeldungen im Simulink-Modell. Eine detaillierte Analyse ist erforderlich, um die Simulation erfolgreich zum Laufen zu bringen.<br>
Die Modifikationen wurden am 09.01.2024 vorgenommen, wobei die Signalverarbeitung der Gierrate überarbeitet und um die Fahrzeugerweiterungen eingebunden wurde. Seitdem ist die Funktionstüchtigkeit beeinträchtigt und das System arbeitet nicht wie beabsichtigt.<br>
Es ist wichtig zu beachten, dass die Simulation zwar die Fahrzeugdaten simuliert, jedoch deutliche Abweichungen bei den Sensorwerten auftreten können, insbesondere bei der Gierrate. Dies hat die Weiterentwicklung des CCF_Online deutlich verzögert.
== Online-Modell ==
Das erste Fahrzeug des Carolocup erkennt erfolgreich die Parklücke. Die in der Datei "start.m" auswählbare Variante des AEP, bei der das Fahrzeug nach dem Finden der Parklücke angehalten werden soll, funktioniert wie beabsichtigt. Wie in den Entwicklungspotenzialen beschrieben, sollte jedoch die gesetzte Geschwindigkeit im Zustand 4 (Endzustand des Stateflows) überarbeitet werden, da das Fahrzeug trotz des durch den Warnblinker signalisierten Zustands immer noch langsam weiterfährt (Geschwindigkeit ist auf 0m/s gesetzt).<br><br>
Die zweite Variante, bei der das Fahrzeug nach dem Finden der Parklücke einparken soll, ist ebenfalls funktionsunfähig. Die Zustände im AEP werden erfolgreich umgesetzt. Um Probleme wie das Nicht-Losfahren des Fahrzeugs zu vermeiden, wurden zunächst die Geschwindigkeiten beim Einparken erhöht.<br>
Der Einparkvorgang funktioniert bis zum Zustand 3.6, wie in den weiterführenden Artikeln beschrieben, einwandfrei. Jedoch erfolgt kein Linkseinschlag, wodurch das Fahrzeug nicht korrekt einparken kann. Dieses Problem wird ebenfalls in den Entwicklungspotenzialen detailliert erläutert. Wenn das Fahrzeug jedoch manuell gedreht wird, werden die Zustände wie erwartet ausgeführt, und der Endzustand, bei dem das Fahrzeug perfekt in der Parklücke steht, wird erreicht.
== Weiterentwicklungspotenziale des AEP auf einen Blick ==
Dieses Unterkapitel behandelt sämtliche identifizierte Probleme. Ziel ist es, eine umfassende Übersicht über die aufgetretenen Schwierigkeiten zu bieten und mögliche Lösungsansätze oder Handlungsempfehlungen zu skizzieren. <br><br>
'''Probleme:''' <br><br>
* Der '''Lenkwinkel''' ''Akt_LwSoll_f64'', der in ''AktRTiPwm_Lw_f64'' für die dSpace-Karte umgewandelt wird, wird nicht korrekt an das Fahrzeug übertragen, da im Einparkvorgang kein Linkseinschlag erfolgt. Obwohl dieser Wert im Zustand 3.6 im Stateflow korrekt gesetzt wird, erfolgt anschließend keine entsprechende Umsetzung. '''Hinweis:''' Zuvor erfolgt ein Rechtseinschlag, welcher umgesetzt wird.<br><br>
* Die '''Sollgeschwindigkeit''' ''Akt_Fahrpedal_f64'', die in ''AktRTiPwm_Gas_f64'' für die dSpace-Karte umgewandelt wird, erfordert eine Anpassung. Ein Offset in der Verarbeitung zum PWM-Signal wird aktuell nicht berücksichtigt, da dieser kürzlich hinzugefügt wurde und bisher nicht dokumentiert ist. Diese Anpassung sollte wahrscheinlich im AEP-Stateflow vorgenommen werden. Das Problem wird deutlich, wenn eine Geschwindigkeit von 0 m/s übergeben wird und das Fahrzeug trotzdem weiterfährt.<br><br>
[[Datei:Aktoren Modell des Carolocup Fahrzeugs.png|650px|]]<br>
* Die '''Gierrate''' ist für den Einparkvorgang essentiell. Ein herausforderndes Problem besteht darin, dass dieser Wert bei längerer Parkplatzsuche erheblich abdriftet. Dies führt dazu, dass während einer Geradeausfahrt der Fahrzeugwinkel bei einer gefundenen Parklücke bereits 23° betragen kann, obwohl er eigentlich 0° sein sollte. Beim ersten Carolocup-Fahrzeugs ist dieser Drift nicht so ausgeprägt. Bei den anderen Fahrzeugen ist jedoch eine weitere Bearbeitung erforderlich, um diesen Effekt zu korrigieren. <br><br>
* Der Einparkvorgang ist bisher ausschließlich für das erste Fahrzeug des Carolocup angepasst worden. Das bedeutet, dass die oben genannten '''Parameterdateien''' auch für die weiteren Fahrzeuge erweitert werden müssen. In diesen Dateien sind sämtliche Fahrzeuginformationen enthalten, darunter die Breite, Länge und der Achsstand, aber auch die Einparkgeschwindigkeiten.<br><br>
* Die '''Resetfunktion''' muss ebenfalls überarbeitet werden. Wenn der Reset-Button betätigt wird und sich der AEP-Stateflow beispielsweise im Zustand 3.6 befindet, wird dieser Zustand durch die Betätigung des Buttons derzeit nicht zurückgesetzt. Momentan erfolgt der Reset durch den Neustart der dSpace-Plattform, was zwar funktioniert, aber keine dauerhafte Lösung darstellt:<br><br>
[[Datei:Plattform neu laden.jpg|650px|]]<br>
* Die Aktoren online müssen dokumentiert und beschrieben werden, da die genaue Ansteuerung im '''Akt-Aktoren-Modell''' nicht ausführlich erläutert sind.


= Nützliche Links =
= Nützliche Links =
Zeile 409: Zeile 477:


= Mögliche Software =
= Mögliche Software =
Matlab 2019b
*Matlab 2019b
*Matlab Simulink 2019


----
----
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]] | [[SDE-Team 2023/24]]
→ zurück zum Hauptartikel: [[Praktikum_SDE|Praktikum SDE]] | [[SDE-Team 2023/24]]

Aktuelle Version vom 15. Januar 2024, 14:03 Uhr

Autoren: Niklas Reeker, Oliver Scholze
Betreuer: Prof. Schneider, Prof. Göbel, Marc Ebmeyer

Einleitung

In diesem Kapitel wird der Ist-Zustand des Fahrzeugs zu Beginn des Wintersemesters 23/24 ermittelt. Des Weiteren werden alle Änderungen beschrieben, die zu einem lauffähigen Einparkalgorithmus führen.

Funktionsweise des AEP

Die Funktionsweise ist sowohl in CCF_Online als auch im CCF_Offline identisch. In der Datei "start.m" können zwei Varianten ausgewählt werden. Zum einen wird lediglich die Parklücke gesucht und das Fahrzeug wird bei erfolgreicher Lokalisierung der Parklücke gestoppt. Die andere Variante hingegen parkt das Fahrzeug nach Auffinden einer Parklücke eigenständig ein. Das Fahrzeug durchläuft einen Stateflow, der mehrere Zustände enthält und durch Bedingungen gesteuert wird. Diese Bedingungen werden mithilfe von Sensorwerten und Berechnungen erfüllt, um den Ablauf zu steuern.

Für eine genauen Einblick in die Funktionsweise und Zustände des Simulink-Stateflows steht der Artikel AEP - Einparkalgorithmus zur Verfügung.

Projektplanung

Hier werden sämtliche Sprint Ordner verlinkt, in denen die A3 Blätter und andere relevante Daten enthalten:

Inbetriebnahme

Ziel-Zustand

Die AEP ist wieder in einen lauffähigen Zustand versetzt. Sowohl Simulation als auch das online-Modell sind funktionsfähig.

Der angestrebte Soll-Zustand muss klar spezifiert werden. Ausgehend vom angestrebten Ziel führt das Rückwärts-Denken in der Regel zu besseren Lösungen als die Suche ohne klares Ziel. Bei der Bestimmung des Ziel-Zustands muss auch geklärt werden, wie sich feststellen lässt, dass der Ziel-Zustand erreicht ist. Wie messen wir, ob die Problemlösungen erfolgreich sind? Welche Basis oder Kennzahl dient als Vergleichsmaßstab?

Ziel-Zustand - Sprint1

In dem ersten Sprint sollen die Parameter überprüft und neu berechnet werden. Des Weiteren soll das Problem genau festgelegt werden, weshalb das AEP nicht funktionsfähig ist. Genaue Maßnahmen sind in dem A3 Lösungsblatt zu finden.

Ziel-Zustand - Sprint2

Das Ziel des Sprintes und das messbare Kriterium, welches das Ziel definiert, ist das Autonome Einparken des Fahrzeugs auf der Testtrecke in einer großen Parklücke. Ergänzend dazu wird der Wiki-Artikel weitergeführt, Versuche und Debugging der Software für autonome Einparken durchgeführt.

Ziel-Zustand - Sprint3

Das Ziel des dritten Sprints besteht darin, das autonome Einparken auf der Teststrecke zu realisieren und der Stateflow korrekt arbeitet. Als Nachweis sollen zwei Videos des Einparkvorgangs dienen, welches im Ordner Sprint 3 des AEP abgelegt wird.

Zu diesem Zweck werden zwei Ziele festgelegt, da das AEP zwei Durchführungsversionen bereitstellt. Diese können im Startprogramm ausgewählt werden. Die erste Version führt ein vollständiges seitliches Einparken durch, während die zweite Version die Parklücke sucht und bei Auffinden einer geeigneten Parklücke anhält.

AEP - Parameter

In diesen Abschnitt werden die relevanten Parameter überprüft und deren Auswertung in den Tabellen notiert.

Sensordaten

Hier werden relevante Sensordaten für das Einparken überprüft.

Testfall ID Parameterbezeichnung Ersteller Datum Ist - Werte Soll - Werte Ergebnis Prüfer Datum Bemerkung
Tabelle: Überprüfung der Sensordaten
1 SenVx_sx_K_f64 Niklas Reeker 17.10.2023 - 2 m 2 m i.O. Oliver Scholze 17.10.2023 Strecke ist negativ
2 SenGier_psi_filt_K_f64 Niklas Reeker 17.10.2023 n.i.O. Oliver Scholze 17.10.2023
3 SenAbs_xVR_K_f64 Niklas Reeker 17.10.2023 / cm 15 cm n.i.O. Oliver Scholze 17.10.2023 Lookup-table Parameter müssen aktualisiert werden (siehe AF:_Abstandssensorik_(SenAbs))
4 SenAbs_xHR_K_f64 Niklas Reeker 17.10.2023 / cm 15 cm n.i.O. Oliver Scholze 17.10.2023 Lookup-table Parameter müssen aktualisiert werden (siehe AF:_Abstandssensorik_(SenAbs))
5 SenAbs_yHR_K_f64 Niklas Reeker 17.10.2023 / cm 15 cm n.i.O. Oliver Scholze 17.10.2023 Lookup-table Parameter müssen aktualisiert werden (siehe AF:_Abstandssensorik_(SenAbs))
6 SenAbs_yHL_K_f64 Niklas Reeker 17.10.2023 / cm 15 cm n.i.O. Oliver Scholze 17.10.2023 Lookup-table Parameter müssen aktualisiert werden (siehe AF:_Abstandssensorik_(SenAbs))

Konstante Eingangsparameter des Fahrzeugs

Hier werden die Basisdaten überprüft und in der Tabelle notiert. Zusätzlich werden die Ist-Werte eingetragen und mit den Soll-Werten (die selbst ermittelt werden) verglichen. Sollten diese nicht übereinstimmen, werden die Parameter in der Software sofort angepasst. Hinweis: Die Parameter werden nicht zusätzlich erklärt, da diese in den nützlichen Links und der Software ausführlich erklärt sind. Außerdem werden die Berechnungen nicht aufgeführt, da diese ebenfalls in den nützlichen Links beschrieben ist.

Dateiname File Revision by
Tabelle: Parameter Dateien
param_AEP.m Datei: [1] 7759 Weiran Wang
param_CAR.m: [2] 5326 Stefan Arndt

Für ein einheitlichen Verständnis für die Abmessung des Fahrzeugs, wird die folgende Abbildung aufgeführt. Darauf wird das Fahrzeug abgebildet, sowie relevante Parameter für die pram.CAR.m Datei eingezeichnet.

Testfall ID Parameterbezeichnung Ersteller Datum Ist - Werte Soll - Werte Ergebnis Prüfer Datum Bemerkung Änderung erfolgt (Soll i.O.)
Tabelle: Überprüfung der konstanten Eingangsparameter des Fahrzeugs
1 PAR_AEP_Measure_or_Park Niklas Reeker 17.10.2023 2 2 i.O. Oliver Scholze 17.10.2023 Auswahl zwischen Einparken oder Parklücke messen -
2 PAR_AEP_Laenge_Parkbucht_f64 Niklas Reeker 17.10.2023 5,21m 5,2m i.O. Oliver Scholze 17.10.2023 Entfernung ab dem die Parkplatzsuche beendet wird. -
3 PAR_AEP_Abstand_Startkoordinate_Parkbucht_f64 Niklas Reeker 17.10.2023 0,415m 0,5m n.i.O. Oliver Scholze 17.10.2023 i.O.
4 PAR_AEP_Suchgeschwindigkeit_f64 Niklas Reeker 17.10.2023 0,3 0,3 i.O. Oliver Scholze 17.10.2023 -
5 PAR_AEP_Vermessgeschwindigkeit_f64 Niklas Reeker 17.10.2023 0,1 undefiniert n.i.O. Oliver Scholze 17.10.2023 Parameter muss am Fahrzeug getestet werden
6 PAR_AEP_Einparkgeschwindigkeit_f64 Niklas Reeker 17.10.2023 -0,3 -0,3 i.O. Oliver Scholze 17.10.2023 -
7 PAR_AEP_Stoppgeschwindigkeit_f64 Niklas Reeker 17.10.2023 0 0 i.O. Oliver Scholze 17.10.2023 -
8 PAR_AEP_Lenkung_MAX_Rechts_f64 Niklas Reeker 17.10.2023 -0,4014rad (-23°) -0,3839rad (-22°) n.i.O. Oliver Scholze 17.10.2023 i.O.
9 PAR_AEP_Lenkung_Mittelstellung_f64 Niklas Reeker 17.10.2023 0° 0° i.O. Oliver Scholze 17.10.2023 -
10 PAR_AEP_Lenkung_MAX_Links_f64 Niklas Reeker 17.10.2023 0,4014rad (23°) 0,4363rad (25°) n.i.O. Oliver Scholze 17.10.2023 i.O.
11 PAR_AEP_IR_MIN_f64 Niklas Reeker 17.10.2023 0,02m 0,02m i.O. Oliver Scholze 17.10.2023 -
12 PAR_AEP_IR_MAX_f64 Niklas Reeker 17.10.2023 0,299m 0,3m i.O. Oliver Scholze 17.10.2023 -
13 PAR_AEP_Umschlagwinkel_f64 Niklas Reeker 17.10.2023 0,5738rad 0,6957rad n.i.O. Oliver Scholze 17.10.2023 Ist entspricht 32,88° und soll entspricht 39,86°, Fahrzeugbreite ist von 0,2m auf 0,29m gestiegen durch Bumper i.O.
14 PAR_AEP_Parkluecke_Soll_f64 Niklas Reeker 17.10.2023 0,6988m 0,8342m n.i.O. Oliver Scholze 17.10.2023 Da sich Fahrzeuglänge durch hinzufügen von Bumper verlängert hat. i.O.
15 PAR_AEP_Korrekturstrecke_Vor_f64 Niklas Reeker 17.10.2023 0,03m undefiniert n.i.O. Oliver Scholze 17.10.2023 Parameter muss am Fahrzeug getestet werden i.O.
16 PAR_AEP_Korrekturfaktor_Rueck_f64 Niklas Reeker 17.10.2023 0,3% undefiniert n.i.O. Oliver Scholze 17.10.2023 Parameter muss am Fahrzeug getestet werden i.O.
17 PAR_AEP_Korrekturstrecke_Rueck_MAX_f64 Niklas Reeker 17.10.2023 0,2075m undefiniert n.i.O. Oliver Scholze 17.10.2023 Parameter muss am Fahrzeug getestet werden i.O.
18 PAR_AEP_Parkluecke_Rueck_Parallel_MIN_f64 Niklas Reeker 17.10.2023 0,95m undefiniert n.i.O. Oliver Scholze 17.10.2023 Parameter muss am Fahrzeug getestet werden i.O.
19 PAR_AEP_Streckenbegrenzung_Rueck_f64 Niklas Reeker 17.10.2023 0,225m undefiniert n.i.O. Oliver Scholze 17.10.2023 Parameter muss am Fahrzeug getestet werden i.O.
20 PAR_AEP_Schlussparkwinkel_f64 Niklas Reeker 17.10.2023 0,0255rad -0,0087rad n.i.O. Oliver Scholze 17.10.2023 Entspricht -0,5° parallel zur Fahrbahn(in SW notiert) i.O.
21 PAR_CAR_Fahrzeuglaenge_f64 Niklas Reeker 17.10.2023 0,43m 0,5m n.i.O. Oliver Scholze 17.10.2023 i.O.
22 PAR_CAR_Mitte_Hinterachse_Ende_f64 Niklas Reeker 17.10.2023 0,1m 0,12m n.i.O. Oliver Scholze 17.10.2023 i.O.
23 PAR_AEP_Schlussparkwinkel_ohne_Korrekturzug_f64 Niklas Reeker 17.10.2023 0,085 0 n.i.O. Oliver Scholze 17.10.2023 Entspricht 4,9° i.O.

Endzustand des AEP vom Carolocup-Fahrzeugs

Dieses Kapitel widmet sich dem Endzustand sowohl des Offline- als auch des Online-Modells im Rahmen des SDE 2-Praktikums. Es bietet eine detaillierte Darstellung der aktuellen Funktionalitäten sowie kritische Betrachtungen, um Schwachstellen und Bereiche für Verbesserungen zu identifizieren.

Darüber hinaus werden in diesem Abschnitt nicht nur die bestehenden Erfolge erörtert, sondern auch aufgezeigt, an welchen Stellen Optimierungen und Weiterentwicklungen notwendig sind. Das Ziel besteht darin, dass zukünftige Semester auf diesen Erkenntnissen aufbauen können, um ihre Ziele effizienter zu erreichen.

Offline-Modell

Das CCF_Offline ermöglichte das automatische Einparken des Fahrzeugs in Simulation ab dem Sprint 2 Termin. Die Integration der Schaltereinheit zur Unterstützung neuer Fahrzeugerweiterungen führte jedoch zu verschiedenen Problemen und Fehlermeldungen im Simulink-Modell. Eine detaillierte Analyse ist erforderlich, um die Simulation erfolgreich zum Laufen zu bringen.

Die Modifikationen wurden am 09.01.2024 vorgenommen, wobei die Signalverarbeitung der Gierrate überarbeitet und um die Fahrzeugerweiterungen eingebunden wurde. Seitdem ist die Funktionstüchtigkeit beeinträchtigt und das System arbeitet nicht wie beabsichtigt.

Es ist wichtig zu beachten, dass die Simulation zwar die Fahrzeugdaten simuliert, jedoch deutliche Abweichungen bei den Sensorwerten auftreten können, insbesondere bei der Gierrate. Dies hat die Weiterentwicklung des CCF_Online deutlich verzögert.

Online-Modell

Das erste Fahrzeug des Carolocup erkennt erfolgreich die Parklücke. Die in der Datei "start.m" auswählbare Variante des AEP, bei der das Fahrzeug nach dem Finden der Parklücke angehalten werden soll, funktioniert wie beabsichtigt. Wie in den Entwicklungspotenzialen beschrieben, sollte jedoch die gesetzte Geschwindigkeit im Zustand 4 (Endzustand des Stateflows) überarbeitet werden, da das Fahrzeug trotz des durch den Warnblinker signalisierten Zustands immer noch langsam weiterfährt (Geschwindigkeit ist auf 0m/s gesetzt).

Die zweite Variante, bei der das Fahrzeug nach dem Finden der Parklücke einparken soll, ist ebenfalls funktionsunfähig. Die Zustände im AEP werden erfolgreich umgesetzt. Um Probleme wie das Nicht-Losfahren des Fahrzeugs zu vermeiden, wurden zunächst die Geschwindigkeiten beim Einparken erhöht.

Der Einparkvorgang funktioniert bis zum Zustand 3.6, wie in den weiterführenden Artikeln beschrieben, einwandfrei. Jedoch erfolgt kein Linkseinschlag, wodurch das Fahrzeug nicht korrekt einparken kann. Dieses Problem wird ebenfalls in den Entwicklungspotenzialen detailliert erläutert. Wenn das Fahrzeug jedoch manuell gedreht wird, werden die Zustände wie erwartet ausgeführt, und der Endzustand, bei dem das Fahrzeug perfekt in der Parklücke steht, wird erreicht.

Weiterentwicklungspotenziale des AEP auf einen Blick

Dieses Unterkapitel behandelt sämtliche identifizierte Probleme. Ziel ist es, eine umfassende Übersicht über die aufgetretenen Schwierigkeiten zu bieten und mögliche Lösungsansätze oder Handlungsempfehlungen zu skizzieren.

Probleme:

  • Der Lenkwinkel Akt_LwSoll_f64, der in AktRTiPwm_Lw_f64 für die dSpace-Karte umgewandelt wird, wird nicht korrekt an das Fahrzeug übertragen, da im Einparkvorgang kein Linkseinschlag erfolgt. Obwohl dieser Wert im Zustand 3.6 im Stateflow korrekt gesetzt wird, erfolgt anschließend keine entsprechende Umsetzung. Hinweis: Zuvor erfolgt ein Rechtseinschlag, welcher umgesetzt wird.

  • Die Sollgeschwindigkeit Akt_Fahrpedal_f64, die in AktRTiPwm_Gas_f64 für die dSpace-Karte umgewandelt wird, erfordert eine Anpassung. Ein Offset in der Verarbeitung zum PWM-Signal wird aktuell nicht berücksichtigt, da dieser kürzlich hinzugefügt wurde und bisher nicht dokumentiert ist. Diese Anpassung sollte wahrscheinlich im AEP-Stateflow vorgenommen werden. Das Problem wird deutlich, wenn eine Geschwindigkeit von 0 m/s übergeben wird und das Fahrzeug trotzdem weiterfährt.



  • Die Gierrate ist für den Einparkvorgang essentiell. Ein herausforderndes Problem besteht darin, dass dieser Wert bei längerer Parkplatzsuche erheblich abdriftet. Dies führt dazu, dass während einer Geradeausfahrt der Fahrzeugwinkel bei einer gefundenen Parklücke bereits 23° betragen kann, obwohl er eigentlich 0° sein sollte. Beim ersten Carolocup-Fahrzeugs ist dieser Drift nicht so ausgeprägt. Bei den anderen Fahrzeugen ist jedoch eine weitere Bearbeitung erforderlich, um diesen Effekt zu korrigieren.

  • Der Einparkvorgang ist bisher ausschließlich für das erste Fahrzeug des Carolocup angepasst worden. Das bedeutet, dass die oben genannten Parameterdateien auch für die weiteren Fahrzeuge erweitert werden müssen. In diesen Dateien sind sämtliche Fahrzeuginformationen enthalten, darunter die Breite, Länge und der Achsstand, aber auch die Einparkgeschwindigkeiten.

  • Die Resetfunktion muss ebenfalls überarbeitet werden. Wenn der Reset-Button betätigt wird und sich der AEP-Stateflow beispielsweise im Zustand 3.6 befindet, wird dieser Zustand durch die Betätigung des Buttons derzeit nicht zurückgesetzt. Momentan erfolgt der Reset durch den Neustart der dSpace-Plattform, was zwar funktioniert, aber keine dauerhafte Lösung darstellt:


  • Die Aktoren online müssen dokumentiert und beschrieben werden, da die genaue Ansteuerung im Akt-Aktoren-Modell nicht ausführlich erläutert sind.

Nützliche Links

→ zum Artikel Einparkalgorithmus: AEP - Einparkalgorithmus
→ zum Artikel Einparksensorik: AEP - Einparksensorik
→ zum Artikel AEP-Autonomes Einparken: AEP - Einparksensorik

Mögliche Software

  • Matlab 2019b
  • Matlab Simulink 2019

→ zurück zum Hauptartikel: Praktikum SDE | SDE-Team 2023/24

Abgerufen von „https://wiki.hshl.de/wiki/index.php?title=AEP:_Einparken&oldid=116998“