AEP: Einparken: Unterschied zwischen den Versionen
| (22 dazwischenliegende Versionen von 2 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 = | = Projektplanung = | ||
| Zeile 16: | Zeile 24: | ||
= Ziel-Zustand = | = Ziel-Zustand = | ||
Die AEP ist wieder in einen lauffähigen Zustand versetzt. Sowohl Simulation als auch das online-Modell sind funktionsfähig. | 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 == | == 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 == | == 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 325: | Zeile 336: | ||
| 17.10.2023 | | 17.10.2023 | ||
| Parameter muss am Fahrzeug getestet werden | | Parameter muss am Fahrzeug getestet werden | ||
| | | <span style="color:green;"> i.O. | ||
|- | |- | ||
| 16 | | 16 | ||
| Zeile 337: | Zeile 348: | ||
| 17.10.2023 | | 17.10.2023 | ||
| Parameter muss am Fahrzeug getestet werden | | Parameter muss am Fahrzeug getestet werden | ||
| | | <span style="color:green;"> i.O. | ||
|- | |- | ||
| 17 | | 17 | ||
| Zeile 349: | Zeile 360: | ||
| 17.10.2023 | | 17.10.2023 | ||
| Parameter muss am Fahrzeug getestet werden | | Parameter muss am Fahrzeug getestet werden | ||
| | | <span style="color:green;"> i.O. | ||
|- | |- | ||
| 18 | | 18 | ||
| Zeile 361: | Zeile 372: | ||
| 17.10.2023 | | 17.10.2023 | ||
| Parameter muss am Fahrzeug getestet werden | | Parameter muss am Fahrzeug getestet werden | ||
| | | <span style="color:green;"> i.O. | ||
|- | |- | ||
| 19 | | 19 | ||
| Zeile 373: | Zeile 384: | ||
| 17.10.2023 | | 17.10.2023 | ||
| Parameter muss am Fahrzeug getestet werden | | Parameter muss am Fahrzeug getestet werden | ||
| | | <span style="color:green;"> i.O. | ||
|- | |- | ||
| 20 | | 20 | ||
| Zeile 424: | Zeile 435: | ||
|- | |- | ||
|} | |} | ||
= 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 == | == 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 == | == 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 = | ||
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 |
|---|---|---|---|---|---|---|---|---|---|
| 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 |
|---|---|---|
| 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.) |
|---|---|---|---|---|---|---|---|---|---|---|
| 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