Einleitung
Die SAE AutoDrive Challenge ist ein 4-jähriger College-Designwettbewerb, an dem 8 Teams aus den USA und Kanada teilnehmen. Das übergeordnete technische Ziel für das dritte Jahr dieses Wettbewerbs ist die Navigation auf einem städtischen Fahrkurs in einem automatisierten Fahrmodus, wie in SAE Level 3 beschrieben.
MathWorks fordert Teams zur Verwendung von Simulationen auf
Die Simulation ist ein sehr nützliches Werkzeug für die autonome Fahrzeugentwicklung. Modellbasiertes Testen kann bei der Algorithmusentwicklung, beim Testen auf Einheiten- und Systemebene sowie beim Testen von Randfall-Szenarien hilfreich sein. Echte Welt Sensor Daten können aufgezeichnet und im System wiedergegeben werden, um Fusionsalgorithmen abzustimmen. Eine Simulationsumgebung kann erstellt werden, um reale Umgebungen zu modellieren, und kann zum Testen verschiedener Algorithmen und Sensorpositionen verwendet werden. Die besten Algorithmen und Sensorpositionen, die die Teamanforderungen erfüllen, können basierend auf den Leistungsergebnissen ausgewählt werden.
Jedes Jahr fordert MathWorks die Teams auf, die Simulation über eine Simulations-Challenge zu verwenden. In diesem Blog werden kurz die Gewinner des 1. und 2. Platzes der 2020 Challenge (University of Toronto und Kettering University), ihr Systemdesign und die Verwendung von MathWorks-Tools zur Erreichung der allgemeinen Wettbewerbsziele behandelt. Die Teams wurden anhand der Art und Weise beurteilt, in der sie die Tools verwendeten:
- Open-Loop-Wahrnehmungstest - Synthese von Daten für Open-Loop-Tests, Bewertung der Richtigkeit der Algorithmen
- Testen von Steuerungen mit geschlossenem Regelkreis - Synthese von Szenarien mit geschlossenem Regelkreis, Bewertung der Leistung von Steuerungsalgorithmen
- Codegenerierung von Steuerungsalgorithmen - Generierung von Code für Algorithmen, Integration des generierten Codes in das Fahrzeug
- Innovation mit MathWorks-Tools – eine Technik/Technologie deutlich von den oben genannten 3 Kategorien unterscheiden
University of Toronto
Das Studententeam der University of Toronto, aUToronto, gewann den 1. Platz in der Challenge.
Wahrnehmungstests im offenen Regelkreis
Der erste Schritt dieses Teams bestand darin, Daten für Wahrnehmungstests im offenen Regelkreis zu synthetisieren. Sie haben sich entschieden, ihren Sensorfusionsalgorithmus zu testen. Um synthetische Daten zum Testen zu synthetisieren, verwendeten sie die (DSD). Mit dieser App können Sie synthetische Fahrszenarien entwerfen, um Ihr autonomes Fahren zu testen. Das Team verwendete ein Radar und 3 Kameras in den Sensorfusionsalgorithmen, die wie in Abbildung 1 konfiguriert sind.
Abbildung 1: Positionen der Teamsensoren (© aUToronto)
Sie modellierten die Kamerasensoren - zusammen mit ihren Positionen, Ausrichtungen und Konfigurationen - in der DSD-App, um Sensordaten zu synthetisieren, die in ihre Sensorfusionsalgorithmen einfließen. Das DSD simuliert die Kameraausgabe nach den Bildverarbeitungs- und Computer-Vision-Algorithmen des Teams und fügt den Daten Rauschen und Ausreißer hinzu.
Der Block "Szenario-Reader" wurde zum Lesen von Szenario-Informationen verwendet, die mit DSD erstellt wurden. Die Schauspieler-Posen wurden als Eingabe an die mehreren Erkennungsgeneratoren gesendet. Die Erkennungen für diese verschiedenen Sensoren wurden dann als ROS-Nachrichtenarrays (Robot Operating System) variabler Größe verpackt und als benutzerdefinierte ROS-Nachrichten an bestimmte ROS-Themen gesendet (Abbildung 2).
Abbildung 2: Simulink-Modell für Open-Loop-Tests (© aUToronto)
Das Team verglich die Ausgabe seines Objekt-Trackers mit den Grundwahrheitswerten von Fahrzeugen. Die RMSE-Metrik (Root Mean Square Error) wurde zur Leistungsbewertung verwendet.
Testen von Regelkreisen
Das Hauptaugenmerk des Teams lag darauf, den modifizierten Planer auf neue Funktionen wie das Umleiten von Bauzonen und das Stoßen um Hindernisse zu testen. Der Planer wurde neu gestaltet, um eine Gitterstruktur zu verwenden, bei der Kanten von der Karte abgeschnitten werden, um nach Bedarf Pfade um Objekte zu finden (Abbildung 3). DSD wurde erneut zum Erstellen von Szenarien verwendet. Barrieren und Ampeln wurden ebenfalls zu den Szenarien hinzugefügt.
Abbildung 3: Gitterstruktur zur Pfadfindung (© aUToronto)
Das Team modellierte einen Ampelverlag mithilfe von Stateflow (Abbildung 4). Wenn sich das Ego-Fahrzeug außerhalb der Reichweite (> 50 m) der Ampel befindet, wird ein unbekannter Zustand veröffentlicht. Wenn sich das Ego in Reichweite befindet, wird eine Rotlichtnachricht veröffentlicht. Die Nachricht wird auf grünes Licht geschaltet, nachdem das Ego 5 Sekunden lang angehalten hat.
Abbildung 4: Statusfluss zum Modellcontroller (© aUToronto)
Die ROS-Knoten für Controller, Planer und Fahrzeugmodell wurden gestartet. Befand sich das Hindernis innerhalb von 50 m vom Ego-Fahrzeug, wurde seine Position als ROS-Nachricht an das Simulink-Modell gesendet (Abbildung 5).
Abbildung 5: Logik zum Senden einer Positionsnachricht (© aUToronto)
Codegenerierung von Steuerungsalgorithmen
Das Team generierte Code für den Stoppschild-Handhabungsalgorithmus (Abbildung 6). Zur Konvertierung des Stateflows in C++-Code wurde Simulink Coder verwendet. Ein Standalone Modulen wurde mit der Code-Packaging-Funktion generiert. Das generierte Modul wurde dann in die Team-Codebasis eingefügt.
Abbildung 6: Statusablauf der Bremslichtsteuerungslogik (© aUToronto)
Innovation mit MathWorks-Tools - Lidar-Kamerakalibrierung
Um die Objekte in einer Szene mit Eingaben von einem Lidar und einem Kamerasensor genau zu interpretieren, müssen die Sensorausgänge miteinander verschmolzen werden. Daher führte das Team eine Transformation zwischen Lidar und Teamkamera durch, um Lidar-Punkte für die Sensorfusion auf ein Bild zu projizieren oder umgekehrt. Anstatt Handmessungen und rotierende Kameras zu verwenden, bis die Projektionen gut aussahen, verwendete das Team das neu entwickelte Kalibrierungswerkzeug für die Lidar-Kamera aus der Lidar-Verarbeitungs-Toolbox. Dieses Werkzeug schätzt eine starre Transformationsmatrix, die die Entsprechungen zwischen den Punkten in der 3D-Lidarebene und den Pixeln in der Bildebene herstellt
Sie bauten eine größere Kalibrierungskarte, da ihre aktuelle für das Werkzeug zu klein war. Das Kamerakalibrierungswerkzeug wurde verwendet, um die intrinsische Matrix für ihre Kamera zu erhalten. Die Ecken des Schachbretts wurden in jedem Bild und den Lidar-Daten gefunden. Die starre Transformationsmatrix zwischen Lidar und Kamera wurde gefunden. Dieser Prozess gibt eine Transformation aus, mit der die Punktwolkendaten auf Bilder projiziert werden können oder umgekehrt. Diese Schritte sind in Abbildung 7 dargestellt.
Abbildung 7: (a) Kamera-Eigenmatrix (b) Schachbrett-Ecken (c) Lidar-Kamera-Transformationsmatrix (© aUToronto)
Kettering Universität
Das Studententeam von der Kettering University, gewann den 2. Platz in der Herausforderung.
Wahrnehmungstests im offenen Regelkreis
Das Team verwendete Unreal Engine, um verschiedene Szenarien zu erstellen. Mit dem 3D-Kamerablock der Simulation wurde dem Ego-Fahrzeug in Unreal eine Kamera hinzugefügt. Ein Simulink-Modell wurde verwendet, um die Spurerkennung unter Verwendung der unwirklichen Bilder durchzuführen (Abbildung 8). Die blauen Quadrate zeigen die Spurerkennungsfunktionen an und die gelben zeigen die Ausgaben bei jedem Schritt an. Diese Ausgabezahlen sind in Abbildung 9 dargestellt.
Abbildung 8: Simulink-Modell für Open-Loop-Tests (© Kettering University)
Abbildung 9: Spurerkennungsausgänge (© Kettering University)
Testen von Regelkreisen
Das Systemdesign des Teams bestand aus 2 Zustandsmaschinen - longitudinal und lateral. Diese in Abb. XNUMX gezeigten Zustandsmaschinen wurden verwendet, um die Logik der Reglerauswahl basierend auf Sensor- und Entscheidungsdaten zu modellieren. Sie wurden miteinander verbunden und zum Aktivieren und Initialisieren der Controller-Subsysteme verwendet.
Abbildung 10: Zustandsautomaten (© Kettering University)
Kombinierte Controller-Simulationen mit dem Simulink-Modell in Abbildung 11 wurden durchgeführt, um die Funktion aller Team-Controller zu überprüfen. Die Eingänge zu diesen Steuerungen wurden mithilfe von Schiebereglern und Messgeräten bereitgestellt.
Abbildung 11: Simulink-Modell für Closed-Loop-Tests (© Kettering University)
Zu den Reglersubsystemen der Längszustandsmaschine gehören der Längsdrehzahlregler und die automatische Notbremsung (AEB). Die Zustände wurden durch die Fahrdynamik in Längsrichtung wie Beschleunigen, Fahren, Abbremsen, Stillstand und Parken bestimmt.
Zu den Steuerungssubsystemen der Lateral State Machine gehören die Steuergeräte Lane Keep Assist (LKA), Lane Change und Turn. Die Zustände wurden basierend auf der seitlichen Fahrzeugdynamik bestimmt (Abbildung 12). Längsgeschwindigkeits-, Spurwechsel- und LKA-Steuerungen werden unten erläutert.
Abbildung 12: Zustände der seitlichen Steuerung (© Kettering University)
Längsregler
Abbildung 13 zeigt das Simulink-Modell zur Modellierung des Längsreglers. Es bestand aus einer PID basierend auf der Geschwindigkeit. Die Referenz- und Ausgangsdrehmomentraten waren begrenzt, um innerhalb der Beschleunigungs- und Ruckgrenzen des Wettbewerbs zu bleiben. Systemeingaben wurden initialisiert und mit Schiebereglern bearbeitet, und ein Bereich wurde zum Anzeigen von Daten verwendet. Abbildung 14 zeigt die Ziel- und tatsächlichen Längsgeschwindigkeitsausgaben.
Abbildung 13: Simulink-Modell des Längsreglers (© Kettering University)
Abbildung 14: Geschwindigkeitsvergleiche in Längsrichtung (© Kettering University)
Spurwechselregler
Der Lane Change Controller des Teams verwendete adaptives MPC (Model Predictive Control). Ein Referenzpfad wurde unter Verwendung parametrischer Funktionen mit Fahrspurwechseleingaben wie Fahrzeuggeschwindigkeit und Fahrspurbreite generiert. Die Ausgänge zur Steuerung waren Referenzseitenposition und Gieren. Ein 3DOF-Modell (Freiheitsgrad) wurde verwendet, um die Fahrzeugkarosserie zu simulieren. Abbildung 15 zeigt das für die Simulation verwendete Simulink-Modell. Abbildung 16 zeigt die Ergebnisse der Simulation mit Referenz- und simulierten Spurwechselpfaden sowie die Pfade, die nach fahrzeuginternen Tests erhalten wurden.
Abbildung 15: Simulink-Modell des Spurwechselreglers (© Kettering University)
Abbildung 16: Vergleiche von Spurwechselpfaden (© Kettering University)
Fahrzeugmodell
Das Team entwickelte und validierte ein einspuriges und zweispuriges 3DOF-Fahrzeugmodell. Die anfängliche Validierung wurde unter Verwendung eines linearen Fahrradmodells durchgeführt. Die endgültige Validierung wurde mit physikalischen Testdaten durchgeführt. Die Abbildung zeigt die Ausgabe des Querbeschleunigungsvergleichs mit Erst- und Endvalidierung ohne und mit Testdaten.
Abbildung 17: (a) Vergleiche der Querbeschleunigung (b) Vergleiche mit Testdaten (© Kettering University)
Innovation mit MathWorks-Tools - Unwirkliche Stadt
Das Team verwendete Unreal zum Testen aller Controller im geschlossenen Regelkreis. Sie schufen eine unwirkliche Stadt mit kontrollierbaren Fußgängerbewegungen und Ampeln. Es wurden anpassbare Schauspieler erstellt und ihre Informationen wie Name des Schauspielers, Typ des Schauspielers, Details des Schauspielers, Animationsdetails und Tags für den schnellen Zugriff gespeichert. Eine Ampelkarte wurde zusammen mit der Position der Ampeln mit der Bezeichnung Abbildung 18 erstellt.
Abbildung 18: Unwirkliche Ampelkarte (© Kettering University)
Abbildung 19 zeigt die Kommunikationsstruktur des Simulink-Unreal-Systems. Die Entscheidungsfindung für die unwirkliche Szene, bestehend aus Fahrzeugposition, Fußgängerbewegung, Ampelstatus usw., wurde mithilfe von Stateflow getroffen und als Eingabe an die Steuerungen gesendet (Abbildung 20).
Abbildung 19: Simulink Unreale Systemkommunikationsstruktur (© Kettering University)
Abbildung 20: Stateflow für unwirkliche Szenenentscheidungen (© Kettering University)
Zusammenfassend konnten die Studententeams der University of Toronto und der Kettering University MATLAB und Simulink nutzen, um Fusions-, Verfolgungs- und Navigationsalgorithmen zu entwerfen, zu bauen, zu testen und zu bewerten, um dem Bau eines autonomen SAE Level 4-Fahrzeugs einen Schritt näher zu kommen Simulation. Sie erstellten komplizierte Szenarien mit Ampeln und mehreren Akteuren in verschiedenen Simulationsumgebungen, integrierten die Umgebungen in Simulink und implementierten und testeten die von ihnen ausgewählten Algorithmen für diese Szenarien. Wahrnehmungsalgorithmen mit offenem und geschlossenem Regelkreis wurden mit Simulink modelliert und getestet, und für diese Systeme wurde Code generiert. Die Teams entwarfen und testeten auch verschiedene Controller-Algorithmen mit Simulink und Stateflow. Die MathWorks-Tools wurden von beiden Meisterschaftsteams innovativ und umfassend eingesetzt.