Open Source Robotics

Eine kuratierte Sammlung hochwertiger Open-Source-Robotikprojekte, Werkzeuge und Software für die Robotik-Community.

Pylot: A Modular Platform for Exploring Latency-Accuracy Tradeoffs in Autonomous Vehicles

Autoren: Ionel Gog, Sukrit Kalra, Peter Schafhalter, Matthew A. Wright, Joseph E. Gonzalez, Ion Stoica · ICRA 2021

Lizenzen

  • Open Access
  • Paper: CC BY 4.0

Alles Folgende stützt sich auf das vollständige Paper unter seiner Lizenz CC BY 4.0; die Abbildung wird mit Nennung der Autoren gezeigt.

Kurz gesagt

Modulare, deterministische AV-Pipeline auf einer Datenfluss-Laufzeitumgebung: Detektoren, Tracker, Prädiktoren oder Planer austauschen und sehen, wie ihre Laufzeit das End-to-End-Fahren in CARLA oder in einem echten Auto beeinflusst.

Warum es wichtig ist

Teams, die Fahr- oder Mobilroboter-Stacks bauen, können einen neuen Detektor oder Planer innerhalb einer vollständigen Pipeline testen und Kollisionen sowie Fahrkomfort messen statt nur Offline-Genauigkeit. Die Arbeit zeigt, dass sich die beste Komponentenwahl mit Fahrgeschwindigkeit und Szenario ändert, was dafür spricht, Komponenten im Kontext zu evaluieren.

Problem

Komponenten autonomer Fahrzeuge werden meist mit Offline-Metriken wie der Average Precision bewertet, die die Laufzeit ignorieren, obwohl ein langsames, aber genaues Modell das Fahrzeug unsicherer machen kann. Bestehende offene Stacks wie Autoware und Apollo bieten nur eingeschränkte Simulatorschnittstellen ohne fotorealistische Kameras, und ihr Publish-Subscribe-Design erschwert die deterministische Wiedergabe von Fahrszenarien.

Lösungsansatz

Pylot strukturiert die gesamte Pipeline (Detektion, Tracking, Prädiktion, Planung, Regelung) als Datenflussgraphen von Operatoren, die Zeitstempel-Nachrichten mit Watermarks austauschen, und läuft auf dem ERDOS-System der Autoren; das macht die Ausführung deterministisch und erlaubt es, Komponenten mit unterschiedlichen Laufzeiten ohne Nachjustieren auszutauschen. Mitgeliefert werden mehrere Referenzimplementierungen pro Komponente sowie auf Ground Truth beruhende „perfekte“ Versionen aus CARLA und ein pseudo-asynchroner Modus, der CARLA synchron mit über 200 Hz laufen lässt und jeden Steuerbefehl um die gemessene Laufzeit der Pipeline verzögert. Eine ROS-Zwischenschicht (Shim) lässt dieselbe Pipeline ein reales Fahrzeug fahren.

Wichtigste Erkenntnisse

  • Zeitgerechte Genauigkeit (timely accuracy), die die Ausgabe eines Moduls an der Welt zum Zeitpunkt der fertigen Ausgabe statt zum Zeitpunkt der Eingabeerfassung misst, macht sichtbar, wie Laufzeit die Genauigkeit in einer bewegten Szene aushöhlt.
  • Der beste Detektor oder Tracker ist kontextabhängig: Schnelle Detektoren mit geringerer Genauigkeit schlagen bei hohen Geschwindigkeiten langsame, hochgenaue, und SORT, DeepSORT und DaSiamRPN passen jeweils zu unterschiedlichen Situationen.
  • In einem Notausweich-Szenario vermieden Planerkonfigurationen mit geringerer Laufzeit Kollisionen häufiger, während der Frenet-Optimal-Trajectory-Planer eine ruhigere Fahrt als RRT* bot, auf Kosten weniger vermiedener Kollisionen.
  • Ein Datenflussmodell mit Watermarks reduziert die Pipeline auf ein Kahn Process Network, was eine deterministische Wiedergabe für das Debugging ermöglicht, die Publish-Subscribe-Systemen fehlt.

Hauptergebnisse

  • Eine Laufzeit von 10 ms senkt die mittlere zeitgerechte mIoU einer perfekten Komponente für semantische Segmentierung auf etwa 0,75, unter die mIoU der drei besten Cityscapes-Einreichungen.
  • Die mittlere zeitgerechte AP50 eines perfekten Fußgängerdetektors halbiert sich bei 35 ms Laufzeit.
  • Bei 20 ms Laufzeit ist die mediane zeitgerechte mIoU bei 40 m/s um 28 % niedriger als bei 10 m/s, und die mediane zeitgerechte AP50 fällt von 1,0 bei 10 m/s auf 0 bei 40 m/s.
  • Im Szenario mit verdecktem Fußgänger (Table I) scheiterten die langsamen Konfigurationen von FOT (P99 550 ms), RRT (P99 76 ms) und Hybrid A (P99 760 ms) bei jeder Zielgeschwindigkeit von 16 bis 22 m/s, während die schnelle Konfiguration jedes Planers die Kollision bei 16 m/s vermied.
  • Die Portierung der Pipeline von CARLA auf ein Lincoln-MKZ-Testfahrzeug erforderte 434 Zeilen Python-Code; Pylot selbst umfasst etwa 28.000 Zeilen Python.
  • Das zugrunde liegende Datenflusssystem soll ROS bei der Kommunikationslatenz um 30 % übertreffen, und Pylot wird als beste Einreichung im HD-Map-Track der CARLA Autonomous Driving Challenge beschrieben.

Einschränkungen

  • Ansätze des bestärkenden Lernens für das Fahren werden noch nicht unterstützt; eine Schnittstelle zu OpenAI Gym wird als künftige Arbeit genannt.
  • Der End-to-End-Vergleich der Planer verwendet Ground-Truth-Wahrnehmung statt der Wahrnehmungsmodelle und nur ein Notfallszenario.
  • Die Studien zur zeitgerechten Genauigkeit verwenden perfekte Wahrnehmungskomponenten mit emulierten Laufzeiten, nicht die Laufzeiten realer Modelle im Regelkreis.
  • Der Einsatz im realen Fahrzeug wird als Portierung mit Standardmodellen beschrieben, ohne berichtete Fahrmetriken auf dem echten Auto.

Wirkung auf das Fachgebiet

Die Arbeit war Finalistin für den IEEE ICRA 2021 Best Paper Award on Unmanned Aerial Vehicles und hat 107 Zitierungen. Pylot ist als Open-Source-Code veröffentlicht, mit Referenz- und Ground-Truth-Implementierungen der Komponenten sowie einer Suite NHTSA-basierter Testszenarien für CARLA.

Zusammenfassung

Wir stellen Pylot vor, eine Plattform für die Forschung und Entwicklung autonomer Fahrzeuge (AV), die mit dem Ziel gebaut wurde, Forschenden zu ermöglichen, die Auswirkungen der Latenz und Genauigkeit ihrer Modelle und Algorithmen auf das End-to-End-Fahrverhalten eines AV zu untersuchen. Erreicht wird dies durch eine modulare Struktur, die unser leistungsfähiges Datenflusssystem ermöglicht; es stellt die Komponenten der AV-Software-Pipeline (Objektdetektoren, Bewegungsplaner usw.) als Datenflussgraphen von Operatoren dar, die über Datenströme mit Zeitstempel-Nachrichten kommunizieren. Pylot lässt sich ohne Weiteres an verbreitete AV-Simulatoren wie CARLA anbinden und mit minimalen Codeänderungen leicht auf reale Fahrzeuge bringen. Um den Aufwand zu verringern, eine ganze Pipeline zu entwickeln, nur um eine einzelne Komponente zu evaluieren, stellt Pylot mehrere Referenzimplementierungen nach dem Stand der Technik für die verschiedenen Komponenten einer AV-Pipeline bereit. Mit diesen Referenzimplementierungen kann eine Pylot-basierte AV-Pipeline ein reales Fahrzeug fahren und erzielt eine hohe Punktzahl in der CARLA Autonomous Driving Challenge. Außerdem stellen wir mehrere durch Pylot ermöglichte Fallstudien vor, darunter Belege für den Bedarf an kontextabhängigen Komponenten und an einer Zeitzuteilung pro Komponente. Pylot ist quelloffen, der Code ist unter https://github.com/erdos-project/pylot verfügbar.

Links

  • arXiv 2104.07830: https://arxiv.org/abs/2104.07830
  • DOI 10.1109/ICRA48506.2021.9561747: https://doi.org/10.1109/ICRA48506.2021.9561747
  • PDF: https://arxiv.org/pdf/2104.07830v1
  • Code: https://github.com/erdos-project/pylot

Diese Website benötigt JavaScript. Bitte aktivieren Sie JavaScript, um unsere Open-Source-Robotikprojekte zu erkunden.