Willkommen zur Formula-Student-Blogreihe!
Diese Blogreihe ist für alle, die schon immer einen Blick hinter die Kulissen eines selbstständig organisierten studentischen Projekts werfen wollten, bei dem ein Rennfahrzeug im sechsstelligen Bereich ohne jegliche Beaufsichtigung gebaut wird. Und dieses Fahrzeug auch noch autonom auf einer Rennstrecke mit 65km/h navigiert!
Diese Blogreihe rund um die Formula Student Competition 2018 mit municHMotorsport besteht aus drei Teilen:
Inhalt
Das Formula Student Event ist einer der weltweit größten interdisziplinären studentischen Wettbewerbe, bei dem Teams aus der ganzen Welt mitmachen. Das Ziel ist es, ein Gesamtpaket aus durchdachter Konstruktion, Performance, aber auch einer positiven finanziellen Planung abzuliefern.
Der angesehenste Wettbewerb ist die Formula Student Germany, mit einer Teilnahme von 117 Teams bestehend aus 3650 Studierenden im letzten Jahr. Seit 2017 ist der Wettbewerb in drei Kategorien aufgeteilt. Studierende können einen Verbrenner, ein elektrisches oder ein autonomes Fahrzeug bauen, die jeweils strikte Reglements einhalten müssen, um die Sicherheit des Rennwagens und des Fahrers zu gewährleisten. Vom wochenlangen Event nimmt das sogenannte ‘Scrutineering’, also die technische Abnahme, bis zu vier Tage ein und wird von 250 Sachverständigen durchgeführt.
Nach dem bestandenen Scrutineering darf das Auto an verschiedenen statischen und dynamischen Disziplinen teilnehmen, um möglichst viele Punkte (bis zu 1000) zu sammeln. Die Hauptdisziplin ist das Engineering Design, das 325 Punkte bringt. Dabei wird das Konzept des Autos von Judges aus der Industrie in Frage gestellt. Die Bauteil- oder Subsystemverantwortlichen müssen ihre getroffenen Entscheidungen anhand von Daten und Ausarbeitungen belegen können.
Dadurch wird überprüft, ob eine ingenieurstechnische Herangehensweise eingehalten oder irgendwo gepfuscht wurde. Für den autonomen Wettbewerb gibt es zusätzliche Judges, die sich nur für den autonomen Software Stack interessieren - von der Sensor-Pipeline bis zu den Simulationsverfahren.
Diese drei dynamischen Disziplinen muss das Fahrzeug auf der Strecke durchführen:
Abbildung 1. Beschleunigungsrennen Piktogramm
Abbildung 2. Skid-Pad Piktogramm
Abbildung 3. Trackdrive Piktogramm
municHMotorsport ist ein 2005 gegründeter gemeinnütziger Verein der Hochschule München mit der Absicht, Studierenden eine praxisnahe Ausbildung in großen Projekten zu ermöglichen. Das Ziel des Vereins ist die Forschung an einem weltweit anerkannten Wettbewerb zu fördern und eine Chance zu bieten, das erlernte Wissen umzusetzen. Dafür bauen die Studierenden jedes Jahr ein Fahrzeug von Grund auf - angefangen mit dem Monocoque aus Kohlefaser bis zur Bordelektronik, die im Lenkrad verbaut ist.
Im Jahr 2018 sind wir in allen drei Kategorien angetreten und haben einen Verberenner, ein elektrisches und auch ein autonomes Fahrzeug gebaut.
iteratec betreibt seit mehreren Jahren ein Studentenlabor für Machine Learning als Forschungs- und Ausbildungseinheit. Studierende verschiedener Disziplinen wie Mathematik, Physik und Informatik können hier neue Forschungsansätze verproben, in Projekten Erfahrungen im Umgang mit aktuellen Libraries und Technologien sammeln oder Proof of Concepts und Prototypen für Kunden aus Wirtschaft und Forschung erstellen.
Bei einem der Projekte unterstützen drei Studenten von iteratec seit 2017 das Team von municHMotorsport darin, ein autonomes Rennfahrzeug zu entwickeln (siehe Abbildung 4).
Dabei wird das gesammelte Wissen in den Bereichen von Sensor Fusion, Clustering, Computer Vision, Embedded Systeme am Beispiel der Jetson TX2, Projektmanagement und Teamwork akkumuliert und destilliert zurück ins Studentenlabor in Form von Vorträgen und Präsentationen gebracht.
Wie baut man ein autonomes Auto? Das ist eine Frage, die man sich nicht unbedingt tagtäglich stellt. Wir wollen deshalb einen kleinen Einblick geben, um den Umfang dieses Projekts zu skizzieren.
Erfahrungen
Noch bevor man in einem Projekt von Requirements reden kann, muss man sich zunächst das Ziel bewusst machen. Unser Ziel im September 2017 war die letzjährige und leider weniger erfolgreiche Season hinter uns zu lassen und eine stabile Basis für die Zukunft vorzubereiten, was die Teilnahme an allen Disziplinen miteinschloss.
Wir wollten unsere Stärken zu dem Zeitpunkt, soweit es geht, ausspielen und uns auf die optischen umgebungserkennenden Sensoren fokussieren, da wir hier Referenzwerte hatten und ungefähr wussten, was machbar ist.
Die erste Entscheidung, die wir getroffen haben, war es, explizit kein LIDAR (ein laserbasierter Umgebungssensor) zu benutzen, da wir einfach nicht die nötige Kernkompetenz dafür im Team hatten. Die Hochschule München hat zum damaligen Zeitpunkt erst begonnen, in ihren Laboren in diese Richtung zu arbeiten und verfügte daher noch über keine Erfahrungen in diesem Bereich.
Mit der Stereolabs ZED Tiefenkamera haben wir in der letzten Season Taktraten von 10-15 FPS erreicht, jedoch mit vielen False-Positives (Objekte die fälschlicherweise als Pylonen erkennt werden, siehe Abbildung 6). Diese entstanden durch die farbbasierte Erkennung, da wir das Bild in HSV kodiert aufteilten und dann nach den jeweils gelben und blauen Anteilen filterten. Das führte bei bereits schwach schwankenden Lichtbedingungen zu Problemen, da die Filter nicht adaptiv waren, sondern per Hand für Wetterverändernungen angepasst werden mussten, um die bestmöglichste Erkennung zu garantieren. Bei starken Lichtveränderungen funktionierte es einfach nicht (siehe Abbildung 7).
Abbildung 6: Ein fälschlicherweise erkannter Schuh als blaue Pylone
Deshalb fokussierten wir uns auf eine monokulare Kamera und die Erkennung der Objekte durch neuronale Netze, da wir im Bereich Machine Learning stärker aufgestellt waren als letztes Jahr und bereits Erfahrung gesammelt hatten.
Als Rechenplattform haben wir die NVIDIA Jetson TX1 mit dem Auvidea Board J120 benutzt, da es im Jahr 2016 die erste zugängliche Embedded-Plattform mit einer GPU war.
Es gab drei grundlegende Entscheidungen zu treffen:
Und die wichtigste Entscheidung: Wie verknüpfen wir diese Systeme ohne bestehende Softwareblöcke?
Um unser Ziel für die Season zu erreichen, haben wir unsere Kernwerte, die uns durch jede Entscheidung geleitet haben, folgendermaßen definiert:
Wir haben uns auch explizit gegen Eigenschaften entschieden:
Beim Designjudging aus der vorherigen Season kam die fehlende Hardware-Redundanz auf, da im Automotive-Bereich oft mehrere Sensoren und Recheneinheiten die gleiche Aufgabe übernehmen, um ausfallsicher zu sein. Deshalb haben wir angestrebt, dieses Jahr so viele Komponenten wie möglich zu duplizieren.
Nun konnten wir endlich anfangen, Requirements aufzustellen. Zunächst haben wir unsere Recheneinheit festgelegt, um eine ungefähre Vorstellung zu haben, was unsere Hardware leisten kann.
Da wir zum damaligen Zeitpunkt noch nicht wussten, welche Schnittstellen wir brauchen, haben wir die aktuell bekannten genommen und versucht, die typischen Interfaces wie USB 3.0 zu priorisieren, damit die Sensorauswahl so breit wie möglich aufgestellt ist.
Da wir letztes Jahr mit der Jetson TX1 gearbeitet haben, haben wir einen Vergleich mit dessen Neuauflage aufgestellt - der TX2. Wir haben nach viel Recherchearbeit nur dieses Modell als echte Wahl gehabt, da das Preis-Arbeit-Leistungs-Verhältnis unschlagbar war.
Die erste Option war die NVIDIA Drive PX2 mit 250W Verbrauch, was einer sehr hochwertigen Grafikkarte entspricht und die Rechenleistung aufbringt, um ein Tesla Model S/X autonom zu betreiben. Da unsere Aufgabe, durch einen Parkour von Hütchen zu navigieren, wesentlich einfacher ist, haben wir uns dagegen entschieden.
Die zweite Alternative wäre eine FPGA der Firma Xilinx, die eine schnelle Verarbeitung von Bilddaten mit extrem geringen Stromverbrauch ermöglicht. Leider hatten wir da keinerlei Erfahrungswerte und keinen VHDL-Experten (Very High Speed Integrated Circuit Hardware Description Language), der den Arbeitsaufwand abschätzen konnte. Die restlichen Algorithmen, wie SLAM und Trajektorienplanung müssten dann auch auf den Mikrokontroller vom Auto implementiert werden, ohne den Vorteil von General Purpose Processors (übliche programmierbare Prozessoren) zu nutzen.
Somit blieb uns lediglich der Nachfolger, die Jetson TX2, übrig. Die Vergleichskriterien waren übliche Embedded Specs und der Support von:
| # | Name | Jetson TX1 | Jetson TX2 |
|---|---|---|---|
| 1 | CAN Bus | ||
| 2 | Ubuntu 16.04 | ||
| 3 | ROS Support | ||
| 4 | RAM | 4 GB à 1600Hz with 64Bit DDR4 |
8 GB à 1833Hz with 128Bit DDR4 |
| 5 | CPU | Quad-Core ARM à 1.74GHz |
Quad-Core ARM à 2.0 GHz + NVIDIA Denver Dual-Core à 2.0 GHz |
| 6 | GPU | Maxwell, 256 cores | Pascal, 256 cores |
| 7 | Flash Storage | 12 GB à 200MHz | 32 GB à 200MHz |
| 8 | Wifi | IEEE 802.11ac, single-band | IEEE 802.11a/b/g/n/ac, dual-band |
| 9 | Power (Min/Max-P) | 6.5W - 15W | 7.5W - 15W |
| 10 | Power Input | 5.5V - 19.6V | 5.5V - 19.6V |
Da die TX2 in jeder Hinsicht eine Verbesserung war, haben wir uns dafür entschieden, diese Platform als Hauptrecheneinheit für unsereren Software Stack zu benutzen.
Als schöner Nebeneffekt ergab sich auch die Möglichkeit, die TX2 wegen des geringen Verbrauchs mehrfach einzubauen - falls nötig.
Nachdem wir nun die NVIDIA Jetson TX2 als Recheneinheit genutzt haben, mussten wir uns überlegen, welche Software und Sensorik wir brauchen, um unser Fahrzeug auf der Strecke zu lokalisieren und gleichzeitig eine Karte davon zu erstellen.
Dafür haben wir uns 7 Konzepte überlegt und diese in 13 Kriterien eingeteilt, um den morphologischen Kasten einsetzen zu können.
Da die gründliche Analyse deutlich den Rahmen von einem schon bereits zu langen Blogeintrag sprengen würde, sind hier die Kriterien und die Konzepte nur kurz aufgelistet. Zu jedem Kriterium wird eine Antwort geschrieben und zusammen im Team die jeweilige relative Gewichtung ausgehandelt.
Unsere Kriterien:
(0,...,5) (Faktor: -2)(true/false) (Faktor: 2)(true/false) (Faktor: 5)(0,...,3) (Faktor: -3)(-5,...,5) (Faktor: 5)(true/false) (Faktor: 5)(0,...,5) (Faktor: 3)(true/false) (Faktor: -2)(0,..,5) (Faktor: -5)(true/false) (Faktor: 2)(0,...,5) (Faktor: 3)(0,..,2) (Faktor: 2)(true/false) (Faktor: 5)Unsere Konzepte, stark zusammengefasst:
| Nr | Kamera | Klassifizierung | Distanzschätzung | Bewertung |
|---|---|---|---|---|
| 1 | Mono | Darknet | IP | -0.5 |
| 2 | Stereo | Darknet | PC | -25 |
| 3 | Stereo | Haar Cascades | PC | -7 |
| 4 | Mono + Stereo | Darknet + PC | IP + PC | 33 |
| 5 | Mono | Darknet | ORB-SLAM2 | 11 |
| 6 | 2 x Mono | 2 x Darknet | 2 x IP | 16 |
| 7 | 2 x Mono | Darknet | ORB-SLAM2 | 46 |
Das Problem bei der Auswahl von Konzepten ist es, dass man abschätzen muss, wie gut manche Softwarekomponenten (in unserem Fall ORB-SLAM2 oder g2o) funktionieren werden, bevor wir genügend Zeit investiert haben, um sie ausführlich zu testen.
Wir haben zwar Konzept #7 am höchsten mit 47 Punkten bewertet und ausgewählt, wurden aber von der Performance von ORBSLAM2 enttäuscht, sodass wir auf das drittbeste Konzept #6 umsteigen mussten. Wir hatten uns zu diesem Zeitpunkt schon zu sehr auf Monokameras spezialisiert und bereits die Sensorik-Requirementsanalyse duchgeführt. Daher kamen Stereokameras nicht mehr in Frage. Glücklicherweise hatten wir damit bereits gerechnet und waren nicht am Boden zerstört, als unsere rigorose Planung nicht perfekt aufging.
Mit mehr Zeit und Erfahrung für eine gründlichere Analyse, könnte man sicherlich eine besser fundierte Auswahl treffen.
Ein Problem, das wir bei der Definition dieser Kriterien nicht bedacht hatten, war die starke Kopplung des Mapping-Teils und der Distanzschätzung in den SLAM-Algorithmen.
Wir dachten, dass wir die Distanzschätzung von Objekten als einzelne Funktionalität benutzen und den Rest außen vor lassen könnten. Das war ein grober Fehler, da die Distanzschätzung erstmal nichts mit SLAM zu tun hat, sondern völlig unabhängig davon funktionieren muss. Manche SLAM-Algorithmen können zwar auch mit 2D-Bildern zurechtkommen, aber der sogenannte “Landmark Extraction”-Schritt läuft eigenständig. Er muss dafür sorgen, dass die erkannten Objekte, in eine vergleichbare Form gebracht werden und so mit den Landmarks in der Karte abgeglichen werden können.
In unserem selbst entwickelten SLAM-Algorithmus ist der Unterschied durch ein GMM sehr leicht zu erkennen:
Das türkise Cluster links unten definiert ein Landmark, deren wahrscheinlichste Position irgendwo bei (0.9, 0,9) liegt. Die Ellipsen repräsentieren die Kovarianzen, oder sehr umgangssprachlich die “Wahrscheinlichkeit”, wo sich die wirkliche Position des Objekts befindet. Die Beobachtung x4 hat dagegen keine Wahrscheinlichkeit, sondern nur eine Position (1.5, 0.5).
Eine Ambiguität wäre die Beobachtung x2, da sie sowohl zu dem violetten als auch zu dem gelben Cluster zugeordnet werden kann.
Damit sind wir fertig mit der Software-Requirementsanalyse und können unsere Sensorik genauer spezifizieren.
Bei der Abnahme des letzjährigen E-Autos waren bereits folgende Sensoren verbaut:
Wir haben beschlossen, diese intrinsischen Sensoren auf die Probe zu stellen, da sie üblicherweise in dem Wettbewerb von der ein oder anderen Firma in jedem Auto verbaut werden. Für den Fall, dass die Sensoren doch nicht genau genug wären, hatten wir uns bereits im Vorhinein Gedanken gemacht, wie wir die Daten replizieren und fusionieren könnten (Raddrehzahl für Geschwindgkeit, Lenkwinkel für Yaw,…).
Die Erfahrungen aus dem letztem Jahr haben uns gezeigt, dass ein DGPS-System nicht immer verlässlich ist und mit geringer Taktrate Daten liefert. Es kommt stark auf das Wetter, die Satellitenpositon und andere Umweltstörfaktoren an, wie gut der Sensor funktioniert. Ganz abgesehen davon handelt es sich um ein 25x7x3cm großes Modul, das nicht einfach in einem Auto unterzubringen ist. Da wir ein minimales Setup fahren wollten, haben wir diesen Sensor lediglich als nachträgliche Verifikationsmethode genommen und ihn per Hand benutzt (siehe Abbildung 9).
Damit kommen wir zur wichtigsten Enscheidung - der Umgebungssensorik.
Zunächst mussten wir unsere Mindesttaktrate bestimmen. Dafür haben wir die Formula Student Rules benutzt, um die Rahmenbedingungen festzulegen. Dieser Teil der Pipeline ist üblicherweise das größte Bottleneck für die Gesamtperformance. Deshalb mussten wir darauf achten, genug Spiel zu lassen, falls Berechnungen und Annahmen nicht ganz aufgehen.
Wir konnten maximal 120km/h fahren mit Pylonen im Maximalabstand von 5m und Minimalabstand von 1m (Erfahrungswert, da kein minimaler Abstand angegeben ist). Um eine geschätzte Position der Pylonen zu erhalten, mussten wir sie mindestens zwei Mal im kürzesten Abstand sehen - das heißt zwei Mal in 1m. Bei 120km/h, oder 33.33m/s braucht man für einen Meter 0.03s. Daraus ergab sich die Taktrate von 33fps.
Realistisch gesehen fährt man aber durchschnittlich 70km/h, da die Strecke kurvenreich ist, was zu einer Taktrate von 19.4fps führte. Deshalb bewegten wir uns mit Puffer im Bereich zwischen 20-30fps, was die minimalen Anforderungen für die Objekterkennung angeht. Je öfter wir die Pylonen sehen, umso besser wird die geschätzte Positon.
Aus dieser Rechnung ergab sich auch die minimale Scharfstelldistanz, die mindestens 1m betragen sollte, da wir sonst gar keine Chance gehabt hätten, die Objekte trotz ausreichender Taktrate zu sehen. Leider spielt aber noch ein anderer Faktor eine Rolle - die Zeit, die das Auto braucht, um auf die neue Umgebung zu reagieren und entsprechend zu lenken. Diese Zeit ist der gesamte Regelweg vom Eingang des Bildes bis die Aktorik das Lenkrad in die gewünschte Position bringt und konnte zum aktuellen Zeitpunkt nur sehr schwer abgeschätzt werden.
Man kann dennoch argumentieren, dass man die Streckenform besser abschätzen kann, je mehr Pylonen man gleichzeitig sieht. Unsere Mindestanforderung war es, zwei Pylonen der gleichen Farbe zu sehen, um eine Kurve zu erkennen, ohne den vorherigen Zustand zu speichern (bereits gesehene Pylonen, Positionsveränderung der aktuellen Pylonen relativ zum Fahrzeug). Aus der Distanz von der Kamera zur Nase von 1.55m und dem 5m Maximalabstand ergab sich die Scharfstelldistanz von 6.55m.
Der letzte Punkt, den wir hier aber nicht behandeln, war die Auflösung, die mindestens 1280x1024 betragen musste, da 23x23x32cm Pylonen in 10m Entfernung 1cm² groß sind und für viele Objekterkennungsalgorithmen Schwierigkeiten darstellen. Mit einem Objektiv, der Sensorgröße und der Auflösung kann man dieses Requirement feiner festlegen.
Fassen wir zusammen:
20fps zu liefern1.55m bis 6.55m scharfstellbar seinZusätzliche Faktoren:
Wir haben uns alle Kameras der Firmen FLIR, BASLER, Allied Vision und E-CON Systems nach groben Kriterien gefiltert und haben uns dann für für 11 Kameras entschieden. Die Analyse mit dem morphologischen Kasten brachte uns auf die FLIR Blackfly S. Da sie leider vom Hersteller in Amerika nur auf Anfrage produziert wird, haben wir mehrere Monate gewartet bis die Lieferung sich auf voraussichtlich Mitte Mai verschoben hat. Deshalb mussten wir auf die praktisch identische Kamera acA1300-200uc von Basler ausweichen, die wir glücklicherweise zeitlich gesponsert bekommen haben.
Das gleiche Prozedere sollte auch für das Objektiv passieren, aber da wir im Sponsoring bereits ein auf den ersten Blick sehr passendes Objektiv mitgeliefert bekommen haben, ging dies leider unter. Wir werden erst viel später bemerken, wie teuer uns diese Entscheidung zu stehen kommen wird.
Die wichtigen Faktoren nachdem das Objektiv ausgewählt werden sollte:
Damit sind wir mit unserer Auswahl der Hardware fertig. Nach der Requirementsanalyse der Software haben wir jeweils zwei vollständig redundante Umgebungsmodule verbaut, also zwei unabhängige Kameras und jeweils zwei Recheneinheiten.
Damit haben wir das Gesamtkonzept vom Fahrzeug für die Software und dessen Abhängigkeiten definiert und konnten uns an die Aufgabenaufteilung machen, zum Beispiel:
… und viele mehr. Die nächsten Schritte waren die Definitionen von Arbeitsblöcken, die jeweils in kleinere Arbeitspakete mit Zeitrahmen aufgeteilt werden. Diese können Personen zugewiesen werden und deren Fortschritt wird in wöchentlichen Treffen besprochen, um eine potenziell neue Priorisierungen zu schaffen.
Wir haben vom Augsburger Team Starkstrom gehört, dass sie FPGAs benutzen, um Objekte mit Hough Transform zu erkennen. Damit schaffen sie mehr als 30 FPS.
Wir brauchen ein Kühlsystem für die Jetsons, wenn sie unter Volllast mehrere Stunden lang unter der prallen Sonne steht. Die Jetsonbox hatte nur Öffnungen für die Kabel und war tief im Inneren des Autos verbaut, wo sich die Hitze staute. Das Problem hat sich gezeigt, als sich die Jetson plötzlich neu gestartet hat.
Wenn die Distanzschätzung auf intrinsischen Parametern wie der Sensorgröße basiert, sollte man sich nicht auf das Datasheet der Kamera verlassen, sondern direkt das vom Sensor lesen. Selbst die zweite Nachkommastelle im µm Bereich hilft, Fehler zu beseitigen.
Die Objektiventscheidung muss gründlicher und in Kooperation mit der Kameraentscheidung durchgeführt werden. Man braucht mindestens einen horizontalen Öffnungswinkel von 90°, um Pylonen in Kurven mit einer Distanz von 6-10m zu erkennen.
Es kommt eine neue Embedded-Recheneinheit von NVIDIA raus - die Jetson AGX Xavier. Diese ist deutlich mächtiger, verbraucht aber nur maximal 30W und kommt mit einem eigenem Converterboard. Das entkoppelt uns von der Abhängigkeit von Auvidea und sie kommt bereits mit einem eigenem Housing!
Da nun die Basis für die Monokularkamera langsam aufgebaut wurde, können wir uns auch nach anderen Themen umschauen, zu denen wir Fachwissen aufbauen wollen, um wissenschaftliche Vergleiche aufzusetzen. Im Fokus stehen dabei natürlich Stereokameras und LIDARs.
Im nächsten Teil der Blogserie widmen wir uns der Einbindung des neuronalen Netzes Darknet YOLO in die NVidia Jetson Architektur sowie dem Training und den Schritten, die nötig waren, um so ein Modell einzubinden und iterativ zu verbessern.
Was bedeutet Machine Learning und wie kann Ihr Unternehmen vom Einsatz profitieren? Erfahren Sie, wie wir Sie beim Thema Machine Learning unterstützen können: