"Tesla Model S" by Nghi Le von flickr.com unter CC BY-NC-ND 2.0 Lizenz

False Positive und Kundenakzeptanz – Wieso der Tesla Autopilot Crash kaum zu verhindern war

by Paul Balzer on 4. Juli 2016

1 Comment

Irgendwann musste es passieren: Ein im automatisierten Fahrbetrieb befindliches Fahrzeug ist in einen Unfall verwickelt und kann die Situation nicht retten. In diesem Fall ist ein Mensch um’s Leben gekommen. Sehr tragisch. Was ist passiert?

Ein Truck biegt an einer Kreuzung links ab und nimmt einem geradeaus fahrenden Fahrzeug die Vorfahrt. Soweit erst einmal ein statistisch gesehen relativ häufiger Vorfall. In diesem Fall war das Fahrzeug ein Tesla Model S im ‚Autopilot‘ Modus. Das bedeutet, dass das Fahrzeug selbst die Längs- und Querführung übernommen hat (Lenken & Gas/Bremse). Die Software wird von Tesla unter Realbedingungen ‚beim Kunden‘ getestet, sie ist ausdrücklich als Beta Version verfügbar, das bedeutet der Kunde darf sich nicht auf die Fehlerfreiheit verlassen, denn er hat eingewilligt sie als Testfahrer zu nutzen. Mutig von Tesla, deutsche Hersteller haben sich dagegen entschieden, wenngleich sie technisch auch so weit wären.

Es ist ein Unglück, welches durch die Verkettung menschlichen Versagens hervorgerufen wird aber in der Verfehlung der Technik mündet:

  1. LKW Fahrer nimmt die Vorfahrt
  2. PKW Fahrer schaut nicht auf die Straße
  3. Autopilot reagiert nicht

Die mediale Debatte entfaltet sich natürlich in Richtung Tesla und Fehler der „Autopilot“ Funktion. Wieso hat der Autopilot das nicht erkannt? Nungut, steigen wir mit ein.

Sensorik im Tesla Model S

Die Augen des Autopiloten für diese Situation sind die Kombination aus zwei Sensortypen:

  1. Monokamera
  2. Radar

Beide haben spezifische Vor- und Nachteile, gemeinsam sind sie ein sich gegenseitig prima ergänzendes Duo.

Monokamera

Die Monokamera kann keine Entfernung zu irgendetwas messen, sondern reduziert die 3D Welt im Blickfeld auf die Ebene des Kamerachips. Dadurch geht Tiefeninformation verloren, welche durch Annahmen und Algorithmen teilweise versucht wird, wieder zurück zu gewinnen (es wird beispielsweise die Breite eines Fahrzeugs in Heckansicht angenommen, wodurch sich ein Abstand schätzen lässt).

Das System ist prinzipiell dafür ausgelegt Fahrzeuge von hinten zu sehen und die Kontur zu erkennen, eine Fahrspur zu finden und den Freiraum vor dem Fahrzeug auf Hindernisse zu überprüfen. Einen sehr guten Einblick zur eingesetzten Kamera&Algorithmen liefert der CEO von MobilEye in diesem Vortrag.

Radar

Das Radar, welches in der Front des Tesla Model S verbaut ist, liefert hingegen genau die fehlenden Informationen: Abstand und Geschwindigkeit von Objekten direkt vor dem Fahrzeug, typischerweise in der eigenen Fahrspur.

Dafür hat das Radar einen großen Nachteil: Es kann kaum bestimmen, ob ein Objekt auf der eigenen oder auf der Nebenspur fährt. Die Winkelauflösung ist nur dadurch gegeben, dass mehrere Radar Transceiver in verschiedene Richtungen schauen (z.B. -5° nach links, 0° nach vorn und 5° nach rechts) und durch Auswertung der Signalstärke des Radar Echos kann man schätzen wo das Objekt sich befindet.

Problematisch bei Radar ist, dass es elektromagnetische Wellen sind, welche natürlich von metallischen/ferromagnetischen Oberflächen stark reflektiert werden, von Plastik oder Haut nicht so stark. Wie kompliziert die Signalauswertung von FMCW Radaren ist, kann man sich wunderbar in einem Video von Rohde&Schwarz ansehen.

Sensordatenfusion

Wer noch nicht mit Sensoren gearbeitet hat, glaub ja, dass dort völlig eindeutige Informationen heraus kommen. Beispielsweise ein Abstand zu einem Hindernis oder die Größe eines Objekts. Dem ist nicht so!

Sensoren messen alle fehlerhaft und verrauscht. Man muss als Algorithmenentwickler einen geeigneten Ansatz finden, die Messfehler heraus zu bekommen bzw. Annahmen treffen die den wahren Wert aus den Messdaten heraus holen. Das gelingt mal gut mal weniger gut. Ein gutes Mittel ist, die Informationen der verschiedenen Sensoren zu fusionieren.

Schätzen sie mal: Die Objekthypothese

Dabei wird eine Objekthypothese aufgestellt und jeder Sensor bestärkt die Hypothese bzw. schwächt sie ab. Sieht beispielsweise die Kamera irgendwie einen Umriss vor dem Auto, wird sie die Objekthypothese aufstellen, dass sich dort etwas befindet. Kommt nun vom Radar ebenfalls eine leichte Signatur, so wird diese Hypothese bestärkt. Das Fahrzeug bewegt sich ein Stück weiter. Das Objekt wird verfolgt (man sagt ‚getrackt‘) und es wird geschaut, ob sich an der vermuteten Stelle nun wieder etwas befindet. Meldet sowohl Kamera als auch Radar an der Stelle wieder ein Objekt, so gilt die Hypothese wieder als bestärkt und die Wahrscheinlichkeit, dass sie stimmt, steigt an (man sagt ‚confidence‘). Natürlich kann sich ein Sensor auch irren und die Hypothese wird wieder verworfen.

Im nachfolgenden Video der Baselabs GmbH sieht man Sensordatenfusion sehr schön (die „Confidence“ ist durch die Größe der Ellipsen um die Objekte ausgedrückt: Umso kleiner, umso sicherer ist die Objekthypothese):

Ab einer gewissen Wahrscheinlichkeit wird das Objekt als Vorhanden angenommen und im Falle einer möglichen Kollision werden geeignete Maßnahmen ergriffen (akustisch oder direkt Bremseingriff).

Zwickmühle bei der Entwicklung

Nun kommt man als Entwickler zu einem Punkt, an dem man dem Computer sagen muss, ab welcher Confidence er welche Eskalationsstufen einleiten soll. Im einfachsten Fall merkt man, dass eine Situation nicht eindeutig ist und fordert den Fahrer zu Übernahme auf. Es ist klar, dass hierfür ausreichend Zeit zur Verfügung stehen muss.

Sensorik und Hypothese

Im Falle des Tesla Crash sind nun mehrere Sachen zusammen gekommen: Der LKW auf der Gegenspur auf der anderen Seite der Kreuzung wird von der Kamera nicht unbedingt als relevantes Objekt eingestuft. Als er abbiegt und in die eigene Spur eindringt, ist er weit weg und nur kurz von vorn zu sehen, danach von der Seite. In diesem konkreten Fall war es ein weißer LKW vor einem hellen Himmel. Eine Signatur (Erscheinungsbild), auf welche die Kamera nicht programmiert ist bzw. sensorisch an ihre Grenzen kommt. Sie macht lediglich eine ‚Free Space Detection‘, d.h. sucht die eigene Fahrspur ab, ob sich in dieser Hindernisse befinden. Dem könnte auch so gewesen sein: Die Zugmaschine mit Achsen/Rädern wurde sicherlich als Hindernis erkannt und die Objekthypothese initialisiert, doch kurze Zeit später war dieses Hindernis wieder von der eigenen Spur verschwunden, denn der LKW ist weiter abgebogen und der Auflieger ragte über die Fahrbahn. Dieser ist aber >1m über der Fahrbahn und demzufolge für eine Mono-Kamera, welche alles auf eine Bildebene reduzieren muss, fast am Horizont projeziert. Der LKW hatte auch noch eine ähnliche Farbe wie der helle Himmel (Hindergrund), sodass es die Kamera schwer hatte überhaupt etwas zu erkennen.

Bleibt noch das Radar, welches ja eigentlich Abstände direkt messen kann.

Auch hier eine Verkettung unglücklicher Umstände: Der Auflieger des LKW ist ca. 1m über der Fahrbahn, das Radar hat vermutlich sozusagen darunter durch gemessen. Wie man liest, hatte der Auflieger auch keinen Unterfahrschutz, welcher die elektromagnetische Welle hätte reflektieren können.

VALTAC truck Langley BC 2008_0809

Die Radarnebenkeulen haben vermutlich ein Objekt erkannt, doch man kann nicht wegen jeder Objekthypothese eine Vollbremsung einleiten.

ADAS_TradeOff

Es ist ein schmaler Grat: Auf der einen Seite soll das System solche Situationen erkennen, auf der anderen Seite ergibt eine Brücke oder ein Autobahn Verkehrsschild eine ähnliche Radar Signatur. Das System darf auf keinen Fall beim Durchfahren einer Autobahnbrücke eine Vollbremsung machen.

False Positive und Kundenakzeptanz

Schon im Test zum Mobileye System wird deutlich wie schwer eine False Positive Rate an der Kundenakzeptanz kratzt. Man stelle sich vor eine automatische Notbremsung löst nur in 0,1% der Situationen falsch aus: Das hört sich ziemlich gut an, oder? Wenn man aber pro Tag durch 8 Autobahnbrücken fährt, dann würde das Fahrzeug jedes Jahr rund 3 Vollbremsung vor dieser machen. Es wird ziemlich schnell klar, dass es einen Kompromiss geben muss. Eine so drastische Reaktion wie eine automatische Notbremsung (AEB = Automated Emergency Breaking) kann nur durchgeführt werden, wenn sich das Fahrzeug sehr sicher ist, dass es eine Kollision geben wird.

Im Falle des LKW war es das nicht und ich bezweifle, dass man zukünftig bei dieser Art der Verkettung unglücklicher Umstände (weißer LKW, heller Himmel, hoher Auflieger, seitliche Signatur) mit dieser Sensorik eine zufriedenstellende Lösung finden wird.

Das Auftreten eines solchen Events ist so selten, dass man dies als Entwickler nicht abdecken kann. Sicherlich werden die Schwellwerte nun etwas angepasst werden und eventuell wird simulativ nachgewiesen, dass dieser Unfall mit der neuen Autpilot-Software verhindert worden wäre, doch es bleiben immer Situationen, in denen die Sensoren kein eindeutiges Bild geben können.

Fazit

Am gleichen Tag ist nicht nur der Fahrer des Model S im Straßenverkehr in den USA gestorben, sondern auch noch ca. 90 andere Menschen, weil auch in diesen Situationen unglückliche Umstände zusammen kamen. Die Fahrzeuge waren aber nicht selbstfahrend. Das mediale Echo ist undifferenziert und macht insgesamt Stimmung gegen die selbstfahrenden Fahrzeuge, was in gewisser Weise nicht gerechtfertigt ist.

Wir werden als Gesellschaft entscheiden müssen, ob wir damit leben können, dass hin und wieder ein Roboter einen Unfall nicht verhindern kann oder ob weiterhin 90% der Unfälle im Straßenverkehr auf Grund menschlichen Versagens viele Tote fordert, woran wir uns aber gewöhnt haben.

Und das der Tesla es kann, sieht man in diesem Video sehr eindrucksvoll, obwohl auch hier die Sichtbedingungen sehr schlecht waren:


 

Titelbild: „Tesla Model S“ by Nghi Le von flickr.com unter CC BY-NC-ND 2.0 Lizenz

Leave a Reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>