AEP - Autonomes Einparken: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| Zeile 260: | Zeile 260: | ||
*parkende Hindernisse werden nicht mehr dargestellt (ab Revision 5539) | *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 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. Am Ende werden die Objekte mit einer Zählschleife im Vektor "x" in der Reihenfolge Objekt dann Parklücke zusammengefasst. | |||
= Online-Modell = | = Online-Modell = | ||
Version vom 26. April 2022, 15:53 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:
Die Einbindung des AEP Blocks (gelb umrandet) im Online-Modell (Carolo-Cup-Fahrzeug) ist in der folgenen Abbildung dargestellt:
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
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. Am Ende werden die Objekte 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