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 ersten Platz beim Roborace. Wie optimistisch waren Sie und Ihre Kollegen, dass es klappen könnte?
Vielen Dank. Das ganze Team stand von Anfang an unter großem Druck, da das Projekt bei uns am Lehrstuhl 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 Forschungsvorhabens durchaus bewusst und dennoch optimistisch, dass wir bis zum Event in Berlin eine funktionierende Software 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 entwickelt hatten. Dennoch bestanden viele Unsicherheiten, 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-Software zu entwickeln, weit übertroffen haben und unserem 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 Software funktioniert und wie lange die Entwicklung gedauert hat?
Die Struktur der Software baut auf den drei Säulen Perception, Planning und Control auf. Die Software befindet sich in ständiger Weiterentwicklung, wobei ich hier auf die wichtigsten Funktionen der jeweiligen Module eingehen will – diese sind bereits umgesetzt, in Entwicklung oder geplant. Das Perception-Modul stellt die Schnittstelle zur Umwelt dar. In diesem werden die Signale, die die Sensoren erfassen, aufbereitet und zur Weiterverarbeitung zur Verfügung gestellt. Zum Einsatz kommt eine Vielzahl an unterschiedlichen Sensoren, 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 Einbezug der gesamten zur Verfügung stehenden Sensorik. Außerdem ist das Perception-Modul dafür zuständig, statische und dynamische Hindernisse (andere Rennfahrzeuge) zu detektieren, und im Falle von dynamischen 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 Methoden der Künstlichen Intelligenz, um die Entscheidungen 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ährend eines Rennens keinen Zugriff auf das Fahrzeug haben.
Das bedeutet also, dass das Fahrzeug selbst die „Rennintelligenz“ 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 zuständig, die berechnete Aktion bzw. die Trajektorie des Planning-Moduls umzusetzen. Das bedeutet, die Aktoren Lenkung, Elektromaschinen und mechanische Bremsen so anzusteuern, dass das Fahrzeug die vorgegebene Aktion umsetzt, also beispielsweise der geplanten Ideallinie folgt. Das beinhaltet auch, auf Störungen und Abweichungen 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 bisherige 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 Entwicklungen, die wir als Team und im Rahmen unserer jeweiligen Forschungsprojekte verfolgen werden.
Sie konnten Ihre Software vor einem ersten Testeinsatz in England nur an einem kleinen Modellauto erproben. Hat sich die Skalierung 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 Modellfahrzeug 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 zwischen 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 Parametern 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 Modellfahrzeuge ist, dass sie uns immer zur Verfügung stehen und dass wir mit sehr geringem finanziellen Aufwand darauf 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 vergleichsweise geringem Aufwand mehrere Modellfahrzeuge aufzurüsten und diese dann am Lehrstuhl gegeneinander fahren zu lassen – sozusagen ein Mini-Roborace zu veranstalten. 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)
Beim autonomen Fahren unterscheidet man sechs verschiedene Autonomiestufen. Von Stufe 0, bei der noch alles manuell gesteuert werden muss, bis Stufe 5 – sprich Vollautomatisierung. Die meisten derzeit verfügbaren Autos sind mit Technik der Stufe 1 ausgestattet, mehr Automatisierung in Serienfahrzeugen ist aktuell noch die Ausnahme. Was ist Ihrer Erfahrung nach die größte Herausforderung bei der Entwicklung von Techniken, die autonomes Fahren möglich machen?
Die größte Herausforderung bei der Vollautomatisierung von Fahrfunktionen ist die Verschiedenartigkeit der Szenarien, die im Straßenverkehr auftreten. Am deutlichsten wird das im Stadtverkehr, wo neben den anderen Fahrzeugen eine große Zahl anderer Verkehrsteilnehmer anwesend ist, beispielsweise Fußgänger und Radfahrer. Es existieren viele unterschiedliche Fahrbahnarten und -kreuzungen, es gibt Linksabbieger und Parkplatzsucher, die sich teilweise deutlich anders verhalten als „normal“ fahrende Fahrzeuge und vieles mehr. Die Umwelt des Fahrzeugs im Stadtverkehr ist sehr abwechslungsreich im Vergleich zu Fahrsituationen außerhalb von Städten.
Es gibt heute bereits viele Situationen, in denen sich ein Fahrzeug komplett selbstständig bewegen kann. Ein gutes Beispiel dafür ist das Fahren auf der Autobahn. Diese Umgebung ist strukturisiert im Vergleich zum abwechslungsreichen Stadtverkehr. Auf der Autobahn kann bis auf Ausnahmen viel besser eingeschränkt werden, was an möglichen Szenarien auftreten kann. Das bedeutet, die Wahrscheinlichkeit, dass etwas „Unerwartetes“ auftritt, ist deutlich geringer als im Stadtverkehr, was das automatisierte Fahren in dieser Umgebung erleichtert. Wenn die Rahmenbedingungen stimmen (Wetterbedingungen, Fahrbahnqualität, Fahrbahnmarkierungen, usw.), können schon heute auf der Autobahn große Distanzen mit automatisierten Fahrfunktionen zurückgelegt werden.
Außer Acht gelassen werden dann aber Situationen, die plötzlich auftreten und nicht dem „Erwarteten“ entsprechen. In solchen Fällen ist es schwierig, dass die Software die Situation richtig interpretiert und die richtigen Schlüsse daraus zieht, weshalb aktuell dann der Fahrer in die Pflicht genommen wird, der ständig eingriffsbereit am Steuer sein muss. Schlussendlich wird man sich damit abfinden müssen, dass die Software im selbstfahrenden Auto nahezu alle auftretenden Situationen im Straßenverkehr bewältigen kann, allerdings bei einem geringen Bruchteil an Situationen überfordert ist. Denkbar wäre dann, dass das Fahrzeug in so einer Situation einfach anhält und auf einen Befehl des Passagiers wartet. Nichtsdestotrotz wird das automatisierte Fahren die Sicherheit im Straßenverkehr erheblich steigern und zu einer Reduzierung von Personen- und Sachschäden führen.
Für die Streckenplanung und die Umfelderkennung verarbeitet Ihre Software in Sekundenbruchteilen Informationen aus GPS-Daten, Kamera, Lidar-System, Radar und Ultraschallsensoren. Wie viel „Deep Learning“ steckt in Ihrer Arbeit?
Aufgrund der Tatsache, dass erst die großen Fortschritte im Bereich der Künstlichen Intelligenz den Entwicklungsboom selbstfahrender Fahrzeuge in dem Umfang ermöglichen, wie wir ihn seit einigen Jahren sehen, liegt auf der Hand, dass auch wir sehr stark darauf aufbauen. Künstliche Intelligenz erlaubt es uns, Unmengen an Daten, die man mit einem konventionellen Algorithmus nur sehr schwer oder gar nicht erfassen kann, zu analysieren und zu verarbeiten, um daraus die richtigen Schlüsse zu ziehen.
In ihrer Frage erwähnen Sie konkret das sogenannte „Deep Learning“, was eine spezielle Klasse von Optimierungsmethoden künstlicher neuronaler Netze beschreibt. Dieses Verfahren eignet sich unter anderem gut zur Objekterkennung aus Bilddateien, weshalb es ein zentraler Bestandteil des Perception-Moduls ist. Grundsätzlich ist unser Forschungsziel, neben dem reinen Einsatz von Methoden der Künstlichen Intelligenz auch, die bisher bewährten „konventionellen“ Verfahren mit den auf Methoden der Künstlichen Intelligenz basierenden Ansätzen zu vergleichen. Momentan sind wir noch ganz am Anfang der Entwicklung, was den Einsatz Künstlicher Intelligenz in unserem Fahrzeug betrifft. Der Einsatz solcher Methoden wird sich später durch alle der drei bereits genannten Säulen der Software-Architektur ziehen und dort eine entscheidende Rolle spielen.
Das Perception-Modul wird überwiegend auf Methoden der Künstlichen Intelligenz basieren, vor allem zur Bildsegmentierung und Objekterkennung. Gleiches gilt für das Planning-Modul, sozusagen das „Gehirn“ des Fahrzeugs, das die Entscheidung trifft, welche Aktion jetzt ausgeführt werden soll. Vor allem das Planning-Modul muss die „Rennintelligenz“ widerspiegeln, die in einem konventionellen Rennen sowohl der Rennfahrer als auch dessen Renningenieure darstellen. Auch im Control-Modul, das hauptsächlich auf die etablierten Verfahren der Regelungstechnik zurückgreift, haben wir Ansätze aus der KI eingebettet. Damit erreichen wir, dass unsere Regelung ständig trainiert, dazulernt und sich selbst verbessert. Das führt dazu, dass das Fahrzeug mit jeder Runde ohne Zutun von außen besser und schneller über die Rennstrecke fahren können wird.
Angesichts der wachsenden Digitalisierung und Vernetzung von Fahrzeugen stellt sich beinahe zwangsläufig die Frage: Wie sicher kann autonomes Fahren sein? Stichwort Software-Manipulation...
Das Thema Sicherheit gegen Eingriffe von außen ist natürlich in der Serienentwicklung extrem wichtig, weil die potentielle Anzahl an betroffenen Fahrzeugen sehr groß ist, beispielsweise alle Fahrzeuge einer Modellreihe oder alle Fahrzeuge eines Herstellers. Für uns spielt dieses Thema im Moment eine geordnete Rolle. Sicherheit bei uns bedeutet, wie können wir Absichern, dass die Künstliche Intelligenz keine „falschen“ Entscheidungen trifft. Wir beschränken uns auf unser Fahrzeug und die Software-Funktionen, die darauf laufen. Das schließt das umfangreiche Gebiet der Security gegenüber Angriffen von außen bisher aus.
Solange wir nicht dazu „gezwungen“ sind, uns mit dem Thema intensiver zu beschäftigen, liegt der Fokus unserer Arbeit klar auf anderen Gebieten. Sollte es zukünftig im Rahmen eines Roborace-Events Challenges geben, die auf solche Security-Anwendungen abzielen, dann wäre das Thema der Software-Manipulation durch Dritte auch für uns hochrelevant. Ein Beispiel dafür wäre, das Fahrzeug der jeweils anderen Teams während der Fahrt zu hacken und die Software so zu manipulieren, dass das Fahrzeug langsamer fährt oder stehen bleibt. Solange solche Szenarien nicht der Fall sind, werden wir in dieses Gebiet nicht weiter als bisher einsteigen.
Letztendlich wird man – im Hinblick auf Straßenfahrzeuge – akzeptieren müssen, dass kein System vollkommen sicher gestaltbar ist. Es werden einzelne erfolgreiche Angriffe auf Fahrzeuge in Kauf genommen werden müssen – man wird sie nicht verhindern können. Wichtig ist, dass ein Massenangriff, zum Beispiel auf eine ganze Modellreihe eines Herstellers, unterbunden werden kann.
Fahrer im DevBot-Cockpit (Quelle: Roborace)
Künstliche Intelligenz kann bei Hindernissen aufgrund ihrer kurzen Reaktionszeit im Straßenverkehr das Autofahren sicherer machen. Wie geht Ihre Software mit „unsichtbaren“Gefahren wie Schnee, Schlaglöchern, Öl oder Glatteis um?
Das ist eine gute Frage, die uns vor allem im Rennsport sehr beschäftigt. Mit Schnee und Glatteis werden wir im jetzigen Rennformat vermutlich nicht konfrontiert werden. Öl und Schlaglöcher bzw. Bodenwellen können auf den aktuellen Formel-E-Rennstrecken aber durchaus vorkommen. Das gleiche gilt für eine nasse Fahrbahn aufgrund von Regen.
Die angesprochenen „unsichtbaren“ Gefahren haben alle gemeinsam, dass sie einen sprunghaften Abfall des Reibwertpotenzials zwischen Fahrbahn und Reifen zur Folge haben. Das bedeutet, dass die maximal übertragbaren Kräfte zwischen Reifen und Fahrbahn plötzlich niedriger ausfallen. Das hat zur Folge, dass beispielsweise der Bremsweg länger oder das Fahrzeug beim Lenken unkontrollierbar wird.
Im Rennsport ist das Reibwertpotenzial deshalb so entscheidend, weil es optimal ausgenutzt werden muss, um die beste Rundenzeit zu erzielen. Dadurch ist die „Reifenkraft-Reserve“, um auf einen Abfall des Reibwertpotenzials reagieren zu können, sehr gering. Das führt dazu, dass schon bei geringen Reibwertpotenzial-Schwankungen die maximal übertragbare Kraft überschritten werden kann und die Räder blockieren oder das Fahrzeug in Kurven ausbricht.
Für uns von großer Bedeutung ist es, das Potenzial bereits im Vorhinein bestmöglich zu ermitteln, da es sonst in der Regel zu spät ist, auf ein plötzlich niedrigeres Reibwertpotenzial zu reagieren, beispielsweise wenn sich das Fahrzeug schon im Bremsvorgang befindet. Dadurch, dass sich auf den Formel-E-Strecken die Streckenbegrenzung häufig direkt neben der Fahrbahn befindet, würde eine solche Situation meist mit einer Kollision enden und das Rennende für uns bedeuten.
Im normalen Straßenverkehr bewegt sich der Fahrer in der Regel weit unterhalb des maximal nutzbaren Reibwerts, das heißt diese Thematik ist für ihn weniger relevant. Wo es allerdings sehr relevant wird, sind die erwähnten Beispiele mit Öl, Eis, usw., da hier das Reibwertpotenzial plötzlich soweit abfällt, dass es auch den gewöhnlichen Fahrer betrifft. In solchen Situationen wäre die Prädiktion des Reibwertpotenzials, wie wir sie für unser Rennfahrzeug umsetzen wollen, von großem Nutzen für die Sicherheit. Denkbar für die Übertragbarkeit auf den Straßenverkehr wäre, das Reibwertpotenzial der Straße unabhängig vom Reifen zu quantifizieren. Diese Information könnte dann nämlich allen Verkehrsteilnehmern zur Verfügung gestellt werden.
Die gute Qualität der Informationen über den Fahrbahnzustand, die wir durch das häufige Überfahren desselben Abschnitts erreichen, kann im Straßenverkehr dadurch erlangt werden, dass hier viele Fahrzeuge hintereinander denselben Fahrbahnabschnitt überfahren. Der entscheidende Unterschied ist, dass sich die Fahrzeuge alle voneinander unterscheiden, was die reifenunabhängige Darstellung des Fahrbahnzustands erfordert. Die Straßenqualität im Voraus zu kennen, wäre ein großer Sicherheitsgewinn im Straßenverkehr.
Der DevBot, ein Rennfahrzeug mit Autonomiestufe 5, fuhr mit Ihrer Software in der zweiten Runde des Roborace 150 km/h schnell: ein Hochgeschwindigkeitsauto auf einer abgeriegelten und präparierten Strecke. Wie verwertbar sind die gewonnenen Erkenntnisse für einen durchschnittlichen Alltags-Pkw?
Es stimmt insofern, dass wir uns im Rennszenario fern vom alltäglichen Straßenverkehr bewegen, der ja den Fokus von automatisierten Fahrfunktionen darstellt. Wir werden beispielsweise nicht mit der Situation konfrontiert werden, einem plötzlich auf die Straße laufenden Kind ausweichen zu müssen. Ein großer Vorteil für unsere Entwicklung ist, dass die riesige Variantenvielfalt an möglichen Verkehrsszenarien, wie ich sie bereits skizziert habe, entfällt. Die Umgebung, in der wir uns durch den Renneinsatz bewegen, stellt allerdings eine Kondensation von wichtigen Teilaspekten des automatisierten Fahrens in extremer Ausprägung dar.
Allem voran steht das Fahren im fahrdynamischen Grenzbereich. Dieser tritt im Straßenverkehr dann auf, wenn extreme Fahrmanöver ausgeführt werden müssen, zum Beispiel bei einer Gefahrenbremsung oder einem Ausweichmanöver zur Unfallvermeidung. Diese Situationen treten zwar vergleichsweise selten auf, sind allerdings umso wichtiger für die Sicherheit. Beim Fahren auf der Rennstrecke befinden wir uns mit dem Fahrzeug im Optimalfall immer am fahrdynamischen Limit, was bedeutet, dass das ganze Fahrzeug und die darauf laufenden Algorithmen ständig mit einer „Gefahrensituation“ umgehen können müssen. Dass wir uns dabei künftig mit über 200 km/h bewegen, verschärft die Anforderungen an die Software zusätzlich.
Errolson Hugh, der Fahrer des TUM-Roborace-Teams (Quelle: Roborace)
Genau dadurch, dass wir diesen extremen Fahrzustand ständig haben, müssen wir in der Lage sein, unsere Software in solchen Situationen zuverlässig zu betreiben. Daraus resultiert eine große Chance, die Algorithmen ausführlich testen zu können. Insofern erhoffen wir uns dadurch umfassende Erkenntnisse, die wir in die Serienentwicklung einfließen lassen können. Durch die Rennsportumgebung kommen auch ganz neue Herausforderungen hinzu, die uns zwar Vorteile bieten, auf der anderen Seite aber eine deutlich straffere Entwicklung als in der Serie erfordern. Neben dem Stresstest für Komponenten und Algorithmen gewinnen wir sehr gut vergleichbare Messdaten, da wir nach jeder Runde die gleichen Fahrbahnabschnitte wieder und wieder überfahren. Außerdem haben wir sehr kurze Entwicklungszyklen während einer Saison, da zwischen den einzelnen Events nur wenige Wochen liegen.
Das heißt, dass der Entwurf von neuen Software-Funktionen, die Implementierung und der Test in schneller Abfolge passieren müssen, was uns einen schnellen Entwicklungsfortschritt erlaubt. Für uns als Universität ist die Zusammenarbeit mit Roborace außerdem ein riesiger Vorteil, da uns die Entwicklung, der Aufbau und der Betrieb der Fahrzeuge komplett abgenommen werden. Wir können uns vollständig auf die Entwicklung neuer Software für automatisiertes Fahren konzentrieren. Wäre dieser Rahmen nicht gegeben, wäre es für eine Universität unmöglich, solche Prototypen aufzubauen und ein solches Projekt finanziell zu stemmen. Neben dem bereits genannten Know-how-Gewinn lernen wir auch abseits der Rennstrecke viel über die Entwicklung von automatisierten Fahrfunktionen. Ein Beispiel ist unsere Hardware-in-the-Loop-Simulation, in der wir die gesamte Fahrzeugumgebung mit statischer und dynamischer Umwelt und die Fahrdynamik simulieren. Unsere Software läuft dabei auf den originalen Steuergeräten des DevBots.
Vor allem Technologiekonzerne und Software-Firmen – wie zum Beispiel Google und Apple – haben das Thema Künstliche Intelligenz für sich entdeckt und zeigen sich experimentierfreudig. Die klassischen Autohersteller scheinen sich da schwerer zu tun. Woran könnte das Ihrer Meinung nach liegen?
Der entscheidende Punkt ist meiner Meinung nach, dass dieses Thema für die IT-Konzerne zum alltäglichen Geschäft gehört. Der Know-how-Aufbau findet dort in viel größerem Umfang und viel schneller statt und startete vor allem viel früher als bei den Automobilherstellern. Dort war zu Beginn dieses Entwicklungsbooms rund um das automatisierte Fahren schlicht und ergreifend das nötige Know-how nicht oder nur begrenzt vorhanden. Gleiches gilt für die Fachleute und die internen Strukturen, die so umfangreiche Software-Projekte erst ermöglichen.
In der Automobilbranche war man viel mehr darauf bedacht, Schritt für Schritt immer umfassendere Fahrerassistenzfunktionen einzuführen, die dann letztendlich in einem selbstfahrenden Auto münden. Allerdings war dieser Entwicklungszyklus von den entsprechenden Fahrzeugmodell-Zyklen abhängig, das heißt, dass neue Funktionen mit neu auf den Markt kommenden Fahrzeugmodellen eingeführt wurden. Für die Entwicklung von automatisierten Fahrfunktionen ist dieses Vorgehen viel zu langsam und zu unflexibel. Die Weiterentwicklung der Software muss kontinuierlich erfolgen und die Fahrzeuge müssen ständig mit Updates versorgt werden. Für die Automobilhersteller heißt das, dass sie die Entwicklungsgeschwindigkeit enorm hochschrauben und die nötige Infrastruktur aufbauen mussten.
Ein wichtiger Aspekt, den es bei der ganzen Diskussion zu berücksichtigen gilt, ist die Tatsache, dass die IT-Unternehmen ja nicht daran interessiert sind, selbst Fahrzeuge herzustellen, sondern nur die Software dafür entwickeln wollen. Worauf sie eigentlich abzielen, ist die Unmenge an Daten, die beim Fahren mit autonomen Fahrzeugen (zwangsläufig) anfällt, um sie für die eigenen Dienste zu nutzen.
Die Lage ist allerdings bei weitem nicht so dramatisch, wie sie gerne dargestellt wird, wenn von der abgehängten oder rückständigen deutschen Automobilindustrie gesprochen wird. Alle Hersteller haben enorme Investitionen getätigt und strategisch wichtige Partnerschaften geschlossen, um auf dem Gebiet konkurrenzfähig mitspielen zu können. Alle Fahrzueghersteller und IT-Unternehmen bewegen sich ungefähr vergleichbarem Niveau mit unterschiedlich stark ausgeprägten Kernkompetenzen. Einzig Google sticht wirklich heraus und ist, was die Software-Entwicklung betrifft, vermutlich „am weitesten“. Die große Unbekannte ist Apple, von denen sehr wenig bekannt ist.
Es bleibt abzuwarten, welches System bzw. welche Systeme sich langfristig am Markt durchsetzen werden. Dass jeder Hersteller sein komplett eigenes System am Markt etablieren kann, ist allerdings sehr unwahrscheinlich.
Sollte sich das autonome Fahren immer mehr als Standard etablieren, brauchen wir auch international einen rechtlichen Rahmen dafür, wie sich das Fahrzeug in bestimmten Situationen verhalten soll. Wie bringt man einer Künstlichen Intelligenz bei, ethisch „korrekte“ Entscheidungen zu treffen?
Der erste Schritt ist, einen rechtlichen Rahmen für den Einsatz von automatisierten Fahrfunktionen zu schaffen, so wie das für den heutigen, manuellen Straßenverkehr seit Jahrzehnten der Fall ist. Die wichtigste notwendige Änderung ist vergleichsweise einfach zu benennen, nämlich, dass der Fahrer die Erlaubnis bekommen muss, nicht aufmerksam am Steuer zu sitzen und beispielsweise das Handy benutzen darf. Viel schwieriger wird das Thema, wenn es darum geht, Verantwortlichkeiten festzulegen. Das wirft unter anderem die Frage auf, wer für einen Unfall haftet, wenn der Fahrer die Fahraufgabe an das Fahrzeug übergeben hat und damit nicht für den Unfall verantwortlich ist.
Wenn es darum geht, dass Fahrzeuge „ethisch korrekte“ Entscheidungen treffen sollen, wird die Angelegenheit deutlich komplizierter. Soll der Gesetzgeber ähnlich der Straßenverkehrsordnung bestimmte Verhaltensweisen und Aktionen definieren und vorgeben? Dabei stellt sich schon alleine die Frage, was genau „ethisch korrekt“ bedeutet. Ein vor allem aus technischer Sicht nicht fassbarer Begriff, der auch von verschiedenen Menschen sehr unterschiedlich interpretiert werden kann. Für die Behandlung dieses wichtigen, aber schwierigen Themas wurde durch das Verkehrsministerium eine Ethikkommission unter der Leitung des ehemaligen Bundesverfassungsrichters Prof. Dr. Dr. Udo Di Fabio berufen. Diese Kommission beschäftigte sich ausführlich mit dem Thema des automatisierten Fahrens und erarbeitete Leitlinien für die Programmierung solcher Fahrsysteme, die 2017 in einem Abschlussbericht vorgelegt wurden.
Das schwierige Thema, dass unser Rennfahrzeug ethisch „korrekte“ Entscheidungen treffen können muss, können wir aktuell zum Glück vernachlässigen. In der abgeschlossenen Umgebung, in der wir uns derzeit bewegen, muss das Fahrzeug Entscheidungen treffen,die mit dem Reglement der Rennserie konform sind. Das ist auch vollkommen ausreichend, da sich zu keiner Zeit Menschen in Gefahr befinden.
In der Serienentwicklung von selbstfahrenden Fahrzeugen ist die Entwicklung noch weit davon entfernt, bei einem bevorstehenden Unfall eine „ethisch korrekte“ Entscheidung zu treffen. Im Falle einer unvermeidlichen Kollision wird zuerst versucht, mögliche Ausweichmanöver zu fahren. Ist das nicht mehr möglich, so wird das Fahrzeug unter Einhaltung der aktuellen Fahrspur maximal verzögert, um die Kollisionsschwere so stark wie möglich zu verringern.
Bei der Diskussion über „ethisch korrekte“ Entscheidungen wird stets auf das Ziel verwiesen, mit dem automatisierten Fahren Unfälle in Zukunft komplett zu vermeiden, um solche Entscheidungen nicht treffen zu müssen. Außerdem ist es derzeit rein aus technischer Sicht nicht möglich, die genaue Anzahl an Personen in einer Menschengruppe zu erfassen. Gleiches gilt für die Qualifizierung von Menschen anhand ihrer Merkmale, weshalb die häufig herangezogenen Dilemma-Situationen für „ethisch korrektes“ Handeln eher theoretischer Natur sind.
Welche nächsten Schritte haben Sie für Ihre Software geplant? Sehen Sie Vermarktungspotenzial für die Industrie?
Wir konzentrieren uns seit dem Roborace-Event in Berlin wieder voll auf unsere Forschungsthemen am Lehrstuhl. Berlin war für uns erst der Anfang, um zu zeigen, dass wir eine leistungsfähige Software entwickelt haben. Auf Basis derer können wir jetzt in die Funktionsentwicklung einsteigen, die dazu führen wird, dass das Fahrzeug schneller wird. Zum einen können wir die Sicherheiten, die aktuell noch berücksichtigt werden, schrittweise verringern. Zum anderen wird das Fahrzeug immer „intelligenter“, was einen großen Leistungssprung bedeutet. Das heißt konkret, dass das Fahrzeug zunehmend präziser auf die Umweltbedingungen – hier stehen aktuell vor allem statische und dynamische Objekte im Fokus – eingehen und daraus die richtigen Schlüsse ziehen können wird. Das geschieht durch Entwicklung von neuen Funktionen und durch das Sammeln von Erfahrungswerten, auf die das Fahrzueg zurückgreifen kann.
Natürlich entsteht hier sehr viel Know-how, das für die Industrie interessant ist. Vor allem auch, weil wir die Gelegenheit haben, unsere Forschungsergebnisse im Einsatz unter Extrembedingungen zu überprüfen. Ohne Roborace wäre das für uns als Forschungseinrichtung schlicht unmöglich, wenn man bedenkt, was Entwicklung, Betrieb und Logistik rund um die Rennfahrzeuge kosten würden. Dadurch, dass wir aber diese einzigartige Möglichkeit haben, können wir valide Forschungsergebnisse produzieren, die anschließend in die Serienentwicklung zurückgespielt werden können. Das Thema des automatisierten Fahrens ist natürlich sehr viel weitreichender als die Szenarios, die wir in unserer Forschung berücksichtigen.
Allerdings leistet das sichere Steuern des Fahrzeugs in hochdynamischen Situationen einen entscheidenden Beitrag zur Sicherheit der automatisierten Fahrfunktionen. Neben der Entwicklung von Algorithmen, die dazu in der Lage sind, spielt auch der Aspekt der Echtzeitfähigkeit eine große Rolle. Wir können davon ausgehen, dass die Algorithmen im Straßenverkehr garantiert schnell genug sind, wenn wir sie für die Rennszenarien echtzeitfähig implementieren können. Aus diesen Gründen ist die Relevanz unserer Forschung trotz oder gerade wegen des reinen Renneinsatzes sehr hoch. Daher sehen wir für unsere entwickelten Algorithmen ein hohes Vermarktungspotenzial.
Werden Sie beim nächsten Roborace wieder an den Start gehen?
Definitiv. Wir stehen derzeit in engem Kontakt mit Roborace und planen die Saison 2019, an der wir wieder teilnehmen werden. Geplant sind mehrere Events, die im Rahmen der FIA-Formel-E-Weltmeisterschaft stattfinden. An den Events sollen mehrere Teams teilnehmen, die sowohl mit menschlichen Fahrern als auch mit ihrer Software gegeneinander antreten werden. Neben dem reinen Zeitfahren, wie beim diesjährigen Berlin-Event, sind weitere, neue Wettbewerbsformate in Planung.
Unser Team befindet sich aktuell in der Abstimmungsphase über neue Funktionen und Verbesserungen unserer Software. Hauptentwicklungsziele sind dabei das Deketieren von und der Umgang mit dynamischen Objekten sowie eine deutliche Steigerung der Fahrzeug-Performance. Durch den Einstieg weiterer Teams steigt der kompetitive Charakter der Events weiter an, was für mehr Spannung für die Zuschauer und vor allem für uns als Team sorgt. Wir freuen uns sehr über die neue Konkurrenz und den Wettbewerb.
Es bleibt auf jeden Fall spannend – sowohl für uns im Roborace als auch für die Entwicklung von selbstfahrenden Fahrzeugen im Allgemeinen.
Herzlichen Dank für das Gespräch, Herr Hermansdorfer. (aho)
-
Interviewpartner
Leonhard Hermansdorfer
Lehrstuhl für Fahrzeugtechnik, Technische Universität München
-
Diesen Beitrag als PDF downloaden