Autonomes Fahren ist eines der wichtigsten Zukunftsthemen. Auch die Technische Universität München ist mit einer selbst entwickelten Künstlichen Intelligenz (KI) in diesem Bereich aktiv und hat sich 2018 im Wettrennen für autonome Fahrzeuge "Roborace" den ersten Platz gesichert. Projektmitarbeiter Leonhard Hermansdorfer spricht im Interview über die Herausforderungen, Deep Learning und ehtisch korrekte Entscheidungen von Maschinen.

Dieser Beitrag ist zuerst in eMobilJournal 01/2019 erschienen.

Sieben Nachwuchswissenschaftler der Technischen Universität München (TUM) haben eine Software für autonom fahrende Fahrzeuge entwickelt. Mit der Künstlichen Intelligenz (KI) sicherten sich die Forscher im Mai 2018 den ersten Platz beim Wettrennen für autonome Fahrzeuge „Roborace“ in Berlin. Dabei traten ein menschlicher Fahrer und die Künstliche Intelligenz der TUM und der Universität Pisa gegeneinander an. Mit der kumulierten Bestzeit von Mensch und Maschine fuhren die Münchner den Sieg ein. Welche Erkenntnisse lassen sich daraus für die Autos der Zukunft gewinnen? Leonhard Hermansdorfer vom Lehrstuhl für Fahrzeugtechnik der TUM ist wissenschaftlicher Mitarbeiter im Projekt und gibt im eMobilJournal-Interview spannende Einblicke in das Themenfeld „Autonomes Fahren“.

Herr Hermansdorfer, Glückwunsch zum ers­ten Platz beim Roborace. Wie optimistisch waren Sie und Ihre Kollegen, dass es klap­pen könnte?

Vielen Dank. Das ganze Team stand von Anfang an unter großem Druck, da das Projekt bei uns am Lehr­stuhl erst knapp ein Jahr vor dem Berlin-Event ins Leben gerufen wurde. Hinzu kommt, dass das Projekt und das gesetzte Ziel viele Unbekannte mit sich brachte. Wir konnten weder auf bisherige Erfahrungswerte, noch auf wissenschaftliche Arbeiten genau auf diesem Gebiet zurückgreifen. Untersuchungen zum automatisierten Fahren am fahrdynamischen Limit für den Einsatz in einem Rennszenario gibt es bisher sehr wenige und es war von Anfang an ein hohes Maß an Ideenreichtum notwendig.

Wir waren uns der Komplexität des Forschungsvorha­bens durchaus bewusst und dennoch optimistisch, dass wir bis zum Event in Berlin eine funktionierende Soft­ware entwickeln können. Die Entwicklungsphase war natürlich von Höhen und Tiefen geprägt, wir hatten jedoch nie das Gefühl, dass wir nicht rechtzeitig fertig werden würden und nicht teilnehmen könnten. Durch eine Vielzahl an Simulationen und einige Test-tage mit dem Realfahrzeug war uns bereits im Voraus klar, dass wir ein funktionierendes Software-Paket ent­wickelt hatten. Dennoch bestanden viele Unsicherhei­ten, die wir bis zum Rennwochenende in Berlin nicht hundertprozentig lösen konnten. Aus diesem Grund war selbst nach den erfolgreichen Tests noch lange nicht alles in trockenen Tüchern und die Anspannung groß, vor allem, weil es der erste Einsatz unserer Software vor so großem Publikum war.

Letztendlich können wir zufrieden feststellen, dass wir unser Minimalziel, eine funktionierende Basis-Soft­ware zu entwickeln, weit übertroffen haben und unse­rem Maximalziel, als Schnellster aller vier Teilnehmer, das heißt auch schneller als beide menschliche Fahrer abzuschließen, sehr nahegekommen sind.

Das Roborace-Team der TUM (v.l.): Felix Nobis, Leonhard Hermansdorfer, Alexander Wischnewski, Johannes Betz, Tim Stahl, Alexander Heilmeier (Quelle: Roborace)

Können Sie kurz beschreiben, wie Ihre Soft­ware funktioniert und wie lange die Ent­wicklung gedauert hat?

Die Struktur der Software baut auf den drei Säulen Per­ception, Planning und Control auf. Die Software befin­det sich in ständiger Weiterentwicklung, wobei ich hier auf die wichtigsten Funktionen der jeweiligen Module eingehen will – diese sind bereits umgesetzt, in Entwick­lung oder geplant. Das Perception-Modul stellt die Schnittstelle zur Um­welt dar. In diesem werden die Signale, die die Senso­ren erfassen, aufbereitet und zur Weiterverarbeitung zur Verfügung gestellt. Zum Einsatz kommt eine Vielzahl an unterschiedlichen Senso­ren, darunter Kamera, Lidar, Radar, Ultraschall, dGPS und Beschleunigungssensoren.

Eine weitere Aufgabe des Perception-Moduls ist es, eine Karte der Umgebung zu erstellen und sich während der Fahrt mithilfe dieser Karte im Raum zu lokalisieren. Das geschieht unter Ein­bezug der gesamten zur Verfügung stehenden Sensorik. Außerdem ist das Perception-Modul dafür zuständig, statische und dynamische Hindernisse (andere Renn­fahrzeuge) zu detektieren, und im Falle von dynami­schen Objekten deren Bewegung vorherzusagen. Zusammenfassend beantwortet das Perception-Modul für uns die Frage, wo wir uns auf der Strecke befinden und was im Umfeld unseres Fahrzeugs passiert bzw. wahrscheinlich passieren wird.

Das Planning-Modul greift die Informationen des Perception-Moduls unmittelbar auf. In diesem werden auf Grundlage der vorliegenden Informationen über die aktuelle sowie die vorhergesagte zukünftige Situation Aktionen geplant, die unser Fahrzeug durchführen soll. Die Auswahl der Aktionen geschieht immer im Hinblick auf die hinterlegte Rennstrategie mit dem Hauptziel, das Rennen

Das Planning-Modul greift die Informationen des Perception-Moduls unmittelbar auf. In diesem werden auf Grundlage der vorliegenden Informationen über die aktuelle sowie die vorhergesagte zukünftige Situation Aktionen geplant, die unser Fahrzeug durchführen soll. Die Auswahl der Aktionen geschieht immer im Hinblick auf die hinterlegte Rennstrategie mit dem Hauptziel, das Rennen so schnell wie möglich zu beenden. In diesem Modul arbeiten wir mit verschiedenen Me­thoden der Künstlichen Intelligenz, um die Entschei­dungen anhand der zur Verfügung stehenden Daten und unter Berücksichtigung der gemachten Erfahrungen zu treffen. Das ist für uns ein wichtigter Schritt, da wir wäh­rend eines Rennens keinen Zu­griff auf das Fahrzeug haben.

Das bedeutet also, dass das Fahrzeug selbst die „Rennin­telligenz“ besitzen muss, um die richtigen Entscheidungen, sowohl kurz- als auch langfristig, zu treffen. Output des Moduls ist die Wunsch-Trajektorie, die das Fahrzeug im nächsten Zeitschritt fahren soll. Das Control-Modul ist als letzte Instanz dafür zu­ständig, die berechnete Aktion bzw. die Trajektorie des Planning-Moduls umzusetzen. Das bedeutet, die Akto­ren Lenkung, Elektromaschinen und mechanische Brem­sen so anzusteuern, dass das Fahrzeug die vorgegebene Aktion umsetzt, also beispielsweise der geplanten Ideal­linie folgt. Das beinhaltet auch, auf Störungen und Ab­weichungen vom geplanten Fahrweg zu reagieren und korrigierend einzugreifen.

Mit der Software-Entwicklung begonnen wurde erst im Dezember 2017, parallel dazu wurden seit Herbst 2017 weitere Teammitglieder angeworben. Das Team war erst im Laufe des Frühjahrs 2018 komplett. Die bis­herige Entwicklungsdauer kann also auf ca. ein halbes bis dreiviertel Jahr beziffert werden. Der in Berlin verwendete Software-Stand dient jetzt als Basis für alle weiteren Ent­wicklungen, die wir als Team und im Rahmen unserer je­weiligen Forschungsprojekte verfolgen werden.

Sie konnten Ihre Software vor einem ersten Testeinsatz in England nur an einem kleinen Modellauto erproben. Hat sich die Skalie­rung vor Ort auf den lebensgroßen Maßstab, das Rennauto DevBot, als Herausforderung gestaltet?

Die Software auf dem Dev-Bot zum Laufen zu bekommen, stellte kein großes Problem dar, da wir die Schnittstellen zwischen unserer Software und der Software von Roborace vollständig simulieren können.   Diese Schnittstellen haben wir auch auf unserem Mo­dellfahrzeug identisch gestaltet, um möglichst viele gleiche Software-Teile auf beiden Fahrzeugen nutzen zu können. Tatsächlich ist es so, dass ungefähr 90 Prozent des Codes, der auf dem DevBot läuft, ohne Änderungen auf das Modellfahrzeug übertragen werden können und umgekehrt. Das heißt, aus Sicht der Inbetriebnahme gibt es keinen großen Unterschied zwi­schen Modellauto und DevBot.

Große Unterschiede ergeben sich dann im Betrieb der Software auf dem DevBot und dem Modellfahrzeug. Das fängt bei den physikalischen Parame­tern wie Masse und Trägheiten an und hört bei der Anzahl und Art der zur Verfügung stehenden Sensoren auf. Auf dem DevBot bekommen wir durch die Vielzahl an verschiedenen Sensoren erheblich mehr Feedback als auf den kleinen Modellfahrzeugen, was uns ganz andere Möglichkeiten gibt.

Der enorme Vorteil der Modellfahr­zeuge ist, dass sie uns immer zur Ver­fügung stehen und dass wir mit sehr geringem finanziellen Aufwand da­rauf testen können. Außerdem können wir auch Algorithmen auf ihnen testen, die sich noch mitten in der Entwicklung befinden, ohne dabei ein großes Risiko eingehen zu müssen. Das ist auf dem gro­ßen Fahrzeug nicht möglich. Zusätzlich haben wir die Möglichkeit, mit vergleichs­weise geringem Aufwand mehrere Modellfahrzeuge aufzurüsten und diese dann am Lehrstuhl gegeneinander fahren zu lassen – sozusagen ein Mini-Roborace zu ver­anstalten. Das hilft uns in der Entwicklung natürlich enorm weiter, weil wir so den kompetitiven Charakter der Events simulieren können. Das kann mit den Dev-Bots nur mit sehr hohem Aufwand umgesetzt werden.

Das Rennfahrzeug DevBot mit Fahrer beim Formel-E-Event in Berlin (Quelle: Roborace)