DE102021111446A1

DE102021111446A1 - Objektdetektion unter verwenden von planarer homographie und selbst-überwachtem szenenstruktur verständnis

Info

Publication number: DE102021111446A1
Application number: DE102021111446.2A
Authority: DE
Inventors: Le An; Yu-Te Cheng; Oliver Wilhelm Knieps; Su Inn Park
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2020-05-05
Filing date: 2021-05-04
Publication date: 2021-11-11
Also published as: CN113609888A; US20240046409A1

Abstract

In verschiedenen Beispielen wird eine Einzelkamera verwendet, um zwei Bilder einer Szene von verschiedenen Positionen aufzunehmen. Ein trainiertes neuronales Netzwerk gibt, indem es die zwei Bilder als Eingaben nimmt, eine Szenenstruktur-Karte aus, die ein Verhältnis von Höhen- zu Tiefenwerten für Pixelpositionen, die mit den Bildern assoziiert sind, anzeigt. Dieses Verhältnis kann die Anwesenheit eines Objekts über einer Oberfläche (z. B. Straßenoberfläche) innerhalb der Szene anzeigen. Objektdetektion kann dann auf Nicht-Null Werten oder Regionen innerhalb der Szenenstruktur-Karte durchgeführt werden.

Description

HINTERGRUND DER ERFINDUNG
Ausführungsbeispiele der vorliegenden Offenbarung lösen verschiedene Probleme, welche Computer Vision beinhalten, und sind in einer Vielfalt von Kontexten anwendbar, wie zum Beispiel Hindernisdetektion auf der Straße für autonom fahrende Fahrzeuge. Zum Beispiel ist es, für menschliche Fahrer, kritisch mögliche Straßengefahren auf der eigenen Spur zu erkennen und dann Aktionen, wie zum Beispiel Stoppen oder einen Spurwechsel durchzuführen in einer zeitigen Weise durchzuführen, um Unfälle zu vermeiden. Ähnlich wird von einem selbstfahrenden Fahrzeug erwartet, dass es diese Fähigkeit hat, alle möglichen gefährlichen Konditionen auf der Straße zu erkennen.
Ausführungsbeispiele, die hierin beschrieben sind, repräsentieren Verbesserungen über frühere Versuche das Problem der Detektion von Straßengefahren oder anderer Objekte auf einer Straßenoberfläche zu adressieren.
ZUSAMMENFASSUNG DER ERFINDUNG
Ausführungsbeispiele der vorliegenden Offenbarung beziehen sich auf Objektdetektion unter Verwenden von planarer Homographie und selbstüberwachten Verständnis einer Szenenstruktur. Systeme und Verfahren werden offenbart, die eine Einzelkamera verwenden können, welche an der Front der autonom fahrenden Maschine montiert ist, um Bilder aufzunehmen, die verwendet werden, um ein Deep-Neural-Network (DNN) zu trainieren, um eine Szenenstruktur-Karte vorherzusagen. Während einer Trainingsphase wird eine planare Homographie zwischen zwei Bildframes, welche von der Kamera zu zwei verschiedenen Zeitpunkten aufgenommen werden, berechnet und ein erster gewarpter Frame wird erzeugt, basierend zumindest in Teilen auf der planaren Homographie. Die verbleibende Differenz zwischen dem ersten gewarpten Bild und dem zweiten Frame wird als ein Residual-Fluss modelliert, der basierend zumindest in Teilen auf der Szenenstruktur, die unter Verwenden der zwei Bilder als Eingabe als eine Ausgabe des DNN erlangt wird. Schließlich wird der Residual-Fluss verwendet, um ein zweites gewarptes Bild, basierend zumindest in Teilen auf dem ersten gewarpten Bild, zu erzeugen und der Unterschied (z. B. der photometrische Verlust) zwischen dem zweiten Bild und dem zweiten gewarpten Bild kann verwendet werden, um die Parameter des DNN zu aktualisieren.
Während der Implematierungsphase werden zwei Bildframes, welche zu zwei unterschiedlichen Zeitpunkten ausgenommen werden können, als Eingabe für das DNN bereitgestellt und die Szenenstruktur wird bestimmt. Die Szenenstruktur umfasst ein Set von numerischen Werten, wo ein spezifischer numerische Wert ein Verhältnis zwischen der Höhe und Tiefe eines spezifischen Pixels, welches in den beiden Bildframes beinhaltet ist, anzeigt. In verschiedenen Ausführungsbeispielen können Nicht-Null Werte in der Szenenstruktur-Karte das Vorhandensein von Hindernissen oberhalb der Straßenoberfläche anzeigen, was die Initiierung eines oder mehrerer Hindernis-Detektions-Algorithmen verursachen kann.
Im Gegensatz zu hierin diskutierten konventionellen Systemen, können, für Simplizität und Kosteneffizienz, Ausführungsbeispiele der vorliegenden Offenbarung Straßenhindernisse mit minimalen Sensoren detektieren. Zum Beispiel, können die offenbarten Systeme und Verfahren effizient mittels einer Einzelbildkamera (z. B. einer monokularen Kamera), welche nach vorne gerichtet (z. B. eine Dashcam oder eine andere nach vorne gerichtete Kamera, wie nachfolgend genauer beschrieben) an einem Fahrzeug installiert ist, operieren.
Z. B. verwenden einige vorherigen Techniken zwei Bilder einer Sequenz als Eingabe, die iterativ prozessiert sind, um eine Ground-Homographie zu berechnen, basierend auf Feature-Matching und einem auf dem Konsensprinzip beruhenden Algorithmus. Nachfolgend werden gefährliche Objekte aus dem Unterschied zwischen den Ausgaben der prozessierten Bilder detektiert. Dieses simple Verfahren kann für komplexe Szenen versagen, bei denen viele Featurepunkte aus Off-Ground Objekten extrahiert würden, weshalb eine planare Homographie Schätzung negativ beeinflusst wird. Zusätzlich könnte ein Extrahieren von Bildfeatures und ein Durchführen von iterativen Matchen für jeden Frame, was, zum Teil wegen der zeitlichen Erfordernissen für die Iteration, in Real-Zeit Einsätzen nicht machbar ist, sein.
Andere Techniken setzen vorteilhaft beides, Bildfeatures geringen Levels, wie Bildgradienten, und Tiefen-Bilder von Stereokameras ein, um Hindernisse Aus-zu-Segmentieren mittels Optimierens eines Markov-Random-Field (MRF) Modells. Dieses Verfahren basiert auf der Annahme das Bereiche um ein Hindernis Krümmung großer Tiefe, Varianz großer Tiefe und große Bildgradienten zeigen. Implementierungen solcher Techniken verlassen sich auf Stereokamera-Eingaben und externe Tiefen Schätzverfahren. Zusätzlich benötigt die Technik ein Deep-Neural-Network, welches für Straßensegmentierung trainiert wurde. Die Komplexität und Computererfordernisse von solch einer Pipeline können untragbar und/oder unpraktisch für viele Anwendungen sein.
Figurenliste
Die vorliegenden Systeme und Verfahren für Objektdetektion unter Verwenden von planarer Homographie und selbstüberwachten Verständnis einer Szenenstruktur werden nachfolgend unter Bezugnahme auf die beigefügten Figuren im Detail beschrieben:

1 ist eine Illustration eines beispielhaften Einzelkamerasystems, welches verwendet wird, um ein Objekt auf einer Straßenoberfläche zu detektieren, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
2 ist ein beispielhafter Prozess eines Erzeugens eines gewarpten Bildes zum Verwenden in einem Trainingsprozess, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
3 ist ein beispielhafter Prozess eines Trainingsmodells, welches bei dem Einzelkamerasystem der 1 verwendet wird, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
4 ist ein beispielhafter Prozess eines Erzeugens eines gewarpten Bildes zum Verwenden in einem Trainingsprozess und Trainierens eines Modells, welches bei dem beispielhaften Einzelkamerasystem der 1 verwendet wird, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
5 ist ein beispielhafter Prozess des Verwendens eines Trainingsmodells zum Detektieren von Objekten mittels des Einzelkamerasystems von 1, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
6 ist eine beispielhafte Szenenstruktur-Karte, welche mittels des trainierten Modells erzeugt wurde, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
7A ist ein Beispiel eines Eingabebildes für ein trainiertes DNN, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
7B ist eine beispielhafte Szenenstruktur-Karte, welche mittels des trainierten Modells erzeugt wurde, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
8A ist ein Beispiel eines Eingabebildes für ein trainiertes DNN, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
8B ist eine beispielhafte Szenenstruktur-Karte, welche mittels des trainierten Modells erzeugt wurde, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
9A ist ein Beispiel eines Eingabebildes für ein trainiertes DNN, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
9B ist eine beispielhafte Szenenstruktur-Karte, welche mittels des trainierten Modells erzeugt wurde, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
10 zeigt ein Beispiel für ein autonomes Fahrzeug, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
11 zeigt ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Beispielfahrzeug von 10, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
12 ist ein Blockdiagramm einer Beispielsystemarchitektur für das autonome Beispielfahrzeug von 10, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
13 ist ein Systemdiagramm für die Kommunikation zwischen dem/den Cloud-basierten Server(n) und dem autonomen Beispielfahrzeug von 10, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung; und
14 ist ein Beispiel-Blockdiagramm für ein Rechengerät, das für die Implementierung von Ausführungsbeispielen der vorliegenden Offenbarung geeignet ist.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Systeme und Verfahren werden offenbart, die sich auf Objektdetektion unter Verwenden von planarer Homographie und selbst-überwachtem Verständnis einer Szenenstruktur beziehen.
Objektdetektion, einschließlich der Detektion von möglichen Hindernissen, ist ein wichtiges Feature für autonome Maschinen, entweder mit Assistenz-Fahrfunktionalität oder voller autonomer Fahrfähigkeit. Ausführungsbeispiele der vorliegenden Offenbarung stellen einen kamerabasierten Ansatz für Objektdetektion bereit, welcher sowohl Computer Vision als auch Deep-Learning Techniken verwendet. Zusätzlich kann diese Lösung wegen ihrer Simplizität und Kosteneffizienz mittels minimalen Sensoreinsatz und computergestützten Erfordernissen durchgeführt werden. Insbesondere können die vorgeschlagenen Verfahren und Systeme ein Objekt oberhalb einer Straßenoberfläche mit nur einer Einzelkamera (z. B. monokularen Kamera) detektieren, die an einem bewegenden Fahrzeug installiert ist, wie zum Beispiel eine Dashkamera oder ähnliche nach vorne gerichtete Kamera.
In verschiedenen Ansätzen können autonome Maschinen Eingaben von multimodalen Sensoren, wie beispielsweise Kamera, Radar und/oder Lidar verwenden, wenn sie verschiedene Operationen durchführen (z. B. Detektieren von Hindernissen auf einem Straßenservice). Jedoch benötigt die Verwendung von zusätzlichen Eingaben zusätzliche Kosten sowohl durch die Notwendigkeit für zusätzliche Hardware als auch zusätzlichen Rechenbedarf, um diese zusätzlichen Eingaben zu prozessieren. Im verschiedenen Ausführungsbeispielen, die in der vorliegenden Offenbarung beschrieben werden, wird das Detektieren von Hindernissen auf der Straße durchgeführt, indem ein minimales Setup von Sensorsystemen und Rechenintensität verwendet wird. Zum Beispiel können die Systeme und Verfahren, die hierin beschrieben werden, bei Einsätzen, welche nur eine einzelne nach vorne gerichtete Kamera aufweisen, welche an einem bewegenden Fahrzeug oder Roboter montiert ist, verwendet werden. Während diese Systeme und Verfahren als solches nicht beschränkt sind, könnte das Einbeziehen von fortgeschrittenen Sensoren wie beispielweise Lidar nicht so kosteneffizient sein und die Komplexität des Systems sehr vergrößern, was einen Einsatz im großen Maßstab in der nahen Zukunft verhindert.
Ferner wird ein Überwachtes-Lernen-Ansatz schwierig zu skalieren und zu verallgemeinern sein, da gelabelte Daten für Straßenhindernisse selten sind und es unmöglich ist, alle möglichen Arten von Hindernissen auf der Straße aufzuzählen. Zusätzlich wird ein manuelles Labeln einer großen Sammlung von Daten zum Trainieren von neuronalen Netzen sehr teuer sein.
Ausführungsbespiele der Systeme und Verfahren, welche hierin beschrieben werden, verwenden eine Einzelkamera, welche an einem bewegten Fahrzeug oder Roboter montiert ist, um Bilder einer Umgebung aufzunehmen, welche das Fahrzeug umgibt. Während einer Beispiel-Trainingsphase werde zwei Frames der Kamera als Eingabe verwendet, um ein Deep-Neural-Network (DNN) zu trainieren. In einem Beispiel wird das DNN dann von einem oder mehr Computersystemen innerhalb des Fahrzeugs oder Roboter verwendet, um eine Szenenstruktur-Karte vorherzusagen, welche die gleiche Größe wie die Eingabebilder hat. In dieser Strukturkarte gibt es, in einem Ausführungsbeispiel, eine Matrix von numerischen Werten, bestimmt basierend zumindest zum Teil auf einem Verhältnis zwischen Höhe und Tiefe, was für eine spezifische Pixelposition vorhergesagt wird. Unter Verwenden eines Straßensegmentierung- oder eines Spurdetektions-Algorithmus (welcher auf gegenwärtigen Techniken basieren kann) können Punkte auf der Straße mit einem Nicht-Null-Wert in der Strukturkarte ein Hindernis sein. In verschiedenen Ausführungsbeispielen kann dann eine Zeichen-Box (bounding-box) bestimmt werden, die das Hindernis umschließt. Konventionelle Techniken wie Schwellwertverfahren oder Verbundene-Komponenten-Analyse (connected component analysis) werden in verschiedenen Ausführungsbeispielen angewendet, um die Zeichen-Box zu erzeugen. In dem oben beschriebenen Beispiel, kann das DNN unüberwachtes oder selbstüberwachtes Lernen durchführen. Jedoch kann in verschiedenen anderen Ausführungsbeispielen überwachtes Lernen verwendet werden, um die Präzession zu erhöhen (z. B. um die Höhe und Tiefe eines Objektes auf der Straßenoberfläche vorherzusagen). Zum Beispiel können zusätzliche Sensordaten wie Lidardaten verwendet werden, um überwachtes Lernen des DNN durchzuführen.
Die vorgeschlagenen Systeme und Verfahren können als eine essentielle Komponente in existierender Software für selbstfahrende Fahrzeuge aufgenommen werden, um sicheren Betrieb auf allen Leveln von autonomen Fahrsystemen sicherzustellen. Zusätzlich stellen die Anwendung dieser Techniken in Einzelkamerasystemen Kostenersparnis (z. B. Sensorkosten und Rechenkosten) bereit und reduzieren die Voraussetzungen für das Ermöglichen von selbstfahrenden Fahrzeugen. Ein anderer spezifischer Verdienst des vorgeschlagenen Verfahrens ist, dass wegen der Natur des selbstüberwachten Lernens ein großer Aufwand für Datenlabeln eingespart werden kann, was den Entwicklungsprozess beschleunigen und Kosten reduzieren würde. Zusätzlich können andere Anwendungsdomänen, wie beispielweise Robotik, dieses Verfahren verwenden, zum Beispiel um Roboter weg von oder um Hindernisse zu navigieren.
Mit Bezug auf 1, ist 1 ein Beispiel für ein Fahrzeug 102 mit einer einzelnen frontmontierten Kamera 108, welches ein trainiertes DNN verwendet, um ein Objekt 106 auf einer Straßenoberfläche 110 zu detektieren, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Ferner wird die Kamera 108 verwendet, wie in größeren Detail unten beschrieben wird, um Bilder einer Szene aufzunehmen, was dazu verwendet werden kann, um das DNN zu trainieren und/oder als eine Eingabe in das DNN bereitgestellt werden kann, um Objekte auf einer Straßenoberfläche zu detektieren. Es sollte verstanden werden, dass dieses und andere Anordnungen, welche hierin beschrieben werden, nur als Beispiele dargelegt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Interface, Funktionen, Ordnungen, Gruppierungen von Funktionen, etc.) können zusätzlich oder anstelle der gezeigten verwendet werden und manche Elemente können gänzlich weggelassen werden. Weiter sind viele der hier beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Lage implementiert werden können. Verschiedene hierin als von Einheiten durchgeführt beschriebene Funktionalitäten können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der Anweisungen ausführt, die im Speicher gespeichert sind.
1 illustriert zwei Szenen T0 und T1, wobei T0 einen ersten Zeitpunkt, an dem ein erstes Bild 104A der Szene aufgenommen wird, und T1 einen zweiten Zeitpunkt, an dem ein zweites Bild 104B aufgenommen wird, illustriert. Gemäß einem oder mehr Ausführungsbeispielen können Implementierungen entweder zwei (oder mehr) aufeinanderfolgende Frames oder zwei (oder mehr) Bilder, die durch eine Zeitspanne (z. B. 0,2 Sekunden) getrennt sind, verwenden. Zum Beispiel ist das erstes Bild 104A benachbart zu dem zweiten Bild 104B in einem Video, welches durch die Kamera 108 aufgenommen wurde. In einem anderen Beispiel sind das erste Bild 104A und das zweite Bild 104B mittels der Kamera 108 aufgenommen aber voneinander durch ein Zeitintervall von beispielweise 0,2 Sekunden getrennt. In verschiedenen Ausführungsbeispielen, kann das Zeitintervall zwischen dem ersten Bild 104A und dem zweiten Bild 104B modifiziert werden basierend zumindest zum Teil auf Daten, welche mittels (eines) Trägheitsmesseinheit-Sensor(en) (inertial measurement unit, IMU) des Fahrzeugs 102 erlangt werden, welche(r) im größeren Detail unten beschrieben wird/werden. Zum Beispiel kann das Intervall zwischen dem Aufnehmen des ersten Bildes 104A und des zweiten Bildes 104B vergrößert oder verkleinert werden basierend zumindest zum Teil auf der Geschwindigkeit des Fahrzeugs. In einem noch anderen Beispiel kann das Aufnehmen von Bildern zeitweise pausiert, vergrößert oder verkleinert werden, wenn der Lenkwinkel des Fahrzeugs einen Schwellwert (z. B. 30%) überschreitet.
In verschiedenen Ausführungsbeispielen beinhalten das erste Bild 104A und das zweite Bild 104B (oder zusätzliche Bilder als Volumendaten, wie im größeren Detail weiter unten beschrieben) Informationen von nahezu derselben Szene aber aus einer etwas anderen Sicht, und deshalb kann eine dreidimensionale Struktur der Szene, wie Tiefe und Höhe an jeder Pixelposition, von dem Frameunterschied abgeleitet werden. Nachfolgend ist ein Zweiphasen-Prozess beschrieben, welcher eine Trainingsphase und eine Einsatzphase aufweist, um das DNN zu verwenden, um Objekte auf einer Straßenoberfläche zu detektieren, unter Verwenden des ersten Bildes 104A und des zweiten Bildes 104B.
Während einer Beispiel-Trainingsphase kann, wie unten in größeren Detail im Zusammenhang mit 2 und 3 beschrieben, ein DNN oder ähnlicher Algorithmus trainiert werden, um ein Objekt in der Straße vorherzusagen, unter Verwenden des ersten Bildes 104A und des zweiten Bildes 104B als Eingaben. In anderen Ausführungsbeispielen können mehrere Bilder und/oder Daten (z. B. Sensordaten) als Eingaben für das DNN bereitgestellt werden. Während der Trainingsphase kann eine Sammlung von Trainingsbildern verwendet werden, um das DNN zu trainieren. Zusätzlich kann die Kamera 108 eine Vielzahl von Bildern und/oder Video aufnehmen, welche zusätzlich zu oder als Alternative zu der Sammlung von Trainingsbildern als Trainingsdaten verwendet werden können. Unter Verwenden des ersten Bildes 104A und/oder des zweiten Bildes 104B als Beispiel kann, während der Trainingsphase, ein Straßensegmentierungs- und/oder Spurdetektionsalgorithmus auf die Bilder angewendet werden, um eine ungefähre Region der Straße im ersten Bild 104A und/oder im zweiten Bild 104B zu identifizieren.
Zusätzlich werden diese Algorithmen oder andere geeignete Algorithmen in verschiedenen Ausführungsbeispielen verwendet, um Featureextraktion an den Bildern durchzuführen, was verwendet wird, das DNN zu trainieren (z. B. das erste Bild 104A und das zweite Bild 104B). Das Extrahieren von Features aus den Straßenregionen in den Trainingsbildern ermöglicht eine Homographie basierend auf Featurematching, wobei, zum Beispiel, das erste Bild 104A zu dem zweiten Bild 104B gewarpt wird, um ein gewarptes Bild zu generieren. Wie nachfolgend im größeren Detail im Zusammenhang mit 3 beschrieben, werden die gewarpten Bilder, die als ein Ergebnis dieser Homographie erzeugt werden, weiter gewarpt unter Verwenden einer Residual-Fluss-Karte (z. B. ein Vektor), welche zumindest teilweise basierend auf einer Szenenstruktur-Karte berechnet wird, welche vom DNN ausgegeben wird.
In verschiedenen Ausführungsbeispielen wird ein Random-Sample-Consensus (RANSAC) oder ein ähnlicher Algorithmus verwendet, um eine Homographie-Transformation (z. B. 3x3 Matrix) zu schätzen, so dass eine Korrespondenz zwischen Schlüsselpunkten, die auf der Straßenoberfläche detektiert werden, unter Verwenden von Featureextraktoren, wie Speeded Up Robust Features (SURF), Robust Independent Elementary Features (BRIEF) und Oriented FAST und Rotated BRIEF (ORB), und Scale-Invariant Feature Transform (SIFT) etabliert werden kann. Dies wird als planare Homographie bezeichnet. In noch anderen Ausführungsbeispielen, wo zusätzliche Informationen über die Kamera 108 oder Kamera(s) in dem Fahrzeug 110 (z. B. Kamerastellung oder andere Kameraparameter) bekannt sind, ist ein Schätzen der Homographie-Transformation nicht nötig, weil die Übereinstimmung zwischen den Bildkoordinaten und den Realweltkoordinaten aus der Kamerastellung oder den anderen Kameraparametern bestimmt werden kann.
Zurückkehrend zu dem Beispiel in 1 wird planare Homographie verwendet, um das erste Bild 104A zu dem zweiten Bild 104B hin zu warpen. In dem gewarpten Bild, was als Ergebnis der planaren Homographie generiert wird, wird alles (z. B. das Objekt 106), was nicht auf der Ebene (z. B. der Straßenoberfläche, identifiziert unter Verwenden der oben beschriebenen Algorithmen) ist, nicht an den korrespondierenden Punkten in dem zweiten Bild 104B auszurichten werden. Basierend zumindest zum Teil auf diesem gewarpten Bild kann der verbleibende Unterschied zwischen dem gewarpten Bild und dem zweiten Bild 104B mittels eines Residual-Flusses modelliert werden, was basierend zumindest zum Teil auf einer Höhe eines spezifischen Punktes (z. B. eines Pixels im Bild, welcher das Objekt 106 repräsentiert) über der Ebene bestimmt wird. Ferner können, während Ebenen als illustratives Beispiel verwendet werden, die Techniken auf andere Oberflächen angewendet werden. Zum Beispiel gekrümmte Flächen (z. B. Hügel, Dämme, Schlaglöcher, Bordsteine, Rampen, usw.), die konvex oder konkav oder auf andere Weise in der Richtung der Fahrzeugbewegung (das Gleiche in andere Richtungen, usw.) gekrümmt sind. In verschiedenen Ausführungsbeispielen wird der Residual-Fluss, während der Trainingsphase, zumindest teilweise basierend auf der Szenenstruktur berechnet, die das DNN ausgibt. Zurückkehrend zu dem obigen Beispiel wird die Szenenstruktur-Karte mittels des DNN generiert, wobei das erste Bild 104A und das zweite Bild 104B als Eingaben genommen werden. Wie nachfolgend in größeren Detail beschrieben, ist die Szenenstruktur-Karte eine Matrix, die das Verhältnis zwischen der Höhe und Tiefe an Pixelpositionen innerhalb der Bilder repräsentiert.
In verschiedenen Ausführungsbeispielen sind, während des Trainings des DNN, die Eingaben des DNN das erste Bild 104A und das zweite Bild 104B, die Ausgabe des DNN ist die Szenenstruktur-Karte, welche in die Residual-Fluss-Karte konvertiert wird (zum Beispiel unter Verwenden von bekannten Techniken). Der Residual-Fluss kann dann verwendet werden, um das gewarpte Bild (z. B. das Bild, das, wie oben beschrieben, mittels Warpens des ersten Bildes 104A zu dem zweiten Bild 104B erzeugt wird) weiter zu dem zweiten Bild 104B hin zu warpen, was zu einem zweiten gewarpten Bild führt. In verschiedenen Ausführungsbeispielen ist der Zweck des Residual-Flusses die Punkte über der Ebene (z. B. die Straßenoberfläche 110) auszurichten. Gerade so wie die planare Homographie Punkte der Straßenoberfläche 110 in 1 auszurichten, kann der Residual-Fluss verwendet werden, um Punkte des Objekts 106 auszurichten.
Im Allgemeinen, je näher das zweite gewarpte Bild (z. B. das Ergebnis des Warpens des gewarpten Bildes zu dem zweiten Bild 104B hin, wie oben beschrieben) an dem zweiten Bild 104B ist, desto akkurater ist der Residual-Fluss und deshalb ist die Szenenstruktur umso akkurater. Als Folge kann der photometrische Verlust zwischen dem zweiten gewarpten Bild (z. B. ein mehrfach gewarptes Bild, welches durch zumindest Warpens des ersten gewarpten Bildes erzeugt wird) und dem zweiten Bild 104B (z. B. die Differenz zwischen den Bildern) verwendet werden, um die Parameter des DNN während des Trainings upzudaten. Während der Einsatzphase generiert das DNN die Szenenstruktur-Karte, zum Beispiel basierend zumindest zum Teil auf dem ersten Bild 104A und dem zweiten Bild 104B, die planare Homographie und Residual-Fluss mögen nicht berechnet werden und die Parameter des DNN mögen nicht angepasst werden.
Ferner kann das DNN oder andere geeignete Netze trainiert werden, um jede Anzahl von Bildern und/oder Sensordaten als eine Eingabe zu nehmen. Nicht beschränkende Beispiele beinhalten zwei (oder mehr) Bilder von einer Einzelkamera, die im Abstand von einer Sekunde aufgenommen werden, nichtaufeinanderfolgende Bilder eines Videos, welches von einer Einzelkamera zugeführt wird, oder sogar vier Bilder, die von zwei Kameras zu zwei Zeitpunkten aufgenommen werden. Die Systeme und Verfahren, die in der vorliegenden Offenbarung beschrieben werden, sind flexibel und können, in verschiedenen Ausführungsbeispielen, eine Objektdetektion unter Verwenden von gerade zwei Bildern von einer Einzelkamera durchführen. Wie in der vorliegenden Offenbarung beschrieben, kann dann das DNN die Szenenstruktur-Karte aus den zwei Bildern vorhersagen. Das DNN kann trainiert werden, um jedes bildbasierte Eingabeformat zu benutzen. Ferner können die Bilder Graustufenbilder oder Farbbilder in allen Arten von Farbräumen, wie RGB oder YUV, umfassen.
Zusätzlich zu der Fähigkeit mehrere Bilder zu verwenden, um die Szenenstruktur-Karte zu erzeugen, können während einer Beispiel-Trainingsphase, mehrere Bilder (z. B. 30 Frames, die während einer Sekunde aufgenommen werden) als eine Eingabe für das DNN verwendet werden. Zum Beispiel, bei einer gegebenen Sequenz von Bildern (z. B. Bild 1, Bild 2, ..., Bild 30) können mehrere Kombinationen von Bildern (z. B. Bild 1 und Bild 2, Bild 1 und Bild 30, Bild 2 und Bild 30,...) verwendet werden, um die Homographie und den photometrischen Verlust zu berechnen, wie oben beschrieben. In einem anderen Beispiel, kann die gesamte Sequenz von Bildern (z. B. die 30 Bilder) als ein Volumen gestapelt (z. B. Volumendaten) werden, welches Bild 1, Bild 2, ..., Bild 30 aufweist, und als eine Eingabe für das DNN verwendet wird. In solchen Beispielen können die zusätzlichen Bilder feinkörnigere Informationen und Szenendetails bereitstellen, um eine verbesserte Performance des DNN zu ermöglichen.
In verschiedenen Ausführungsbeispielen werden während der Einsatzphase das erste Bild 104A und das zweite Bild 104B als Eingaben in das DNN verwendet, welches das Objekt 106 oberhalb der Straßenoberfläche 110 detektiert, unter Verwenden der Information (z. B. das Verhältnis zwischen Höhe und Tiefe) in der Szenenstruktur-Karte. Wie in größeren Detail nachfolgend im Zusammenhang mit 4 beschrieben, können, wenn eine Gefahrdetektion durchgeführt wird, die Nicht-Null Positionen innerhalb der Straßenregion der Szenenstruktur-Karte identifiziert werden. Diese Nicht-Null Positionen zeigen, dass eine Höhe über der Straße 110 nicht Null ist und zeigen daher, dass ein Objekt 106 (z. B. Debris) auf der Straße ist. Das System, welches das DNN ausführt, oder ein anderes System kann Zeichen-Boxen erzeugen, die diese Nicht-Null Regionen umgeben, unter Verwenden von Standard Bildbearbeitungstechniken (z. B. Schwellwertverfahren, Dilatation/Erosion, Verbundene-Komponenten-Analyse, oder jedem anderen geeigneten Bildbearbeitungsalgorithmus).
Mit einem trainierten DNN und unter Verwenden der Techniken, welche in der vorliegenden Offenbarung beschrieben werden, können akkurate Szenenstruktur-Karten aus gerade zwei Bildern, erlangt von der Kamera 108 an einem Fahrzeug 102, während es in Bewegung ist, generiert werden. In verschiedenen Ausführungsbeispielen werden alle Regionen, welche zu Nicht-Null Werten in der Szenenstruktur-Karte korrespondieren, als mögliche Hindernisse betrachtet werden. Ferner kann das DNN in einer selbstüberwachtes-Lernen oder nicht-überwachtes-Lernen Weise operieren, ohne die Notwendigkeit irgendeines menschlichen Labeln einer spezifischen Form, Typ oder Position eines Hindernisses.
Schließlich sollte beachtet werden, dass, obwohl ein Fahrzeug 102 mit einer Einzelkamera 108 in 1 gezeigt ist, der vorgeschlagene Ansatz einfach ausgedehnt werden kann, um mehrere Bildframes zu verwenden, um die Szenenstruktur besser aufzunehmen. Zusätzlich können Bilder mehrerer Kameras (z. B. eine Stereokamera) zusätzliche visuelle Hinweise der gleichen Szene bereitstellen, was deshalb zu einer besseren Präzession führt. Ferner, während die beschriebenen Systeme und Verfahren ein DNN verwenden, können andere Netzwerkmodelle verwendet werden. Zum Beispiel nimmt das oben beschriebene DNN zwei oder mehr Bilder als Eingabe, und Ausgabe ist eine Szenenstruktur-Karte (die als ein Bild generiert werden kann). Als ein Ergebnis kann jedes Voll Convolutial Network oder Convolutial Network, das als Bild ausgeformte Ausgaben liefert, im Zusammenhang mit jedem der in der vorliegenden Offenbarung beschriebenen Ausführungsbeispielen verwendet werden. Nicht beschränkende Beispiele für geeignete Netzwerke umfassen: U-Net, DeeplabV3+, DeeplabV3, SegNet und FCN. Es sollte beachtet werden, dass im Allgemeinen jedes Netzwerk, das für eine semantische Segmentation geeignet ist, verwendet werden kann.
Die Systeme und Verfahren, welche in der vorliegenden Offenbarung beschrieben werden, können auch in zusätzlichen Anwendungen verwendet werden. Als ein Beispiel ist die nicht beschränkte Anwendung der vorliegenden Offenbarung auf Tiefenschätzung, Höhenschätzung, Off-Ground-Objektdetektion, Off-Ground Objektsegmentation, robotikbezogene Anwendungen, Navigation, oder andere bildbearbeitende und Computer Vision Anwendungen gerichtet. Im Allgemeinen sagen die beschriebenen neuronalen Netzwerke eine Szenenstruktur voraus, die mehr fundamentale geometrischen Informationen einer Real-World Szene beinhaltet; daher sind die neuronalen Netzwerke anwendbar auf Anwendungen, wo Schätzung und/oder Vorhersagen von geometrische Real-World-Informationen einer Szene verwendet werden.
Ausführungsbeispiele der vorliegenden Offenbarung stellen einen neuartigen Ansatz zum Verwenden von selbstüberwachten Lernen für Hindernisdetektion mit einer Einzelkamera bereit; die Übernahme eines DNN, im Vergleich zu konventionellen Computer Vision oder bildbearbeitungsbasierten Verfahren, kann komplexe Muster in Real-World-Daten modellieren; die selbstlernenden Mechanismen gemäß Ausführungsbeispielen der vorliegenden Erfindung, und vermeiden auch teures menschliches Labeln im Vergleich zu überwachten Lernen. Anstelle dessen können große Volumen an ungelabelten Daten, welche einfach erreichbar sind, verwendet werden, um die Genauigkeit der berechneten Vorhersagen zu vergrößern. Ferner verlangen die Systeme und Verfahren, die hierin beschrieben werden, keinerlei vorheriges Wissen über Tiefe oder Disparität. In verschiedenen Ausführungsbeispielen werden nur Farbbilder als Eingabe während der Einsatzphase benötigt.
Jetzt Bezug nehmend auf die 2, 3, 4 und 5 weist jeder hierin beschriebene Block der Verfahren 200, 300, 400 und 500 einen Berechnungsprozess auf, der durchgeführt werden kann unter Verwenden jeder Kombination von Hardware, Firmware und/oder Software. Zum Beispiel können verschiedene Funktionen mittels eines Prozessors ausgeführt werden, welcher Befehle abarbeitet, die im Memory gespeichert sind. Jedes der Verfahren kann auch als computerverwendbare Befehle, die auf einem Computer-Speichermedium gespeichert sind, verkörpert werden. Die Verfahren können mittels einer standalone Anwendung, einen Service oder gehosteten Service (standalone oder in Kombination mit einem anderen gehosteten Service), als Plugin zu einem anderen Produkt, um einige zu nennen, bereitgestellt werden. Zusätzlich wird Verfahren 200 beispielhaft mit Bezug auf das Objektdetektionssystem von 1 beschrieben. Jedoch können diese Verfahren zusätzlich oder alternativ mittels jedes einem System oder jeder Kombination von Systemen ausgeführt werden, einschließlich aber nicht beschränkt auf die hierin beschriebenen.
2 ist ein Flussdiagramm, welches ein Verfahren 200 zum Erzeugen eines gewarpten Bildes zeigt, welches, in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Offenbarung, während einer Trainingsphase eines DNN verwendet wird. Das Verfahren 200 beinhaltet bei Block 202 ein Erlangen eines ersten und eines zweiten Bildes. Wie oben beschrieben, können die Bilder von einer Einzelkamera, welche an einem Fahrzeug montiert ist (z. B. eine Dashkamera) erlangt werden. In einem Ausführungsbeispiel sind die Bilder aufeinanderfolgende Bilder eines Videostreams. In noch anderen Ausführungsbeispielen, gibt es einen zeitlichen Versatz (z. B. 0,2 Sekunden) zwischen den Bildern. Dieser zeitliche Versatz kann basierend zumindest zum Teil auf Informationen über die Bewegung der Kamera oder des Fahrzeugs, an welches die Kamera fixiert ist, modifiziert werden (z. B. Geschwindigkeit, Global Positioning System (GPS) Koordinaten, Lenkwinkel, usw.). Ferner kann, wie oben beschrieben, Verfahren 200 modifiziert werden, um Volumendaten, wie zum Beispiel zusätzliche Bilder und/oder Sensordaten, einzuschließen.
Bei Block 204 identifiziert das System, das Verfahren 200 ausführt, eine Straßenregion in den ersten und zweiten Bildern. Wie oben beschrieben, können Straßensegmentierung, Freier-Raum-Schätzung und/oder Spurdetektion-Algorithmus verwendet werden, um die Straßenregion zu identifizieren. Die Straßenregion wird identifiziert, um ein Objekt oberhalb der Straße zu detektieren.
Bei Block 206 detektiert das System, das Verfahren 200 ausführt, Schlüsselpunkte und extrahiert Schlüsselpunkt-Features aus den ersten und zweiten Bildern. Zum Beispiel kann ORB oder ein ähnlicher Algorithmus verwendet werden, um Schlüsselpunkte zu detektieren und Features von den Bildern zu extrahieren. Die Features und korrespondierenden Schlüsselpunkte, welche aus den Bildern extrahiert werden, erlauben, wie nachfolgend beschrieben, eine Schätzung einer planaren Homographie und die Bestimmung der Ebene, die mit der Straße assoziiert ist.
Bei Block 208 schätzt das System, das Verfahren 200 ausführt, eine Homographie-Transformation, um das erste Bild zu dem zweiten Bild zu warpen. In verschiedenen Ausführungsbeispielen wird RANSAC verwendet, um die Homographie-Transformation basierend zumindest zum Teil auf Informationen, welche von den Bildern erlangt werden, zu schätzen. Zum Beispiel ist die planare Homographie zumindest in Teilen auf Feature-Matching und Konsens von vorsegmentierten Straßenoberflächen in den ersten und zweiten Bildern basierend. Das System, das das Verfahren 200 ausführt, benötigt keine präzise Isolierung von Straßenregionen von der Szene. Zudem werden die Operationen, die im Zusammenhang mit 2 beschrieben werden, während der Trainingsphase durchgeführt, werden für die Einsatzphase nicht benötigt und erlegen während der Einsatzphase keine Rechenlasten auf.
Als ein Ergebnis einer direkten Homographie Schätzung mittels Schlüsselpunkten-Matchen und/oder Feature-Extraktion werden keine Informationen über eine Kalibration von Kameras (z. B. Kamerastellung) benötigt und Koordinatenkonversion, zum Beispiel von einer Bildebene zu Weltkoordinaten, wird umgangen. Dies reduziert signifikant die Systemkomplexität. In Ausführungsbeispielen, wo Kamerakalibrierung ohne weiteres verfügbar und zuverlässig ist, kann Verfahren 200 modifiziert werden, Kamerastellung zu verwenden, um Homographie zu berechnen, anstelle eines Ausführens der oben bei Block 206 und 208 beschriebenen Prozeduren.
Bei Block 210 verwendet das System, das Verfahren 200 ausführt, die geschätzte Homographie-Transformation, um eine planare Homographie durchzuführen, um das erste Bild zu dem zweiten Bild hin zu warpen und ein erstes gewarptes Bild zu generieren. Bei Block 212 wird das Prozessieren der Bilder und das Erzeugen des gewarpten Bilden komplettiert und das Trainieren des DNN setzt sich bei Block 302 in 3 fort. In verschiedenen Ausführungsbeispielen können die Operationen, die in 2 beschrieben sind, ausgelassen werden, in anderer Reihenfolge durchgeführt werden, parallel oder in einer Kombination von seriell und parallel durchgeführt werden. Betreffend das Prozessieren von Eingaben (z. B. das im Zusammenhang mit 2 beschriebene Prozessieren der Bilder), können Transformationen wie beispielsweise Mittelwert-Subtraktion (mean substraction), Standardabweichungsnormalisierung (standard deviation normalization), wie auch Vorprozessieren von Eingaben für bessere Ergebnisse, wie beispielsweise Bildentrauschen, selektiv ausgewählt werden.
3 ist ein Flussdiagramm, das ein Verfahren 300 zum Trainieren eines DNN zeigt, um ein Objekt auf einer Straßenoberfläche zu detektieren, in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das Verfahren 300 beinhaltet bei Block 302 ein Bereitstellen eines ersten Bildes und eines zweiten Bildes als Eingaben an ein DNN. Verfahren 300 kann, in verschiedenen Ausführungsbeispielen, Teil einer umfangreichen Trainingsphase, um das DNN für einen Einsatz vorzubereiten, sein. Die Computer Vision- und Bildbearbeitungs-Operationen, die im Zusammenhang mit 2 beschrieben sind, erzeugen Daten (z. B. das gewarpte Bild), die in Zusammenhang mit dem Verfahren 300 verwendet werden können. Wie oben beschrieben, gibt das DNN eine Szenenstruktur-Karte basierend zumindest zum Teil auf dem ersten Bild und dem zweiten Bild aus.
Bei Block 304 konvertiert das System, welches Verfahren 300 ausführt, die Szenenstruktur-Karte, die von dem DNN ausgegeben wird, in eine Residual-Fluss-Karte. In verschiedenen Ausführungsbeispielen kann der Residual-Fluss als ein Vektor modelliert werden, der verwendet werden kann, das gewarpte Bilde, das unter Verwenden der in 2 beschriebenen planaren Homographie erzeugt wurde, zu dem zweiten Bild hin weiter zu warpen. Bestimmung des Residual-Flusses kann unter Verwenden bekannter Computer Vision- oder Mustererkennungstechniken durchgeführt werden. Bei Block 306 wird das erste gewarpte Bild (z. B. das gewarpte Bild, welches bei Block 210 des Verfahrens 200 generiert wurde) weiter zu dem zweiten Bild hin gewarpt basierend zumindest zum Teil auf dem Residual-Fluss, um ein zweites gewarptes Bild zu erzeugen. In verschiedenen Ausführungsbeispielen richtet die oben beschriebene planare Homographie die Straßenoberfläche zwischen dem ersten und dem zweiten Bild aus, während das weitere Warpen bei Block 306 des Verfahrens 300 Objekte oberhalb der Straßenoberfläche abstimmt.
Bei Block 308 bestimmt das System, das Verfahren 300 ausführt, die photometrische Differenz zwischen dem zweiten gewarpten Bild und dem zweiten Bild. Die photometrische Differenz und/oder der photometrische Verlust misst die Differenz zwischen einem Eingabebild (z. B. dem zweiten Bild) und einem gewarpten Bild (z. B. das zweite gewarpte Bild, welches bei Block 306 erzeugt wurde) basierend auf dem vorhergesagten optischen Fluss mittels des DNN. Bei Block 310 kann das System, das Verfahren 300 ausführt, die Parameter des DNN basierend zumindest zum Teil auf der bei Block 308 bestimmten photometrischen Differenz updaten.
Ferner kann jedes von dem Verfahren 200 und Verfahren 300 in verschiedenen Ausführungsbeispielen für verschiedene Settings, z. B. mehrere Eingabe Frames, mehrere Kamera Eingaben, mehrere zusätzliche Sensoren, usw. verallgemeinert werden. Zusätzlich kann das Design des DNN auf Stand der Technik Techniken abgestimmt werden, um Präzession und Latenzerfordernisse weiter zu adressieren.
4 ist ein Flussdiagramm, das ein Verfahren 400 zum Erzeugen eines gewarpten Bildes zeigt, welches während einer Trainingsphase eines DNN verwendet wird, und zum Trainieren des DNN, um ein Objekt auf der Straßenoberfläche zu detektieren, in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das Verfahren 400, bei Block 402A und 402B, umfasst Erlangen eines ersten Bildframes und eines zweiten Bildframes. Wie oben beschrieben können die Bilder von einer Einzelkamera, welche an einem Fahrzeug montiert ist, (z. B. eine Dashkamera) erlangt werden. In einem Ausführungsbeispiel sind die Bilder aufeinanderfolgende Bilder in einem Videostream. In noch anderen Ausführungsbeispielen kann ein zeitlicher Versatz (z. B. 0,2 Sekunden) zwischen den Bildern sein. Dieser zeitliche Versatz kann modifiziert werden basierend zumindest zum Teil auf der Bewegung der Kamera oder des Fahrzeugs an welches die Kamera fixiert ist (z. B. Geschwindigkeit, Global Positioning System (GPS) Koordinaten, Lenkwinkel, usw.). Ferner kann das Verfahren 400, wie oben beschrieben, modifiziert werden, um Volumendaten, wie zusätzliche Bilder und/oder Sensordaten, zu beinhalten.
Das Verfahren 400, bei Block 404, umfasst ein Bereitstellen des ersten Bildframes 402A und des zweiten Bildframes 402B als Eingaben an das DNN. Die Computer Vision- und Bildbearbeitungs-Operationen, welche im Zusammenhang mit 2 beschrieben wurden, erzeugen Daten, zum Beispiel das gewarpte Bild 410, nachfolgend im größeren Detail beschrieben. Wie oben beschrieben, gibt das DNN eine Szenenstruktur-Karte 406 basierend zumindest zum Teil auf dem ersten Bildframe 402A und dem zweiten Bildframe 402B aus. In verschiedenen Ausführungsbeispielen beinhaltet die Szenenstruktur-Karte 406 Bilder und Daten, die in der vorliegenden Offenbarung beschrieben sind, zum Beispiel wie im Zusammenhang mit 5 unten beschrieben.
Bei Block 408 konvertiert das System, das das Verfahren 400 ausführt, die Szenenstruktur-Karte 406 in eine Residual-Fluss-Karte angesichts der kalibrierten Kamerahöhe und der geschätzten Homographie. In verschiedenen Ausführungsbeispielen kann der Residual-Fluss 408 als ein Vektor modelliert werden, der verwendet werden kann, um das gewarpte Bild 1 410, welches unter Verwenden der in 2 beschriebenen planaren Homographie erzeugt wurde, weiter zu dem zweiten Bild hin zu warpen. Bestimmen des Residual-Flusses wird, in verschiedenen Ausführungsbeispielen durchgeführt unter Verwenden von bekannter Computer Vision- und Bilderkennungs-Techniken.
Bei Block 412 verwendet das System, das Verfahren 400 ausführt, den Residual-Fluss 408, um das gewarpte Bild 1 410 zu dem zweiten Bildframe 2 402B hin weiter zu warpen. In verschiedenen Ausführungsbeispielen wird das Warpen des gewarpten Bildes 1 410 unter Verwenden des Residual-Flusses 408 ausgeführt. Der Residual-Fluss 408 stellt Informationen bereit, welche mit Objekten oberhalb der Straßenoberfläche assoziiert sind, was verwendet wird, um Objekte oberhalb der Straßenoberfläche in dem gewarpten Bild 1 410 hin zu Objekten oberhalb der Straßenoberfläche in dem zweiten Bildframe 402B zu warpen. Das Bildwarpen, das in Block 412 auftritt, erzeugt ein weiter gewarptes Bild 1 414. Wie oben beschrieben ist das weiter gewarpte Bild 1 414 ein Bild, welches als ein Ergebnis eines Warpens des gewarpten Bildes 1 410 hin zu dem zweiten Bildframe 402B erzeugt wird.
Bei Block 416 bestimmt das System, das Verfahren 400 ausführt, die photometrische Differenz (z. B. Verlustberechnung) zwischen dem weiter gewarpten Bild 1 414 und dem zweiten Bildframe 402B. Die photometrische Differenz und/oder der photometrische Verlust misst die Differenz zwischen einem Eingabebild (z. B. dem zweiten Bildframe 402B) und einem gewarpten Bild (z. B. dem weiter gewarpten Bild 1 414) basierend auf den vorhergesagten optischen Fluss mittels des DNN.
5 ist ein Flussdiagramm, das ein Verfahren 500 für eine Einsatzphase eines trainierten DNN zeigt, in Übereinstimmung mit einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das Verfahren 500 umfasst, bei Block 502, ein erstes Bild und ein zweites Bild als Eingaben für ein trainiertes DNN bereitzustellen. Bei Block 504 erlangt das System, das Verfahren 500 ausführt, eine Szenenstruktur-Karte, welche als eine Ausgabe des DNN erzeugt wird. Wie in der vorliegenden Offenbarung beschrieben, nimmt das DNN Bilder als Eingaben und Ausgaben, eine Szenenstruktur-Karte, die für Objekte innerhalb einer Szene eine vorhergesagte Höhe über einer Straßenoberfläche anzeigt.
Bei Block 506 führt das System, das Verfahren 500 ausführt, eine Analyse der Szenenstruktur-Karte aus. In verschiedenen Ausführungsbeispiele beinhaltet die Szenenstruktur-Karte ein Verhältnis von Höhe zu Tiefe bei jedem Pixel innerhalb der Szene wie mittels des DNN vorhergesagt. In solchen Ausführungsbeispielen kann jeder Nicht-Null Wert für einen Pixel ein Objekt oder ein Teil davon oberhalb der Straßenoberfläche repräsentieren. Pixel mit einem Null Wert können indizieren, dass da nichts auf der Straßenoberfläche ist. Daher beinhaltet in einem Ausführungsbeispiel die Analyse der Szenenstruktur-Karte das Aus-Maskieren von Pixeln, die nicht ein Objekt auf der Straßenoberfläche repräsentieren. Verschiedene Techniken zum Fokussieren auf die Nicht-Null Werte, welche in der Szenenstruktur-Karte beinhaltet sind, können im Zusammenhang mit den in der vorliegenden Offenbarung beschriebenen Ausführungsbeispielen verwendet werden.
Bei Block 508 kann das System, das Verfahren 500 ausführt, Hindernisse auf der Straßenoberfläche detektieren. Zum Beispiel indem es zumindest Blob-Erkennung und/oder Verbundene-Komponenten-Analyse an den Nicht-Null Pixeln durchführt, die in der Szenenstruktur-Karte indiziert werden. Gemäß einen oder mehr weiteren Ausführungsbeispielen kann die Implementierung einer Zwei-Bild Eingabe zu einer Vielfach-Bild Eingabe ausgedehnt werden, so dass die zeitliche Information, welche in den volumetrischen Videodaten eingeschlossen ist, verwenden werden kann, um die Ergebnisse zu verbessern. Anstelle des Verwendens einer Einzelkamera können Vielfach-Kameras wie zum Beispiel Stereo-Kameras wirksam eingesetzt werden. Die Disparität von überlappenden Szenen zwischen verschiedenen Kameras kann die Information vervollständigen, welche mittels einer Einzelkamera mit einer Szene aufgenommen zu verschiedenen Zeitpunkten getragen wird. Technische Details, wie photometrischer Verlust Funktionen, die im Training eines neuronalen Netzwerks (z. B. dem DNN) verwendet werden, können auf verschiedene Volumendaten Eingaben (z. B. Stereokameras) ausgedehnt werden. Zum Beispiel können wir, um die Ähnlichkeit zwischen einem gewarpten Bild und einem Referenzbild zu berechnen, L1 Verlust, L2-Verlust, Strukturelle-Ähnlichkeit (Structural SIMilarity, SSIM) Verlust oder ähnliche geeignete Techniken verwenden. Wenn multi-modale Daten verfügbar sind, kann das neuronale Netzwerk modifiziert werden, um mehr Eingaben anzunehmen. Zum Beispiel kann, wenn Radar/Lidar Daten verfügbar sind, diese Information in Verbindung mit Kamerabildern verwendet werden, um die Szenenstruktur-Karte vorherzusagen.
6 illustriert eine Beispielausgabe oder eine Szenenstruktur-Karte 602, erzeugt basierend zumindest zum Teil auf zwei Bildern, die als Eingabe für ein DNN bereitgestellt werden. In verschiedenen Ausführungsbeispielen ist die Ausgabe des DNN eine einzelne Szenenstruktur-Karte 602. Ferner kann die Szenenstruktur-Karte 602 die gleiche Größe wie die Eingabebilder oder eine reduzierte Größe haben, abhängig von der Präzision und Effizienz. Zum Beispiel nimmt das DNN beim aktuellen Zeitstempel, zu dem das DNN verwendet wird, um die Szenenstruktur-Karte vorherzusagen, sowohl den aktuellen Frame als eine Eingabe als auch einen oder mehrere vorherige Frames als Eingaben (z. B. 640x480 RGB Farbbilder, welche mit einer Einzelkamera aufgenommen wurden) und führt die Inferenz aus. Als ein Ergebnis wird die Szenenstruktur-Karte einer Größe 640x480 ausgegeben, so dass an verschiedenen Pixelpositionen der Wert der Szenenstruktur-Karte 602 das Verhältnis zwischen Höhe und Tiefe indiziert. Wie oben beschrieben kann die Szenenstruktur-Karte 602 auch eine reduzierte Ausgabe-Größe, z. B. 320x240, haben, im Falle dass die Auflösung gröber wird, was bedeutet, dass nun in der Karte ein Pixel Höhen/Tiefen-Informationen gibt, welche zu vier Pixeln im Originalbild korrespondieren. In verschiedenen Ausführungsbeispielen kann die reduzierte Größe der Szenenstruktur-Karte die Effizienz vergrößern.
7A zeigt ein Beispiel Eingabebild 700A einer Box in einer Straßenszene. Das Eingabebild 700A wird in verschiedenen Ausführungsbeispielen mittels einer nach vorne gerichteten Kamera eines bewegten Fahrzeugs aufgenommen, wie oben beschrieben. 7B zeigt eine beispielhafte Ausgabe-Szenenstruktur-Karte der Box, die in Bild 700A gezeigt ist. Die beispielhafte Ausgabe-Szenenstruktur-Karte wird in verschiedenen Beispielen mittels eines trainierten DNN erzeugt, wie oben beschrieben, was als eine Eingabe von Bild 700A und zumindest eines anderen Bildes bereitgestellt wird.
8A zeigt ein Beispiel-Eingabebild 800A von einem Fahrzeug in einer Straßenszene. Das Eingabebild 800A wird in verschiedenen Ausführungsbeispielen mittels einer nach vorne gerichteten Kamera eines bewegten Fahrzeugs aufgenommen, wie oben beschrieben. 8B zeigt eine beispielhafte Ausgabe-Szenenstruktur-Karte des Fahrzeugs, das in Bild 800A gezeigt ist. Die beispielhafte Ausgabe-Szenenstruktur-Karte wird in verschiedenen Beispielen mittels eines trainierten DNN erzeugt, wie oben beschrieben, was als eine Eingabe von Bild 800A und zumindest eines anderen Bildes bereitgestellt wird.
9A zeigt ein Beispiel-Eingabebild 900A von zweidimensionalen Straßenmarkierungen in einer Straßenszene. Das Eingabebild 900A wird in verschiedenen Ausführungsbeispielen mittels einer nach vorne gerichteten Kamera eines bewegten Fahrzeugs aufgenommen, wie oben beschrieben. 9B zeigt eine beispielhafte Ausgabe-Szenenstruktur-Karte der zweidimensionalen Straßenmarkierung, die in Bild 900A gezeigt ist. Die beispielhafte Ausgabe-Szenenstruktur-Karte wird in verschiedenen Beispielen mittels eines trainierten DNN erzeugt, wie oben beschrieben, was als eine Eingabe von Bild 900A und zumindest eines anderen Bildes bereitgestellt wird.
BEISPIELHAFTES AUTONOMES FAHRZEUG
10 ist eine Darstellung eines Beispiels eines autonomen Fahrzeugs 1000 gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das autonome Fahrzeug 1000 (hier alternativ als „Fahrzeug 1000“ bezeichnet) kann, ohne Einschränkung, ein Personenfahrzeug umfassen, wie z. B. einen Pkw, einen Lkw, einen Bus, ein Ersthelferfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrfahrzeug, ein Polizeifahrzeug, eine Ambulanz, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne und/oder eine andere Art von Fahrzeug (z. B. das unbemannt ist, oder das einen oder mehrere Fahrgäste aufnimmt). Autonome Fahrzeuge werden im Allgemeinen in Form von Automatisierungsstufen beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (Standard Nr. J3016-201806 , veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609 , veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert werden. Das Fahrzeug 1000 kann eine Funktionalität gemäß einem oder mehreren der Level 3 - Level 5 der autonomen Fahrstufen aufweisen. Beispielsweise kann das Fahrzeug 1000 je nach Ausführungsbeispiel eine bedingte Automatisierung (Level 3), eine hohe Automatisierung (Level 4) und/oder eine vollständige Automatisierung (Level 5) aufweisen.
Das Fahrzeug 1000 kann Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z. B. 2, 4, 6, 8, 18, usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs umfassen. Das Fahrzeug 1000 kann ein Antriebssystem 1050 umfassen, wie z. B. einen Verbrennungsmotor, ein Hybrid-Elektroaggregat, einen vollelektrischen Motor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 1050 kann mit einem Antriebsstrang des Fahrzeugs 1000 verbunden sein, der ein Getriebe umfassen kann, um den Vortrieb des Fahrzeugs 1000 zu ermöglichen. Das Antriebssystem 1050 kann in Reaktion auf den Empfang von Signalen von der Drosselklappe/Beschleunigungsvorrichtung 1052 gesteuert werden.
Ein Lenksystem 1054, das ein Lenkrad umfassen kann, kann verwendet werden, um das Fahrzeug 1000 zu lenken (z. B. entlang eines gewünschten Weges oder einer Route), wenn das Antriebssystem 1050 in Betrieb ist (z. B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 1054 kann Signale von einem Lenkaktuator 1056 empfangen. Das Lenkrad kann für die Funktionalität der Vollautomatisierung (Level 5) optional sein.
Das Bremssensorsystem 1046 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf den Empfang von Signalen von den Bremsaktuatoren 1048 und/oder Bremssensoren zu betätigen.
Die Steuerung(en) 1036, die eine oder mehr CPU(s), ein oder mehrere System-on-a-Chip (SoCs) 1004 (12 und/oder GPU(s) umfassen können, können Signale (z. B. repräsentativ für Befehle) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 1000 senden. Beispielsweise kann/können die Steuerung(en) Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 1048, zur Betätigung des Lenksystems 1054 über einen oder mehrere Lenkaktuatoren 1056 und/oder zur Betätigung des Antriebssystems 1050 über einen oder mehrere Drossel-/Beschleunigungsregler 1052 senden. Die Steuerung(en) 1036 kann/können ein oder mehrere Onboard-(z. B. integrierte) Rechengeräte (z. B. Supercomputer) umfassen, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z. B. Signale, die Befehle repräsentieren), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Fahren des Fahrzeugs 1000 zu unterstützen. Die Steuerung(en) 1036 kann/können eine erste Steuerung 1036 für autonome Fahrfunktionen, eine zweite Steuerung 1036 für funktionale Sicherheitsfunktionen, eine dritte Steuerung 1036 für Funktionalität der künstlichen Intelligenz (z. B. Computer Vision), eine vierte Steuerung 1036 für Infotainment-Funktionalität, eine fünfte Steuerung 1036 für Redundanz in Notfällen und/oder andere Steuerungen umfassen. In einigen Beispielen kann eine einzelne Steuerung 1036 zwei oder mehr der oben genannten Funktionalitäten übernehmen, zwei oder mehr Steuerungen 1036 können eine einzelne Funktionalität übernehmen und/oder eine beliebige Kombination davon.
Die Steuerung(en) 1036 kann/können die Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 1000 in Reaktion auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren empfangen werden (z. B. Sensoreingaben). Die Sensordaten können beispielsweise und ohne Einschränkung von (einem) Sensor(en) des globalen Navigationssatellitensystems 1058 (z. B. Global Positioning System-Sensor(en)), RADAR-Sensor(en) 1060, Ultraschallsensor(en) 1062, LIDAR-Sensor(en) 1064, Sensor(en) einer Trägheitsmesseinheit (IMU) 1066 (z. B. Beschleunigungssensor(en), Gyroskop(en), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 1096, Stereokamera(s) 1068, Weitwinkelkamera(s) 1070 (z. B, Fischaugenkameras), Infrarotkamera(s) 1072, Umgebungskamera(s) 1074 (z. B. 360-Grad-Kameras), Fern- und/oder Mittelbereichskamera(s) 1098, Geschwindigkeitssensor(en) 1044 (z. B. zur Messung der Geschwindigkeit des Fahrzeugs 1000), Vibrationssensor(en) 1042, Lenksensor(en) 1040, Bremssensor(en) 1046 (z. B. als Teil des Bremssensorsystems 1046), und/oder andere Sensortypen empfangen werden.
Eine oder mehrere der Steuerungen 1036 können Eingaben (z. B. in Form von Eingabedaten) von einem Instrumentencluster 1032 des Fahrzeugs 1000 empfangen und Ausgaben (z. B. in Form von Ausgabedaten, Anzeigedaten usw.) über eine Mensch-Maschine-Schnittstelle (HMI)-Anzeige 1034, einen akustischen Signalgeber, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 1000 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z. B. die HD-Karte 1022 von 12), Positionsdaten (z. B. die Position des Fahrzeugs 1000, zum Beispiel auf einer Karte), Richtung, Position anderer Fahrzeuge (z. B. ein Belegungsraster), Informationen über Objekte und Status von Objekten, wie von der/den Steuerung(en) 1036 wahrgenommen, usw. umfassen. Beispielsweise kann die HMI-Anzeige 1034 Informationen über das Vorhandensein eines oder mehrerer Objekte anzeigen (z. B. ein Straßenschild, ein Warnschild, eine sich ändernde Ampel usw.) und/oder Informationen über Fahrmanöver, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z. B. jetzt die Spur wechseln, in zwei Meilen die Ausfahrt 34B nehmen, usw.).
Das Fahrzeug 1000 umfasst weiterhin eine Netzwerkschnittstelle 1024, die eine oder mehrere drahtlose Antenne(n) 1026 und/oder Modem(s) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann die Netzwerkschnittstelle 1024 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA 2000 usw. zu kommunizieren. Die drahtlose(n) Antenne(n) 1026 kann/können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Geräte usw.) über lokale Netzwerke wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Low-Power-Wide-Area-Netzwerke (LPWANs) wie LoRaWAN, SigFox usw. ermöglichen.
11 ist ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug 1000 von 10, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Die Kameras und die jeweiligen Sichtfelder stellen ein exemplarisches Ausführungsbeispiel dar und sind nicht einschränkend gedacht. Beispielsweise können zusätzliche und/oder alternative Kameras umfasst sein und/oder die Kameras können sich an verschiedenen Kamerapositionen des Fahrzeugs 1100 befinden.
Die Kameratypen für die Kameras können, sind aber nicht beschränkt auf, Digitalkameras umfassen, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 1100 ausgebildet sein können. Die Kamera(s) kann/können auf der automobilen Sicherheitsintegritätsstufe (Autonomie Safety Integrity Level, ASIL) B und/oder einer anderen ASIL arbeiten. Die Kameratypen können je nach Ausführungsbeispiel eine beliebige Bildaufnahmerate erreichen, z. B. 60 Bilder pro Sekunde (fps), 120 fps, 240 fps usw.. Die Kameras können Rolling Shutter, Global Shutter, einen anderen Verschlusstyp oder eine Kombination davon verwenden. In einigen Beispielen kann das Farbfilter-Array ein Rot-Klar-Klar-Klar (RCCC) Farbfilter-Array, ein Rot-Klar-Klar-Blau (RCCB) Farbfilter-Array, ein Rot-Blau-Grün-Klar (RGBC) Farbfilter-Array, ein Foveon X3-Farbfilter-Array, ein Bayer-Sensor (RGGB) Farbfilter-Array, ein Monochrom-Sensor-Farbfilter-Array und/oder eine andere Art von Farbfilter-Array umfassen. In einigen Ausführungsbeispielen können Clear-Pixel-Kameras, wie z. B. Kameras mit einem RCCC-, einem RCCB- und/oder einem RBGC-Farbfilter-Array, verwendet werden, im Versuch die Lichtempfindlichkeit zu erhöhen.
In einigen Beispielen kann eine oder mehrere der Kamera(s) verwendet werden, um erweiterte Fahrerassistenzsystem (ADAS)-Funktionen auszuführen (z. B. als Teil eines redundanten oder ausfallsicheren Designs). So kann z. B. eine Multifunktions-Monokamera installiert werden, um Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung zu ermöglichen. Eine oder mehrere der Kamera(s) (z. B. alle Kameras) können simultan Bilddaten (z. B. Video) aufnehmen und bereitstellen.
Eine oder mehrere der Kameras können in einer Montagebaugruppe, wie z. B. einer kundenspezifisch gestalteten (3-D-gedruckten) Baugruppe, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z. B. Reflexionen vom Armaturenbrett, die sich in den Außenspiegeln der Windschutzscheibe spiegeln) auszuschalten, die die Bilddatenerfassungsfähigkeiten der Kamera stören könnten. In Bezug auf Seitenspiegel-Montagebaugruppen können die Seitenspiegel-Baugruppen kundenspezifisch 3-D-gedruckt werden, so dass die Kameramontageplatte zur Form des Seitenspiegels passt. In einigen Beispielen kann/können die Kamera(s) in den Seitenspiegel integriert werden. Bei Seitenkameras kann/können die Kamera(s) auch in die vier Säulen an jeder Ecke der Kabine integriert werden.
Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 1100 umfasst (z. B. nach vorne gerichtete Kameras), können für die Rundumsicht verwendet werden, um dabei zu helfen, nach vorne gerichtete Wege und Hindernisse zu identifizieren, sowie mit Hilfe einer oder mehrerer Steuerungen 1136 und/oder Steuer-SoCs Informationen bereitzustellen, die für die Erstellung eines Belegungsgitters und/oder das Bestimmen der bevorzugten Fahrzeugwege entscheidend sind. Nach vorne gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorne gerichtete Kameras können auch für ADAS-Funktionen und -Systeme wie Spurverlassenswarnungen (Lane Depature Warnings, LDW), autonome Geschwindigkeitsregelung (Autonomous Cruise Control, ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung verwendet werden.
Eine Vielzahl von Kameras kann in einer nach vorne gerichteten Konfiguration verwendet werden, umfassend beispielweise eine monokulare Kameraplattform, die einen CMOS (Complementary Metal Oxide Semiconductor)-Farbbildgeber umfasst. Ein weiteres Beispiel kann eine Weitwinkelkamera(s) 1170 sein, die verwendet werden kann, um Objekte zu erkennen, die von der Peripherie ins Blickfeld kommen (z. B. Fußgänger, kreuzenden Verkehr oder Fahrräder). Obwohl in 11 nur eine Weitwinkelkamera gezeigt ist, kann sich eine beliebige Anzahl von Weitwinkelkameras 1170 am Fahrzeug 1100 befinden. Zusätzlich kann (können) Fernbereichskamera(s) 1198 (z. B. ein Fern-Stereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert wurde. Die Fernbereichskamera(s) 1198 kann/können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
Eine oder mehrere Stereokameras 1168 können auch in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 1168 kann/können eine integrierte Steuereinheit umfassen, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (z. B. FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Eine solche Einheit kann dazu verwendet werden, eine 3D-Karte der Fahrzeugumgebung zu erzeugen, die eine Abschätzung der Entfernung für all die Punkte im Bild umfasst. Eine alternative Stereokamera(s) 1168 kann einen kompakte Stereo-Vision-Sensor(en) umfassen, der zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip umfasst, der den Abstand zwischen dem Fahrzeug und dem Zielobjekt messen kann und die generierten Informationen (z. B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurverlassenswarnfunktionen verwendet. Andere Typen von Stereokamera(s) 1168 kann/können zusätzlich oder alternativ zu den hier beschriebenen verwendet werden.
Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 1100 umfasst (z. B. Seitenkameras), können für die Umgebungsansicht verwendet werden, was Informationen liefert, die zum Erstellen und Aktualisieren des Belegungsrasters sowie zum Erzeugen von Seitenaufprall-Kollisionswarnungen verwendet werden. Beispielsweise können die Umgebungskamera(s) 1174 (z. B. vier Umgebungskameras 1174 wie in 11 gezeigt) um das Fahrzeug 1100 positioniert werden. Die Umgebungskamera(s) 1174 kann/können Weitwinkelkamera(s) 1170, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches umfassen. Beispielsweise können vier Fischaugenkameras an der Front, am Heck und an den Seiten des Fahrzeugs positioniert werden. In einer alternativen Anordnung kann das Fahrzeug drei Surround-Kamera(s) 1174 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z. B. eine nach vorne gerichtete Kamera) als vierte Surround-View-Kamera einsetzen.
Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 1100 umfasst (z. B. Rücksichtkameras), können für die Einparkhilfe, Umgebungssicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsrasters verwendet werden. Eine große Vielfalt von Kameras kann verwendet werden, einschließlich, aber nicht beschränkt auf, Kameras, die auch als nach vorne gerichtete Kamera(s) geeignet sind (z. B. Fern- und/oder Mittelbereichskamera(s) 1198, Stereokamera(s) 1168), Infrarotkamera(s) 1172 usw.), wie hier beschrieben.
12 ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 1000 von 10, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Es sollte verstanden werden, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargelegt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter sind viele der hier beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene Funktionen, die hier als von Einheiten ausgeführt beschrieben werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Memory gespeicherte Anweisungen ausführt.
Jede der Komponenten, Merkmale und Systeme des Fahrzeugs 1200 in 12 ist so gezeigt, dass sie über Bus 1202 verbunden ist. Der Bus 1202 kann eine CAN-Datenschnittstelle (Controller Area Network) umfassen (hier alternativ als ein „CAN-Bus“ bezeichnet). Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 1200 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionalitäten des Fahrzeugs 1200 verwendet wird, wie z. B. Betätigung von Bremsen, Beschleunigung, Bremsen, Lenkung, Scheibenwischern, usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten enthält, jeder mit seinem eigenen eindeutigen Identifikator (z. B. einer CAN-ID). Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, die Fahrgeschwindigkeit, die Drehzahl des Motors (RPM), die Tastenpositionen und/oder andere Fahrzeugstatusanzeigen zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
Obwohl der Bus 1202 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung gedacht. Beispielsweise können zusätzlich oder alternativ zum CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Obwohl eine einzelne Leitung zur Darstellung des Busses 1202 verwendet wird, ist dies nicht als Einschränkung zu verstehen. Beispielsweise kann es eine beliebige Anzahl von Bussen 1202 geben, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Arten von Bussen, die ein anderes Protokoll verwenden, umfassen können. In einigen Beispielen können zwei oder mehr Busse 1202 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder sie können zur Redundanz verwendet werden. So kann z. B. ein erster Bus 1202 für die Funktionalität der Kollisionsvermeidung und ein zweiter Bus 1202 für die Stellbewegungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 1202 mit jeder der Komponenten des Fahrzeugs 1200 kommunizieren, und zwei oder mehr Busse 1202 können mit denselben Komponenten kommunizieren. In einigen Beispielen kann jeder SoC 1204, jede Steuerung 1236 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf dieselben Eingabedaten (z. B. Eingaben von Sensoren des Fahrzeugs 1200) haben und mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
Das Fahrzeug 1200 kann eine oder mehrere Steuerung(en) 1236 umfassen, wie sie hierin mit Bezug auf 10 beschrieben sind. Die Steuerung(en) 1236 kann/können für eine Vielzahl von Funktionen verwendet werden. Die Steuerung(en) 1236 kann/können an jede/jedes der verschiedenen anderen Komponenten und Systeme des Fahrzeugs 1200 gekoppelt sein und kann/können für die Steuerung des Fahrzeugs 1200, die künstliche Intelligenz des Fahrzeugs 1200, das Infotainment für das Fahrzeug 1200 und/oder Ähnliches verwendet werden.
Das Fahrzeug 1200 kann ein oder mehrere System-on-a-Chip (SoC) 1204 umfassen. Der SoC 1204 kann CPU(s) 1206, GPU(s) 1208, Prozessor(en) 1210, Cache(s) 1212, Beschleuniger 1214, Datenspeicher 1216 und/oder andere nicht gezeigte Komponenten und Features umfassen. Der/die SoC(s) 1204 kann/können für das Steuern des Fahrzeugs 1200 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise kann der/die SoC(s) 1204 in einem System (z. B. dem System des Fahrzeugs 1200) mit einer HD-Karte 1222 kombiniert werden, die Kartenauffrischungen
und/oder -aktualisierungen über eine Netzwerkschnittstelle 1224 von einem oder mehreren Servern (z. B. Server(n) 1378 aus 13) erlangen kann.
Die CPU(s) 1206 kann/können einen CPU-Cluster oder CPU-Komplex umfassen (hier alternativ als „CCPLEX“ bezeichnet). Die CPU(s) 1206 kann/können mehrere Kerne und/oder L2-Caches umfassen. In einigen Ausführungsbeispielen kann die CPU(s) 1206 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In einigen Ausführungsbeispielen kann/können die CPU(s) 1206 vier Dual-Core-Cluster umfassen, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z. B. einen 2 MB L2-Cache). Die CPU(s) 1206 (z. B. der CCPLEX) kann/können so konfiguriert sein, dass sie einen simultanen Clusterbetrieb unterstützt/unterstützen, was jeder Kombination der Cluster der CPU(s) 1206 ermöglicht, zu jedem gegebenen Zeitpunkt aktiv sein kann.
Die CPU(s) 1206 kann/können Leistungsverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Features umfassen: einzelne Hardwareblöcke können im Leerlauf automatisch gegated werden, um dynamische Leistung zu sparen; jeder Kerntakt kann gegated werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig leistungs-gegated sein; jeder Kern-Cluster kann unabhängig takt-gegated sein, wenn alle Kerne takt-gegated oder leistungs-gegated sind; und/oder jeder Kern-Cluster kann unabhängig leistungs-gegated sein, wenn alle Kerne leistungs-gegated sind. Die CPU(s) 1206 kann/können weiter einen verbesserten Algorithmus zur Verwaltung von Leistungszuständen implementieren, bei dem zulässige Leistungszustände und erwartete Aufwachzeiten spezifiziert werden und die Hardware/der Mikrocode für den Kern, den Cluster und das CCPLEX den besten Leistungszustand zum Eintritt bestimmt. Die Prozessorkerne können vereinfachte Leistungszustands-Eintrittssequenzen in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
Die GPU(s) 1208 kann/können eine integrierte GPU umfassen (hier alternativ als „iGPU“ bezeichnet). Die GPU(s) 1208 kann/können programmierbar sein und für parallele Arbeitslasten effizient sein. Die GPU(s) 1208 kann/können in einigen Beispielen einen verbesserten Tensor-Befehlssatz verwenden. Die GPU(s) 1208 kann/können einen oder mehrere Streaming-Mikroprozessoren umfassen, wobei jeder Streaming-Mikroprozessor einen L1-Cache umfassen kann (z. B. einen L1-Cache mit einer Speicherkapazität von mindestens 96 KB), und zwei oder mehr der Streaming-Mikroprozessoren können gemeinsam einen L2-Cache nutzen (z. B. einen L2-Cache mit einer Speicherkapazität von 512 KB). In einigen Ausführungsbeispielen kann/können die GPU(s) 1208 mindestens acht Streaming-Mikroprozessoren umfassen. Die GPU(s) 1208 kann/können computerbasierte Programmierschnittstelle(n) (API(s)) verwenden. Außerdem können die GPU(s) 1208 eine oder mehrere parallele Berechnungsplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
Die GPU(s) 1208 kann/können für beste Performance in automobilen und eingebetteten Anwendungsfällen leistungsoptimiert sein. Die GPU(s) 1208 kann/können z. B. auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein.
Jedoch ist dies nicht als einschränkend gedacht und die GPU(s) 1208 kann/können jedoch auch hergestellt werden, unter Verwenden von anderen Halbleiterfertigungsverfahren. Jeder Streaming-Mikroprozessor kann eine Anzahl von gemischt-präzisen Rechenkernen enthalten, die in mehrere Blöcke partitioniert sind. Beispielsweise und nicht einschränkend können 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke unterteilt sein. In einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32 Kerne, 8 FP64 Kerne, 16 INT32 Kerne, zwei gemischt-präzise NVIDIA TENSOR COREs für Deep Learning-Matrixarithmetik, ein L0-Befehls-Cache, ein Warp-Planer, eine Verteilungseinheit und/oder eine 64-KB-Registerdatei zugewiesen sein. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Fließkommadatenpfade umfassen, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnungen und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfähigkeit umfassen, um eine feingranulare Synchronisation und Kooperation zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können einen kombinierten L1-Datencache und eine gemeinsam genutzte Speichereinheit umfassen, um die Performance zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
Die GPU(s) 1208 kann/können einen Speicher hoher Bandbreite (high bandwidth memory, HBM) und/oder ein 16 GB HBM2 Speicher-Subsystem umfassen, um in einigen Beispielen um die 900 GB/Sekunde Spitzen Speicherbandbreite bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zu dem HBM-Speicher ein synchroner Graphik-Random-Access-Speicher (SGRAM) verwendet werden, wie zum Beispiel ein Graphik-Doppelraten-Typ5-synchronen-Random-Access-Speicher (Graphics Double Data Type Five Synchronous Random Access Memory, GDD5).
Die GPU(s) 1208 kann/können eine Unified-Memory-Technologie umfassen, die Zugriffszähler umfasst, um eine genauere Migration von Speicherseiten zu dem Prozessor zu ermöglichen, der am häufigsten auf sie zugreift, wodurch die Effizienz für Speicherbereiche verbessert wird, die von den Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, damit die GPU(s) 1208 direkt auf die Seitentabellen der CPU(s) 1206 zugreifen kann/können. In solchen Beispielen kann bei einem Fehlversuch der Speicherverwaltungseinheit (MMU) der GPU(s) 1208 eine Adressübersetzungsanforderung an die CPU(s) 1206 übertragen werden. Als Antwort kann/können die CPU(s) 1206 in ihren Seitentabellen nach der virtuell zu physikalischen Zuordnung für die Adresse suchen und die Übersetzung zurück an die GPU(s) 1208 übertragen. So kann die Unified-Memory-Technologie einen einzigen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 1206 als auch der GPU(s) 1208 ermöglichen, was die Programmierung der GPU(s) 1208 und die Portierung von Anwendungen auf die GPU(s) 1208 vereinfacht.
Darüber hinaus kann/können die GPU(s) 1208 einen Zugriffszähler umfassen, der die Häufigkeit der Zugriffe der GPU(s) 1208 auf den Speicher anderer Prozessoren verfolgen kann. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
Der/die SoC(s) 1204 kann/können eine beliebige Anzahl von Cache(s) 1212 umfassen, einschließlich der hier beschriebenen. Zum Beispiel kann/können der/die Cache(s) 1212 einen L3-Cache umfassen, der sowohl der/den CPU(s) 1206 als auch der/den GPU(s) 1208 zur Verfügung steht (z. B. der sowohl mit der/den CPU(s) 1206 als auch mit der/den GPU(s) 1208 verbunden ist). Der/die Cache(s) 1212 kann/können einen Write-Back-Cache umfassen, der die Zustände von Zeilen nachverfolgen kann, z. B. durch Verwenden eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann je nach Ausführungsbeispiel 4 MB oder mehr umfassen, obwohl auch kleinere Cache-Größen verwendet werden können.
Der/die SOC(s) 1204 kann eine Arithmetik-Logik-Einheit (ALU(s)) umfassen, die beim Durchführen vom Prozessieren im Zusammenhang mit jeder der Vielfalt von Aufgaben und Operationen des Fahrzeugs 1200, wie zum Beispiel Prozessieren der DNN, eingesetzt werden kann. Zusätzlich kann/können der/die SoC(s)1204 eine Floating-Point- Einheit(en) (FPU(s)), oder andere mathematische Coprozessoren- oder numerische Coprozessoren-Typen, umfassen, zum Durchführen mathematischer Operationen innerhalb des Systems. Zum Beispiel kann/können der/die SoC(s) 104 einen oder mehr FPUs umfassen, die als Ausführungs-Einheiten innerhalb einer CPU(s) 1206 und/oder GPU(s) 1208 integriert sind.
Der/die SoC(s) 1204 kann/können einen oder mehrere Beschleuniger 1214 umfassen (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Der/die SoC(s) 1204 kann/können z. B. einen Hardware-Beschleunigungs-Cluster umfassen, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher umfassen kann. Der große On-Chip-Speicher (z. B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster in die Lage versetzen, neuronale Netzwerke und andere Berechnungen zu beschleunigen. Der Hardware-Beschleunigungscluster kann zur Ergänzung der GPU(s) 1208 und zum Auslagern von einigen der Aufgaben der GPU(s) 1208 verwendet werden (z. B. um mehr Zyklen der GPU(s) 1208 für die Ausführung anderer Aufgaben freizugeben). Der/die Beschleuniger 1214 kann/können beispielsweise für gezielte Arbeitslasten (z. B. Wahrnehmung, Faltungsneuronale Netze (convolutional neural networks, CNNs) usw.) verwendet werden, die stabil genug sind, um für die Beschleunigung geeignet zu sein. Der hier verwendete Begriff „CNN“ kann alle Arten von CNNs umfassen, einschließlich auf Bereichen basierender oder regionaler Faltungsneuronaler Netze (RCNs) und Fast RCNs (z. B. wie für Objekterkennung verwendet).
Der/die Beschleuniger 1214 (z. B. der Hardware-Beschleunigungscluster) kann/können einen Deep-Learning-Beschleuniger (DLA) umfassen. Der/die DLA(s) kann/können eine oder mehrere Tensor Processing Units (TPUs) umfassen, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Operationen pro Sekunde für Deep Learning-Anwendungen und Inferenzieren bereitstellen. Die TPUs können Beschleuniger sein, die für die Ausführung von Bildverarbeitungsfunktionen konfiguriert und optimiert sind (z. B. für CNNs, RCNNs, usw.). Die DLA(s) können weiter für einen bestimmten Satz von neuronalen Netzwerktypen und Fließkommaoperationen sowie Inferenzieren optimiert sein. Das Design der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Universal-GPU und übertrifft die Leistung einer CPU bei weitem. Die TPU(s) kann/können mehrere Funktionen ausführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datentypen sowohl für Features als auch Gewichte sowie Postprozessorfunktionen unterstützt.
Der/die DLA(s) kann/können schnell und effizient neuronale Netze, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für jede von einer Vielfalt von Funktionen ausführen, einschließlich, zum Beispiel und ohne Einschränkung: ein CNN für die Objektidentifikation und -detektierung unter Verwenden von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwenden von Daten von Kamerasensoren; ein CNN für die Erkennung und Identifizierung von Notfallfahrzeugen und die Erkennung unter Verwenden von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und die Identifizierung des Fahrzeugbesitzers unter Verwenden von Daten von Kamerasensoren; und/oder ein CNN für sicherheits- und/oder schutzrelevante Ereignisse.
Der/die DLA(s) kann/können jede Funktion der GPU(s) 1208 ausführen, und durch die Verwendung eines Inferenz-Beschleunigers kann ein Designer beispielsweise entweder den/die DLA(s) oder die GPU(s) 1208 für eine beliebige Funktion vorherbestimmen. Beispielsweise kann der Designer die Verarbeitung von CNNs und Fließkommaoperationen auf den/die DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 1208 und/oder anderen Beschleuniger(n) 1214 überlassen.
Der/die Beschleuniger 1214 (z. B. der Hardware-Beschleunigungscluster) kann/können (einen) programmierbaren Vision Beschleuniger (PVA) umfassen, der hier alternativ auch als Beschleuniger für Computer Vision bezeichnet werden kann. Der/die PVA(s) kann/können so designt und konfiguriert sein, dass er/sie Algorithmen für Computer Vision für fortschrittliche Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented Reality (AR) und/oder Virtual Reality (VR)-Anmeldungen beschleunigt/beschleunigen. Der/die PVA(s) kann/können ein Ausgleich zwischen Performance und Flexibilität bieten. So kann jeder PVA zum Beispiel und ohne Einschränkung eine beliebige Anzahl von RISC-Kernen (Computer mit reduziertem Befehlssatz), direkten Speicherzugriff (Direct Memory Access, DMA) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren irgendeiner der hierin beschriebenen Kameras), Bildsignalprozessor(en) und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher umfassen. Die RISC-Kerne können, je nach Ausführungsbeispiel, jedes einer Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. Die RISC-Kerne können mit einem oder mehreren integrierten Schaltkreisen, anwendungsspezifischen integrierten Schaltkreisen (ASICs) und/oder Speichermitteln implementiert werden. Die RISC-Kerne können z. B. einen Befehls-Cache und/oder einen eng gekoppelten (tightly coupled) RAM umfassen.
Der DMA kann es Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 1206 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Features unterstützen, die verwendet werden, um eine Optimierung der PVA bereitzustellen, einschließlich, aber nicht beschränkt auf die Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. In einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die Blockbreite, Blockhöhe, Blocktiefe, horizontales Blockstepping, vertikales Blockstepping und/oder Tiefenstepping umfassen können.
Die Vektorprozessoren können programmierbare Prozessoren sein, die so gestaltet sein können, dass sie effizient und flexibel die Programmierung für Computer Visions-Algorithmen ausführen und Signalverarbeitungsfähigkeiten bereitstellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen umfassen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA Engine(s) (z. B. zwei DMA Engines) und/oder andere Peripheriegeräte umfassen. Das Vektorverarbeitungs-Subsystem kann als die primäre Verarbeitungs-Engine des PVA arbeiten und kann eine Vektorverarbeitungs-Einheit (VPU), einen Befehls-Cache und/oder einen Vektorspeicher (z. B. VMEM) umfassen. Ein VPU-Kern kann einen digitalen Signalprozessor umfassen, wie z. B. einen SIMD- (Single Instruction, Multiple Data), VLIW- (Very Long Instruction Word) digitalen Signalprozessor. Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit verbessern.
Jeder der Vektorprozessoren kann einen Befehls-Cache umfassen und kann mit einem dedizierten Speicher gekoppelt sein. Als Ergebnis kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren arbeitet. In anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA umfasst sind, so konfiguriert sein, dass sie Datenparallelität verwenden. Zum Beispiel kann in einigen Ausführungsbeispielen die Vielzahl von Vektorprozessoren, die in einem einzelnen PVA enthalten sind, denselben Algorithmus für Computer Vision ausführen, jedoch für unterschiedliche Bereiche eines Bildes. In anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, simultan verschiedene Computer Visions-Algorithmen auf demselben Bild ausführen, oder sogar verschiedene Algorithmen auf sequentiellen Bildern oder Teilen eines Bildes ausführen. Unter anderem kann der Hardware-Beschleunigungs-Cluster eine beliebige Anzahl von PVAs umfassen, und in jedem PVA kann eine beliebige Anzahl von Vektorprozessoren enthalten sein. Darüber hinaus kann/können der/die PVA(s) zusätzlichen ECC-Speicher (Error Correcting Code) umfassen, um die Gesamt-System-Sicherheit zu verbessern.
Der/die Beschleuniger 1214 (z. B. der Hardware-Beschleunigungscluster) kann/können ein Netzwerk für Computer Vision auf dem Chip und SRAM umfassen, um ein SRAM mit hoher Bandbreite und geringer Latenz für den/die Beschleuniger 1214 bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM umfassen, der z. B. und ohne Einschränkung aus acht frei konfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine erweiterte Peripheriebus-Schnittstelle (APB), eine Konfigurations-Schaltungsanordnung, eine Steuerung und einen Multiplexer umfassen. Es kann jeder beliebige Speichertyp verwendet werden. Der PVA und der DLA können auf den Speicher über ein Backbone zugreifen, das dem PVA und dem DLA einen Hochgeschwindigkeitszugriff auf den Speicher ermöglicht. Der Backbone kann ein Netzwerk für Computer Vision auf dem Chip umfassen, das den PVA und den DLA mit dem Speicher verbindet (z. B. unter Verwenden des APB).
Das Netzwerk für Computer Vision auf dem Chip kann eine Schnittstelle umfassen, die vor der Übertragung von Steuersignalen/Adressen/Daten bestimmt, dass sowohl den PVA als auch den DLA einsatzbereite und gültige Signale liefern. Eine solche Schnittstelle kann separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten als auch eine Burst-Kommunikation für die kontinuierliche Datenübertragung vorsehen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, obwohl auch andere Normen und Protokolle verwendet werden können.
In einigen Beispielen kann der/die SoC(s) 1204 einen Echtzeit-Raytracing-Hardwarebeschleuniger umfassen, wie er in der US-Patentanmeldung Nr. 16/101.232 , eingereicht am 10. August 2018, beschrieben ist. Der Echtzeit-Raytracing-Hardwarebeschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeit-Visualisierungssimulationen zu erzeugen, zur RADAR-Signalinterpretation, zur Schallausbreitungssynthese und/oder -analyse, zur Simulation von SONAR-Systemen, zur allgemeinen Wellenausbreitungssimulation, zum Vergleich mit LIDAR-Daten zum Zwecke der Lokalisierung und/oder anderen Funktionen und/oder für andere Verwendungen.
In einigen Ausführungsbeispielen können eine oder mehr Baum-Traversierungseinheiten (tree traversal units, TTUs) zum Ausführen einer oder mehr Raytracing zugehörigen Operationen verwendet werden.
Der/die Beschleuniger 1214 (z. B. der Hardware-Beschleuniger-Cluster) haben ein breites Array an Verwendungen für das autonome Fahren. Der PVA kann ein programmierbarer Visions-Beschleuniger sein, der für Schlüssel-Verarbeitungsschritte in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten des PVA passen gut zu algorithmischen Domänen, die eine vorhersagbare Verarbeitung bei geringer Leistung und niedriger Latenz benötigen. Mit anderen Worten: Der PVA eignet sich gut für halbdichte oder dichte reguläre Berechnungen, selbst bei kleinen Datensätzen, die vorhersagbare Laufzeiten mit geringer Latenz und geringe Leistung benötigen. Daher sind, im Kontext von Plattformen für autonome Fahrzeuge, die PVAs für die Ausführung klassischer Algorithmen für Computer Vision konzipiert, da sie effizient bei der Objekterkennung sind und mit ganzzahliger Mathematik arbeiten.
Zum Beispiel, gemäß einem Ausführungsbeispiel der Technologie, wird der PVA verwendet, um Computer-Stereo-Vision auszuführen. Ein semiglobaler auf Matching basierter Algorithmus kann in einigen Beispielen verwendet werden, obwohl dies nicht als einschränkend gedacht ist. Viele Anwendungen für Level 3-5 autonomes Fahren benötigen fliegendes Bewegungsschätzen/Stereo-Matching (z. B. Struktur von Bewegung, Fußgängererkennung, Spurdetektion, usw.). Der PVA kann eine Computer-Stereo-Vision-Funktion auf Eingaben von zwei monokularen Kameras durchführen.
In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Zum Beispiel kann der PVA verwendet werden, um Roh-RADAR-Daten zu verarbeiten (z. B. unter Verwenden einer 4D Fast Fourier Transformation), um ein verarbeitetes RADAR-Signal zu liefern, bevor der nächste RADAR-Puls emittiert wird. In anderen Beispielen wird der PVA für Laufzeit-Depth-Prozessieren verwendet, indem Roh-Laufzeitdaten verarbeitet werden, um verarbeitete Daten der Laufzeit bereitzustellen, zum Beispiel.
Der DLA kann verwendet werden, um jede Art von Netzwerk zu betreiben, um die Steuerung und die Fahrsicherheit zu verbessern, einschließlich z. B. eines neuronalen Netzwerks, das ein Maß für die Konfidenz für jede Objekterkennung ausgibt. Ein solcher Konfidenzwert kann als Wahrscheinlichkeit interpretiert werden oder als Bereitstellen eines relative „Gewichts“ jeder Erkennung im Vergleich zu anderen Erkennungen. Dieser Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen eher als echt positive Erkennungen als als falsch positive Erkennungen betrachtet werden sollten. Zum Beispiel kann das System einen Schwellwert für die Konfidenz festlegen und nur die Erkennungen, die den Schwellenwert überschreiten, als echt positive Erkennungen betrachten. In einem automatischen Notbremssystem (AEB) würden falsch positive Erkennungen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was offensichtlich unerwünscht ist. Daher sollten nur die zuverlässigsten Erkennungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netz zur Regression des Konfidenzwertes verwenden. Das neuronale Netzwerk kann als Eingabe mindestens eine Teilmenge von Parametern verwenden, wie z. B. die Abmessungen der Bounding Box, die (z. B. von einem anderen Teilsystem) erhaltene Abschätzung der Bodenebene, die Ausgabe des Trägheitsmesseinheit-Sensors (IMU) 1266, die mit der Orientierung des Fahrzeugs 1200 korreliert, die Entfernung, die 3D-Positionsschätzungen des Objekts, die vom neuronalen Netzwerk und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 1264 oder RADAR-Sensor(en) 1260) erhalten werden, und andere.
Der/die SoC(s) 1204 kann/können Datenspeicher 1216 (z. B. ein Memory) umfassen. Der/die Datenspeicher 1216 können On-Chip-Speicher des/der SoC(s) 1204 sein, die neuronale Netzwerke speichern können, die auf der GPU und/oder dem DLA auszuführen sind. In einigen Beispielen kann die Kapazität des/der Datenspeicher(s) 1216 groß genug sein, um mehrere Instanzen von neuronalen Netzen zur Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 1216 kann/können L2 oder L3 Cache(s) 1212 umfassen. Der Verweis auf den/die Datenspeicher 1216 kann den Verweis auf den Speicher umfassen, der mit dem PVA, DLA und/oder anderen Beschleunigern 1214 assoziiert ist, wie hier beschrieben.
Der/die SoC(s) 1204 kann/können einen oder mehr Prozessor(en) 1210 (z. B. eingebettete Prozessoren) umfassen. Der/die Prozessor(en) 1210 kann/können einen Boot- und Leistungsverwaltungsprozessor umfassen, der ein dedizierter Prozessor und ein Subsystem sein kann, um die Boot-Leistung- und - Verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Leistungsverwaltungsprozessor kann ein Teil der Boot-Sequenz des/der SoC(s) 1204 sein und kann Laufzeit-Leistungsverwaltungsdienste bereitstellen. Der Boot-Leistungsversorgungs- und - Verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Systemübergängen mit niedrigem Leistungszustand, Verwaltung von SoC(s) 1204-thermischen und Temperatursensoren und/oder Verwaltung der SoC(s) 1204-Leistungszustände bieten. Jeder Temperatursensor kann als ein Ringoszillator implementiert sein, dessen Ausgabefrequenz proportional zur Temperatur ist, und der/die SoC(s) 1204 kann/können die Ringoszillatoren verwenden, um Temperaturen der CPU(s) 1206, GPU(s) 1208 und/oder des/der Beschleuniger(s) 1214 zu erkennen. Wenn bestimmt wird, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Leistungsverwaltungsprozessor in eine Temperaturfehlerroutine eintreten und den/die SoC(s) 1204 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 1200 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen (z. B. das Fahrzeug 1200 zu einem sicheren Halt bringen).
Der/die Prozessor(en) 1210 kann/können weiter einen Satz von eingebetteten Prozessoren umfassen, die als Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audio-Subsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen und eine breite und flexible Palette von Audio-E/A-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
Der/die Prozessor(en) 1210 kann/können weiter eine „always on“-Prozessor-Engine umfassen, die die notwendigen Hardware-Features zur Unterstützung von Niedrig-Leistungs-Sensormanagement- und von Aufweck-Anwendungsfällen bereitstellen kann. Die „always on“-Prozessor-Engine kann einen Prozessorkern, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z. B. Timer und Interrupt-Controller), verschiedene I/O-Controller-Peripheriegeräte und eine Weiterleitungslogik umfassen.
Der/die Prozessor(en) 1210 kann/können weiter eine Sicherheits-Cluster-Engine umfassen, die ein dediziertes Prozessor-Subsystem umfasst, um das Sicherheitsmanagement von Automobilanwendungen handzuhaben. Die Sicherheits-Cluster-Engine kann zwei oder mehr Prozessorkerne, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z. B. Timer, eine Interrupt-Steuerung usw.) und/oder Routing-Logik umfassen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Lockstep-Modus arbeiten und als ein einziger Kern mit Vergleichslogik funktionieren, um jedwede Unterschiede zwischen ihren Operationen zu erkennen.
Der/die Prozessor(en) 1210 kann/können ferner eine Realtime-Kamera-Engine umfassen, die ein dediziertes Prozessor-Subsystem für das Handhaben von Realtime-Kamera-Management umfassen kann.
Der/die Prozessor(en) 1210 kann/können ferner einen High-Dynamic-Range-Signalprozessor umfassen, der einen Bildsignalprozessor umfasst, der eine Hardware-Engine ist, die Teil der Kamera-Verarbeitungs-Pipeline ist.
Der/die Prozessor(en) 1210 kann/können einen Videobildkompositor umfassen, bei dem es sich um einen Verarbeitungsblock (z. B. auf einem Mikroprozessor implementiert) handeln kann, der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das finale Bild für das Abspielfenster zu erzeugen. Der Videobildkompositor kann eine Linsenverzerrungskorrektur an der/den Weitwinkelkamera(s) 1270, an der/den Surround-Kamera(s) 1274 und/oder an kabineninternen Überwachungskamerasensoren durchführen. Ein kabineninterner Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netzwerk überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein kabineninternes System kann Lippenlesen durchführen, um Autotelefondienste zu aktivieren und einen Telefonanruf zu tätigen, Emails zu diktieren, das Fahrzeugziel zu ändern, das Infotainmentsystem zu aktivieren oder zu ändern und seine Einstellungen zu ändern, oder um stimmenaktiviertes Netzsurfen bereitzustellen. Bestimmte Funktionen sind für den Fahrer nur verfügbar, wenn das Fahrzeug in einem autonomen Modus operiert, und sind sonst gesperrt.
Der Videobildkompositor kann eine verbesserte temporale Rauschunterdrückung sowohl für räumliche als auch temporale Rauschunterdrückung umfassen. Zum Beispiel, wenn in einem Video Bewegung auftritt, gewichtet die Rauschreduktion die Informationen angemessen, verringert das Gewicht von Informationen, die von benachbarten Frames bereitgestellt werden. Wenn ein Bild oder ein Teil eines Bildes keine Bewegung umfasst, kann die temporale Rauschunterdrückung, die vom Videobildkompositor durchgeführt wird, Informationen vom vorherigen Bild verwenden, um Rauschen im aktuellen Bild zu reduzieren.
Der Videobildkompositor kann auch so konfiguriert sein, dass er eine Stereobildentzerrung an Eingabe-Frames der Stereolinse durchführt. Der Videobildkompositor kann weiter für die Komposition der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 1208 nicht benötigt wird, um ständig neue Oberflächen zu rendern. Selbst wenn die GPU(s) 1208 eingeschaltet ist und aktiv 3D-Rendering durchführt, kann der Videobildkompositor verwendet werden, um die GPU(s) 1208 zu entlasten, um die Performance und Reaktionsfähigkeit zu verbessern.
Der/die SoC(s) 1204 kann/können weiterhin eine serielle Mobile-Industry-Processor-Interface (MIPI)-Kameraschnittstelle zum Empfang von Video und Eingabe von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock umfassen, was für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Der/die SoC(s) 1204 kann/können weiter eine Eingabe/Ausgabe-Steuerung(en) umfassen, die per Software gesteuert werden kann/können und für den Empfang von E/A-Signalen verwendet werden kann, die keiner bestimmten Rolle zugeordnet sind.
Der/die SoC(s) 1204 kann/können weiter eine Vielzahl von Peripherieschnittstellen umfassen, um die Kommunikation mit Peripheriegeräten, Audiocodecs, Leistungsverwaltung und/oder anderen Geräten zu ermöglichen. Der/die SoC(s) 1204 kann/können verwendet werden, um Daten von Kameras (z. B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LIDAR-Sensor(en) 1264, RADAR-Sensor(en) 1260 usw., die über Ethernet verbunden sein können), Daten vom Bus 1202 (z. B. Geschwindigkeit des Fahrzeugs 1200, Lenkradposition usw.), Daten von GNSS-Sensor(en) 1258 (z. B. verbunden über Ethernet oder CAN-Bus) zu verarbeiten. Der/die SoC(s) 1204 kann/können weiter dedizierte Hochleistungs-Massenspeicher-Steuerungen umfassen, die ihre eigenen DMA-Engines umfassen können und die verwendet werden können, um die CPU(s) 1206 von routinemäßigen Datenverwaltungsaufgaben zu befreien.
Der/die SoC(s) 1204 kann/können eine End-to-End-Plattform mit einer flexiblen Architektur sein, die die Automatisierungsstufen 3-5 überspannt und dadurch eine umfassende funktionale Sicherheitsarchitektur bereitstellt, die Computer Vision und ADAS-Techniken einsetzt und effizient nutzt für Diversität und Redundanz und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack bereitstellt zusammen mit Deep Learning-Hilfsmitteln. Der/die SoC(s) 1204 kann/können schneller, zuverlässiger und sogar energie- und platzeffizienter sein als herkömmliche Systeme. Zum Beispiel kann/können der/die Beschleuniger 1214, wenn kombiniert mit der/den CPU(s) 1206, der/den GPU(s) 1208 und dem/den Datenspeicher(n) 1216 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Level 3-5 bilden.
Die Technologie stellt daher Fähigkeiten und Funktionalität bereit, welche nicht durch konventionelle Systeme erlangt werden können. Zum Beispiel können Computer Vision Algorithmen auf CPUs ausgeführt werden, die unter Verwenden einer High-Level Programmiersprachen wie die C Programmiersprache konfiguriert sein können, um eine breite Vielfalt von Prozessieralgorithmen über eine breite Vielfalt von visuellen Daten auszuführen. Jedoch sind CPUs oft unfähig, die Performanceansprüche von vielen Computer Vision Anwendungen zu erfüllen, wie die, die mit Ausführzeit und Leistungsverbrauch in Beziehung stehen, zum Beispiel. Insbesondere sind viele CPUs unfähig komplexe Objektdetektionsalgorithmen in Realtime auszuführen, was ein Erfordernis von fahrzeuginternen ADAS-Anwendungen und ein Erfordernis für autonome Fahrzeuge von praktisch Level 3-5 ist.
Im Gegensatz zu konventionellen Systemen erlaubt, mittels Bereitstellens eines CPU-Komplexes, GPU-Komplexes und eines Hardwarebeschleunigungs-Clusters, die hierin beschriebene Technologie, dass neuronale Netzwerke simultan und/oder sequentiell betrieben werden und dass die Ergebnisse miteinander kombiniert werden, um Level 3-5 autonomes Fahren Funktionalität zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder dGPU (z. B. die GPU(s) 1220) ausgeführt wird, eine Text- und Worterkennung umfassen, was es dem Supercomputer erlaubt, Verkehrsschilder zu lesen und zu verstehen, einschließlich Zeichen für die das neuronale Netzwerk nicht spezifisch trainiert wurde. Der DLA kann ferner ein neuronales Netzwerk umfassen, das fähig ist, das Schild zu identifizieren, zu interpretieren und semantisches Verständnis bereitzustellen und das semantische Verständnis an die Wegplanungsmodule, die auf dem CPU-Komplex laufen, weiterzugeben.
Als ein anderes Beispiel können mehrere neuronale Netzwerke simultan laufen, wie dies für Level 3, 4 oder 5 Fahren erforderlich ist. Zum Beispiel kann ein Warnschild, welches aus „Achtung: Blinkende Lichter zeigen Eisbedingungen an“ zusammen mit einem elektrischen Licht besteht, unabhängig oder kollektiv interpretiert werden, mittels mehrerer neuronaler Netzwerke. Das Zeichen selbst kann mittels eines ersten eingesetzten neuronalen Netzwerkes (z. B. ein neuronales Netzwerk, das trainiert wurde) als ein Verkehrsschild, identifiziert werden, der Text „Blinkende Lichter zeigen Eisbedingungen an“ kann mittels eines zweiten eingesetzten neuronalen Netzwerks interpretiert werden, das die Wegplanungssoftware (vorzugsweise auf dem CPU-Komplex ausgeführt) des Fahrzeugs informiert, dass, wenn blinkende Lichter detektiert werden, Eisbedingungen vorhanden sind. Das blinkende Licht kann mittels Betreibens eines dritten eingesetzten neuronalen Netzwerks über mehrere Frames identifiziert werden, was die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Abwesenheit) von blinkenden Lichtern informiert. Alle drei neuronalen Netzwerke können gleichzeitig laufen, zum Beispiel innerhalb des DLA und/oder des/der GPU(s) 1208.
In einigen Ausführungsbeispielen, kann ein CNN für Gesichtserkennung und Fahrzeugbesitzeridentifikation Daten von Kamerasensoren verwenden, um die Präsenz eines autorisierten Fahrers und/oder Besitzer des Fahrzeugs 1200 zu identifizieren. Die „always-on“-Sensor-Prozessier-Engine kann verwendet werden, das Fahrzeug aufzuschließen, wenn sich der Besitzer der Fahrertür nähert und die Lichter anzuschalten, und im Sicherheitsmodus, das Fahrzeug zu sperren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgt/sorgen der/die SoC(s) 1204 für Schutz gegen Diebstahl und/oder Carjacking.
In einem anderen Beispiel kann ein CNN für eine Notfallfahrzeug-Detektion und Identifikation Daten von Mikrophonen 1296 verwenden, um Notfallfahrzeug-Sirenen zu detektieren und identifizieren. Im Gegensatz zu konventionellen Systemen, die generelle Klassifizierer verwenden, um Sirenen zu detektieren und manuell Features extrahieren, verwendet/verwenden der/die SoC(s) 1204 das CNN zum Klassifizieren sowohl von Umgebungs- und Stadtgeräuschen als auch zum Klassifizieren von visuellen Daten. In einem bevorzugten Ausführungsbeispiel ist das CNN, das auf dem DLA läuft, trainiert, um die relative Annäherungsgeschwindigkeit des Notfallfahrzeugs (z. B. unter Verwenden des Dopplereffekts) zu identifizieren. Das CNN kann auch trainiert sein, um Notfallfahrzeuge spezifisch für die lokale Gegend, in der das Fahrzeug operiert, wie mittels des/der GNSS Sensoren 1258 identifiziert, zu identifizieren. Daher wird, zum Beispiel, wenn es in Europa operiert, das CNN versuchen, europäische Sirenen zu detektieren, und wenn es in den Vereinigten Staaten ist, wird das CNN versuchen nur nordamerikanische Sirenen zu identifizieren. Sobald ein Notfallfahrzeug detektiert wird, kann ein Steuerprogramm verwendet werden, um eine Notfallfahrzeug-Sicherheitsroutine auszuführen, abbremsen des Fahrzeugs, auf die Seite der Straße fahren, parken des Fahrzeugs und/oder das Fahrzeug im Leerlauf laufen lassen, unter Assistenz von Ultraschallsensoren 1262 bis das/die Notfallfahrzeug(e) vorbei sind.
Das Fahrzeug kann eine CPU(s) 1218 (z. B. diskrete CPU(s) oder dCPU(s)) umfassen, die an den/die SoC(s) 1204 mittels eines Hochgeschwindigkeits-Interconnects (z. B. PCle) gekoppelt ist. Die CPU(s) 1218 kann/können zum Beispiel einen X86 Prozessor umfassen. Die CPU(s) 1218 kann/können verwendet werden, um eine Vielfalt an Funktionen durchzuführen, einschließlich Vermitteln bei potentiell inkonsistenter Ergebnisse zwischen ADAS Sensoren und des/der SoC(s) 1204 und/oder Überwachen des Status und Gesundheit der Steuerung(en) 1236 und/oder des Infotainment-SoC 1230, zum Beispiel.
Das Fahrzeug 1200 kann eine GPU(s) 1220 (z. B. diskrete GPU(s) oder dGPU(s)) umfassen, die an den/die SoC(s) 1204 mittels eines Hochgeschwindigkeits-Interconnects (z. B. NVLINK von NVIDIA)) gekoppelt sein kann. Die GPU(s) 1220 kann/können zusätzliche künstliche-Intelligenz-Funktionalität, wie zum Beispiel mittels Ausführens redundanter und/oder anderer neuronaler Netzwerke, bereitstellen und kann/können verwendet werden, um neuronale Netzwerke, basierend auf Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 1200, zu trainieren und/oder upzudaten.
Das Fahrzeug 1200 kann weiterhin die Netzwerkschnittstelle 1224 umfassen, die eine oder mehrere drahtlose Antennen 1226 umfassen kann (z. B. eine oder mehrere drahtlose Antennen für verschiedene Kommunikationsprotokolle, wie eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzwerkschnittstelle 1224 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit dem/den Server(n) 1278 und/oder anderen Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Rechengeräten (z. B. Client-Geräten von Fahrgästen) zu ermöglichen. Um mit anderen Fahrzeugen zu kommunizieren, kann eine direkte Verbindung zwischen den beiden Fahrzeugen hergestellt werden und/oder eine indirekte Verbindung (z. B. über Netzwerke und das Internet). Direkte Verbindungen können über eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 1200 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 1200 liefern (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 1200). Diese Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktionalität des Fahrzeugs 1200 sein.
Die Netzwerkschnittstelle 1224 kann einen SoC umfassen, der Modulations- und Demodulationsfunktionalität bereitstellt und der/den Steuerung(en) 1236 ermöglicht/ermöglichen, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 1224 kann ein Funkfrequenz-Frontend für die Aufwärtskonvertierung von Basisband auf Funkfrequenz und die Abwärtskonvertierung von Funkfrequenz auf Basisband umfassen. Die Frequenzumwandlungen können durch bekannte Verfahren durchgeführt werden und/oder können mit Super-Heterodyn-Verfahren durchgeführt werden. In einigen Beispielen kann die Funktionalität des Hochfrequenz-Frontend durch einen separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann drahtlose Funktionalität zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA 2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle umfassen.
Das Fahrzeug 1200 kann weiter einen oder mehrere Datenspeicher 1228 umfassen, die einen Speicher außerhalb des Chips (z. B. außerhalb des/der SoC(s) 1204) umfassen können. Der/die Datenspeicher 1228 kann/können ein oder mehrere Speicherelemente umfassen, einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte, die mindestens ein Datenbit speichern können.
Das Fahrzeug 1200 kann weiterhin GNSS-Sensor(en) 1258 umfassen (z. B. GPS- und/oder unterstützte GPS-Sensoren), um die Funktionen Kartierung, Wahrnehmung, Erzeugung von Belegungsrastern und/oder Pfadplanung zu unterstützen. Es kann eine beliebige Anzahl von GNSS-Sensor(en) 1258 verwendet werden, die z. B. und ohne Einschränkung ein GPS umfassen, das einen USB-Anschluss mit einer Ethernet-zu-Seriell (RS-232)-Brücke verwendet.
Das Fahrzeug 1200 kann weiterhin RADAR-Sensor(en) 1260 umfassen. Der/die RADAR-Sensor(en) 1260 kann/können vom Fahrzeug 1200 zur Lang-Reichweiten-Fahrzeugdetektion verwendet werden, auch bei Dunkelheit und/oder schlechten Wetterbedingungen. Die funktionalen RADAR-Sicherheitsstufen können ASIL B sein. Der/die RADAR-Sensor(en) 1260 kann/können den CAN und/oder den Bus 1202 (z. B. zur Übertragung der von dem/den RADAR-Sensor(en) 1260 erzeugten Daten) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, mit Zugriff auf Ethernet, um auf Rohdaten zuzugreifen, in einigen Beispielen. Es kann eine Vielzahl von RADAR-Sensortypen verwendet werden. Beispielsweise und ohne Einschränkung kann der/die RADAR-Sensor(en) 1260 für die Verwendung als Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen wird/werden Puls-Doppler-RADAR-Sensor(en) verwendet.
Der/die RADAR-Sensor(en) 1260 kann/können verschiedene Konfigurationen umfassen, wie z. B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit weitem Sichtfeld, seitliche Abdeckung kurzer Reichweite usw. In einigen Beispielen kann RADAR mit großer Reichweite für die adaptive Geschwindigkeitsregelungsfunktionalität verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein weites Sichtfeld bieten, das durch zwei oder mehr unabhängige Scans realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 1260 kann/können bei der Unterscheidung zwischen statischen und sich bewegenden Objekten helfen und kann/können von ADAS-Systemen für Notbremsassistenten und Vorwärtskollisionswarnungen verwendet werden. Langstrecken-RADAR-Sensoren können monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle umfassen. In einem Beispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Strahlenmuster erzeugen, das so gestaltet ist, dass es die Umgebung des Fahrzeugs mit höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den angrenzenden Fahrspuren erfasst. Die beiden anderen Antennen können das Sichtfeld erweitern, so dass Fahrzeuge, die in die Fahrspur des Fahrzeugs 1200 einfahren oder diese verlassen, schnell erkannt werden können.
RADAR-Systeme mit mittlerer Reichweite können z. B. eine Reichweite von bis zu 1260 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 1250 Grad (hinten) umfassen. RADAR-Systeme mit kurzer Reichweite können, ohne Einschränkung, RADAR-Sensoren umfassen, die für die Installation an beiden Enden des hinteren Stoßfängers ausgelegt sind. Wenn ein solches RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers installiert ist, kann es zwei Strahlen erzeugen, die ständig den toten Winkel im hinteren Bereich und nahe dem Fahrzeug überwachen.
RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Toter-Winkel-Detektion und/oder als Spurwechselassistent verwendet werden.
Das Fahrzeug 1200 kann weiterhin Ultraschallsensor(en) 1262 umfassen. Der/die Ultraschallsensor(en) 1262, der/die an der Vorderseite, an der Rückseite und/oder an den Seiten des Fahrzeugs 1200 positioniert sein kann/können, kann/können zur Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsrasters verwendet werden. Es kann eine Vielzahl von Ultraschallsensoren 1262 verwendet werden, und es können unterschiedliche Ultraschallsensoren 1262 für unterschiedliche Erfassungsbereiche (z. B. 2,5 m, 4 m) verwendet werden. Der/die Ultraschallsensor(en) 1262 kann/können bei funktionalen Sicherheitsstufen von ASIL B arbeiten.
Das Fahrzeug 1200 kann LIDAR-Sensor(en) 1264 umfassen. Der/die LIDAR-Sensor(en) 1264 kann/können für Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 1264 kann/können funktionale Sicherheitsstufe ASIL B sein. In einigen Beispielen kann das Fahrzeug 1200 mehrere LIDAR-Sensoren 1264 umfassen (z. B. zwei, vier, sechs usw.), die Ethernet verwenden können (z. B. um Daten an einen Gigabit-Ethernet-Switch zu liefern).
In einigen Beispielen kann/können der/die LIDAR-Sensor(en) 1264 in der Lage sein, eine Liste von Objekten und deren Abstände für ein 360-Grad-Sichtfeld zu liefern. Kommerziell erhältliche(r) LIDAR-Sensor(en) 1264 kann/können eine bekanntgemachte Reichweite von ca. 100 m haben, mit einer Genauigkeit von 2 cm-3 cm und mit Unterstützung für eine 100 Mbps Ethernet-Verbindung, zum Beispiel. In einigen Beispielen kann/können ein oder mehrere nicht vorspringende LIDAR-Sensoren 1264 verwendet werden. In solchen Beispielen kann der/die LIDAR-Sensor(en) 1264 als kleines Gerät implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 1200 eingebettet werden kann. Der/die LIDAR-Sensor(en) 1264 kann/können in solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von 35 Grad bieten, mit einer Reichweite von 200 m selbst für Objekte mit geringer Reflektivität. Der/die frontseitige(n) LIDAR-Sensor(en) 1264 kann/können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert werden.
In einigen Beispielen können auch LIDAR-Technologien, wie 3D-Blitz-LIDAR, verwendet werden. 3D-Blitz-LIDAR verwendet einen Laserblitz als Sendequelle, um die Fahrzeugumgebung bis zu einer Entfernung von ca. 200 m zu beleuchten. Eine Blitz-LIDAR-Einheit umfasst einen Rezeptor, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum dem Bereich vom Fahrzeug zu den Objekten entspricht. Blitz-LIDAR kann erlauben mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebungen zu erzeugen. In einigen Beispielen können vier Blitz-LIDAR Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 1200. Erhältliche 3D-Blitz-LIDAR Systeme umfassen eine Festkörper 3D-starrendes-Array-LIDAR-Kamera mit keinen beweglichen Teilen außer einem Lüfter (z. B. eine nicht scannende LIDAR-Vorrichtung). Die Blitz-LIDAR-Vorrichtung kann einen fünf Nanosekunden Klasse I (augensicheren) Laserpuls je Frame verwenden und kann das reflektierte Laserlicht in der Form von 3D Reichweitenpunkte-Wolken und mitregistrierten Intensitätsdaten aufnehmen. Durch Verwenden von Blitz-LIDAR, und weil Blitz-LIDAR eine Festkörper-Vorrichtung ohne bewegliche Teile ist, kann/können der/die LIDAR Sensor(en) 1264 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Erschütterungen sein.
Das Fahrzeug kann weiterhin IMU-Sensor(en) 1266 umfassen. Der/die IMU-Sensor(en) 1266 kann/können in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 1200 angeordnet sein. Der/die IMU-Sensor(en) 1266 kann/können z. B. und ohne Einschränkung einen oder mehrere Beschleunigungsmesser, einen oder mehrere Magnetometer, ein oder mehrere Gyroskope, einen oder mehrere Magnetkompasse und/oder andere Sensortypen umfassen. In einigen Beispielen, wie z. B. bei sechsachsigen Anwendungen, können der/die IMU-Sensor(en) 1266 Beschleunigungsmesser und Gyroskope umfassen, während bei neunachsigen Anwendungen der/die IMU-Sensor(en) 1266 Beschleunigungsmesser, Gyroskope und Magnetometer umfassen können.
In einigen Ausführungsbeispielen kann/können der/die IMU-Sensor(en) 1266 als ein miniaturisiertes, hochleistungsfähiges GPS-gestütztes Trägheitsnavigationssystem (GPS/INS) implementiert werden, das MEMS-Trägheitssensoren, einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen kombiniert, um Abschätzungen von Position, Geschwindigkeit und Lage zu liefern. Als solches kann/können in einigen Beispielen der/die IMU-Sensor(en) 1266 das Fahrzeug 1200 in die Lage versetzen, den Kurs abzuschätzen, ohne dass eine Eingabe von einem Magnetsensor erforderlich ist, mittels direkten Beobachtens und Korrelierens der Änderungen in Geschwindigkeit vom GPS mit dem/den IMU-Sensor(en) 1266. In einigen Beispielen können der/die IMU-Sensor(en) 1266 und der/die GNSS-Sensor(en) 1258 in einer einzigen integrierten Einheit kombiniert werden.
Das Fahrzeug kann das/die Mikrofon(e) 1296 umfassen, die im und/oder um das Fahrzeug 1200 herum angebracht sind. Das/die Mikrofon(e) 1296 kann/können u. a. zum Detektieren und Identifizieren von Notfallfahrzeugen verwendet werden.
Das Fahrzeug kann weiterhin eine beliebige Anzahl von Kameratypen umfassen, z. B. Stereokamera(s) 1268, Weitwinkelkamera(s) 1270, Infrarotkamera(s) 1272, Umgebungskamera(s) 1274, Fern- und/oder Mittelbereichskamera(s) 1298 und/oder andere Kameratypen. Die Kameras können zur Erfassung von Bilddaten rund um einen gesamten Umfang des Fahrzeugs 1200 verwendet werden. Die verwendeten Kameratypen hängen von den Ausführungsbeispielen und Anforderungen für das Fahrzeug 1200 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 1200 herum zu gewährleisten. Darüber hinaus kann die Anzahl der Kameras je nach Ausführungsbeispiel unterschiedlich sein. Das Fahrzeug kann z. B. sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras umfassen. Die Kameras können, als Beispiel und ohne Einschränkung, Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kamera(s) wird hierin mit Bezug auf 10 und 11 detaillierter beschrieben.
Das Fahrzeug 1200 kann weiterhin den/die Vibrationssensor(en) 1242 umfassen. Der/die Vibrationssensor(en) 1242 kann/können Vibrationen von Komponenten des Fahrzeugs, wie z. B. der Achse(n), messen. Zum Beispiel können Änderungen der Vibrationen eine Änderung der Straßenoberfläche anzeigen. In einem anderen Beispiel, wenn zwei oder mehr Vibrationssensoren 1242 verwendet werden, können die Unterschiede zwischen den Vibrationen verwendet werden, um die Reibung oder den Schlupf der Fahrbahnoberfläche zu bestimmen (z. B. wenn der Unterschied in der Vibration zwischen einer angetriebenen Achse und einer frei rotierenden Achse besteht).
Das Fahrzeug 1200 kann ein ADAS-System 1238 umfassen. Das ADAS-System 1238 kann in einigen Beispielen einen SoC umfassen. Das ADAS-System 1238 kann eine autonome/adaptive/automatische Geschwindigkeitsreglung (ACC), eine kooperative adaptive Geschwindigkeitsreglung (CACC), eine Auffahrwarnung (FCW), eine automatische Notbremsung (AEB), einen Spurverlassenswarnung (LDW), einen Spurhalteassistenten (LKA), einen Toter-Winkel-Warner (BSW), einen rückwärtigen-Querverkehrswarner (rear cross-traffic warning, RCTW), ein Kollisionswarnsystem (CWS), eine Spurenzentrierung (LC) und/oder andere Features und Funktionalitäten umfassen.
Die ACC-Systeme können RADAR-Sensor(en) 1260, LIDAR-Sensor(en) 1264 und/oder eine Kamera(s) verwenden. Die ACC-Systeme können Längs-ACC und/oder Quer-ACC umfassen. Der Längs-ACC überwacht und regelt den Abstand zum unmittelbar vorausfahrenden Fahrzeug 1200 und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Der Quer-ACC führt die Abstandshaltung durch und empfiehlt dem Fahrzeug 1200, die Spur zu wechseln, wenn dies erforderlich ist. Quer-ACC ist mit anderen ADAS-Anwendungen wie LC und CWS verwandt.
CACC nutzt Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 1224 und/oder die Funkantenne(n) 1226 von anderen Fahrzeugen über eine drahtlose Verbindung oder indirekt über eine Netzwerkverbindung (z. B. über das Internet) empfangen werden können. Direkte Verbindungen können durch eine Fahrzeug-zu-Fahrzeug (V2V)-Kommunikationsverbindung bereitgestellt werden, während indirekte Verbindungen eine Infrastruktur-zu-Fahrzeug (12V)-Kommunikationsverbindung sein können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Informationen über die unmittelbar vorhergehenden Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem Fahrzeug 1200 und auf derselben Spur wie dieses befinden), während das 12V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr liefert. CACC-Systeme können entweder irgendeine der beiden oder beide 12V- und V2V-Informationsquellen umfassen. Aufgrund der Informationen über die Fahrzeuge vor dem Fahrzeug 1200 kann CACC zuverlässiger sein und es hat das Potenzial, den Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
FCW-Systeme sind so konstruiert, dass sie den Fahrer vor einer Gefahr warnen, so dass er korrigierende Handlungen vornehmen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 1260, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung ausgeben, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
AEB-Systeme detektieren eine drohende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines spezifizierten Zeit- oder Abstandsparameters korrigierend eingreift. AEB-Systeme können nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1260 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr detektiert, warnt es typischerweise zuerst den Fahrer, damit er korrigierende Maßnahmen ergreift, um die Kollision zu vermeiden, und wenn der Fahrer keine korrigierenden Maßnahmen ergreift, kann das AEB-System automatisch die Bremsen betätigen, in einem Versuch die Auswirkungen der vorhergesagten Kollision zu verhindern oder zumindest abzuschwächen. AEB-Systeme können Techniken wie eine dynamische Bremsunterstützung und/oder eine Bremsung bei bevorstehenden Unfall umfassen.
LDW Systeme stellen optische, hörbare und/oder taktile Warnungen, wie zum Beispiel Lenkrad- oder Sitzvibrationen, bereit, um den Fahrer zu alarmieren, wenn das Fahrzeug 1200 Spurmarkierungen überfährt. Ein LDW System aktiviert nicht, wenn der Fahrer mittels Aktivierens des Blinkers ein absichtliches Spurverlassen anzeigt. LDW Systeme können zur Vorderseite gerichtete Kameras verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
LKA Systeme sind eine Abwandlung von LDW Systemen. LKA Systeme stellen eine Lenkeingabe oder Bremsen bereit, um das Fahrzeug 1200 zu korrigieren, wenn das Fahrzeug beginnt, die Spur zu verlassen.
BSW Systeme detektieren und warnen den Fahrer vor Fahrzeugen im toten Winkel eines Fahrzeugs. BSW Systeme können optische, hörbare und/oder taktile Warnungen bereitstellen, um anzuzeigen, dass ein Zusammenführen oder Wechseln von Spuren unsicher ist. Das System kann eine zusätzliche Warnung bereitstellen, wenn der Fahrer einen Blinker verwendet. BSW Systeme können zur Rückseite gerichtete Kameras und/oder RADAR Sensor(en) 1260 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit Fahrerfeedback gekoppelt ist,
z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
RCTW Systeme können optische, hörbare und/oder taktile Benachrichtigungen bereitstellen, wenn ein Objekt außerhalb des Rückkamerabereichs detektiert wird, wenn das Fahrzeug 1200 rückwärtsfährt. Einige RCTW Systeme umfassen AEB um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. RCTW Systeme können ein oder mehr rückwärts gerichtete RADAR Sensor(en) 1260 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
Herkömmliche ADAS Systeme können anfällig für falsch positive Ergebnisse sein, was ärgerlich und störend für einen Fahrer sein kann, aber typischerweise nicht katastrophal ist, weil ADAS Systeme den Fahrer alarmieren und dem Fahrer erlauben, zu entscheiden, ob eine Sicherheitskondition wirklich vorhanden ist und entsprechend zu handeln. Jedoch muss in einem autonomen Fahrzeug 1200 das Fahrzeug 1200 selber, im Falle von widersprüchlichen Ergebnissen, entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. einer ersten Steuerung 1236 oder einer zweiten Steuerung 1236) beachtet. Zum Beispiel kann das ADAS System 1238 ein Backup oder sekundärer Computer zum Bereitstellen von Wahrnehmungsinformation an ein Backup-Computer Rationalitäts-Modul (rationality module) sein. Auf dem Backup-Computer Rationalitäts-Monitor kann eine redundante diversitäre Software auf Hardwarekomponenten laufen, um Fehler in der Wahrnehmung und dynamischen Fahraufgaben zu detektieren. Ausgaben des ADAS System 1238 können einer überwachenden MCU bereitgestellt werden. Wenn Ausgaben des primären Computers und des sekundären Computers in Konflikt sind, muss die überwachende MCU entscheiden, wie der Konflikt beizulegen ist, um sichere Operation zu gewährleisten.
In einigen Ausführungsbeispielen kann der primäre Computer konfiguriert sein, der überwachenden MCU einen Konfidenzwert bereitzustellen, der die Konfidenz des primären Computers in das gewählte Ergebnis anzeigt. Wenn der Konfidenzwert einen Schwellwert überschreitet, kann die überwachende MCU der Richtung des primären Computers folgen, unabhängig ob der sekundäre Computer ein widersprechendes oder inkonsistentes Ergebnis bereitstellt. Wo der Konfidenzwert nicht den Schwellwert erfüllt, und wo der primäre Computer und der sekundäre Computer unterschiedliche Ergebnisse liefern (z. B. der Konflikt), kann das überwachende MCU zwischen den Computern vermitteln, um die adäquate Folge zu bestimmen.
Die überwachende MCU kann konfiguriert sein, ein neuronales Netzwerk(e) auszuführen, das trainiert und konfiguriert ist, um, basierend auf Ausgaben vom primären Computer und vom sekundären Computer, Bedingungen, unter denen der sekundäre Computer Fehlalarme bereitstellt, zu bestimmen. Daher kann das/die neuronalen Netzwerk(e) in der überwachenden MCU lernen, wann der Ausgabe des sekundären Computers vertraut werden kann und wann nicht. Zum Beispiel kann, wenn der sekundäre Computer ein RADAR-basiertes FCW System ist, ein neuronales Netzwerk(e) in der überwachenden MCU lernen, wann das FCW System metallische Objekte identifiziert, die tatsächlich keine Gefahren sind, wie ein Ablaufgitter oder ein Gullydeckel, die einen Alarm triggern. Ähnlich kann, wenn der sekundäre Computer ein kamerabasiertes LDW System ist, ein neuronales Netzwerk in der überwachenden MCU lernen, sich über das LDW hinwegzusetzen, wenn Fahrradfahrer oder Fußgänger anwesend sind und ein Spurwechseln tatsächlich das sicherste Manöver ist. In Ausführungsbeispielen die ein Laufenlassen von (einem) neuronalen Netzwerk(en) auf der überwachenden MCU umfassen, kann die überwachende MCU zumindest eines von einem DLA oder GPU, geeignet zum Laufenlassen des/der neuronalen Netzwerk(e), mit assoziierten Speicher, umfassen. In bevorzugten Ausführungsbeispielen, kann die überwachende MCU eine Komponente der SoC(s) 1204 aufweisen und/oder als eine Komponente der SoC(s) 1204 eingefügt sein.
In anderen Beispielen kann das ADAS System 1238 einen sekundären Computer umfassen, der ADAS Funktionalität durchführt, unter Verwenden von traditionellen Regeln von Computer Vision. Als solches kann der sekundäre Computer klassische Computer Visionsregeln (if-then) verwenden und das Vorhandensein eines neuronalen Netzwerks/e in der überwachenden MCU kann die Zuverlässigkeit, Sicherheit und Performance verbessern. Zum Beispiel macht die verschiedenartige Implementierung und die beabsichtigte Nicht-Gleichheit das Gesamtsystem fehlertoleranter insbesondere gegenüber Fehlern durch Software (oder Software-Hardware-Schnittstelle)-Funktionalität. Zum Beispiel kann, wenn es einen Softwarebug oder Fehler in der Software, die auf dem primären Computer läuft, gibt, und der Nicht-Gleiche Softwarecode, der auf dem sekundären Computer läuft, stellt das gleiche Gesamtergebnis bereit, die überwachende MCU größeres Vertrauen haben, dass das Gesamtergebnis korrekt ist und der Bug in der Software oder Hardware, die durch den primären Computer verwendet wird, verursacht keinen materiellen Fehler.
In einigen Beispielen kann die Ausgabe des ADAS Systems 1236 in den Wahrnehmungsblock (perception block) des primären Computers und/oder den dynamischen Fahr-Aufgaben-Block (dynamic driving task block) des primären Computers gegeben werden. Zum Beispiel kann, wenn das ADAS System 1238 wegen eines Objekts unmittelbar voraus eine Vorwärts-Auffahrunfallwarnung anzeigt, der Wahrnehmungsblock diese Information nutzen, wenn Objekte identifiziert werden. In anderen Beispielen, kann der sekundäre Computer sein eigenes neuronales Netzwerk haben, das trainiert ist und daher das Risiko von Falsch-Positiven verringern, wie hierin beschrieben.
Das Fahrzeug 1200 kann weiter das Infotainment-SoC 1230 umfassen (z. B. ein fahrzeuginternes Infotainment-System (IVI)). Obwohl als SoC gezeigt und beschrieben, mag das Infotainment-System kein SoC sein und kann zwei oder mehr diskrete Komponenten umfassen. Das Infotainment-SoC 1230 kann eine Kombination aus Hardware und Software umfassen, die zur Bereitstellung von Audio (z. B. Musik, einem persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon (z. B. Freisprechen), Netzwerkkonnektivität (z. B., LTE, WiFi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Rückwärts-Einparkhilfe, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremsflüssigkeitsstand, Ölstand, Tür offen/zu, Luftfilterinformationen usw.) an das Fahrzeug 1200 verwendet wird. Der Infotainment-SoC 1230 kann z. B. Radios, CD-Spieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, WiFi, Audiobedienelemente am Lenkrad, freihändige Stimmensteuerung, ein Heads-up-Display (HUD), eine HMI-Anzeige 1234, ein Telematikgerät, ein Steuerungspaneel (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Feature und/oder Systemen) und/oder andere Komponenten umfassen. Der Infotainment-SoC 1230 kann ferner verwendet werden, um einen Benutzer(n) des Fahrzeugs Informationen (z. B. visuell und/oder hörbar) bereitzustellen, wie beispielsweise Informationen vom ADAS System 1238, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Informationen zur umliegenden Umgebung (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen, usw.) und/oder andere Informationen.
Der Infotainment-SoC 1230 kann GPU-Funktionalität umfassen. Der Infotainment-SoC 1230 kann über den Bus 1202 (z. B. CAN-Bus, Ethernet usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 1200 kommunizieren. In einigen Beispielen kann der Infotainment-SoC 1230 mit einer Überwachungs-MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige selbstfahrende Funktionen ausführen kann, wenn die primäre(n) Steuerung(en) 1236 (z. B. die primären und/oder Backup-Computer des Fahrzeugs 1200) ausfallen. In einem solchen Beispiel kann der Infotainment-SoC 1230 das Fahrzeug 1200 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen, wie hier beschrieben.
Das Fahrzeug 1200 kann weiterhin ein Instrumentencluster 1232 umfassen (z. B. ein digitales Armaturenbrett, ein Elektronisches-Instrument Cluster, eine Digitales-Instrument Panel usw.). Das Instrumentencluster 1232 kann eine Steuerung und/oder einen Supercomputer umfassen (z. B. eine diskrete Steuerung oder einen Supercomputer). Das Instrumentencluster 1232 kann einen Satz von Instrumentation umfassen, wie z. B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltpositionsanzeige, Sicherheitsgurt-Warnleuchte(n), Feststellbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Airbag (SRS)-Systeminformationen, Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen, usw. In einigen Beispielen können die Informationen angezeigt und/oder vom Infotainment-SoC 1230 und dem Instrumentencluster 1232 gemeinsam genutzt werden. Mit anderen Worten, das Instrumentencluster 1232 kann als Teil des Infotainment-SoC 1230 eingefügt sein oder umgekehrt.
13 ist ein Systemdiagramm für die Kommunikation zwischen dem/den Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug 1000 von 10A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das System 1376 kann den/die Server 1378, das/die Netzwerk(e) 1390 und die Fahrzeuge, einschließlich des Fahrzeugs 1300, umfassen. Der/die Server 1378 kann/können eine Vielzahl von GPUs 1384(A)-1384(H) (hierin kollektiv als GPUs 1384 bezeichnet), PCIe-Switches 1382(A)-1382(H) (hierin kollektiv als PCIe-Switches 1382 bezeichnet), und/oder CPUs 1380(A)-1380(B) (hierin kollektiv als CPUs 1380 bezeichnet) umfassen. Die GPUs 1384, die CPUs 1380 und die PCIe-Switches können über Hochgeschwindigkeits-Interconnects miteinander verbunden sein, wie z. B. und ohne Einschränkung die von NVIDIA entwickelten NVLink-Schnittstellen 1388 und/oder PCIe-Verbindungen 1386. In einigen Beispielen sind die GPUs 1384 über NVLink und/oder NVSwitch SoC und die GPUs 1384 und die PCIe-Switches 1382 über PCIe-Interconnects verbunden. Obwohl acht GPUs 1384, zwei CPUs 1380 und zwei PCIe-Switches gezeigt werden, ist dies nicht als Einschränkung zu verstehen. Je nach Ausführungsbeispiel kann jeder der Server 1378 eine beliebige Anzahl von GPUs 1384, CPUs 1380 und/oder PCIe-Switches umfassen. Der/die Server 1378 kann/können beispielsweise jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1384 umfassen.
Der/die Server 1378 kann/können über das/die Netzwerk(e) 1390 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenzustände zeigen, z. B. kürzlich begonnene Straßenarbeiten. Der/die Server 1378 kann/können über das/die Netzwerk(e) 1390 und an die Fahrzeuge neuronale Netzwerke 1392, aktualisierte neuronale Netze 1392 und/oder Karteninformationen 1394 übertragen, einschließlich Informationen zu Verkehrs- und Straßenbedingungen. Die Aktualisierungen der Karteninformationen 1394 können Aktualisierungen für die HD-Karte 1322 umfassen, z. B. Informationen zu Baustellen, Schlaglöchern, Umleitungen, Überschwemmungen und/oder anderen Hindernissen. In einigen Beispielen können die neuronalen Netzwerke 1392, die aktualisierten neuronalen Netzwerke 1392 und/oder die Karteninformationen 1394 aus neuem Training und/oder Erfahrungen resultieren, die in Daten dargestellt sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder basierend auf Training, das an einem Rechenzentrum durchgeführt wurde (z. B. unter Verwenden des/der Server(s) 1378 und/oder anderer Server).
Der/die Server 1378 kann/können verwendet werden, um Modelle für maschinelles Lernen (z. B. neuronale Netzwerke) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen erzeugt werden und/oder können in einer Simulation erzeugt werden (z. B. unter Verwenden einer Game Engine). In einigen Beispielen werden die Trainingsdaten mit Tags versehen (z. B. wenn das neuronale Netzwerk von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B. wenn das neuronale Netzwerk kein überwachtes Lernen benötigt). Training kann gemäß irgendeiner oder mehrerer Klassen von Maschinenlerntechniken durchgeführt werden, einschließlich und ohne Beschränkung Klassen wie: überwachtes Lernen, teilüberwachtes Lernen, unüberwachtes Lernen, Selbstlernen, bestärkendes Lernen, föderales Lernen, Transfer Learning, Feature-Learning (einschließlich Hauptkomponenten und Clusteranalyse), Multilinear-Subspace-Learning, Nichtlineare dimensionale Reduktion (manifold learning), Repräsentationslernen (representation learning) (einschließlich Ersatz-Wörterbuch-Lernen), regelbasiertes Maschinenlernen, Anomalie-Detektion und alle Varianten oder Kombinationen dafür. Sobald die maschinellen Lernmodelle trainiert sind, können die maschinellen Lernmodelle von den Fahrzeugen verwendet werden (z. B. über das/die Netzwerk(e) 1390 an die Fahrzeuge übertragen werden), und/oder die maschinellen Lernmodelle können von dem/den Server(n) 1378 verwendet werden, um die Fahrzeuge aus der Ferne zu überwachen.
In einigen Beispielen kann/können der/die Server 1378 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle Echtzeit neuronale Netzwerke für intelligentes Inferenzieren in Echtzeit anwenden. Der/die Server 1378 kann/können Deep Learning-Supercomputer und/oder dedizierte KI-Computer umfassen, die von GPU(s) 1384 angetrieben werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX Station-Maschinen. In einigen Beispielen kann/können der/die Server 1378 jedoch eine Deep Learning-Infrastruktur umfassen, die nur CPU-betriebene Rechenzentren verwendet.
Die Deep Learning-Infrastruktur des/der Server(s) 1378 kann zu schnellem Echtzeit Inferenzieren fähig sein und kann diese Fähigkeit nutzen, um den Zustand der Prozessoren, der Software und/oder der assoziierten Hardware im Fahrzeug 1300 zu evaluieren und zu verifizieren. Beispielsweise kann die Deep Learning-Infrastruktur periodische Updates vom Fahrzeug 1300 erhalten, wie eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 1300 in dieser Sequenz von Bildern lokalisiert hat (z. B. über Computer Vision und/oder andere maschinelle Objektklassifizierungstechniken). Die Deep Learning-Infrastruktur kann ihr eigenes neuronales Netzwerk ausführen, um die Objekte zu identifizieren und sie mit den vom Fahrzeug 1300 identifizierten Objekten zu vergleichen und wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 1300 eine Fehlfunktion aufweist, kann/können der/die Server 1378 ein Signal an das Fahrzeug 1300 senden, was einen ausfallsicheren Computer des Fahrzeugs 1300 anweist, die Steuerung zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver zu komplettieren.
Zum Inferenzieren kann/können der/die Server 1378 die GPU(s) 1384 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT von NVIDIA) umfassen. Die Kombination aus GPU-betriebenen Servern und Inferenz-Beschleunigung kann eine Echtzeit-Reaktionsfähigkeit ermöglichen. In anderen Beispielen, z. B. wenn die Performance weniger kritisch ist, können mit CPUs, FPGAs und anderen Prozessoren betriebene Server zum Inferenzieren verwendet werden.
BEISPIELHAFTES RECHENGERÄT
14 ist ein Blockdiagramm eines beispielhaften Rechengeräts 1400, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist. Das Rechengerät 1400 kann ein Interconnect-System 1402 umfassen, das direkt oder indirekt die folgenden Geräte koppelt: Speicher 1404, eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 1406, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1408, eine Kommunikationsschnittstelle 1410, Eingabe-/Ausgabe-(E/A-)Ports 1412, Eingabe-/Ausgabekomponenten 1414, eine Leistungsversorgung 1416 und eine oder mehrere Präsentationskomponenten 1418 (z. B. Anzeige(n)), und eine oder mehrere Logikeinheiten 1420.
Obwohl die verschiedenen Blöcke in 14 als über das Interconnect-System 1402 mit Leitungen verbunden dargestellt sind, ist dies nicht als einschränkend zu verstehen und dient nur der Übersichtlichkeit. In einigen Ausführungsbeispielen kann z. B. eine Präsentationskomponente 1418, wie ein Anzeigegerät, als E/A-Komponente 1414 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als ein anderes Beispiel können die CPUs 1406 und/oder GPUs 1408 Speicher umfassen (z. B. kann der Speicher 1404 ein Speichergerät zusätzlich zum Speicher der GPUs 1408, der CPUs 1406 und/oder anderer Komponenten darstellen). Mit anderen Worten ist das Rechengerät von 14 lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“, „Erweiterte Realität-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da alle als im Umfang des Rechengeräts von 14 liegend in Betracht gezogen werden.
Das Interconnect-System 1402 kann einen oder mehrere Links oder Busse repräsentieren, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Interconnect-System 1402 kann einen oder mehrere Bus- oder Linktypen umfassen, z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect express), und/oder einen anderen Typ von Bus oder Link. In einigen Ausführungsbeispielen, gibt es direkte Verbindungen zwischen Komponenten. Zum Beispiel kann die CPU 1406 direkt an den Speicher 1404 verbunden sein. Ferner kann die CPU 1406 direkt an die GPU 1408 verbunden sein. Wo es eine direkte, oder point-to-point, Verbindung zwischen Komponenten gibt, kann das Interconnect-System 1402 einen PCIe Link umfassen, um die Verbindung auszuführen. In diesen Beispielen braucht ein PCI Bus nicht in dem Rechengerät 1400 enthalten zu sein.
Der Speicher 1404 kann jedes von einer Vielzahl von computerlesbaren Medien umfassen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Rechengerät 1400 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie entfernbare und nicht-entfernbare Medien umfassen. Beispielhaft und ohne Einschränkung können die computerlesbaren Medien Computer-Speichermedien und Kommunikationsmedien umfassen.
Die Computer-Speichermedien können sowohl flüchtige als auch nicht flüchtige Medien und/oder entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen, wie z. B. computerlesbare Anweisungen, Datenstrukturen, Programmmodulen und/oder andere Datentypen, implementiert sind. Beispielsweise kann der Speicher 1404 computerlesbare Anweisungen speichern (z. B., die ein oder mehrere Programme und/oder ein oder mehrere Programmelemente darstellen, wie z. B. ein Betriebssystem). Computerspeichermedien können RAM, ROM, EEPROM, Flash-Speicher oder eine andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf die das Rechengerät 1400 zugreifen kann, umfassen, sind aber nicht darauf beschränkt. Wie hier verwendet, umfasst der Begriff „Computer-Speichermedien“ nicht Signale per se.
Das Computerspeichermedium kann computerlesbare Befehle, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal verkörpern wie beispielsweise eine Trägerwelle oder einem anderen Transportmechanismus und umfasst jedes Informations-Übergabe-Medium. Der Term „moduliertes Datensignal“ kann sich auf ein Signal beziehen, das ein oder mehr seiner Charakteristiken in solch einer Weise gesetzt oder geändert hat, um Information in das Signal zu kodieren. Auf dem Wege eines Beispiels und nicht Beschränkung kann das Computerspeichermedium drahtgebundene Medien, wie ein drahtgebundenes Netzwerk oder eine Direkt-Draht-Verbindung und drahtlose Medien, wie akustische, RF, Infrarot und andere drahtlose Medien umfassen. Kombinationen von allen oben genannten sollen ebenfalls innerhalb des Umfangs von computerlesbaren Medien umfasst sein.
Die CPU(s) 1406 kann/können so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten des Rechengeräts 1400 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 1406 kann/können jeweils einen oder mehrere Kerne umfassen (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.), die in der Lage sind, eine Vielzahl von Software-Threads simultan zu verarbeiten. Die CPU(s) 1406 kann/können jede Art von Prozessor umfassen und je nach Art des implementierten Rechengeräts 1400 unterschiedliche Typen von Prozessoren umfassen (z. B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Zum Beispiel kann, je nach Art des Rechengeräts 1400 der Prozessor ein ARM-Prozessor (Advanced RISC Machines Processor) sein, der mit einem reduzierten Befehlssatz (RISC) implementiert ist, oder ein x86-Prozessor, der mit komplexem Befehlssatz (Complex Instruction Set Computing, CISC) implementiert ist. Das Rechengerät 1400 kann eine oder mehrere CPUs 1406 umfassen, zusätzlich zu einem oder mehreren Mikroprozessoren oder Zusatz-Coprozessoren, wie z. B. mathematischen Coprozessoren.
Zusätzlich oder alternativ zu der/den CPU(s) 1406 können die GPU(s) 1408 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten des Rechengeräts 1400 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehr der GPU(s) 1408 kann/können eine integrierte GPU(s) (z. B. mit einem oder mehr der CPU(s) 1406) sein und/oder eine oder mehr der GPU(s) 1408 kann/können eine diskrete GPU sein. In Ausführungsbeispielen kann/können eine oder mehr der GPU(s) 1408 ein Coprozessor von einer oder mehr der CPU(s) 1406 sein. Die GPU(s) 1408 kann/können von dem Rechengerät 1400 zum Rendern von Grafiken (z. B. 3D-Grafiken) verwendet werden oder Universalberechnungen durchführen. Zum Beispiel kann/können die GPU(s) 1408 zum Universalberechnen auf GPU(s) (GPGPU) verwendet werden. Die GPU(s) 1408 kann/können hunderte oder tausende von Kernen umfassen, die in der Lage sind, hunderte oder tausende von Software-Threads simultan zu verarbeiten. Die GPU(s) 1408 kann/können als Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von der/den CPU(s) 1406, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 1408 kann/können einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder irgendwelchen anderen geeigneten Daten, wie zum Beispiel GPGPU Daten, umfassen. Der Anzeigespeicher kann als Teil des Speichers 1404 eingefügt sein. Die GPU(s) 1408 kann/können zwei oder mehr GPUs umfassen, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt (z. B. unter Verwenden von NVLINK) verbinden oder kann die GPUs durch einen Switch (z. B. NVSwitch) verbinden. Wenn zusammen kombiniert kann jede GPU 1408 Pixeldaten oder GPGPU Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben erzeugen (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher umfassen oder Speicher gemeinsam mit anderen GPUs nutzen.
Zusätzlich oder alternativ zu der/den CPU(s) 1406 und/oder der/den (GPU(s) 1408 kann/können die Logikeinheit(en) so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten des Rechengeräts 1400 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsbeispielen kann/können die CPU(s) 1406, die GPU(s) 1408 und/oder die Logikeinheit(en) 1420 einzeln oder zusammen jede Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehr der Logikeinheiten 1420 kann/können Teil von und/oder in eine oder mehr der CPU(s) 1406 und/oder der GPU(s) 1408 integriert sein und/oder eine oder mehr der Logikeinheiten 1420 kann/können diskrete Komponenten oder auf andere Weise extern zu der/den CPU(s) 1406 und/oder der/den GPU(s) 1408 sein. In einigen Ausführungsbeispielen kann/können eine oder mehr der Logikeinheiten 1420 ein Coprozessor von einer oder mehr der CPU(s) 1406 und/oder einer oder mehr der GPU(s) 1408 sein.
Beispiele für die Logikeinheit(en) 1420 umfassen einen oder mehr Prozessorkerne und/oder Komponenten davon, wie beispielsweise Tensorkerne (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphikprozessorcluster (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Baum-Traversierungseinheiten (Tree Traversal Units, TTUs), künstliche Intelligenz Beschleuniger (Artificial Intelligence Accelerators, AlAs), Deep Learning Beschleuniger (DLAs), Arithmetisch-logische Einheiten (ALUs), Anwendungsspezifische integrierte Schaltungen (ASICs), Gleitkommaeinheiten (FPUs), E/A Elemente, Peripheral Component Interconnects (PCIs), Peripheral Component Interconnects Express (PCle) Elemente, und/oder ähnliche.
Die Kommunikationsschnittstelle 1410 kann einen oder mehrere Empfänger, Sender und/oder Transceiver umfassen, die es dem Rechengerät 1400 ermöglichen, mit anderen Rechengeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikationen. Die Kommunikationsschnittstelle 1410 kann Komponenten und Funktionalitäten umfassen, die eine Kommunikation über jedes von einer Anzahl von verschiedenen Netzwerken ermöglichen, wie z. B. drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weitverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet.
Die E/A-Anschlüsse 1412 können es ermöglichen, dass das Rechengerät 1400 mit anderen Geräten logisch gekoppelt ist, einschließlich der E/A-Komponenten 1414, der Präsentationskomponente(n) 1418 und/oder anderer Komponenten, von denen einige in das Rechengerät 1400 eingebaut (z. B. integriert in) sein können. Beispielhafte E/A-Komponenten 1414 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, eine Spielsteuerung, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die E/A-Komponenten 1414 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben verarbeitet, die von einem Benutzer erzeugt werden. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein entsprechendes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten in größeren Detail beschrieben) in Verbindung mit einer Anzeige des Rechengeräts 1400 implementieren. Das Rechengerät 1400 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestendetektion und -erkennung umfassen. Zusätzlich kann das Rechengerät 1400 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) umfassen, die eine Bewegungserkennung ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von dem Rechengerät 1400 verwendet werden, um immersive Augmented Reality oder virtuelle Realität zu rendern.
Die Leistungsversorgung 1416 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon umfassen. Die Stromversorgung 1416 kann das Rechengerät 1400 mit Strom versorgen, um den Betrieb der Komponenten des Rechengeräts 1400 zu ermöglichen.
Die Präsentationskomponente(n) 1418 kann/können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 1418 kann/können Daten von anderen Komponenten (z. B. der/den GPU(s) 1408, der/den CPU(s) 1406 usw.) empfangen und die Daten ausgeben (z. B. als ein Bild, Video, Ton usw.).
Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen beschrieben werden, einschließlich computerausführbarer Anweisungen, wie z. B. Programmmodule, die von einem Computer oder einer anderen Maschine, wie z. B. einem Personal Data Assistant oder einem anderen tragbaren Gerät, ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf Codes, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, Universalcomputern, spezielleren Rechengeräten, usw. Die Offenbarung kann auch in verteilten Rechenumgebungen angewendet werden, in denen Aufgaben von entfernt arbeitenden Geräten ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind.
Wenn hier von „und/oder“ in Bezug auf zwei oder mehr Elemente die Rede ist, so ist damit nur ein Element oder eine Kombination von Elementen gemeint. Beispielsweise kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C umfassen. Darüber hinaus kann „mindestens eines von Element A oder Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B umfassen. Weiter kann „mindestens eines von Element A und Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B umfassen.
Der Gegenstand der vorliegenden Offenbarung wird hierin spezifisch beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch nicht den Umfang der vorliegenden Offenbarung einschränken. Vielmehr haben die Erfinder in Erwägung gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden kann, um verschiedene Schritte oder Kombinationen von Schritten ähnlich den in diesem Dokument beschriebenen in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente von verwendeten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbart dargestellten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

WO 3016201806 A [0054]
WO 3016201609 A [0054]
US 16101232 B [0097]

Zitierte Nicht-Patentliteratur

ISO 26262 [0096]

Claims

Ein System aufweisend: einen oder mehr Prozessoren; und Speicher, der Befehle speichert, die als Ergebnis, wenn sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, zum: Aufnehmen eines ersten Bildes und eines zweiten Bildes, wobei das erste Bild zu einer ersten Zeit von einer ersten Position einer Szene aufgenommen wird und das zweite Bild zu einer zweiten Zeit von einer zweiten Position der Szene aufgenommen ist; Erzeugen, unter Verwenden eines neuronalen Netzwerks und basierend auf dem ersten Bild und dem zweiten Bild, einer Szenenstruktur-Karte, die repräsentativ für eine planare Homographie-Schätzung ist, die zu einer oder mehr Oberflächen in der Szene korrespondiert; und Detektieren eines Objekts in der Szene basierend zumindest zum Teil auf einem Set von Werten von der Szenenstruktur-Karte.
System nach Anspruch 1, wobei der Speicher ferner Befehle umfasst, die als Ergebnis, wenn sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, zum: Bestimmen der planaren Homographie-Schätzung, um, basierend zumindest zum Teil auf einem Set von Schlüsselpunkten, die vom ersten Bild und dem zweiten Bild extrahiert wurden, das erste Bild zu dem zweiten Bild zu warpen; und Erzeugen eines ersten gewarpten Bildes mittels zumindest Warpens des ersten Bildes zu dem zweiten Bild, basierend zumindest zum Teil auf der planaren Homographie-Schätzung.
System nach Anspruch 2, wobei der Speicher ferner Befehle umfasst, die als Ergebnis, wenn sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, zum: Bestimmen eines Residual-Flusses basierend zumindest zum Teil auf dem ersten gewarpten Bild und der Szenenstruktur-Karte, wobei der Residual-Fluss verwendet wird, um das erste gewarpte Bild zu dem zweiten Bild zu transformieren mittels zumindest Modellierens eines Transformierens des Subset von Werten der Szenenstruktur-Karte zu korrespondierenden Pixel in dem zweiten Bild; und Erzeugen eines zweiten gewarpten Bildes basierend zumindest zum Teil auf dem ersten gewarpten Bild, der Szenenstruktur-Karte und dem Residual-Fluss.
Das System nach Anspruch 3, wobei der Speicher ferner Befehle umfasst, die als Ergebnis, wenn sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, zum: Bestimmen einer photometrischen Differenz zwischen dem zweiten gewarpten Bild und dem zweiten Bild; und Modifizieren eines Parameters des neuronalen Netzwerks basierend zumindest zum Teil auf der photometrischen Differenz.
Das System nach irgendeinem der vorherigen Ansprüche, wobei das erste Bild und das zweite Bild von einer Einzelkamera aufgenommen werden.
Das System nach irgendeinem der vorherigen Ansprüche, wobei zumindest eine Oberfläche der einen oder mehr Oberflächen eine Straßenoberfläche ist.
Das System nach irgendeinem der vorherigen Ansprüche, wobei die Befehle, die das System dazu bringen, das Objekt in der Szene zu detektieren, ferner Befehle umfassen, die als Ergebnis, wenn sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, Verbundene-Komponenten-Analyse auf Pixelpositionen des ersten Bildes und des zweiten Bildes durchzuführen, die zu Pixelpositionen korrespondieren, die mit einem Subset von Werten von dem Set von Werten innerhalb der Szenenstruktur-Karte assoziiert sind, die Nicht-Null Werte sind.
Das System nach irgendeinem der vorherigen Ansprüche, wobei zumindest eine Oberfläche der einen oder mehr Oberflächen eine Ebene ist.
Ein computerimplementiertes Verfahren aufweisend: Trainieren eines Deep-Neural-Netzwerks (DNN) mittels zumindest: Erlangen eines ersten Bildes, das während eines ersten Zeitintervalls aufgenommen wird und eines zweiten Bildes, das während eines zweiten Zeitintervalls aufgenommen wird; Erzeugen eines ersten gewarpten Bildes mittels Warpens zumindest des ersten Bildes hin zu dem zweiten Bild basierend zumindest zum Teil auf einer planaren Homographie; Bestimmen eines Residual-Flusses basierend zumindest zum Teil auf dem ersten gewarpten Bild und einer Szenenstruktur-Karte, die erzeugt wird, indem zumindest das erste Bild und das zweite Bild dem DNN als Eingaben bereitgestellt werden, wobei die Szenenstruktur-Karte ein Verhältnis von Höhe zu Tiefe für einen spezifischen Pixel innerhalb des ersten Bildes und des zweiten Bildes umfasst; Erzeugen eines zweiten gewarpten Bildes basierend zumindest zum Teil auf dem ersten gewarpten Bild und dem Residual-Fluss; Berechnen eines photometrischen Verlustes zwischen dem ersten Bild und dem zweiten gewarpten Bild; und Modifizieren eines Parameters des DNN basierend zumindest zum Teil auf dem photometrischen Verlust.
Das computerimplementierte Verfahren nach Anspruch 9, wobei das Verfahren ferner aufweist: Erlangen eines dritten Bildes, das während eines dritten Zeitintervalls aufgenommen wird, und eines vierten Bildes, das während eines vierten Zeitintervalls aufgenommen wird; Erzeugen einer zweiten Szenenstruktur-Karte, indem zumindest das dritte Bild und das vierte Bild dem DNN als Eingabe bereitgestellt werden; und Detektieren eines Hindernisses innerhalb der zweiten Szenenstruktur-Karte basierend zumindest zum Teil auf einem Set von Nicht-Null Werten, das mit einem Set von Pixeln assoziiert ist, die in der zweiten Szenenstruktur-Karte repräsentiert sind.
Das computerimplementierte Verfahren nach Anspruch 10, wobei das Verfahren ferner aufweist, Bestimmen der planaren Homographie, indem zumindest ein Set von Schlüsselpunkten in dem ersten Bild und dem zweiten Bild bestimmt wird, basierend zumindest zum Teil auf einem Set von gematchten Features, die zumindest mittels Feature-Matching zwischen dem ersten Bild und dem zweiten Bild erlangt werden.
Das computerimplementierte Verfahren nach Anspruch 10 oder 11, wobei die zweite Szenenstruktur-Karte eine Höhe über einer Oberflächenebene, die zu einem Teil der Straßenoberfläche korrespondiert, anzeigt.
Das computerimplementierte Verfahren nach irgendeinem der Ansprüche 9 bis 12, wobei das erste Bild und das zweite Bild aufeinanderfolgend aufgenommen werden.
Das computerimplementierte Verfahren nach irgendeinem der Ansprüche 9 bis 13, wobei das erste Bild und das zweite Bild mit einer monokularen Einzelkamera aufgenommen werden.
Ein Verfahren zum Detektieren von Hindernissen, aufweisend Detektieren des Hindernisses unter Verwenden eines neuronalen Netzwerkes, das gemäß dem Verfahren des Anspruchs 9 trainiert wurde.
Ein autonomes Fahrzeug aufweisend ein System zum Detektieren eines Hindernisses unter Verwenden eines neuronalen Netzwerks, das mittels eines Verfahrens nach irgendeinem der Ansprüche 9 bis 14 trainiert wurde.
Ein System aufweisend: einen oder mehr Prozessoren; und Speicher, der Befehle speichert, die als Ergebnis, wenn sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, zum: Erlangen eines ersten Bildes einer Szene und eines zweiten Bildes der Szene, wobei das erste Bild und das zweite Bild von unterschiedlichen Positionen aufgenommen werden; Erzeugen eines transformierten ersten Bildes, indem zumindest das erste Bild zu dem zweiten Bild hin transformiert wird, basierend zumindest zum Teil auf einem Set von Features, die vom ersten Bild und vom zweiten Bild erlangt werden; Verwenden eines neuronalen Netzwerks zum Erzeugen, basierend auf dem ersten Bild und dem zweiten Bild, einer Karte, die ein Verhältnis von Höhe und Tiefe mit korrespondierenden Positionen in der Szene assoziiert; Verwenden eines Residual-Flusses, um das erste transformierte Bild weiter zu dem zweiten Bild hin zu transformieren, um ein weiter transformiertes Bild zu erzeugen; und Updaten des neuronalen Netzwerks basierend auf einer Messung einer Differenz zwischen dem weiter transformierten Bild und dem zweiten Bild.
Das System nach Anspruch 17, wobei das erste Bild und das zweite Bild nicht-aufeinanderfolgende Bilder sind, die mittels einer Kamera über ein Zeitintervall aufgenommen werden.
Das System nach Anspruch 18, wobei die Kamera innerhalb eines Fahrzeugs nach vorne gerichtet montiert ist.
Das System nach Anspruch 19, wobei der Speicher ferner Befehle umfasst, die als Ergebnis, wenn Sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, eine Samplingrate eines Sets von Bildern, basierend zumindest zum Teil auf einer mit dem Fahrzeug assoziierten Geschwindigkeit, zu modifizieren, wobei das erste Bild und das zweite Bild Mitglieder des Sets von Bildern sind.
Das System nach Anspruch 19 oder 20, wobei der Speicher ferner Befehle umfasst, die als Ergebnis, wenn Sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, eine Samplingrate eines Sets von Bildern, basierend zumindest zum Teil auf einem mit dem Fahrzeug assoziierten Lenkwinkel zu modifizieren, wobei das erste Bild und das zweite Bild Mitglieder des Sets von Bildern sind.
Das System nach irgendeinem der Ansprüche 17 oder 21, wobei die Befehle, die das System dazu bringen, das transformierte erste Bild zu erzeugen, ferner Befehle umfassen, die als ein Ergebnis, wenn Sie mittels des einen oder mehr Prozessoren ausgeführt werden, das System dazu bringen, eine Homographie Transformation zu schätzen, basierend zumindest zum Teil auf einem ersten Subset von Features des Sets von Features, die von einer ersten Region des ersten Bildes erlangt werden, und eines zweiten Subset von Features des Sets von Feature, die von einer zweiten Region des zweiten Bildes erlangt werden.
Das System nach irgendeinem der Ansprüche 17 bis 22, wobei der Speicher fernen Befehle umfasst, die das System dazu bringen, das Set von Features zu extrahieren, indem zumindest das erste Bild und das zweite Bild als Eingaben für einen Consensus-basierten Algorithmus bereitgestellt werden.
Das System nach irgendeinem der Ansprüche 17 bis 23, wobei die Karte ferner ein Set von Werten aufweist, wobei ein erster Wert des Sets von Werten ein Verhältnis von Höhe und Tiefe einer Pixelposition innerhalb des ersten Bildes umfasst.