DE102020130749A1

DE102020130749A1 - System zum maschinellen lernen zur blickbestimmung mit adaptiver gewichtung von eingaben

Info

Publication number: DE102020130749A1
Application number: DE102020130749.7A
Authority: DE
Inventors: Nishant Puri
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2019-12-16
Filing date: 2020-11-20
Publication date: 2021-06-17
Also published as: US20230206488A1

Abstract

System und Verfahren zum maschinellen Lernen, welche eine Blickrichtung bestimmen, indem sie eine Gesichtsorientierungsinformation, wie z. B. Gesichtslandmarken, verwenden, um eine Augenrichtungsinformation zu ändern, welche von Bildern der Augen eines Objekts bestimmt werden. Die Systemeingaben weisen Augenausschnitte der Augen des Objekts sowie eine Gesichtsorientierungsinformation, wie Gesichtslandmarken, des Gesichts des Objekts in dem eingegebenen Bild auf. Die Gesichtsorientierungsinformation oder die Gesichtslandmarkeninformation werden verwendet, um eine grobe Vorhersage der Blickrichtung zu bestimmen und um einen Kontextvektor von Merkmalen zu lernen, welche eine Gesichtspose des Objekts beschreiben. Der Kontextvektor wird dann zur adaptiven Neugewichtung der von den Augenausschnitten bestimmten Augenrichtungsmerkmale verwendet. Die neu gewichteten Merkmale werden dann mit der groben Blickrichtungsvorhersage kombiniert, um die Blickrichtung zu bestimmen.

Description

Hintergrund
Ausführungsformen der Offenbarung beziehen sich allgemein auf maschinelle Lernsysteme bzw. ein System zum maschinellen Lernen. Genauer gesagt beziehen sich Ausführungsformen der Offenbarung auf Systeme zum maschinellen Lernen zur Blickbestimmung mit adaptiver Gewichtung von Eingaben.
Zusammenfassung
In letzter Zeit wurden faltende neuronale Netze (CNNs) entwickelt, um die Blickrichtung von Objekten zu schätzen. Solche CNNs können z.B. die Blickrichtung, in die ein Objekt bzw. eine Person blickt, aus einem Eingabebild des Objekts bestimmen. Dies ermöglicht es Systemen, die solche CNNs verwenden, den Blick eines Objekts zu verfolgen und entsprechend in Echtzeit zu reagieren.
Herkömmliche Systeme zur Blick(richtungs)bestimmung sind jedoch nicht ohne Nachteile. Die Gesamtleistung und Robustheit solcher Systeme bleibt begrenzt, insbesondere bei Randfällen oder extremen Situationen wie bei großen Änderungen der Kopfhaltung oder bei teilweiser Verdeckung von Gesichtern oder Augen.
Dementsprechend werden hier Systeme und Verfahren für ein robusteres Blickbestimmungssystem beschrieben, das die Systemeingaben entsprechend einer Gesichtslandmarkeninformation adaptiv neu gewichtet. Ein beispielhaftes Blickbestimmungssystem kann eine Kamera oder eine andere Einrichtung zur Bildbestimmung und einen Prozessor, wie z. B. einen Parallelprozessor, verwenden, der in der Lage ist, Inferenzoperationen von maschinellen Lernnetzwerken, wie z. B. CNNs, auszuführen. Bei bestimmten Ausführungsformen der Offenbarung kann das System Bilddaten empfangen, die einem von der Kamera aufgenommenen Bild eines Objekts entsprechen. Ein oder mehrere Netzwerke zum maschinellen Lernen sind so strukturiert, dass sie als Eingaben einen oder mehrere Abschnitte des Bildes aufnehmen, die mindestens einem Auge des Objekts entsprechen, und zugehörige Merkmale ausgeben, wobei diese Merkmale der Blickrichtung des mindestens einen Auges des Objekts entsprechen. Gesichtsposeinformationen des Objekts werden dann verwendet, um diese augenbezogenen Merkmale zu modifizieren. Diese Informationen über die Gesichtspose bzw. Gesichtshaltung bzw. Gesichtsstellung können von einem oder mehreren Modellen zum maschinellen Lernen bestimmt werden, die so ausgestaltet sind, dass sie das Bild des Objekts aufnehmen und die Gesichtsposeinformation als Ausgabe generieren. Die Gesichtsposeinformation kann dann verwendet werden, um sowohl einen Kontextvektor von Merkmalen, die der Gesichtspose des Objekts entsprechen, als auch eine geschätzte Blickrichtung zu bestimmen. Das heißt, dass das/die Modell(e) zum maschinellen Lernen sowohl den Kontextvektor als auch die geschätzte Blickrichtung aus der eingegebenen Gesichtsposeinformation bestimmen können.
Die augenbezogenen Merkmale können dann entsprechend dem Kontextvektor modifiziert werden, und die Blickrichtung kann aus diesen modifizierten Merkmalen bestimmt werden. Genauer gesagt, können die modifizierten augenbezogenen Merkmale mit der geschätzten Blickrichtung kombiniert werden, und die Blickrichtung kann aus dieser Kombination bestimmt werden. Auf diese Weise wird die Blickrichtung aus Augenbildinformationen, die durch die Gesichtsposeinformation modifiziert wurden, und aus einer anfänglichen Schätzung der Blickrichtung bestimmt, wobei diese anfängliche Schätzung aus Gesichtslandmarken bzw. Gesichtsorientierungspunkten bestimmt werden kann.
Die bestimmte Blickrichtung kann dann auf beliebige Art und Weise verwendet werden, z. B. um eine beliebige Operation eines Systems einzuleiten. Zum Beispiel kann die bestimmte Blickrichtung verwendet werden, um eine beliebige Operation bzw. Vorgang eines Fahrzeugs, wie z. B. eines autonomen Fahrzeugs, zu initiieren.
Wie vorab beschrieben ist, wird die Information über die Gesichtshaltung bzw. die Gesichtsposeinformation verwendet, um sowohl einen Kontextvektor als auch eine geschätzte Blickrichtung zu bestimmen. Diese Gesichtsposeinformation kann eine beliebige Information sein, die die räumliche Orientierung des Gesichts des Objekts angibt, wie z. B. ein Satz von Gesichtslandmarken, die aus dem Eingangsbild bzw. eingegebenen Bild bestimmt wurden. Ein oder mehrere Modelle zum maschinellen Lernen können die Gesichtsposeinformation, z. B. die Gesichtslandmarken, verarbeiten, um den Kontextvektor und die geschätzte Blickrichtung zu erzeugen, wobei der Kontextvektor als seine Elemente Merkmale aufweist, die der Gesichtshaltung bzw. Gesichtspose des Objekts entsprechen, d. h. der Position und der Ausrichtung des Gesichts des Objekts.
Die Modifikation von augenbezogenen Merkmalen kann auf beliebige Weise erfolgen. Zum Beispiel kann der Kontextvektor verwendet werden, um Gewichtungswerte zu bestimmen, die mit den augenbezogenen Merkmalen multipliziert werden können. Das heißt, die modifizierten augenbezogenen Merkmale können durch Multiplikation der ursprünglichen augenbezogenen Merkmale mit entsprechenden Gewichtungswerten bestimmt werden.
Dementsprechend verwenden Ausführungsformen der Offenbarung Abschnitte des eingegeben Bildes, um Augenrichtungsmerkmale zu bestimmen, und verwenden Informationen zur Gesichtsausrichtung bzw. eine Gesichtsorientierungsinformation, um diese Augenrichtungsmerkmale zu modifizieren. Die Blickrichtung wird dann aus den modifizierten Augenrichtungsmerkmalen bestimmt. Verschiedene Modelle zum maschinellen Lernen können zur Bestimmung von Augenrichtungsmerkmalen verwendet werden, und die verschiedenen in diesem Verfahren verwendeten Operationen können von Rechenschaltungen wie z. B. Parallelverarbeitungsschaltungen durchgeführt werden. Auf diese Weise wird die Blickrichtung nicht nur aus Abschnitten des eingegeben Bildes, wie z. B. Augenausschnitten, bestimmt. Vielmehr werden die von diesen Augenausschnitten ausgegebenen Informationen entsprechend der Ausrichtung des Gesichts des Objekts modifiziert, und die Blickrichtung wird dann anhand dieser modifizierten Ausgabe bestimmt.
Wie vorab beschrieben ist, wird die eingegebene Gesichtsausrichtung bzw. Gesichtsorientierung verwendet, um einen Kontextvektor der Gesichtsorientierungsmerkmale zu bestimmen. Dementsprechend kann in Ausführungsformen der Offenbarung die Blickrichtung eines Objekts aus Modellen zum maschinellen Lernen bestimmt werden, die als Eingaben Gesichtsorientierungsmerkmale, die einer Orientierung eines Gesichts des Objekts entsprechen, eine Schätzung der Blickrichtung und einen Abschnitt des Bildes, der mindestens einem Auge des Objekts entspricht, aufweisen.
Figurenliste
Die obigen und andere Merkmale und Vorteile der Offenbarung werden bei Betrachtung der folgenden detaillierten Beschreibung in Verbindung mit den beigefügten Zeichnungen deutlich, in denen sich gleiche Bezugszeichen durchgehend auf gleiche Teile beziehen und wobei gilt:

1 ist ein Flussdiagramm, das konzeptionell die Funktion von Blickbestimmungsverfahren von Ausführungsformen der Offenbarung darstellt;
2 ist eine Blockdiagramm-Darstellung von beispielhaften Modellen zum maschinellen Lernen zur Blickbestimmung von Ausführungsformen der Offenbarung;
3 ist eine Blockdiagramm-Darstellung eines Blickbestimmungssystems von Ausführungsformen der Offenbarung;
4A ist eine Darstellung eines Beispiels eines autonomen Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
4B ist ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug von 4A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
4C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 4A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
4D ist eine Systemdarstellung für die Kommunikation zwischen dem/den Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug von 4A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
5 ist ein Blockdiagramm einer beispielhaften Recheneinrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
6 ist ein Flussdiagramm, das Prozessschritte zum Bestimmen der Blickrichtung gemäß Ausführungsformen der vorliegenden Offenbarung darstellt.

Detaillierte Beschreibung
Bei mindestens einer Ausführungsform bezieht sich die Offenbarung auf Systeme und Verfahren zum maschinellen Lernen, die die Blickrichtung bestimmen, indem sie eine Gesichtsorientierungsinformation, wie z. B. Gesichtslandmarken, verwenden, um eine aus Bildern der Augen eines Objekts bestimmte Augenrichtungsinformation zu modifizieren. Die Systemeingaben weisen Augenausschnitte der Augen des Objekts sowie eine Gesichtsorientierungsinformation, wie z. B. Gesichtslandmarken des Gesichts des Objekts, in dem Eingabebild auf. Die Gesichtsorientierungsinformation, z. B. die Informationen zu den Gesichtslandmarken, wird verwendet, um eine grobe Vorhersage der Blickrichtung zu bestimmen und einen Kontextvektor von Merkmalen zu lernen, die die Gesichtshaltung des Objekts beschreiben. Ein Kontextvektor wird dann verwendet, um die aus den Augenausschnitten bestimmten Augenrichtungsmerkmale adaptiv neu zu gewichten. Die neu gewichteten Merkmale werden dann mit der groben Blickvorhersage kombiniert, um die Blickrichtung zu bestimmen.
1 ist ein Flussdiagramm, das konzeptionell die Funktion der Blickbestimmungsverfahren von Ausführungsformen der Offenbarung darstellt. Eine oder mehrere Augenaufnahmen 100 und ein Satz von Gesichtslandmarken 110 dienen als Eingaben für ein oder mehrere Modelle zum maschinellen Lernen. Diese Modelle zum maschinellen Lernen werden trainiert, um einen Satz von Merkmalen 120 aus den eingegebenen Augenausschnitten 100 auszugeben, und um sowohl einen Kontextvektor 130 als auch eine grobe Vorhersage 140 eines Blickvektors auszugeben. Die grobe Vorhersage 140 ist eine Schätzung der Blickrichtung des Objekts. Die Merkmale 120 werden entsprechend dem Kontextvektor 130 neu gewichtet, um einen Satz von neu gewichteten Merkmalen 150 zu erzeugen. Genauer gesagt werden die Merkmale 120 konzeptionell entsprechend der Blickrichtung, die durch die Merkmale des Kontextvektors 130 angezeigt wird, unterschiedlich gewichtet. So führen Merkmale des Kontextvektors 130, die einem Blick in eine bestimmte Richtung entsprechen, zu größeren Gewichtungswerten für Merkmale 120, die ebenfalls einem Blick in diese Richtung entsprechen. Merkmale 120, die einen Blick anzeigen, der mit dem von den Gesichtsmerkmalen 110 angezeigten Blick übereinstimmt, erhalten somit ein größeres Gewicht bei der endgültigen Bestimmung der Blickrichtung.
Die neu gewichteten Merkmale 150 werden mit der groben Vorhersage 140 verknüpft, und zusammen werden diese Größen zur Bestimmung der Blickrichtung verwendet. Auf diese Weise können Informationen zu Gesichtslandmarken verwendet werden, um das Verfahren der Bestimmung der Blickrichtung aus Augenbildern zu modifizieren. Genauer gesagt wird eine Orientierung des Gesichts des Objekts in Form eines Merkmalsvektors und einer Schätzung der Blickrichtung verwendet, um die Schätzung des Blicks aus einem eingegeben Bild, z. B. aus Augenausschnitten, zu ergänzen oder zu korrigieren. Auf diese Weise wird die Information über den Augenausschnitt um die Richtung ergänzt, in der das Gesicht des Objekts ausgerichtet ist, was zu genaueren Ergebnissen bezüglich der Blickrichtung führt.
2 ist eine Blockdiagramm-Darstellung von beispielhaften Modellen zum maschinellen Lernen zur Blickbestimmung von Ausführungsformen der Offenbarung. Bei mindestens einer Ausführungsform weisen die Modelle zum maschinellen Lernen von 2 die Merkmalsextraktionsschichten 215, 220 und 225 sowie die vollverknüpften bzw. vollständig verbundenen Schichten 255 auf, die, wie es dargestellt ist, angeordnet sind. Die Merkmalsextraktionsschicht 215 weist als Eingabe 200 ein Bild des linken Auges auf, und die Merkmalsextraktionsschicht 225 weist als Eingabe 210 ein Bild des rechten Auges auf. Die Merkmalsextraktionsschichten 215 und 225 können jeweils Merkmale ihrer jeweiligen eingegeben Bilder 200, 210 nach beliebigen Verfahren extrahieren. Beispielsweise können die Merkmalsextraktionsschichten 215 und 225 jeweils ein Merkmalslernabschnitt eines CNN sein, der in jeder geeigneten Weise strukturiert ist und beliebige Faltungskerne und Pooling-Schichten verwendet, die für die Extraktion von Merkmalen der Augen von Objekten geeignet sind. Die Merkmalsextraktionsschichten oder -blöcke 215, 225 geben somit jeweils Merkmale aus, die die Blickrichtung der in den jeweiligen eingegeben Bildern 200, 210 dargestellten Augen repräsentieren können.
Da die Merkmalsextraktionsschichten 215 und 225 jeweils so ausgestaltet sind, dass sie die Augen als Eingabe analysieren, können ihre entsprechenden Gewichtungswerte aus Effizienzgründen gemeinsam benutzt werden oder identisch sein. Ausführungsformen der Offenbarung ziehen jedoch beliebige Gewichtungswerte für jede der Merkmalsextraktionsschichten 215 und 225 in Betracht, ob gemeinsam genutzt oder nicht.
Bei mindestens einer Ausführungsform weist die Merkmalsextraktionsschicht 220 als Eingabe einen Satz von Gesichtslandmarken 205 oder einen Satz von Landmarkenpunkten des Gesichts eines Objekts auf, die auf beliebige Weise bestimmt werden können. Ähnlich wie die Merkmalsextraktionsschichten 215 und 225 kann die Merkmalsextraktionsschicht 220 ein beliebiger Abschnitt eines CNN zum Erlernen von Merkmalen sein, der auf jede geeignete Weise strukturiert ist und beliebige Faltungskerne und Pooling-Schichten verwendet, die für die Extraktion von Merkmalen von Gesichtslandmarken geeignet sind. Eine Ausgabe der Merkmalsextraktionsschicht 220 ist ein Satz von Gesichtsorientierungsmerkmalen 235, die die Orientierung des Gesichts darstellen können, aus dem die Gesichtslandmarken 205 bestimmt werden, sowie eine Schätzung des ausgegebenen Blickvektors 230. Die Gesichtsorientierungsmerkmale 235 können zu einem Kontextvektor zusammengesetzt werden, es kann sich aber auch um eine beliebige Menge von Informationen handeln, die in beliebiger Weise angeordnet sind und die die Orientierung des Gesichts wiedergeben, von dem die Gesichtslandmarken 205 und die Augenausschnitte 200, 210 entnommen werden. Die Schätzung des ausgegebenen Blickvektors 230 kann eine beliebige Schätzung der Richtung sein, wie z. B. ein Satz von Winkeln, die einen Blickvektor im dreidimensionalen Raum definieren.
Ausführungsformen der Offenbarung sehen die Verwendung einer beliebigen Anzahl von Landmarken in einem beliebigen Satz von Gesichtslandmarken 205 vor. Zum Beispiel kann jeder Satz von Gesichtslandmarken 205 64 oder 104 Landmarken aufweisen.
Die Ausgaben der Merkmalsextraktionsschichten 215 und 225 werden in die Kanalaufmerksamkeitsnetzwerke 240 bzw. 245 eingegeben, und der Kontextvektor 235 wird in beide Kanalaufmerksamkeitsnetzwerke 240 und 245 eingegeben. Somit erhält jedes Kanalaufmerksamkeitsnetzwerk 240, 245 eine Kopie des Kontextvektors 235 sowie die von einer der Merkmalsextraktionsschichten 220 und 225 ausgegebenen Merkmale.
Die Kanalaufmerksamkeitsnetze 240, 245 lernen jeweils Gewichte von ihrem eingegebenen Kontextvektor 235 und multiplizieren diese Gewichte mit entsprechenden Merkmalen, die von den Merkmalsextraktionsschichten 215 und 225 eingegeben werden. Die Kanalaufmerksamkeitsnetzwerke 240, 245 können jeweils Gewichtungswerte nach beliebigen Verfahren bestimmen. Beispielsweise können die Aufmerksamkeitsnetzwerke 240, 245 jeweils ein Kodiererabschnitt eines Aufmerksamkeitsnetzwerks sein, der auf jede geeignete Weise strukturiert ist, um Aufmerksamkeitsgewichte zu bestimmen, die verwendet werden, um die von den Merkmalsextraktionsschichten 215 und 225 ausgegebenen Merkmale neu zu gewichten, wobei die Aufmerksamkeitsgewichte den Anteilen entsprechen, mit denen die Merkmale zur Blickrichtung beitragen. Bei mindestens einer Ausführungsform können die Aufmerksamkeitsgewichte z. B. gemäß einer beliebigen Funktion bestimmt werden, wie z. B. einer Sigmoidfunktion im Bereich von 0,0 bis 1,0, einer hyperbolischen Tangensfunktion oder dergleichen. Bei mindestens einer Ausführungsform können die Aufmerksamkeitsgewichte mit ihren entsprechenden Eingangsmerkmalen aus den Merkmalsextraktionsschichten 215 und 225 multipliziert werden, um jedes Merkmal neu zu gewichten.
Ausführungsformen der Offenbarung sehen eine beliebige Anzahl von Merkmalen vor, die von jeder der Merkmalsextraktionsschichten 215 und 225 ausgegeben werden. Bei einigen Ausführungsformen kann die Anzahl der verwendeten Merkmale von der Architektur der Merkmalsextraktionsschichten 215 und 225 abhängen, d.h. von der Anzahl der Merkmale, für die die Schichten 215, 225 zur Ausgabe ausgelegt sind. Beispielsweise können die Schichten 215 und 225 so ausgestaltet sein, dass sie 512 Merkmale für jeden eingegebenen Augenausschnitt ausgeben. Bei einigen Ausführungsformen kann die Merkmalsextraktionsschicht 220 auch so ausgelegt sein, dass sie die gleiche Anzahl von Merkmalen wie die Schichten 215 und 225 ausgibt. In diesem Beispiel kann die Schicht 220 auch so ausgestaltet sein, dass sie 512 Merkmale für jeden Eingabesatz von Gesichtslandmarken 205 ausgibt. Die Aufmerksamkeitsnetzwerke 240 und 245 können dann jeweils 512 Gewichtungswerte bestimmen, einen für jedes Merkmal, das von den Merkmalsextraktionsschichten 215 und 225 ausgegeben wird.
Neu gewichtete Merkmale, die jeder Augeneingabe 200, 210 entsprechen, werden dann von den Kanalaufmerksamkeitsnetzwerken 240, 245 an den Verkettungsblock 250 ausgegeben, wo sie miteinander und mit dem geschätzten Blickvektor 230 verknüpft werden.
Die verknüpften Ergebnisse, die Blickrichtungsmerkmale, die mit der Orientierung des Gesichts eines Objekts gewichtet sind, sowie eine Schätzung der Blickrichtung des Objekts aufweisen, werden dann in vollständig verbundene Schichten 255 eingegeben. Vollständig verbundene Schichten 255 können ein beliebiger Klassifikator sein, der geeignet ist, die eingegebenen Blickbeschreibungsmerkmale und Blickrichtungen in Richtungsklassifikationen zu klassifizieren, die die Richtung angeben, in die das Objekt schaut. Beispielsweise kann es sich bei den vollständig verbundenen Schichten 255 um ein mehrschichtiges Perzeptron oder um andere vollständig verbundene Schichten eines CNN handeln, die so ausgestaltet und trainiert sind, dass sie eingegebene Merkmale und Richtungen in eine von mehreren diskreten Blickrichtungen klassifizieren. Vollständig verbundene Schichten 255 können somit Wahrscheinlichkeiten der Blickrichtung des Objekts ausgeben.
Es kann beobachtet werden, dass der Kontextvektor 235 die blickbezogenen Informationen verfeinert, die aus dem linken und rechten Augenausschnitt bestimmt wurden. Das heißt, Ausführungsformen der Offenbarung verwenden Informationen über die Ausrichtung des Gesichts des Objekts, z. B. Gesichtslandmarken 205, um die Genauigkeit der Blickinformation zu verbessern, die von den eingegebenen Augenausschnitten bereitgestellt wird. So kann jede Eingabe, die eine Gesichtsorientierungsinformation übermittelt, anstelle der Gesichtslandmarken 205 verwendet werden. Als ein Beispiel sehen Ausführungsformen der Offenbarung die Verwendung von Eingaben wie die Stimmrichtung des Objekts vor, die z. B. durch einen Satz von Mikrofonen erfasst wird, die in der Nähe des Objekts platziert sind. Bei einer solchen Ausführungsform kann die Merkmalsextraktionsschicht 220 so strukturiert sein, dass sie Merkmale der aufgezeichneten Audiosignale von den Mikrofonen extrahiert. Als weiteres Beispiel kann die Eingabe für die Merkmalsextraktionsschicht 220 ein Satz von Gesichtslandmarken sein, der Veränderungen gegenüber einem Referenzsatz von Landmarken darstellt, anstatt von Landmarken-Positionspunkten. Bei einer solchen Ausführungsform kann die Merkmalsextraktionsschicht 220 so strukturiert sein, dass sie Merkmale entsprechend den Änderungen der Landmarken extrahiert, vielleicht unter Bezugnahme auf einen Referenzsatz von Landmarken, der in dem im Folgenden beschriebenen Speicher 408 gespeichert ist, oder sie kann auf Sätze von Landmarkenänderungen anstatt auf Sätze von Landmarkenpunkten trainiert werden.
3 ist eine Blockdiagramm-Darstellung eines beispielhaften Blickbestimmungssystems von Ausführungsformen der Offenbarung. Hier steht die Recheneinrichtung 300, bei der es sich um eine beliebige elektronische Recheneinrichtung handeln kann, die einen Verarbeitungsschaltkreis enthält, der in der Lage ist, die Blickbestimmungsoperationen von Ausführungsformen der Offenbarung auszuführen, in elektronischer Kommunikation sowohl mit einer Kamera 310 als auch mit einem blickunterstützten System 320. Im Betrieb nimmt die Kamera 310 Bilder eines Objekts auf und überträgt sie an die Recheneinrichtung 300, die dann die Modelle zum maschinellen Lernen von z. B. 2 implementiert, indem sie aus dem Bild der Kamera 310 die in 2 gezeigten Eingaben bestimmt und die ausgegebene Blickrichtung des Objekts berechnet. Die Recheneinrichtung 300 überträgt diese Blickrichtung an das blickunterstützte System 320, das abhängig davon eine Aktion ausführt oder eine oder mehrere Operationen durchführt.
Das blickunterstützte System 320 kann ein beliebiges System sein, das in der Lage ist, eine oder mehrere Aktionen basierend auf der Blickrichtung durchzuführen, die es von der Recheneinrichtung 300 empfängt. Es sind beliebige Konfigurationen von einer Kamera 310, einer Recheneinrichtung 300 und einem blickunterstützten System 320 denkbar. Als ein Beispiel kann das blickunterstützte System 320 ein autonomes Fahrzeug sein, das in der Lage ist, die Blickrichtung des Fahrers oder eines anderen Insassen zu bestimmen und darauf zu reagieren, wie das im Folgenden beschriebene autonome Fahrzeug 400. Bei diesem Beispiel können die Kamera 310 und die Recheneinrichtung 300 innerhalb des Fahrzeugs positioniert sein, während das blickunterstützte System 320 das Fahrzeug selbst darstellen kann. Die Kamera 310 kann an einer beliebigen Stelle innerhalb des Fahrzeugs positioniert sein, die ihr einen Blick auf den Fahrer oder einen Insassen ermöglicht. Dementsprechend kann die Kamera 310 Bilder des Fahrers erfassen und diese an die Recheneinrichtung 300 übertragen, die die Eingaben 200, 205, 215, 220 und 225 berechnet und die Blickrichtung des Fahrers bestimmt. Diese Blickrichtung kann dann z. B. an ein anderes Softwaremodul übertragen werden, das Aktionen bestimmt, die das Fahrzeug abhängig davon ausführen kann. Zum Beispiel kann das Fahrzeug feststellen, dass die Blickrichtung einen abgelenkten Fahrer oder einen Fahrer, der seine Aufmerksamkeit nicht auf die Straße gerichtet hat, repräsentiert, und kann abhängig davon jede Art von Operation einleiten. Solche Operationen können jede Art von Warnung an den Fahrer (z. B. eine visuelle oder akustische Warnung, eine Warnung auf einem Head-up-Display oder Ähnliches), die Einleitung eines Autopiloten, einen Brems- oder Abbiegevorgang oder eine andere Operation aufweisen. Die Recheneinrichtung 300 kann innerhalb des Fahrzeugs des blickunterstützten Systems 320 als lokaler Prozessor positioniert sein, oder sie kann ein abgesetzter Prozessor sein, der Bilder von der Kamera 310 empfängt und Blickrichtungen oder Anweisungen drahtlos an das Fahrzeug des blickunterstützten Systems 320 überträgt.
Als weiteres Beispiel kann das blickunterstützte System 320 ein Virtual-Reality- oder Augmented-Reality-System sein, das in der Lage ist, Bilder abhängig von einer Bewegung und einem Blick von Benutzern anzuzeigen. Bei diesem Beispiel weist das blickunterstützte System 320 eine Virtual-Reality- oder Augmented-Reality-Anzeige auf, beispielsweise ein Headset, das von einem Benutzer getragen wird und so ausgestaltet ist, dass es Bilder darauf projiziert. Die Kamera 310 und die Recheneinrichtung 300 können innerhalb des Headsets angeordnet sein, wobei die Kamera 310 Bilder von den Augen des Benutzers erfasst und die Recheneinrichtung 300 seine Blickrichtung bestimmt. Diese Blickrichtung kann dann an die Virtual-Reality- oder Augmented-Reality-Anzeige übertragen werden, die abhängig davon eine beliebige Aktion ausführen kann. Um beispielsweise Rechenressourcen zu sparen, kann das blickunterstützte System 320 nur die Virtual-Reality- oder Augmented-Reality-Elemente rendern, die sich innerhalb des Blickfelds des Benutzers befinden, wie es mit der bestimmten Blickrichtung bestimmt wird. In ähnlicher Weise kann das blickunterstützte System 320 den Benutzer auf Objekte oder Ereignisse aufmerksam machen, die sich außerhalb des Sichtfeldes des Benutzers befinden, die der Benutzer aber vermeiden möchte oder die ihn interessieren könnten. Wie bei dem obigen Beispiel des autonomen Fahrzeugs kann die Recheneinrichtung 300 eines Virtual-Reality- oder Augmented-Reality-Systems innerhalb des Systems 320 angeordnet sein, z. B. innerhalb des Headsets selbst, oder sie kann an einem abgesetzten Ort angeordnet sein, so dass Bilder drahtlos an die Recheneinrichtung 300 übertragen werden und berechnete Blickrichtungen drahtlos zurück an das Headset übertragen werden können, das wiederum verschiedene Operationen abhängig davon durchführen kann.
Als weiteres Beispiel kann das blickunterstützte System 320 ein computergestütztes Werbesystem sein, das bestimmt, welche Anzeigen ein Benutzer ansieht. Genauer gesagt, kann das blickunterstützte System 320 ein beliebiges elektronisches Rechensystem oder eine beliebige elektronische Einrichtung sein, wie z. B. ein Desktop-Computer, ein Laptop-Computer, ein Smartphone, ein Server-Computer oder ähnliches. Die Kamera 310 und die Recheneinrichtung 300 können in diese Recheneinrichtung eingebaut sein, um auf den Benutzer gerichtet zu sein, z. B. in oder in der Nähe des Displays der Recheneinrichtung. Die Kamera 310 kann Bilder des Benutzers aufnehmen und die Recheneinrichtung 300 kann dessen Blickrichtung bestimmen. Die bestimmten Blickrichtungen können dann an das blickunterstützte System 320 übertragen werden, z. B. an die Recheneinrichtung 300, die Werbung für den Benutzer anzeigt, an eine abgesetzte Recheneinrichtung oder ähnliches. Die Recheneinrichtung kann dann die berechnete Blickrichtung verwenden, um zu bestimmen, auf welche Anzeige sich der Benutzer konzentriert, wodurch Informationen über die Wirksamkeit verschiedener Anzeigen bereitgestellt werden.
4A ist eine Darstellung eines Beispiels für ein autonomes Fahrzeug 400, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 400 (hier alternativ als „Fahrzeug 400“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug sein, wie z. B. ein Pkw, ein Lkw, ein Bus, ein First-Responder-Fahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, ein Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne und/oder eine andere Art von Fahrzeug (z. B., das unbemannt ist und/oder einen oder mehrere Insassen beherbergt). 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 400 kann eine Funktionalität gemäß einer oder mehreren der Stufe 3 - Stufe 5 der autonomen Fahrstufen aufweisen. Beispielsweise kann das Fahrzeug 400 je nach Ausführungsform in der Lage sein, bedingt automatisiert (Stufe 3), hochautomatisiert (Stufe 4) und/oder voll automatisiert (Stufe 5) zu fahren.
Das Fahrzeug 400 kann Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z.B. 2, 4, 6, 8, 18, etc.), Reifen, Achsen und andere Komponenten eines Fahrzeugs aufweisen. Das Fahrzeug 400 kann ein Antriebssystem 450 aufweisen, wie z. B. einen Verbrennungsmotor, ein Hybrid-Elektroantrieb, einen reinen Elektromotor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 450 kann mit einem Antriebsstrang des Fahrzeugs 400 verbunden sein, der ein Getriebe aufweisen kann, um den Vortrieb des Fahrzeugs 400 zu ermöglichen. Das Antriebssystem 450 kann abhängig von dem Empfang von Signalen von der Drosselklappe/Beschleunigungsvorrichtung 452 gesteuert werden.
Ein Lenksystem 454, das ein Lenkrad aufweisen kann, kann verwendet werden, um das Fahrzeug 400 zu lenken (z. B. entlang eines gewünschten Weges oder einer Route), wenn das Antriebssystem 450 in Betrieb ist (z. B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 454 kann Signale von einem Lenkaktor 456 empfangen. Das Lenkrad kann für eine vollständige Automatisierung (Stufe 5) optional sein.
Das Bremssensorsystem 446 kann verwendet werden, um die Fahrzeugbremsen abhängig von dem Empfang von Signalen von den Bremsaktuatoren 448 und/oder Bremssensoren zu betätigen. (Eine) Steuerung(en) 436, die eine oder mehrere CPU(s), System-on-Chips (SoCs) 404 (4C) und/oder GPU(s) aufweisen kann/können, kann/können Signale (z. B. repräsentativ für Befehle) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 400 liefern. Beispielsweise kann/können die Steuerung(en) Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 448, zur Betätigung des Lenksystems 454 über einen oder mehrere Lenkaktuatoren 456 und/oder zur Betätigung des Antriebssystems 450 über einen oder mehrere Drossel-/Beschleunigungsregler 452 senden. Die Steuerung(en) 436 kann/können eine oder mehrere integrierte Recheneinrichtungen (z. B. Supercomputer) aufweisen, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z. B. Signale, die Befehle darstellen), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Fahren des Fahrzeugs 400 zu unterstützen. Die Steuerung(en) 436 kann/können eine erste Steuerung 436 für autonome Fahrfunktionen, eine zweite Steuerung 436 für funktionale Sicherheitsfunktionen, eine dritte Steuerung 436 für Funktionen der künstlichen Intelligenz (z. B. Computer Vision), eine vierte Steuerung 436 für Infotainment-Funktionen, eine fünfte Steuerung 436 für Redundanz in Notfällen und/oder andere Steuerungen aufweisen. Bei einigen Beispielen kann eine einzelne Steuerung 436 zwei oder mehr der oben genannten Funktionalitäten handhaben, zwei oder mehr Steuerungen 436 können eine einzelne Funktionalität handhaben, und/oder eine beliebige Kombination davon.
Die Steuerung(en) 436 kann (können) die Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 400 als 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 458 (z. B. Global-Positioning-System-Sensor(en)), RADAR-Sensor(en) 460, Ultraschallsensor(en) 462, LIDAR-Sensor(en) 464, Inertialmesseinheit (IMU)-Sensor(en) 466 (z. B., Beschleunigungssensor(en), Gyroskop(en), Magnet-kompass(en), Magnetometer usw.), Mikrofon(en) 496, Stereokamera(s) 468, Weitwinkelkamera(s) 470 (z. B., (z. B. Fischaugenkameras), Infrarotkamera(s) 472, Umgebungska-mera(s) 474 (z. B. 360-Grad-Kameras), Fern- und/oder Mittelbereichskamera(s) 498, Geschwindigkeitssensor(en) 444 (z. B. zur Messung der Geschwindigkeit des Fahrzeugs 400), Vibrationssensor(en) 442, Lenksensor(en) 440, Bremssensor(en) 446 (z. B. als Teil des Bremssensorsystems 446) und/oder andere Sensortypen empfangen werden.
Ein oder mehrere Steuergerät(e) 436 können Eingaben (z. B. dargestellt durch Eingabedaten) von einem Kombiinstrument 432 des Fahrzeugs 400 empfangen und Ausgaben (z. B. dargestellt durch Ausgabedaten, Anzeigedaten usw.) über eine Mensch-Maschine-Schnittstellen- (HMI-) Anzeige 434, einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 400 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z. B. die HD-Karte 422 in 4C), Positionsdaten (z. B. die Position des Fahrzeugs 400, z. B. auf einer Karte), Richtung, Position anderer Fahrzeuge (z. B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie sie von der/den Steuerung(en) 436 wahrgenommen werden, usw. aufweisen. Zum Beispiel kann die HMI-Anzeige 434 Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. ein Straßenschild, ein Warnschild, eine sich ändernde Ampel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, durchführt oder durchführen wird (z. B. jetzt die Spur wechseln, in zwei Meilen die Ausfahrt 34B nehmen usw.).
Das Fahrzeug 400 weist darüber hinaus eine Netzwerkschnittstelle 424 auf, die eine oder mehrere drahtlose Antennen 426 und/oder Modem(s) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann die Netzwerkschnittstelle 424 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA2000, etc. zu kommunizieren. Die drahtlose(n) Antenne(n) 426 kann/können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Einrichtungen 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.
4B ist ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug 400 von 4A gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die jeweiligen Sichtfelder sind eine beispielhafte Ausführungsform und sind nicht als einschränkend zu verstehen. Beispielsweise können zusätzliche und/oder alternative Kameras vorhanden sein und/oder die Kameras können an verschiedenen Stellen des Fahrzeugs 400 angeordnet sein.
Die Kameratypen für die Kameras können Digitalkameras aufweisen, sind aber nicht auf diese beschränkt, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 400 angepasst sein können. Die Kamera(s) kann/können mit dem Automotive Safety Integrity Level (ASIL) B und/oder mit einem anderen ASIL arbeiten. Die Kameratypen können je nach Ausführungsform eine beliebige Bildaufnahmerate, wie z. B. 60 Bilder pro Sekunde (fps), 120 fps, 240 fps usw., erreichen. Die Kameras können in der Lage sein, Rolling Shutter, Global Shutter, einen anderen Verschlusstyp oder eine Kombination davon zu verwenden. Bei einigen Beispielen kann das Farbfilter-Array ein RCCC-Farbfilter-Array (red clear clear clear), ein RCCB-Farbfilter-Array (red clear clear blue), ein RBGC-Farbfilter-Array (red blue green clear), ein Foveon X3-Farbfilter-Array, ein RGGB-Farbfilter-Array (Bayer-Sensoren), ein Monochrom-Sensor-Farbfilter-Array und/oder eine andere Art von Farbfilter-Array aufweisen. Bei einigen Ausführungsformen können Clear-Pixel-Kameras, wie z. B. Kameras mit einem RCCC-, einem RCCB- und/oder einem RBGC-Farbfilter-Array, verwendet werden, um die Lichtempfindlichkeit zu erhöhen.
Bei einigen Beispielen kann/können eine oder mehrere der Kamera(s) verwendet werden, um erweiterte Fahrerassistenzsystemfunktionen (ADAS) auszuführen (z. B. als Teil eines redundanten oder ausfallsicheren Designs). Zum Beispiel kann eine Multifunktions-Monokamera installiert sein, um Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung aufzuweisen. Eine oder mehrere der Kamera(s) (z.B. alle Kameras) kann/können gleichzeitig Bilddaten (z.B. Video) aufzeichnen und bereitstellen.
Eine oder mehrere der Kameras kann/können in einer Anordnung, wie z. B. einer kundenspezifischen (3D-gedruckten) Anordnung, montiert sein, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z. B. Reflexionen vom Armaturenbrett, die in den Windschutzscheibenspiegeln reflektiert werden) auszuschalten, die die Bilddatenerfassungsfähigkeiten der Kamera beeinträchtigen können. In Bezug auf die Anordnung der Außenspiegel kann die Anordnung der Außenspiegel kundenspezifisch in 3D gedruckt werden, so dass die Kameramontageplatte der Form des Außenspiegels entspricht. Bei einigen Beispielen kann/können die Kamera(s) in den Flügelspiegel integriert sein. Bei Seitenkameras kann/können die Kamera(s) auch in die vier Säulen an jeder Ecke der Fahrgastzelle integriert sein.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung vor dem Fahrzeug 400 aufweist (z. B. nach vom gerichtete Kameras), können für die Rundumsicht verwendet werden, um dabei zu helfen, nach vorn gerichtete Pfade und Hindernisse zu identifizieren, sowie mit Hilfe eines oder mehrerer Steuergeräte 436 und/oder Steuer-SoCs Informationen bereitzustellen, die für die Erstellung eines Belegungsgitters und/oder die Bestimmung der bevorzugten Fahrzeugpfade entscheidend sind. Nach vorn 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 vom gerichtete Kameras können auch für ADAS-Funktionen und -Systeme verwendet werden, die Spurverlassenwarnungen (Lane Departure Warnings, LDW), autonome Geschwindigkeitsregelung (Autonomous Cruise Control, ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung aufweisen.
Eine Vielzahl von Kameras kann in einer nach vorn gerichteten Konfiguration verwendet werden, die z. B. eine monokulare Kameraplattform aufweist, die einen CMOS (Complementary Metal Oxide Semiconductor)-Farbbildgeber enthält. Ein weiteres Beispiel kann eine Weitwinkelkamera 470 sein, die verwendet werden kann, um Objekte wahrzunehmen, die von der Peripherie ins Blickfeld kommen (z. B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl in 4B nur eine Weitwinkelkamera dargestellt ist, kann sich eine beliebige Anzahl von Weitwinkelkameras 470 am Fahrzeug 400 befinden. Zusätzlich kann/können die Weitwinkelkamera(s) 498 (z. B. ein Weitwinkel-Stereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert wurde. Die Weitwinkelkamera(s) 498 kann/können auch für die Objekterkennung und -klassifizierung sowie für die grundlegende Objektverfolgung verwendet werden.
Eine oder mehrere Stereokameras 468 kann/können auch in einer nach vom gerichteten Konfiguration vorhanden sein. Die Stereokamera(s) 468 kann/können eine integrierte Steuereinheit aufweisen, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (z. B. FPGA) und einen Mehrkern-Mikroprozessor mit integrierter CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Eine solche Einheit kann verwendet werden, um eine 3D-Karte der Fahrzeugumgebung zu erstellen, die eine Abstandsschätzung für alle Punkte im Bild aufweist. (Eine) alternative Stereokamera(s) 468 kann/können einen kompakten Stereobildsensor aufweisen, der zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip aufweist, der den Abstand zwischen dem Fahrzeug und dem Zielobjekt misst und die erzeugten Informationen (z. B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurhaltewarnfunktionen verwendet. Andere Typen von Stereokameras 468 können zusätzlich oder alternativ zu den hier beschriebenen verwendet werden.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung seitlich des Fahrzeugs 400 aufweist (z. B. Seitenkameras), können für die Umgebungsansicht verwendet werden und Informationen liefern, die zur Erstellung und Aktualisierung des Belegungsgitters sowie zur Erzeugung von Seitenaufprallwarnungen verwendet werden. Beispielsweise kann/können die Umgebungskamera(s) 474 (z. B. vier Umgebungskameras 474 wie in 4B dargestellt) um das Fahrzeug 400 herum angeordnet sein. Die Umgebungskamera(s) 474 kann/können Weitwinkelkamera(s) 470, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches aufweisen. Zum Beispiel können vier Fischaugenkameras an der Vorderseite, am Heck und an den Seiten des Fahrzeugs positioniert sein. In einer alternativen Anordnung kann das Fahrzeug drei Umgebungskamera(s) 474 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z. B. eine nach vom gerichtete Kamera) als vierte Surround-View-Kamera nutzen.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung hinter dem Fahrzeug 400 aufweist (z. B. Rückfahrkameras), können für die Einparkhilfe, die Umgebungsansicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsrasters verwendet werden. Es kann eine Vielzahl von Kameras verwendet werden, die unter anderem Kameras aufweisen, die auch als nach vom gerichtete Kamera(s) geeignet sind (z. B. Fern- und/oder Mittelbereichskamera(s) 498, Stereokamera(s) 468, Infrarotkamera(s) 472 usw.), wie es hier beschrieben ist.
4C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 400 von 4A gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es sollte verstanden werden, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt sind. 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. Darüber hinaus handelt es sich bei vielen der hier beschriebenen Elemente um funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
Jede der Komponenten, Merkmale und Systeme des Fahrzeugs 400 in 4C ist so dargestellt, dass sie über einen Bus 402 verbunden sind. Der Bus 402 kann eine Controller Area Network (CAN)-Datenschnittstelle aufweisen (hier alternativ als „CAN-Bus“ bezeichnet). Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 400 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 400 verwendet wird, wie z. B. die Betätigung von Bremsen, Beschleunigung, Bremsvorgang, Lenkung, Scheibenwischern usw. Ein CAN-Bus kann so ausgestaltet sein, dass er Dutzende oder sogar Hunderte von Knoten hat, von denen jeder seine eigene eindeutige Kennung hat (z. B. eine CAN-ID). Der CAN-Bus kann gelesen werden, um den Lenkradwinkel, die Fahrgeschwindigkeit, die Motordrehzahl (RPM), die Tastenpositionen und/oder andere Fahrzeugstatusanzeigen zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
Obwohl der Bus 402 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können zusätzlich oder alternativ zum CAN-Bus FlexRay und/oder Ethernet verwendet werden. Auch wenn eine einzelne Leitung zur Darstellung des Busses 402 verwendet wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel kann es eine beliebige Anzahl von Bussen 402 geben, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Bustypen mit einem anderen Protokoll aufweisen können. Bei einigen Beispielen können zwei oder mehr Busse 402 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder sie können für Redundanz verwendet werden. Zum Beispiel kann ein erster Bus 402 für die Kollisionsvermeidungsfunktionalität und ein zweiter Bus 402 für die Ansteuerungssteuerung verwendet werden. Bei jedem Beispiel kann jeder Bus 402 mit jeder der Komponenten des Fahrzeugs 400 kommunizieren, und zwei oder mehr Busse 402 können mit denselben Komponenten kommunizieren. Bei einigen Beispielen kann jedes SoC 404, jedes Steuergerät 436 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf dieselben Eingabedaten haben (z. B. Eingaben von Sensoren des Fahrzeugs 400) und kann mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
Das Fahrzeug 400 kann ein oder mehrere Steuergerät(e) 436 aufweisen, wie sie hier in Bezug auf 4A beschrieben sind. Das/die Steuergerät(e) 436 kann/können für eine Vielzahl von Funktionen verwendet werden. Das/die Steuergerät(e) 436 kann/können mit einer beliebigen der verschiedenen anderen Komponenten und Systeme des Fahrzeugs 400 gekoppelt sein und kann/können zur Steuerung des Fahrzeugs 400, zur künstlichen Intelligenz des Fahrzeugs 400, zum Infotainment für das Fahrzeug 400 und/oder dergleichen verwendet werden.
Das Fahrzeug 400 kann ein System (Systeme) auf einem Chip (SoC) 404 aufweisen. Das SoC 404 kann (eine) CPU(s) 406, (eine) GPU(s) 408, (einen) Prozessor(en) 410, (einen) Cache(s) 412, (einen) Beschleuniger 414, (einen) Datenspeicher 416 und/oder andere nicht dargestellte Komponenten und Merkmale aufweisen. Das/die SoC(s) 404 kann/können zur Steuerung des Fahrzeugs 400 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise kann das/die SoC(s) 404 in einem System (z. B. dem System des Fahrzeugs 400) mit einer HD-Karte 422 kombiniert sein, die Kartenaktualisierungen und/oder -updates über eine Netzwerkschnittstelle 424 von einem oder mehreren Servern (z. B. dem/den Server(n) 478 von 4D) erhalten kann.
Die CPU(s) 406 kann/können ein CPU-Cluster oder CPU-Komplex (hier alternativ als „CCPLEX“ bezeichnet) aufweisen. Die CPU(s) 406 kann/können mehrere Kerne und/oder L2-Caches aufweisen. Bei einigen Ausführungsformen kann/können die CPU(s) 406 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration aufweisen. Bei einigen Ausführungsformen kann/können die CPU(s) 406 vier Dual-Core-Cluster aufweisen, wobei jedes Cluster einen dedizierten L2-Cache (z. B. einen 2 MB L2-Cache) besitzt. Die CPU(s) 406 (z. B. der CCPLEX) kann/können so ausgestaltet sein, dass sie den gleichzeitigen Clusterbetrieb unterstützt/en, so dass eine beliebige Kombination der Cluster der CPU(s) 406 zu einem bestimmten Zeitpunkt aktiv sein kann.
Die CPU(s) 406 kann/können Energieverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Merkmale aufweisen: einzelne Hardwareblöcke können im Leerlauf automatisch taktgesteuert werden, um dynamische Energie zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig stromgesteuert sein; jedes Kerncluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder stromgesteuert sind; und/oder jedes Kerncluster kann unabhängig stromgesteuert sein, wenn alle Kerne stromgesteuert sind. Die CPU(s) 406 kann/können darüber hinaus einen erweiterten Algorithmus für die Verwaltung von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufwachzeiten angegeben werden und die Hardware/der Mikrocode den besten Energiezustand für den Kern, den Cluster und CCPLEX bestimmt. Die Prozessorkerne können vereinfachte Sequenzen zur Eingabe des Energiezustands in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert ist.
Die GPU(s) 408 kann/können eine integrierte GPU aufweisen (hier alternativ als „iGPU“ bezeichnet). Die GPU(s) 408 kann/können programmierbar sein und kann/können effizient für parallele Arbeitslasten sein. Die GPU(s) 408 kann/können in einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Die GPU(s) 408 kann/können einen oder mehrere Streaming-Mikroprozessoren aufweisen, wobei jeder Streaming-Mikroprozessor einen L1-Cache (z. B. einen L1-Cache mit einer Speicherkapazität von mindestens 96 KB) aufweise kann, und zwei oder mehr der Streaming-Mikroprozessoren können sich einen L2-Cache (z. B. einen L2-Cache mit einer Speicherkapazität von 512 KB) teilen. Bei einigen Ausführungsformen kann/können die GPU(s) 408 mindestens acht Streaming-Mikroprozessoren aufweisen. Die GPU(s) 408 kann/können computerbasierte Anwendungspro-grammierschnittstelle(n) (API(s)) verwenden. Darüber hinaus kann/können die GPU(s) 408 eine oder mehrere parallele Rechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
Die GPU(s) 408 kann/können für die beste Leistung in automobilen und eingebetteten Anwendungsfällen energieoptimiert sein. Beispielsweise kann/können die GPU(s) 408 auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Dies ist jedoch nicht als Einschränkung zu verstehen, und die GPU(s) 408 kann/können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von Mixed-Precision-Verarbeitungskernen enthalten, die in mehrere Blöcke unterteilt sind. Beispielsweise und ohne Einschränkung können 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke partitioniert sein. Bei einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Genauigkeit für Deep Learning-Matrixarithmetik, ein L0-Befehls-Cache, ein Warp-Scheduler, eine Dispatch-Einheit und/oder eine 64 KB große Registerdatei zugewiesen werden. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkomma-Datenpfade aufweisen, 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-Planungsfunktion aufweisen, um eine feinkörnigere Synchronisation und Zusammenarbeit zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können einen kombinierten L1-Datencache und eine Shared-Memory-Einheit aufweisen, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
Die GPU(s) 408 kann/können einen Speicher mit hoher Bandbreite (HBM) und/oder ein 16-GB-HBM2-Speicher-Subsystem aufweisen, um in einigen Beispielen eine Spitzen-Speicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispielen kann zusätzlich zu oder alternativ zu dem HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) verwendet werden, wie z. B. ein synchroner Grafik-Doppeldatenraten-Direktzugriffsspeicher vom Typ 5 (GDDR5).
Die GPU(s) 408 kann/können eine Unified-Memory-Technologie aufweisen, die Zugriffszähler enthält, 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. Bei einigen Beispielen kann die Unterstützung von Adresskonvertierungsdiensten (ATS) verwendet werden, damit die GPU(s) 408 direkt auf die Seitentabellen der CPU(s) 406 zugreifen können. Bei solchen Beispielen kann, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 408 einen Fehler feststellt, eine Adresskonvertierungsanforderung an die CPU(s) 406 gesendet werden. Als Antwort darauf kann die CPU(s) 406 in ihren Seitentabellen nach der virtuellphysikalischen Zuordnung für die Adresse suchen und die Konvertierung zurück an die GPU(s) 408 übertragen. Als solches kann die Unified-Memory-Technologie einen einzigen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 406 als auch der GPU(s) 408 ermöglichen, was die Programmierung der GPU(s) 408 und die Portierung von Anwendungen auf die GPU(s) 408 vereinfacht.
Darüber hinaus kann die GPU(s) 408 einen Zugriffszähler aufweisen, der die Häufigkeit des Zugriffs der GPU(s) 408 auf den Speicher anderer Prozessoren verfolgen kann. Der Zugriffszähler kann helfen, sicherzustellen, dass Speicherseiten in den physischen Speicher des Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
Das/die SoC(s) 404 kann/können eine beliebige Anzahl von Cache(s) 412 aufweisen, einschließlich der hier beschriebenen. Beispielsweise kann/können der/die Cache(s) 412 einen L3-Cache aufweisen, der/die sowohl der/den CPU(s) 406 als auch der/den GPU(s) 408 zur Verfügung steht/en (z. B. der/die sowohl mit der/den CPU(s) 406 als auch der/den GPU(s) 408 verbunden ist/sind). Der/die Cache(s) 412 kann/können einen Write-Back-Cache aufweisen, der die Zustände von Zeilen verfolgen kann, z. B. durch Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann je nach Ausführungsform 4 MB oder mehr aufweisen, obwohl auch kleinere Cache-Größen verwendet werden können.
Das/die SoC(s) 404 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) aufweisen, die bei der Durchführung von Verarbeitungen in Bezug auf eine beliebige Vielzahl von Aufgaben oder Operationen des Fahrzeugs 400 - wie z. B. die Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus kann/können das/die SoC(s) 404 eine Gleitkomma-einheit(en) (FPU(s)) - oder andere mathematische Koprozessoren oder numerische Koprozessortypen - zur Durchführung von mathematischen Operationen innerhalb des Systems aufweisen. Zum Beispiel kann das SoC (können die SoCs) 104 eine oder mehrere FPUs aufweisen, die als Ausführungseinheiten in einer CPU (406) und/oder GPU (408) integriert sind.
Das/die SoC(s) 404 kann/können einen oder mehrere Beschleuniger 414 aufweisen (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Zum Beispiel kann das/die SoC(s) 404 einen Hardware-Beschleunigungscluster aufweisen, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher aufweisen kann. Der große On-Chip-Speicher (z. B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster in die Lage versetzen, neuronale Netze und andere Berechnungen zu beschleunigen. Der Hardware-Beschleunigungscluster kann zur Ergänzung der GPU(s) 408 und zur Entlastung einiger Aufgaben der GPU(s) 408 verwendet werden (z. B. um mehr Zyklen der GPU(s) 408 für die Durchführung anderer Aufgaben freizugeben). Der/die Beschleuniger 414 kann/können beispielsweise für gezielte Arbeitslasten (z. B. Wahrnehmung, faltende neuronale Netze (CNNs) usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der Begriff „CNN“, wie er hier verwendet wird, kann alle Arten von CNNs aufweisen, einschließlich regionenbasierter oder regionaler faltender neuronaler Netze (RCNs) und Fast-RCNs (z. B. wie sie für die Objekterkennung verwendet werden).
Der/die Beschleuniger 414 (z. B. der Hardware-Beschleunigungscluster) kann/können einen Deep-Learning-Beschleuniger (DLA) aufweisen. Der/die DLA(s) kann/können eine oder mehrere Tensor Processing Units (TPUs) aufweisen, die so ausgestaltet sein können, dass sie zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Learning-Anwendungen und Inferencing bereitstellen. Die TPUs können Beschleuniger sein, die für die Ausführung von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) ausgestaltet und optimiert sind. Der/die DLA(s) können darüber hinaus für einen bestimmten Satz von Typen neuronaler Netze und Fließkommaoperationen sowie Inferencing optimiert sein. Das Design des/der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Allzweck-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 Merkmale als auch für Gewichte unterstützt, sowie Postprozessorfunktionen.
Der/die DLA(s) kann/können schnell und effizient neuronale Netze, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, die beispielsweise und ohne Einschränkung Folgendes aufweisen: ein CNN für die Objektidentifikation und -erkennung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Erkennung und Identifikation von Einsatzfahrzeugen unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und die Identifikation des Fahrzeugbesitzers unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsrelevante Ereignisse.
Der/die DLA(s) kann/können jede Funktion der GPU(s) 408 ausführen, und durch die Verwendung eines Inferenzbeschleunigers kann ein Designer beispielsweise entweder den/die DLA(s) oder die GPU(s) 408 für jede Funktion gezielt einsetzen. Beispielsweise kann der Entwickler die Verarbeitung von CNNs und Fließkommaoperationen auf den/die DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 408 und/oder anderen Beschleuniger(n) 414 überlassen.
Der/die Beschleuniger 414 (z. B. der Hardware-Beschleunigungscluster) kann/können einen programmierbaren Bildverarbeitungsbeschleuniger (PVA) aufweisen, der hier alternativ auch als Computer-Vision-Beschleuniger bezeichnet werden kann. Der/die PVA(s) kann/können so gestaltet und ausgestaltet sein, dass er/sie Computer-Vision-Algorithmen für fortschrittliche Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented-Reality (AR)- und/oder Virtual-Reality (VR)-Anwendungen beschleunigt. Der/die PVA(s) kann/können ein Gleichgewicht zwischen Leistung und Flexibilität bieten. Zum Beispiel kann jeder PVA beispielsweise und ohne Einschränkung eine beliebige Anzahl von RISC-Kernen (Reduced Instruction Set Computer), direkten Speicherzugriff (DMA) und/oder eine beliebige Anzahl von Vektorprozessoren aufweisen.
Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren einer der hier beschriebenen Kameras), Bildsignalprozessor(en) und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher aufweisen. Die RISC-Kerne können je nach Ausführungsform eine beliebige Anzahl von Protokollen verwenden. Bei einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. Die RISC-Kerne können mit einer oder mehreren integrierten Einrichtungen, anwendungsspezifischen integrierten Schaltungen (ASICs) und/oder Speichereinrichtungen implementiert sein. Beispielsweise können die RISC-Kerne einen Befehls-Cache und/oder einen eng gekoppelten RAM aufweisen.
Der DMA kann es Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 406 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Merkmalen unterstützen, die zur Optimierung der PVA verwendet werden, einschließlich, aber nicht beschränkt auf, die Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. Bei 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 aufweisen können.
Die Vektorprozessoren können programmierbare Prozessoren sein, die so gestaltet sein können, dass sie die Programmierung für Computer-Vision-Algorithmen effizient und flexibel ausführen und Signalverarbeitungsfunktionen bereitstellen. Bei einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen aufweisen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA-Engine(s) (z.B. zwei DMA-Engines) und/oder andere Peripheriegeräte aufweisen. Das Vektorverarbeitungs-Subsystem kann als primäre Verarbeitungsmaschine des PVAs arbeiten und kann eine Vektorverarbeitungseinheit (VPU), einen Befehlscache und/oder einen Vektorspeicher (z. B. VMEM) aufweisen. Ein VPU-Kern kann einen digitalen Signalprozessor aufweisen, wie z. B. einen digitalen Signalprozessor mit einer Anweisung, mehreren Daten (SIMD) und sehr langen Anweisungsworten (VLIW). Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
Jeder der Vektorprozessoren kann einen Befehls-Cache aufweisen und mit einem dedizierten Speicher gekoppelt sein. Als Ergebnis kann bei einigen Beispielen jeder der Vektorprozessoren so ausgestaltet sein, dass er unabhängig von den anderen Vektorprozessoren arbeitet. Bei anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA vorhanden sind, so ausgestaltet sein, dass sie Datenparallelität verwenden. Bei einigen Ausführungsformen kann die Vielzahl der in einem einzigen PVA enthaltenen Vektorprozessoren beispielsweise denselben Computer-Vision-Algorithmus ausführen, jedoch für unterschiedliche Bereiche eines Bildes. Bei anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, gleichzeitig verschiedene Computer-Vision-Algorithmen auf demselben Bild ausführen oder sogar verschiedene Algorithmen auf aufeinanderfolgenden Bildern oder Abschnitten eines Bildes ausführen. Unter anderem kann der Hardware-Beschleunigungs-Cluster eine beliebige Anzahl von PVAs aufweisen und jeder der PVAs kann eine beliebige Anzahl von Vektorprozessoren aufweisen. Darüber hinaus kann/können der/die PVA(s) einen zusätzlichen ECC-Speicher (Error Correcting Code) aufweisen, um die Sicherheit des Gesamtsystems zu erhöhen.
Der (die) Beschleuniger 414 (z. B. der Hardware-Beschleunigungscluster) kann (können) ein Computer-Vision-Netzwerk auf dem Chip und SRAM aufweisen, um einen SRAM mit hoher Bandbreite und niedriger Latenz für den (die) Beschleuniger 414 bereitzustellen. Bei einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM aufweisen, der z. B. und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen kann. Jedes Paar von Speicherblöcken kann eine APB-Schnittstelle (Advanced Peripheral Bus), Konfigurationsschaltungen, einen Controller und einen Multiplexer aufweisen. Es kann jeder beliebige Speichertyp verwendet werden. Der PVA und der DLA können über ein Backbone auf den Speicher zugreifen, das dem PVA und dem DLA einen Hochgeschwindigkeitszugriff auf den Speicher ermöglicht. Der Backbone kann ein Computer-Vision-Netzwerk auf dem Chip aufweisen, das den PVA und den DLA mit dem Speicher verbindet (z. B. unter Verwendung des APB).
Das Computer-Vision-Netzwerk auf dem Chip kann eine Schnittstelle aufweisen, die vor der Übertragung von Steuersignalen/Adressen/Daten feststellt, dass sowohl der PVA als auch der DLA bereitstehende und gültige Signale liefern. Eine solche Schnittstelle kann getrennte Phasen und getrennte Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie 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.
Bei einigen Beispielen kann/können das/die SoC(s) 404 einen Echtzeit-Raytracing-Hardwarebeschleuniger aufweisen, 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, für die RADAR-Signalinterpretation, für die Schallausbreitungssynthese und/oder -analyse, für die Simulation von SONAR-Systemen, für die allgemeine Wellenausbreitungssimulation, für den Vergleich mit LIDAR-Daten zum Zweck der Lokalisierung und/oder für andere Funktionen und/oder für andere Zwecke. Bei einigen Ausführungsformen können eine oder mehrere Tree Traversal Units (TTUs) für die Ausführung einer oder mehrerer Raytracing-bezogener Operationen verwendet werden.
Der/die Beschleuniger 414 (z. B. der Hardware-Beschleuniger-Cluster) hat/haben eine breite Palette von Verwendungen für das autonome Fahren. Der PVA kann ein programmierbarer Bildverarbeitungsbeschleuniger sein, der für wichtige Verarbeitungsschritte in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten des PVAs passen gut zu algorithmischen Domänen, die eine vorhersagbare Verarbeitung bei geringem Stromverbrauch und niedriger Latenzzeit benötigen. Mit anderen Worten, der PVA eignet sich gut für halbdichte oder dichte reguläre Berechnungen, auch bei kleinen Datensätzen, die vorhersagbare Laufzeiten mit geringer Latenz und niedrigem Stromverbrauch benötigen. Im Kontext von Plattformen für autonome Fahrzeuge sind die PVAs daher dafür ausgelegt, klassische Computer-Vision-Algorithmen auszuführen, da sie effizient bei der Objekterkennung sind und mit ganzzahliger Mathematik arbeiten.
Gemäß einer Ausführungsform der Technologie wird der PVA beispielsweise zur Durchführung von Computer-Stereo-Vision verwendet. Bei einigen Beispielen kann ein semiglobaler Matching-basierter Algorithmus verwendet werden, obwohl dies nicht als Einschränkung gedacht ist. Viele Anwendungen für das autonome Fahren der Stufe 3-5 erfordern eine Bewegungsschätzung/Stereo-Matching on-the-fly (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Der PVA kann eine Computer-Stereo-Vision-Funktion auf Eingaben von zwei monokularen Kameras ausführen.
Bei einigen Beispielen kann der PVA verwendet werden, um auf einem dichten optischen Fluss zu arbeiten. Zum Beispiel kann der PVA verwendet werden, um RADAR-Rohdaten zu verarbeiten (z. B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um ein verarbeitetes RADAR-Signal bereitzustellen, bevor der nächste RADAR-Impuls gesendet wird. Bei anderen Beispielen wird der PVA für die Flugzeittiefenverarbeitung verwendet, indem er z. B. Flugzeit-Rohdaten verarbeitet, um verarbeitete Flugzeitdaten bereitzustellen.
Der DLA kann verwendet werden, um jede Art von Netzwerk zu betreiben, um die Kontrolle und die Fahrsicherheit zu verbessern, was beispielsweise ein neuronales Netzwerk einschließt, das für jede Objekterkennung ein Maß für die Konfidenz bzw. das Vertrauen ausgibt. Ein solcher Konfidenzwert kann als Wahrscheinlichkeit interpretiert werden oder eine relative „Gewichtung“ jeder Erkennung im Vergleich zu anderen Erkennungen liefern. Dieser Konfidenzwert bzw. Vertrauenswert ermöglicht es dem System, darüber hinaus Entscheidungen darüber zu treffen, welche Erkennungen als echte positive Erkennungen und welche als falsch positive Erkennungen betrachtet werden sollten. Zum Beispiel kann das System einen Schwellenwert für die Konfidenz festlegen und nur die Erkennungen, die den Schwellenwert überschreiten, als echte positive Erkennungen betrachten. Bei einem automatischen Notbremssystem (AEB) würden falsch positive Erkennungen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was natürlich unerwünscht ist. Daher sollten nur die sichersten Erkennungen als Auslöser für ein AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netz zur Regression des Konfidenzwertes einsetzen. Das neuronale Netz kann als Eingabe zumindest eine Teilmenge von Parametern verwenden, wie z. B. die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Teilsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des IMU-Sensors 466 (Inertial Measurement Unit), die mit der Ausrichtung des Fahrzeugs 400 korreliert, die Entfernung, die 3D-Positionsschätzungen des Objekts, die von dem neuronalen Netz und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 464 oder RADAR-Sensor(en) 460) erhalten werden, und andere.
Das/die SoC(s) 404 kann/können die Datenspeicher 416 (z. B. Speicher) aufweisen. Der (die) Datenspeicher 416 kann (können) ein On-Chip-Speicher des (der) SoC(s) 404 sein, der (die) neuronale Netze speichern kann (können), die auf der GPU und/oder dem DLA ausgeführt werden sollen. Bei einigen Beispielen kann die Kapazität des/der Datenspeicher(s) 416 groß genug sein, um mehrere Instanzen von neuronalen Netzen für Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 416 kann/können (einen) L2 oder L3 Cache(s) 412 umfassen. Der Verweis auf den/die Datenspeicher 416 kann einen Verweis auf den Speicher aufweisen, der mit dem PVA, DLA und/oder anderen Beschleunigern 414 verbunden ist, wie es hierin beschrieben ist.
Das/die SoC(s) 404 kann/können einen oder mehrere Prozessor(en) 410 (z. B. eingebettete Prozessoren) aufweisen. Der/die Prozessor(en) 410 kann/können einen Boot- und Energieverwaltungsprozessor aufweisen, der ein dedizierter Prozessor und ein Subsystem sein kann, um die Boot-Energie- und Verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Energieverwaltungsprozessor kann ein Teil der Boot-Sequenz des/der SoC(s) 404 sein und kann Laufzeit-Energieverwaltungsdienste bereitstellen. Der Boot-Energieversorgungs- und -Verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Systemübergängen mit niedrigem Stromverbrauch, Verwaltung von Temperaturen und Temperatursensoren des/der SoC(s) 404 und/oder Verwaltung der Leistungszustände des/der SoC(s) 404 bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und das/die SoC(s) 404 kann/können die Ringoszillatoren verwenden, um die Temperaturen der CPU(s) 406, GPU(s) 408 und/oder des/der Beschleuniger(s) 414 zu erfassen. Wenn festgestellt wird, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Energieverwaltungsprozessor in eine Temperaturfehlerroutine eintreten und das/die SoC(s) 404 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 400 in einen Chauffeur-to-Safe-Stop-Modus versetzen (z. B. das Fahrzeug 400 zu einem sicheren Halt bringen).
Der/die Prozessor(en) 410 kann/können darüber hinaus einen Satz eingebetteter Prozessoren aufweisen, die als eine Audioverarbeitungsmaschine dienen können. Die Audioverarbeitungsmaschine kann ein Audio-Subsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen und einen breiten und flexiblen Bereich von Audio-E/A-Schnittstellen ermöglicht. Bei einigen Beispielen ist die Audioverarbeitungsmaschine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
Der (die) Prozessor(en) 410 kann (können) darüber hinaus eine „Always-on“-Prozessor-Maschine aufweisen, die die notwendigen Hardware-Funktionen zur Unterstützung von Sensormanagement mit geringem Stromverbrauch und Wake-Use-Cases bereitstellen kann. Die Always-on-Prozessor-Maschine kann einen Prozessorkern, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z. B. Timer und Interrupt-Controller), verschiedene E/A-Controller-Peripheriegeräte und Routing-Logik aufweisen.
Der/die Prozessor(en) 410 kann/können darüber hinaus eine Safety-Cluster-Maschine aufweisen, die ein dediziertes Prozessor-Subsystem zur Handhabung des Sicherheitsmanagements für Automobilanwendungen umfasst. Die Safety-Cluster-Maschine kann zwei oder mehr Prozessorkerne, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z. B. Timer, einen Interrupt-Controller usw.) und/oder Routing-Logik aufweisen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Lockstep-Modus arbeiten und als ein einziger Kern mit einer Vergleichslogik funktionieren, um etwaige Unterschiede zwischen ihren Operationen zu erkennen.
Der/die Prozessor(en) 410 kann/können darüber hinaus eine Echtzeit-Kamera-Maschine aufweisen, die ein dediziertes Prozessor-Subsystem zur Handhabung des Echtzeit-Kameramanagements aufweisen kann.
Der (die) Prozessor(en) 410 kann (können) darüber hinaus einen Signalprozessor mit hohem Dynamikbereich aufweisen, der einen Bildsignalprozessor aufweisen kann, der eine Hardware-Maschine ist, die Teil der Kameraverarbeitungspipeline ist.
Der (die) Prozessor(en) 410 kann (können) einen Videobildkompositor aufweisen, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Spieler-Fenster zu erzeugen. Der Videobildkompositor kann eine Linsenverzerrungskorrektur an der/den Weitwinkelkamera(s) 470, der/den Umgebungskamera(s) 474 und/oder an den Kamerasensoren für die Überwachung in dem Fahrgastraum durchführen. Ein Überwachungskamerasensor innerhalb des Fahrgastraums wird vorzugsweise von einem neuronalen Netz überwacht, das auf einer anderen Instanz des erweiterten SoC läuft und so ausgestaltet ist, dass es Ereignisse innerhalb des Fahrgastraums erkennt und entsprechend reagiert. Ein System im Fahrgastraum kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, das Fahrtziel zu ändern, das Infotainmentsystem und die Einstellungen des Fahrzeugs zu aktivieren oder zu ändern oder sprachgesteuertes Surfen im Internet zu ermöglichen. Bestimmte Funktionen stehen dem Fahrer nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
Der Videobildkompositor kann eine erweiterte zeitliche Rauschunterdrückung sowohl für räumliche als auch zeitliche Rauschunterdrückung aufweisen. Wenn beispielsweise Bewegung in einem Video auftritt, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend und verringert das Gewicht der Informationen, die von benachbarten Bildern geliefert werden. Wenn ein Bild oder ein Abschnitt eines Bildes keine Bewegung aufweist, kann die vom Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
Der Videobildkompositor kann auch so ausgestaltet sein, dass er eine Stereokorrektur an den eingegebenen Stereolinsenbildern durchführt. Der Videobildkompositor kann darüber hinaus für die Komposition der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 408 nicht zum kontinuierlichen Rendem neuer Oberflächen benötigt wird/werden. Selbst wenn die GPU(s) 408 eingeschaltet ist/sind und aktiv 3D-Rendering durchfuhrt/en, kann der Videobildkompositor verwendet werden, um die GPU(s) 408 zu entlasten und die Leistung und Reaktionsfähigkeit zu verbessern.
Das/die SoC(s) 404 kann/können darüber hinaus eine serielle MIPI-Kameraschnittstelle für den Empfang von Videos und Eingaben von Kameras, eine Hochgeschwindigkeits-Schnittstelle und/oder einen Videoeingabeblock aufweisen, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Das/die SoC(s) 404 kann/können darüber hinaus eine Eingangs-/Ausgangs-Steuerung aufweisen, die durch Software gesteuert werden kann und für den Empfang von E/A-Signalen verwendet werden kann, die keiner bestimmten Rolle zugeordnet sind. Das/die SoC(s) 404 kann/können darüber hinaus eine breite Palette von Peripherieschnittstellen aufweisen, um die Kommunikation mit Peripheriegeräten, Audiocodecs, Energieverwaltung und/oder anderen Einrichtungen zu ermöglichen. Das/die SoC(s) 404 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) 464, RADAR-Sensor(en) 460 usw., die über Ethernet verbunden sein können), Daten vom Bus 402 (z. B. Geschwindigkeit des Fahrzeugs 400, Lenkradposition usw.), Daten von GNSS-Sensor(en) 458 (z. B. verbunden über Ethernet oder CAN-Bus) zu verarbeiten. Das/die SoC(s) 404 kann/können darüber hinaus dedizierte Hochleistungs-Massenspeicher-Steuerungen aufweisen, die ihre eigenen DMA-Maschinen aufweisen können, und die verwendet werden können, um die CPU(s) 406 von routinemäßigen Datenverwaltungsaufgaben zu befreien.
Das/die SoC(s) 404 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 für Diversität und Redundanz nutzt und effizient einsetzt, und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Deep-Learning-Tools bietet. Das/die SoC(s) 404 kann/können schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Zum Beispiel kann/können der/die Beschleuniger 414, wenn er/sie mit der/den CPU(s) 406, der/den GPU(s) 408 und dem/den Datenspeicher(n) 416 kombiniert ist/sind, eine schnelle, effiziente Plattform für autonome Fahrzeuge der Stufe 3-5 bilden.
Die Technologie bietet somit Fähigkeiten und Funktionen, die von herkömmlichen Systemen nicht erreicht werden können. Zum Beispiel können Computer-Vision-Algorithmen auf CPUs ausgeführt werden, die mit einer High-Level-Programmiersprache, wie der Programmiersprache C, ausgestaltet sein können, um eine Vielzahl von Verarbeitungsalgorithmen über eine Vielzahl von visuellen Daten auszuführen. Allerdings sind CPUs oft nicht in der Lage, die Leistungsanforderungen vieler Computer-Vision-Anwendungen zu erfüllen, wie z. B. die Anforderungen an die Ausführungszeit und den Stromverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, was eine Anforderung von fahrzeuginternen ADAS-Anwendungen und eine Anforderung für praxistaugliche autonome Fahrzeuge der Stufe 3-5 ist.
Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungs-Clusters die gleichzeitige und/oder sequentielle Ausführung mehrerer neuronaler Netze und die Kombination der Ergebnisse, um die Funktionalität des autonomen Fahrens der Stufe 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder der dGPU (z. B. der/den GPU(s) 420) ausgeführt wird, eine Text- und Worterkennung aufweisen, die es dem Supercomputer ermöglicht, Verkehrszeichen zu lesen und zu verstehen, einschließlich Zeichen, für die das neuronale Netz nicht speziell trainiert wurde. Der DLA kann darüber hinaus ein neuronales Netz aufweisen, das in der Lage ist, das Zeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis zu liefern und dieses semantische Verständnis an die Wegplanungsmodule weiterzugeben, die auf dem CPU-Komplex laufen.
Als weiteres Beispiel können mehrere neuronale Netze gleichzeitig ausgeführt werden, wie es für Stufe 3, 4 oder 5 erforderlich ist. Zum Beispiel kann ein Warnschild, bestehend aus „Vorsicht: Blinkende Lichter weisen auf vereiste Bedingungen hin“, zusammen mit einem elektrischen Licht, unabhängig oder gemeinsam von mehreren neuronalen Netzen interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netz (z. B. einem trainierten neuronalen Netz) als Verkehrsschild identifiziert werden, der Text „Blinkende Lichter deuten auf Eisglätte hin“ kann von einem zweiten eingesetzten neuronalen Netz interpretiert werden, das die Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass bei der Erkennung blinkender Lichter Eisglätte vorliegt. Das Blinklicht kann durch den Betrieb eines dritten eingesetzten neuronalen Netzes über mehrere Bilder identifiziert werden, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. Alle drei neuronalen Netze können gleichzeitig laufen, z. B. innerhalb des DLAs und/oder auf der/den GPU(s) 408.
Bei einigen Beispielen kann ein CNN für die Gesichtserkennung und die Identifizierung des Fahrzeugbesitzers Daten von Kamerasensoren verwenden, um die Anwesenheit eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 400 zu identifizieren. Die „Always-on“-Sensorverarbeitungs-Maschine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn der Besitzer sich der Fahrertür nähert, und die Beleuchtung einzuschalten, und um im Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgen das/die SoC(s) 404 für Sicherheit gegen Diebstahl und/oder Carjacking.
Bei einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 496 verwenden, um Sirenen von Einsatzfahrzeugen zu erkennen und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Erkennung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, nutzt/en das/die SoC(s) 404 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung visueller Daten. Bei einer bevorzugten Ausführungsform wird das CNN, das auf dem DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu erkennen (z. B. durch Verwendung des Dopplereffekts). Das CNN kann auch so trainiert werden, dass es Einsatzfahrzeuge identifiziert, die spezifisch für den lokalen Bereich sind, in dem das Fahrzeug operiert, wie es von GNSS-Sensor(en) 458 identifiziert wird. So wird das CNN z. B. bei einem Einsatz in Europa versuchen, europäische Sirenen zu erkennen, und bei einem Einsatz in den Vereinigten Staaten wird das CNN versuchen, nur nordamerikanische Sirenen zu erkennen. Sobald ein Einsatzfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge auszuführen, das Fahrzeug zu verlangsamen, an den Straßenrand zu fahren, das Fahrzeug zu parken und/oder das Fahrzeug im Leerlauf laufen zu lassen, mit Hilfe der Ultraschallsensoren 462, bis das/die Einsatzfahrzeug(e) vorbeifahrt bzw. vorbeifahren.
Das Fahrzeug kann (eine) CPU(s) 418 (z. B. diskrete CPU(s) oder dCPU(s)) aufweisen, die mit dem/den SoC(s) 404 über eine Hochgeschwindigkeitsverbindung (z. B. PCIe) gekoppelt sein kann/können. Die CPU(s) 418 kann/können z. B. einen X86-Prozessor aufweisen.
Die CPU(s) 418 kann/können verwendet werden, um eine beliebige einer Vielzahl von Funktionen auszuführen, einschließlich der Schlichtung potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und dem/den SoC(s) 404 und/oder der Überwachung des Status und des Zustands der Steuerung(en) 436 und/oder des Infotainment-SoC 430, zum Beispiel.
Das Fahrzeug 400 kann (eine) GPU(s) 420 (z.B. diskrete GPU(s) oder dGPU(s)) aufweisen, die mit dem/den SoC(s) 404 über eine Hochgeschwindigkeitsverbindung (z.B. NVI-DIAs NVLINK) gekoppelt sein kann/können. Der/die GPU(s) 420 kann/können eine zusätzliche künstliche Intelligenzfunktionalität bereitstellen, z. B. durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netze, und kann/können zum Trainieren und/oder Aktualisieren neuronaler Netze auf der Grundlage von Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 400 verwendet werden.
Das Fahrzeug 400 kann darüber hinaus die Netzwerkschnittstelle 424 aufweisen, die eine oder mehrere drahtlose Antennen 426 aufweisen kann (z. B. eine oder mehrere drahtlose Antennen für verschiedene Kommunikationsprotokolle, wie eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzwerkschnittstelle 424 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit dem/den Server(n) 478 und/oder anderen Netzwerkeinrichtungen), mit anderen Fahrzeugen und/oder mit Recheneinrichtungen (z. B. Clienteinrichtungen von Insassen) 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 400 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 400 liefern (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 400). Diese Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 400 sein.
Die Netzwerkschnittstelle 424 kann ein SoC aufweisen, das Modulations- und Demodulationsfunktionalität bereitstellt und dem/den Steuergerät(en) 436 ermöglicht, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 424 kann ein Funkfrequenz-Frontend zur Aufwärtskonvertierung eines Basisbands auf eine Funkfrequenz und zur Abwärtskonvertierung von einer Funkfrequenz auf ein Basisband aufweisen. Die Frequenzumwandlungen können durch bekannte Verfahren durchgeführt werden, und/oder sie können unter Verwendung von Super-Heterodyn-Verfahren durchgeführt werden. Bei einigen Beispielen kann die Hochfrequenz-Front-End-Funktionalität von einem separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann eine drahtlose Funktionalität zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle aufweisen. Das Fahrzeug 400 kann darüber hinaus einen oder mehrere Datenspeicher 428 aufweisen, die eine Speicherung außerhalb des Chips (z. B. außerhalb des SoCs 404) aufweisen können. Der/die Datenspeicher 428 kann/können ein oder mehrere Speicherelemente aufweisen, einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Einrichtungen, die mindestens ein Datenbit speichern können.
Das Fahrzeug 400 kann darüber hinaus (einen) GNSS-Sensor(en) 458 (z. B. GPS- und/oder unterstützte GPS-Sensoren) aufweisen, um bei der Kartierung, der Wahrnehmung, der Erstellung von Belegungsrastern und/oder den Pfadplanungsfunktionen zu helfen. Es kann eine beliebige Anzahl von GNSS-Sensor(en) 458 verwendet werden, die z. B. und ohne Einschränkung ein GPS aufweisen, das einen USB-Anschluss mit einer Ethernet-zu-Seriell-(RS-232)-Brücke verwendet.
Das Fahrzeug 400 kann darüber hinaus RADAR-Sensor(en) 460 aufweisen. Der/die RADAR-Sensor(en) 460 kann/können vom Fahrzeug 400 zur Fahrzeugerkennung über große Entfernungen, auch bei Dunkelheit und/oder schlechten Wetterbedingungen, verwendet werden. Die RADAR-Funktionssicherheitsstufen können ASIL B sein. Der/die RADAR-Sensor(en) 460 kann/können den CAN-Bus und/oder den Bus 402 (z. B. zur Übertragung von Daten, die von dem/den RADAR-Sensor(en) 460 erzeugt werden) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, wobei bei einigen Beispielen der Zugriff auf Rohdaten über Ethernet erfolgt. Es kann eine Vielzahl von RADAR-Sensortypen verwendet werden. Zum Beispiel und ohne Einschränkung können der/die RADAR-Sensor(en) 460 für den Einsatz von Front-, Heck- und Seiten-RADAR geeignet sein. Bei einigen Beispielen werden Puls-Doppler-RADAR-Sensor(en) verwendet.
Der/die RADAR-Sensor(en) 460 kann/können verschiedene Konfigurationen aufweisen, wie z. B. eine große Reichweite mit engem Sichtfeld, eine kurze Reichweite mit breitem Sichtfeld, eine seitliche Abdeckung mit kurzer Reichweite, usw. Bei einigen Beispielen kann ein RADAR mit großer Reichweite für die adaptive Geschwindigkeitsregelungsfunktion verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein breites Sichtfeld bieten, das durch zwei oder mehr unabhängige Abtastungen realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 460 kann/können helfen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und kann/können von ADAS-Systemen für Notbremsassistenten und Vorwärtskollisionswarnungen verwendet werden. Langstrecken-RADAR-Sensoren können ein monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle aufweisen. Bei einem Beispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu dient, die Umgebung des Fahrzeugs 400 bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den benachbarten Fahrspuren zu erfassen. Die anderen beiden Antennen können das Sichtfeld erweitern, so dass Fahrzeuge, die in die Fahrspur des Fahrzeugs 400 einfahren oder diese verlassen, schnell erfasst werden können.
RADAR-Systeme mit mittlerer Reichweite können z. B. eine Reichweite von bis zu 460 m (vorn) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorn) oder 450 Grad (hinten) aufweisen. RADAR-Systeme mit kurzer Reichweite können ohne Einschränkung RADAR-Sensoren aufweisen, die für die Installation an beiden Enden des hinteren Stoßfängers vorgesehen 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 neben dem Fahrzeug überwachen.
RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder als Spurwechselassistent verwendet werden.
Das Fahrzeug 400 kann darüber hinaus Ultraschallsensor(en) 462 aufweisen. Der/die Ultraschallsensor(en) 462, der/die an der Vorderseite, der Rückseite und/oder den Seiten des Fahrzeugs 400 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 462 verwendet werden, und unterschiedliche Ultraschallsensoren 462 können für unterschiedliche Erfassungsbereiche (z. B. 2,5 m, 4 m) verwendet werden. Der/die Ultraschallsensor(en) 462 kann/können bei funktionalen Sicherheitsstufen von ASIL B arbeiten.
Das Fahrzeug 400 kann (einen) LIDAR-Sensor(en) 464 aufweisen. Der/die LIDAR-Sensor(en) 464 kann/können für Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 464 kann/können die funktionale Sicherheitsstufe ASIL B aufweisen. Bei einigen Beispielen kann das Fahrzeug 400 mehrere LIDAR-Sensoren 464 (z. B. zwei, vier, sechs usw.) aufweisen, die Ethernet verwenden können (z. B. zur Bereitstellung von Daten an einen Gigabit-Ethernet-Switch).
Bei einigen Beispielen kann/können der/die LIDAR-Sensor(en) 464 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld zu liefern. Kommerziell erhältliche(r) LIDAR-Sensor(en) 464 kann/können eine angegebene Reichweite von ca. 100m haben, mit einer Genauigkeit von 2cm-3cm und mit Unterstützung für eine 100Mbps Ethernet-Verbindung, zum Beispiel. Bei einigen Beispielen können ein oder mehrere nicht vorstehende LIDAR-Sensoren 464 verwendet werden. Bei solchen Beispielen kann/können der/die LIDAR-Sensor(en) 464 als kleine Einrichtung implementiert sein, die in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 400 eingebettet sein kann. Der/die LIDAR-Sensor(en) 464 kann/können bei solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von bis zu 35 Grad bereitstellen, mit einer Reichweite von 200 m selbst bei Objekten mit geringer Reflektivität. Der/die frontmontierte(n) LIDAR-Sensor(en) 464 kann/können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad ausgestaltet sein.
Bei einigen Beispielen können auch LIDAR-Technologien, wie z. B. 3D-Flash-LIDAR, verwendet werden. 3D Flash LIDAR verwendet einen Blitz eines Lasers als Sendequelle, um die Umgebung des Fahrzeugs bis zu ca. 200 m auszuleuchten. Eine Flash-LIDAR-Einheit weist einen Rezeptor auf, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum der Entfernung des Fahrzeugs zu den Objekten entspricht. Flash-LIDAR kann es ermöglichen, mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung zu erzeugen. Bei einigen Beispielen können vier Flash-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 400. Verfügbare 3D-Flash-LIDAR-Systeme weisen eine Festkörper-3D-Star-Array-LIDAR-Kamera auf, die außer einem Lüfter keine beweglichen Teile aufweist (z. B. eine nicht scannende LIDAR-Einrichtung). Die Flash-LIDAR-Einrichtung kann einen fünf Nanosekunden langen Laserimpuls der Klasse I (augensicher) pro Bild verwenden und das reflektierte Laserlicht in Form von 3D-Entfernungspunktwolken und koregistrierten Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR und weil Flash-LIDAR eine Festkörpereinrichtung ohne bewegliche Teile ist, kann/können der/die LIDAR-Sensor(en) 464 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße sein.
Das Fahrzeug kann darüber hinaus IMU-Sensor(en) 466 aufweisen. Der/die IMU-Sensor(en) 466 kann/können bei einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 400 angeordnet sein. Der/die IMU-Sensor(en) 466 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 aufweisen. Bei einigen Beispielen, wie z. B. bei sechsachsigen Anwendungen, kann der/die IMU-Sensor(en) 466 Beschleunigungsmesser und Gyroskope aufweisen, während bei neunachsigen Anwendungen der/die IMU-Sensor(en) 466 Beschleunigungsmesser, Gyroskope und Magnetometer aufweisen können.
Bei einigen Ausführungsformen kann/können der/die IMU-Sensor(en) 466 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 Schätzungen von Position, Geschwindigkeit und Lage zu liefern. Bei einigen Beispielen können die IMU-Sensoren 466 das Fahrzeug 400 in die Lage versetzen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem die Geschwindigkeitsänderungen von GPS direkt beobachtet und mit den IMU-Sensoren 466 korreliert werden. Bei einigen Beispielen können der/die IMU-Sensor(en) 466 und der/die GNSS-Sensor(en) 458 in einer einzigen integrierten Einheit kombiniert sein. Das Fahrzeug kann ein oder mehrere Mikrofone 496 aufweisen, die im und/oder um das Fahrzeug 400 herum angeordnet sind. Das/die Mikrofon(e) 496 kann/können u. a. zur Erkennung und Identifizierung von Einsatzfahrzeugen verwendet werden.
Das Fahrzeug kann darüber hinaus eine beliebige Anzahl von Kameratypen aufweisen, einschließlich (einer) Stereokamera(s) 468, (einer) Weitwinkelkamera(s) 470, (einer) Infrarot-kamera(s) 472, (einer) Umgebungskamera(s) 474, (einer) Fern- und/oder Mittelbereichska-mera(s) 498 und/oder anderer Kameratypen. Die Kameras können verwendet werden, um Bilddaten rund um den gesamten Umfang des Fahrzeugs 400 zu erfassen. Die verwendeten Kameratypen hängen von den Ausführungsformen und Anforderungen an das Fahrzeug 400 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 400 herum zu gewährleisten. Darüber hinaus kann die Anzahl der Kameras je nach Ausführungsform unterschiedlich sein. Zum Beispiel kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras aufweisen. 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 4A und 4B ausführlicher beschrieben. Das Fahrzeug 400 kann darüber hinaus (einen) Vibrations-sensor(en) 442 aufweisen. Der/die Vibrationssensor(en) 442 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. Bei einem anderen Beispiel, wenn zwei oder mehr Vibrationssensoren 442 verwendet werden, können die Unterschiede zwischen den Vibrationen verwendet werden, um die Reibung oder den Schlupf der Straßenoberfläche zu bestimmen (z. B. wenn der Unterschied in der Vibration zwischen einer angetriebenen Achse und einer frei drehenden Achse besteht).
Das Fahrzeug 400 kann ein ADAS-System 438 aufweisen. Das ADAS-System 438 kann bei einigen Beispielen ein SoC aufweisen. Das ADAS-System 438 kann eine autonome/adaptive/automatische Geschwindigkeitsregelung (ACC), eine kooperative adaptive Geschwindigkeitsregelung (CACC), eine Vorwärts-Crash-Warnung (FCW), eine automatische Notbremsung (AEB), eine Spurverlassenwarnung (LDW), einen Spurhalteassistenten (LKA), einen Toter-Winkel-Warner (BSW), einen Querverkehrswarner (RCTW), ein Kollisionswarnsystem (CWS), eine Spurzentrierung (LC) und/oder andere Merkmale und Funktionen aufweisen.
Die ACC-Systeme können RADAR-Sensor(en) 460, LIDAR-Sensor(en) 464 und/oder eine Kamera(en) verwenden. Die ACC-Systeme können einen ACC in Längsrichtung und/oder einen ACC in Querrichtung aufweisen. Der ACC in Längsrichtung überwacht und regelt den Abstand zum unmittelbar vor dem Fahrzeug 400 befindlichen Fahrzeug und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Lateral ACC führt eine Abstandsregelung durch und rät dem Fahrzeug 400 bei Bedarf zum Spurwechsel. Lateral ACC ist mit anderen ADAS-Anwendungen wie LC und CWS verwandt.
CACC nutzt Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 424 und/oder die drahtlose(n) Antenne(n) 426 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-Kommunikationsverbindung (V2V) bereitgestellt werden, während indirekte Verbindungen Infrastruktur-zu-Fahrzeug-Kommunikationsverbindungen (12V) sein können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Informationen über die unmittelbar vorausfahrenden Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem Fahrzeug 400 und auf der gleichen Spur wie dieses befinden), während das I2V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr liefert. CACC-Systeme können entweder eine oder beide 12V- und V2V-Informationsquellen aufweisen. Angesichts der Informationen über die Fahrzeuge vor dem Fahrzeug 400 kann CACC zuverlässiger sein, und es hat das Potenzial, den reibungslosen Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
FCW-Systeme sind so konzipiert, dass sie den Fahrer vor einer Gefahr warnen, so dass er korrigierend eingreifen kann. FCW-Systeme verwenden eine nach vom gerichtete Kamera und/oder RADAR-Sensor(en) 460, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit der Rückmeldung an den Fahrer gekoppelt ist, wie z. B. ein Display, ein Lautsprecher und/oder eine vibrierende 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 erkennen 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 bestimmten Zeit- oder Abstandsparameters korrigierend eingreift. AEB-Systeme können nach vom gerichtete Kamera(s) und/oder RADAR-Sensor(en) 460 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr erkennt, 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, um die Auswirkungen der vorhergesagten Kollision zu verhindern oder zumindest abzuschwächen. AEB-Systeme können Techniken wie eine dynamische Bremsunterstützung und/oder ein Bremsen bei bevorstehendem Unfall (Crash-Imminent Braking) aufweisen.
LDW-Systeme bieten optische, akustische und/oder taktile Warnungen, wie z. B. Lenkrad- oder Sitzvibrationen, um den Fahrer zu warnen, wenn das Fahrzeug 400 die Fahrbahnmarkierungen überquert. Ein LDW-System wird nicht aktiviert, wenn der Fahrer ein absichtliches Verlassen der Fahrspur anzeigt, indem er einen Blinker betätigt. LDW-Systeme können nach vom gerichtete Kameras verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente.
LKA-Systeme sind eine Variante von LDW-Systemen. LKA-Systeme liefern Lenkeingaben oder Bremsen, um das Fahrzeug 400 zu korrigieren, wenn das Fahrzeug 400 beginnt, die Fahrspur zu verlassen. BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen im toten Winkel des Fahrzeugs. BSW-Systeme können eine optische, akustische und/oder taktile Warnung ausgeben, um darauf hinzuweisen, dass das Zusammenführen oder Wechseln der Fahrspur unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker betätigt. BSW-Systeme können nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 460 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, wie z. B. einem Display, Lautsprecher und/oder einer vibrierenden Komponente.
RCTW-Systeme können eine visuelle, akustische und/oder taktile Benachrichtigung liefern, wenn ein Objekt außerhalb des Bereichs der Rückfahrkamera erkannt wird, wenn das Fahrzeug 400 rückwärtsfahrt. Einige RCTW-Systeme weisen eine AEB auf, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. RCTW-Systeme können einen oder mehrere nach hinten gerichtete(n) RADAR-Sensor(en) 460 verwenden, der/die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt ist/sind, der/die elektrisch mit einer Fahrerrückmeldung gekoppelt ist/sind, wie z. B. ein Display, ein Lautsprecher und/oder eine vibrierende Komponente.
Herkömmliche ADAS-Systeme können anfällig für falsch-positive Ergebnisse sein, die für einen Fahrer ärgerlich und ablenkend sein können, aber typischerweise nicht katastrophal sind, weil die ADAS-Systeme den Fahrer warnen und es dem Fahrer ermöglichen, zu entscheiden, ob eine Sicherheitsbedingung wirklich existiert, und entsprechend zu handeln. In einem autonomen Fahrzeug 400 muss das Fahrzeug 400 jedoch im Falle widersprüchlicher Ergebnisse selbst entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. eines ersten Steuergeräts 436 oder eines zweiten Steuergeräts 436) beachtet. Bei einigen Ausführungsformen kann das ADAS-System 438 beispielsweise ein Backup- und/oder Sekundärcomputer sein, der Wahrnehmungsinformationen für ein Backup-Computer-Rationalitätsmodul bereitstellt. Der Backup-Computer-Rationalitätsmonitor kann eine redundante diverse Software auf Hardwarekomponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahraufgaben zu erkennen. Die Ausgaben des ADAS-Systems 438 können an eine übergeordnete MCU weitergeleitet werden. Wenn die Ausgaben des primären Computers und des sekundären Computers in Konflikt stehen, muss die übergeordnete MCU bestimmen, wie der Konflikt beigelegt werden kann, um einen sicheren Betrieb zu gewährleisten.
Bei einigen Beispielen kann der primäre Computer so ausgestaltet sein, dass er der übergeordneten MCU einen Konfidenzwert liefert, der das Vertrauen des primären Computers in das gewählte Ergebnis angibt. Wenn der Vertrauenswert einen Schwellenwert überschreitet, kann die übergeordnete MCU der Anweisung des primären Computers folgen, unabhängig davon, ob der sekundäre Computer ein dazu widersprüchliches oder inkonsistentes Ergebnis liefert. Wenn der Konfidenzwert den Schwellenwert nicht erreicht und der primäre und der sekundäre Computer unterschiedliche Ergebnisse (z. B. den Konflikt) anzeigen, kann die übergeordnete MCU zwischen den Computern vermitteln, um das geeignete Ergebnis zu bestimmen.
Die überwachende MCU kann so ausgestaltet sein, dass sie ein neuronales Netz bzw. neuronale Netze ausführt, das bzw. die so trainiert und ausgestaltet ist bzw. sind, dass es bzw. sie auf der Grundlage der Ausgaben des primären Computers und des sekundären Computers die Bedingungen bestimmt bzw. bestimmen, unter denen der sekundäre Computer Fehlalarme liefert. So kann/können das/die neuronale(n) Netz(e) in der Überwachungs-MCU lernen, wann der Ausgabe des sekundären Computers vertraut werden kann und wann nicht. Wenn es sich bei dem sekundären Computer beispielsweise um ein RADARbasiertes FCW-System handelt, kann/können (ein) neuronale(s) Netz (e) in der übergeordneten MCU lernen, wann das FCW-System metallische Objekte identifiziert, bei denen es sich in Wirklichkeit nicht um Gefahren handelt, wie z. B. ein Abflussgitter oder ein Schachtdeckel, der einen Alarm auslöst. Wenn der sekundäre Computer ein kamerabasiertes Spurhaltewarnsystem ist, kann ein neuronales Netz in der übergeordneten MCU lernen, das Spurhaltewarnsystem außer Kraft zu setzen, wenn Radfahrer oder Fußgänger vorhanden sind und ein Verlassen der Spur tatsächlich das sicherste Manöver ist. Bei Ausführungsformen, die (ein) neuronale(s) Netz(e) aufweisen, das/die auf der übergeordneten MCU läuft/laufen, kann die übergeordnete MCU mindestens einen DLA oder eine GPU aufweisen, der/die für den Betrieb des/der neuronalen Netzes/Netze mit zugehörigem Speicher geeignet ist. Bei bevorzugten Ausführungsformen kann die Überwachungs-MCU eine Komponente des/der SoC(s) 404 aufweisen und/oder als solche enthalten sein.
Bei anderen Beispielen kann das ADAS-System 438 einen sekundären Computer aufweisen, der die ADAS-Funktionalität unter Verwendung traditioneller Regeln der Computer-Vision bzw. des Computersehens ausführt. Als solches kann der sekundäre Computer klassische Computer-Vision-Regeln (wenn-dann) verwenden, und das Vorhandensein eines neuronalen Netzes (von neuronalen Netzen) in der übergeordneten MCU kann die Zuverlässigkeit, Sicherheit und Leistung verbessern. Zum Beispiel machen die vielfältige Implementierung und die absichtliche Nicht-Gleichheit das Gesamtsystem fehlertoleranter, insbesondere gegenüber Fehlern, die durch Software- (oder Software-Hardware-Schnittstellen-) Funktionalität verursacht werden. Wenn beispielsweise ein Software-Bug oder Fehler in der auf dem primären Computer laufenden Software auftritt und der nicht-identische Software-Code, der auf dem sekundären Computer läuft, das gleiche Gesamtergebnis liefert, kann die überwachende MCU ein größeres Vertrauen haben, dass das Gesamtergebnis korrekt ist und der Bug in der vom primären Computer verwendeten Software oder Hardware keinen wesentlichen Fehler verursacht.
Bei einigen Beispielen kann die Ausgabe des ADAS-Systems 438 in den Wahrnehmungsblock des primären Computers und/oder in den Block für dynamische Fahraufgaben des primären Computers eingespeist werden. Wenn das ADAS-System 438 z. B. eine Vorwärts-Crash-Warnung aufgrund eines unmittelbar vorausliegenden Objekts anzeigt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. Bei anderen Beispielen kann der sekundäre Computer über ein eigenes neuronales Netz verfügen, das trainiert ist und somit das Risiko von Fehlalarmen reduziert, wie es hier beschrieben ist.
Das Fahrzeug 400 kann darüber hinaus das Infotainment-SoC 430 aufweisen (z. B. ein fahrzeuginternes Infotainment-System (IVI)). Obwohl es als SoC dargestellt und beschrieben ist, ist das Infotainment-System möglicherweise kein SoC und kann zwei oder mehr diskrete Komponenten aufweisen. Das Infotainment-SoC 430 kann eine Kombination aus Hardware und Software aufweisen, die verwendet werden kann, um Audioinhalte (z. B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Videos (z. B. TV, Filme, Streaming usw.), Telefonate (z. B. Freisprechen), eine Netzwerkkonnektivität (z. B., LTE, Wi-Fi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Einparkhilfe hinten, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremskraftstoffstand, Ölstand, Tür öffnen/schließen, Luftfilterinformationen usw.) für das Fahrzeug 400 bereitzustellen. Das Infotainment-SoC 430 kann beispielsweise Radios, Plattenspieler, Navigationssysteme, Videoplayer, eine USB- und Bluetooth-Konnektivität, Carputer, ein In-Car-Entertainment, Wi-Fi, Audiobedienelemente am Lenkrad, eine Freisprecheinrichtung, ein Heads-up-Display (HUD), ein HMI-Display 434, eine Telematikeinrichtung, ein Bedienfeld (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten aufweisen. Das Infotainment-SoC 430 kann darüber hinaus verwendet werden, um einem oder mehreren Benutzern des Fahrzeugs Informationen (z. B. visuell und/oder akustisch) zur Verfügung zu stellen, wie z. B. Informationen von dem ADAS-System 438, Informationen zum autonomen Fahren, wie z. B. geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.), und/oder andere Informationen.
Das Infotainment-SoC 430 kann eine GPU-Funktionalität aufweisen. Das Infotainment-SoC 430 kann über den Bus 402 (z.B. CAN-Bus, Ethernet, etc.) mit anderen Einrichtungen, Systemen und/oder Komponenten des Fahrzeugs 400 kommunizieren. Bei einigen Beispielen kann das Infotainment-SoC 430 mit einer Überwachungs-MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, wenn die primäre(n) Steuerung(en) 436 (z. B. der primäre und/oder Backup-Computer des Fahrzeugs 400) ausfällt/ausfallen. In einem solchen Beispiel kann das Infotainment-SoC 430 das Fahrzeug 400 in einen Chauffeur-zu-Safe-Stop-Modus versetzen, wie es hierin beschrieben ist.
Das Fahrzeug 400 kann darüber hinaus ein Kombiinstrument 432 aufweisen (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.). Das Kombiinstrument 432 kann ein Steuergerät und/oder einen Supercomputer aufweisen (z. B. ein diskretes Steuergerät oder einen Supercomputer). Das Kombiinstrument 432 kann eine Reihe von Instrumenten aufweisen, wie z. B. ein Tachometer, eine Kraftstoffstandanzeige, eine Öldruckanzeige, einen Drehzahlmesser, einen Kilometerzähler, Blinker, eine Schaltstellungsanzeige, Sicherheitsgurt- Warnleuchte(n), Feststellbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Airbag (SRS)-Systeminformationen, Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen, usw. Bei einigen Beispielen können die Informationen von dem Infotainment-SoC 430 und dem Kombiinstrument 432 angezeigt und/oder gemeinsam genutzt werden. Mit anderen Worten, das Kombiinstrument 432 kann einen Teil des Infotainment-SoC 430 bilden, oder umgekehrt.
4D ist ein Systemdiagramm für die Kommunikation zwischen dem/den cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug 400 von 4A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System 476 kann den/die Server 478, das/die Netzwerk(e) 490 und die Fahrzeuge, einschließlich des Fahrzeugs 400, aufweisen. Der/die Server 478 kann/können eine Vielzahl von GPUs 484(A)-484(H) (hierin kollektiv als GPUs 484 bezeichnet), PCIe-Switches 482(A)-482(H) (hierin kollektiv als PCIe-Switches 482 bezeichnet), und/oder CPUs 480(A)-480(B) (hierin kollektiv als CPUs 480 bezeichnet) aufweisen. Die GPUs 484, die CPUs 480 und die PCIe-Switches können mit Hochgeschwindigkeits-Verbindungen verbunden sein, wie z. B. und ohne Einschränkung die von NVIDIA entwickelten NVLink-Schnittstellen 488 und/oder PCIe-Verbindungen 486. Bei einigen Beispielen sind die GPUs 484 über NVLink und/oder NVSwitch-SoC und die GPUs 484 und die PCIe-Switches 482 über PCIe-Verbindungen verbunden. Obwohl acht GPUs 484, zwei CPUs 480 und zwei PCIe-Switches dargestellt sind, ist dies nicht als Einschränkung zu verstehen. Je nach Ausführungsform kann jeder der Server 478 eine beliebige Anzahl von GPUs 484, CPUs 480 und/oder PCIe-Switches aufweisen. Beispielsweise kann der/die Server 478 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 484 aufweisen.
Der (die) Server 478 kann (können) über das (die) Netzwerk(e) 490 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenzustände zeigen, wie zum Beispiel kürzlich begonnene Straßenarbeiten. Der (die) Server 478 kann (können) über das (die) Netzwerk(e) 490 und an die Fahrzeuge neuronale Netze 492, aktualisierte neuronale Netze 492 und/oder Karteninformationen 494 übertragen, die Informationen über den Verkehr und die Straßenbedingungen aufweisen. Die Aktualisierungen der Karteninformationen 494 können Aktualisierungen für die HD-Karte 422 aufweisen, z. B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. Bei einigen Beispielen können die neuronalen Netze 492, die aktualisierten neuronalen Netze 492 und/oder die Karteninformationen 494 aus einem neuen Training und/oder Erfahrungen resultieren, die in Daten repräsentiert sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder auf der Grundlage von einem Training, das in einem Datenzentrum durchgeführt wurde (z. B. unter Verwendung des/der Server(s) 478 und/oder anderer Server).
Der/die Server 478 kann/können verwendet werden, um maschinelle Lernmodelle (z. B. neuronale Netze) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen erzeugt werden und/oder in einer Simulation (z. B. unter Verwendung einer Spiele-Maschine) erzeugt werden. Bei einigen Beispielen sind die Trainingsdaten markiert (z. B. wenn das neuronale Netz von überwachtem Lernen profitiert) und/oder werden einer anderen Vorverarbeitung unterzogen, während bei anderen Beispielen die Trainingsdaten nicht markiert und/oder vorverarbeitet sind (z. B. wenn das neuronale Netz kein überwachtes Lernen benötigt). Das Training kann gemäß einer oder mehrerer Klassen von maschinellen Lerntechniken ausgeführt werden, einschließlich, ohne Einschränkung, Klassen wie: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, Selbstlernen, Verstärkungslemen, föderiertes Lernen, Transferlernen, Merkmalslemen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraumlemen, vielfältiges Lernen, Repräsentationslernen (einschließlich Ersatzwörterbuchlernen), regelbasiertes maschinelles Lernen, Anomalieerkennung und jegliche Varianten oder Kombinationen davon. Sobald die maschinellen Lernmodelle trainiert sind, können die maschinellen Lernmodelle von den Fahrzeugen verwendet werden (z. B. über das/die Netzwerk(e) 490 an die Fahrzeuge übertragen werden, und/oder die maschinellen Lernmodelle können von dem/den Server(n) 478 verwendet werden, um die Fahrzeuge aus der Ferne bzw. abgesetzt zu überwachen.
Bei einigen Beispielen kann/können der/die Server 478 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Netze in Echtzeit für intelligentes Inferencing in Echtzeit anwenden. Der/die Server 478 kann/können Deep-Learning-Supercomputer und/oder dedizierte Kl-Computer aufweisen, die von GPU(s) 484 versorgt werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. Bei einigen Beispielen kann/können der/die Server 478 jedoch eine Deep-Learning-Infrastruktur aufweisen, die nur CPU-betriebene Rechenzentren verwendet.
Die Deep-Learning-Infrastruktur des/der Server(s) 478 kann in der Lage sein, schnelles Inferencing in Echtzeit durchzuführen, und kann diese Fähigkeit nutzen, um den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware im Fahrzeug 400 zu bewerten und zu überprüfen. Zum Beispiel kann die Deep-Learning-Infrastruktur periodische Updates von dem Fahrzeug 400 erhalten, wie z. B. eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 400 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 Netz ausführen, um die Objekte zu identifizieren und sie mit den von dem Fahrzeug 400 identifizierten Objekten zu vergleichen, und wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 400 eine Fehlfunktion aufweist, kann der/die Server 478 ein Signal an das Fahrzeug 400 senden, das einen ausfallsicheren Computer des Fahrzeugs 400 anweist, die Kontrolle zu übernehmen, die Insassen zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
Für das Inferencing kann/können der/die Server 478 die GPU(s) 484 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT von NVIDIA) aufweisen. Die Kombination von GPU-gesteuerten Servern und Inferenzbeschleunigung kann eine Echtzeit-Reaktionsfähigkeit ermöglichen. Bei anderen Beispielen, z. B. wenn die Ausführung weniger kritisch ist, können Server, die von CPUs, FPGAs und anderen Prozessoren angetrieben werden, für das Inferencing verwendet werden.
5 ist ein Blockdiagramm (einer) beispielhaften/r Recheneinrichtung(en) 500, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist/sind. Die Recheneinrichtung 500 kann ein Verbindungssystem 502 aufweisen, das direkt oder indirekt die folgenden Einrichtungen koppelt: einen Speicher 504, eine oder mehrere Zentraleinheiten (CPUs) 506, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 508, eine Kommunikationsschnittstelle 510, E/A-Ports 512, Eingangs-/Ausgangskomponenten 514, eine Stromversorgung 516, eine oder mehrere Präsentationskomponenten 518 (z. B. Display(s)) und eine oder mehrere Logikeinheiten 520.
Obwohl die verschiedenen Blöcke in 5 als über das Verbindungssystem 502 mit Leitungen verbunden dargestellt sind, ist dies nicht als einschränkend zu verstehen und dient nur der Übersichtlichkeit. Bei solchen Ausführungsformen kann z. B. eine Präsentationskomponente 518, wie z. B. eine Anzeigeeinrichtung, als E/A-Komponente 514 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 506 und/oder GPUs 508 Speicher aufweisen (z. B. kann der Speicher 504 zusätzlich zum Speicher der GPUs 508, der CPUs 506 und/oder anderer Komponenten eine Speichereinrichtung darstellen). Mit anderen Worten, die Recheneinrichtung von 5 ist lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „Mobilgerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“, „Augmented-Reality-System“ und/oder anderen Einrichtungs- oder Systemtypen unterschieden, da alle im Rahmen der Recheneinrichtung von 5 in Betracht gezogen werden.
Das Verbindungssystem 502 kann eine oder mehrere Verbindungen oder Busse darstellen, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 502 kann einen oder mehrere Bus- oder Verbindungstypen aufweisen, wie 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 eine andere Art von Bus oder Verbindung. Bei einigen Ausführungsformen gibt es direkte Verbindungen zwischen den Komponenten. Zum Beispiel kann die CPU 506 direkt mit dem Speicher 504 verbunden sein. Darüber hinaus kann die CPU 506 direkt mit der GPU 508 verbunden sein. Bei direkten oder Punkt-zu-Punkt-Verbindungen zwischen Komponenten kann das Verbindungssystem 502 eine PCIe-Verbindung aufweisen, um die Verbindung herzustellen. Bei diesen Beispielen muss ein PCI-Bus nicht in der Recheneinrichtung 500 vorhanden sein.
Der Speicher 504 kann eine beliebige Auswahl an computerlesbaren Medien aufweisen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die die Recheneinrichtung 500 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie entfernbare und nicht-entfernbare Medien aufweisen. Als Beispiel und nicht als Einschränkung können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
Die Computer-Speichermedien können sowohl flüchtige als auch nicht flüchtige Medien und/oder entfernbare und nicht entfernbare Medien aufweisen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen, wie z. B. computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder andere Datentypen, implementiert sind. Beispielsweise kann der Speicher 504 computerlesbare Anweisungen speichern (z. B. welche 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 andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium aufweisen, das zum Speichern der gewünschten Informationen verwendet werden kann und auf das die Recheneinrichtung 500 zugreifen kann, ohne darauf beschränkt zu sein. Wie es hier verwendet ist, umfasst das Computer-Speichermedium nicht per se Signale.
Die Computerspeichermedien können computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal wie einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und weisen beliebige Informationsübertragungsmedien auf. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert sind, dass Informationen in dem Signal kodiert sind. Beispielhaft und ohne Einschränkung können die Computerspeichermedien verdrahtete Medien, wie z. B. ein verdrahtetes Netzwerk oder eine direkt verdrahtete Verbindung, und drahtlose Medien, wie z. B. akustische, HF-, Infrarot- und andere drahtlose Medien, aufweisen. Kombinationen der oben genannten Medien sollten ebenfalls im Umfang der computerlesbaren Medien liegen.
Die CPU(s) 506 kann/können so ausgestaltet sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten der Recheneinrichtung 500 zu steuern, um eine oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 506 kann/können jeweils einen oder mehrere Kerne aufweisen (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.), die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 506 kann/können jeden Prozessortyp aufweisen und je nach Art der implementierten Recheneinrichtung 500 verschiedene Typen von Prozessoren aufweisen (z. B. Prozessoren mit weniger Kernen für mobile Einrichtungen und Prozessoren mit mehr Kernen für Server). Je nach Art der Recheneinrichtung 500 kann der Prozessor z. B. ein Advanced RISC Machines (ARM)-Prozessor sein, der mit Reduced Instruction Set Computing (RISC) implementiert ist, oder ein x86-Prozessor, der mit Complex Instruction Set Computing (CISC) implementiert ist. Die Recheneinrichtung 500 kann eine oder mehrere CPUs 506 aufweisen, zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Co-Prozessoren, wie z. B. Mathematik-Coprozessoren.
Zusätzlich zu oder alternativ zu der/den CPU(s) 506 kann/können die GPU(s) 508 so ausgestaltet sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten der Recheneinrichtung 500 zu steuern, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 508 können eine integrierte GPU sein (z. B. mit einer oder mehreren der CPU(s) 506), und/oder eine oder mehrere der GPU(s) 508 können eine diskrete GPU sein. Bei Ausführungsformen kann eine oder mehrere der GPU(s) 508 ein Coprozessor einer oder mehrerer der CPU(s) 506 sein. Die GPU(s) 508 kann/können von der Recheneinrichtung 500 zum Rendern von Grafiken (z. B. 3D-Grafiken) oder zur Durchführung von Allzweckberechnungen verwendet werden. Die GPU(s) 508 kann/können z. B. für General-Purpose-Computing auf GPUs (GPGPU) verwendet werden. Die GPU(s) 508 können Hunderte oder Tausende von Kernen aufweisen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 508 kann/können als Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von der/den CPU(s) 506, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 508 kann einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, wie z. B. GPGPU-Daten, aufweisen. Der Anzeigespeicher kann als Teil des Speichers 504 vorhanden sein. Die GPU(s) 508 . kann/können zwei oder mehr GPUs aufweisen, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt verbinden (z. B. mit NVLINK) oder die GPUs über einen Switch verbinden (z. B. mit NVSwitch). Wenn sie miteinander kombiniert sind, kann jede GPU 508 Pixeldaten oder GPGPU-Daten für verschiedene Abschnitte 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 aufweisen oder sich den Speicher mit anderen GPUs teilen. Zusätzlich zu oder alternativ zu der (den) CPU(s) 506 und/oder der (den) GPU(s) 508 kann (können) die Logikeinheit(en) 520 so ausgestaltet sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt (ausführen), um eine oder mehrere Komponenten der Recheneinrichtung 500 zu steuern, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Bei Ausführungsformen können die CPU(s) 506, die GPU(s) 508 und/oder die Logikeinheit(en) 520 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Abschnitte davon ausführen. Eine oder mehrere der Logikeinheiten 520 können Teil einer oder mehrerer der CPU(s) 506 und/oder der GPU(s) 508 sein und/oder eine oder mehrere der Logikeinheiten 520 können diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 506 und/oder der GPU(s) 508 liegen. Bei Ausführungsformen kann eine oder mehrere der Logikeinheiten 520 ein Koprozessor einer oder mehrerer der CPU(s) 506 und/oder einer oder mehrerer der GPU(s) 508 sein.
Beispiele für die Logikeinheit(en) 520 weisen einen oder mehrere Verarbeitungskerne und/oder Komponenten davon auf, wie z. B. Tensor Cores (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Tree Traversal Units (TTUs), Artificial Intelligence Accelerators (AlAs), Deep Learning Accelerators (DLAs), Arithmetik-Logik-Einheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkommaeinheiten (FPUs), E/A-Elemente, Peripheral Component Interconnect (PCI)- oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
Die Kommunikationsschnittstelle 510 kann einen oder mehrere Empfänger, Sender und/oder Transceiver aufweisen, die es der Recheneinrichtung 500 ermöglichen, mit anderen Recheneinrichtungen über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 510 kann Komponenten und Funktionen aufweisen, um die Kommunikation über eine beliebige Anzahl verschiedener Netzwerke zu 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-Ports 512 können es der Recheneinrichtung 500 ermöglichen, logisch mit anderen Einrichtungen gekoppelt zu sein, einschließlich der E/A-Komponenten 514, der Präsentati-onskomponente(n) 518 und/oder anderer Komponenten, von denen einige in die Recheneinrichtung 500 eingebaut (z. B. integriert) sein können. Beispielhafte E/A-Komponenten 514 weisen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, eine drahtlose Einrichtung usw. auf. Die E/A-Komponenten 514 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 die 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 ausführlicher beschrieben) in Verbindung mit einer Anzeige der Recheneinrichtung 500 implementieren. Die Recheneinrichtung 500 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung aufweisen. Zusätzlich kann die Recheneinrichtung 500 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) aufweisen, die eine Bewegungserkennung ermöglichen. Bei einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Recheneinrichtung 500 verwendet werden, um immersive Augmented Reality oder Virtual Reality darzustellen.
Die Stromversorgung 516 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon aufweisen. Die Stromversorgung 516 kann die Recheneinrichtung 500 mit Strom versorgen, um den Betrieb der Komponenten der Recheneinrichtung 500 zu ermöglichen. Die Präsentationskomponente(n) 518 kann/können ein Display (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Displaytypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten aufweisen. Die Präsentationskomponente(n) 518 kann/können Daten von anderen Komponenten (z. B. der/den GPU(s) 508, der/den CPU(s) 506 usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
6 ist ein Flussdiagramm, das die Verfahrensschritte zur Bestimmung der Blickrichtung gemäß den Ausführungsformen der Offenbarung darstellt. Das Verfahren von 6 kann beginnen, wenn die Recheneinrichtung 300 ein Bild eines Objekts empfängt, das von der Kamera 300 aufgenommen wurde (Schritt 600). Die Recheneinrichtung 300 identifiziert dann das Gesicht und die Augen des Objekts in dem empfangenen Bild (Schritt 610). Gesichter von Objekten können in einem Bild unter Verwendung beliebiger Verfahren oder Prozesse lokalisiert werden, einschließlich bekannter Computer-Vision-basierter Gesichtserkennungsverfahren, die Gesichter ohne Verwendung neuronaler Netze erkennen, wie z. B. Kantenerkennungsverfahren, Verfahren zur Merkmalssuche, probabilistische Gesichtsmodelle, Graph-Matching, Histogramme orientierter Gradienten (HOGs), die in Klassifikatoren wie Support-Vektor-Maschinen, HaarCascade-Klassifikatoren und dergleichen eingespeist werden. Die Lokalisierung von Gesichtern kann auch unter Verwendung von auf neuronalen Netzen basierenden Gesichtserkennungsverfahren durchgeführt werden, wie z. B. solche, die Gesichtserkennungsschemata mit einem tiefen neuronalen Netz (DNN) verwenden, sowie alle anderen. Ausführungsformen der Offenbarung umfassen auch die Lokalisierung der Augen des Objekts aus demselben Bild. Die Lokalisierung der Augen kann auf jede beliebige Art und Weise erfolgen, z. B. durch bekannte Computer-Vision-basierte Augenerkennungsverfahren, die eines der oben genannten, nicht auf neuronalen Netzen basierenden Verfahren aufweisen, sowie durch auf einem neuronalen Netz basierende Augenerkennungsverfahren und dergleichen.
Sobald das Gesicht und die Augen des Objekts in dem empfangenen Bild lokalisiert sind, bestimmt die Recheneinrichtung 300 Landmarken des lokalisierten Gesichts (Schritt 620).
Gesichtslandmarken bzw. Gesichtsorientierungspunkte können beliebige Punkte oder Stellen sein, die charakteristischen Elementen oder repräsentativen Abschnitten eines Gesichts entsprechen, und können mit einem beliebigen Verfahren oder Prozess identifiziert werden. Gesichtslandmarken können in einem Bild mit Hilfe von bekannten Computer-Visionbasierten Landmarken-Erkennungsverfahren lokalisiert werden, die Landmarken ohne Verwendung von neuronalen Netzen identifizieren, wie z. B. Kantenerkennungsverfahren, Merkmalssuchverfahren, probabilistische Gesichtsmodelle, Graph-Matching, Histogramme orientierter Gradienten (HOGs), die in Klassifikatoren wie Support-Vektor-Maschinen, HaarCascade-Klassifikatoren und dergleichen eingespeist werden. Die Erkennung von Landmarken kann auch mit auf neuronalen Netzen basierenden Gesichtserkennungsverfahren durchgeführt werden, wie z. B. solchen, die DNN-basierte Gesichtserkennungsschemata verwenden, sowie mit allen anderen.
Anschließend werden die Augenausschnitte ausgewählt (Schritt 630), z. B. durch Zeichnen eines Begrenzungsrahmens (Bounding Box) um jedes in Schritt 610 identifizierte Auge in bekannter Weise und entsprechendes Zuschneiden des Bildes. Die Augenausschnitte von Schritt 630 und die Gesichtslandmarken von Schritt 620 werden dann in die Modelle zum maschinellen Lernen (z. B. Merkmalsextraktionsschichten 215, 220 und 225, Kanalaufmerksamkeitsnetze 240 und 245 und vollständig verbundene Schichten 255) der Ausführungsformen der Offenbarung eingegeben, um eine Blickschätzung 230, einen Kontextvektor 235 und die von den Merkmalsextraktionsschichten 215 und 225 ausgegebenen Augenrichtungsmerkmale zu berechnen, wie es vorab beschrieben ist (Schritt 640). Der Kontextvektor 235 und die Ausgangsmerkmale von den Merkmalsextraktionsschichten 215 und 225 werden dann in die Kanalaufmerksamkeitsnetze 240 und 245 eingegeben, um gewichtete Augenmerkmale zu berechnen (Schritt 650), die mit der Blickschätzung 230 verknüpft sind und in die vollständig verbundenen Schichten 255 eingegeben werden, um die Blickrichtung zu berechnen (Schritt 660), wie es vorab beschrieben ist. Diese Blickrichtung wird dann an das blickunterstützte System 320 ausgegeben (Schritt 660), das eine oder mehrere Aktionen basierend auf der empfangenen Blickrichtung durchführen kann (Schritt 670).
Das Training der vollständig verbundenen Schichten und der Merkmalsextraktionsschichten der Ausführungsformen der Offenbarung kann auf jede geeignete Weise durchgeführt werden. Bei bestimmten Ausführungsformen können die vollständig verbundenen Schichten und Merkmalsextraktionsschichten von Ausführungsformen der Offenbarung auf überwachte Weise trainiert werden, indem bezeichnete Eingabebilder von Objekten verwendet werden, deren Blickrichtungen bekannt sind. Bei einigen Ausführungsformen können die Modellarchitekturen von Ausführungsformen der Offenbarung von Ende zu Ende trainiert werden.
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 ausgeführt werden, wie z. B. einem persönlichen Datenassistenten oder einer anderen tragbaren Einrichtung. Im Allgemeinen beziehen sich Programmmodule, die Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw. aufweisen, auf Codes, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen ausgeübt werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, Allzweckcomputern, spezielleren Recheneinrichtungen usw. Die Offenbarung kann auch in verteilten Rechenumgebungen ausgeführt werden, in denen Aufgaben von entfernt arbeitenden Einrichtungen ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind.
Wie es hierin verwendet wird, sollte eine Erwähnung von „und/oder“ in Bezug auf zwei oder mehr Elemente so interpretiert werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. Zum Beispiel 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 aufweisen. 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 bedeuten.
Der Gegenstand der vorliegenden Offenbarung wird hier mit Spezifität beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung selbst ist jedoch nicht dazu gedacht, den Umfang der vorliegenden Offenbarung zu begrenzen. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch in anderen Ausführungsformen ausgestaltet sein kann, die andere Schritte oder Kombinationen von Schritten aufweisen, die den in diesem Dokument beschriebenen ähnlich sind, und zwar in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien. Darüber hinaus sollten die Begriffe „Schritt“ und/oder „Block“, obwohl sie hier verwendet werden, um verschiedene Elemente der angewandten Methoden zu bezeichnen, nicht so interpretiert werden, dass sie eine bestimmte Reihenfolge unter oder zwischen verschiedenen hier offengelegten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.
In der vorangegangenen Beschreibung wurde zu Erklärungszwecken eine spezifische Nomenklatur verwendet, um ein umfassendes Verständnis der Offenbarung zu ermöglichen. Es ist jedoch dem Fachmann klar, dass die spezifischen Details nicht erforderlich sind, um die Verfahren und Systeme der Offenbarung auszuführen. Daher dienen die vorstehenden Beschreibungen bestimmter Ausführungsformen der vorliegenden Erfindung der Veranschaulichung und Beschreibung. Sie erheben keinen Anspruch auf Vollständigkeit und beschränken die Erfindung nicht auf die genauen Ausführungsformen, die offenbart sind. Viele Modifikationen und Variationen sind im Hinblick auf die obigen Lehren möglich. Beispielsweise können beliebige Gesichtsorientierungsinformationen zur Bestimmung von Kontextvektoren und Blickabschätzungen verwendet werden, und die Ausführungsformen der Offenbarung sind nicht auf die Verwendung von Gesichtslandmarken beschränkt. Die Ausführungsformen wurden ausgewählt und beschrieben, um die Prinzipien der Erfindung und ihre praktischen Anwendungen bestmöglich zu erläutern und dadurch andere Fachleute in die Lage zu versetzen, die Verfahren und Systeme der Offenbarung und die verschiedenen Ausführungsformen mit verschiedenen Modifikationen, die für die jeweilige Anwendung geeignet sind, bestmöglich zu nutzen. Darüber hinaus können verschiedene Merkmale der verschiedenen Ausführungsformen, ob offenbart oder nicht, gemischt und angepasst oder anderweitig kombiniert werden, um darüber hinaus weitere Ausführungsformen zu schaffen, die in der Offenbarung vorgesehen sind.
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

US 16101232 [0070]

Zitierte Nicht-Patentliteratur

Normen ISO 26262 [0069]

Claims

Verfahren zum Bestimmen einer Blickrichtung eines Objekts in einem Bild, wobei das Verfahren umfasst: Bestimmen, unter Verwendung einer Parallelverarbeitungsschaltung, von Merkmalen, welche der Blickrichtung entsprechen, wobei die Merkmale gemäß einer Ausgabe von einem oder mehreren ersten Modellen zum maschinellen Lernen bestimmt werden, welche als Eingabe einen oder mehrere Abschnitte des Bildes aufweisen, die mindestens einem Auge des Objekts entsprechen; Ändern der Merkmale gemäß einer Ausgabe von einem oder mehreren zweiten Modellen zum maschinellen Lernen, welche als Eingaben eine Gesichtsposeninformation des Objekts aufweisen; Bestimmen der Blickrichtung von den geänderten Merkmalen; und Einleiten eines Vorgangs abhängig von der bestimmten Blickrichtung.
Verfahren nach Anspruch 1, wobei: die Ausgabe des einen oder der mehreren zweiten Modelle zum maschinellen Lernen darüber hinaus eine Schätzung der Blickrichtung umfasst; und das Bestimmen der Blickrichtung darüber hinaus ein Bestimmen der Blickrichtung von den geänderten Merkmalen und von der Schätzung der Blickrichtung umfasst.
Verfahren nach Anspruch 1 oder 2, wobei das Einleiten darüber hinaus ein Einleiten eines Vorgangs eines Fahrzeugs abhängig von der bestimmten Blickrichtung umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Gesichtsposeninformation von dem Bild ermittelte Gesichtslandmarken umfasst.
Verfahren nach einem der vorangehenden Ansprüche, wobei die Ausgabe des einen oder der mehreren zweiten Modelle zum maschinellen Lernen Merkmale umfasst, welche einer Position und eine Orientierung eines Gesichts des Objekts entsprechen.
Verfahren nach Anspruch 5, wobei das Ändern darüber hinaus ein Bestimmen von Gewichtungswerten von der Ausgabe des einen oder der mehreren zweiten Modelle zum maschinellen Lernen und ein Multiplizieren der Merkmale mit den Gewichtungswerten umfasst, um die geänderten Merkmale zu bilden.
Verfahren nach einem der vorhergehenden Ansprüche, welches darüber hinaus ein Empfangen von Bilddaten umfasst, welche dem Bild entsprechen.
Verfahren zum Bestimmen einer Blickrichtung eines Objekts in einem Bild, wobei das Verfahren umfasst: unter Verwendung einer Parallelverarbeitungsschaltung, Bestimmen von Augenrichtungsmerkmalen gemäß einer Ausgabe eines oder mehrerer Modelle zum maschinellen Lernen, welche als Eingabe mindestens einen Abschnitt des Bildes des Objekts aufweisen; Verwenden einer Parallelverarbeitungsschaltung, um eine Gesichtsorientierungsinformation zu verwenden, um die Augenrichtungsmerkmale zu ändern; Bestimmen der Blickrichtung des Objekts von den modifizierten Augenrichtungsmerkmalen; und Einleiten eines Vorgangs abhängig von der bestimmten Blickrichtung.
Verfahren nach Anspruch 8, wobei das Bestimmen darüber hinaus ein Bestimmen einer Blickschätzung von der Gesichtsorientierungsinformation und ein Bestimmen der Blickrichtung des Objekts von den geänderten Augenrichtungsmerkmalen und von der Blickschätzung umfasst.
Verfahren nach Anspruch 8 oder 9, wobei das Einleiten darüber hinaus ein Einleiten eines Vorgangs eines Fahrzeugs abhängig von der bestimmten Blickrichtung umfasst.
Verfahren nach einem der Ansprüche 8 bis 10, wobei die Gesichtsorientierungsinformation von dem Bild bestimmte Gesichtslandmarken umfasst.
Verfahren nach einem der Ansprüche 8 bis 11, wobei ein Verwenden der Gesichtsorientierungsinformation zum Ändern der Augenrichtungsmerkmale darüber hinaus ein Bestimmen von Merkmalen umfasst, welche einer Position und einer Orientierung eines Gesichts des Objekts entsprechen, gemäß einer Ausgabe von einem oder mehreren Modellen zum maschinellen Lernen, die als eine Eingabe die Gesichtsorientierungsinformation aufweisen.
Verfahren nach Anspruch 12, wobei ein Verwenden der Gesichtsorientierungsinformation zum Ändern der Augenrichtungsmerkmale darüber hinaus umfasst ein Bestimmen von Merkmalen, welche einer Position und einer Orientierung eines Gesichts des Objekts entsprechen, und ein Multiplizieren der Augenrichtungsmerkmale mit den Gewichtungswerten, um die geänderten Merkmale zu bilden.
Verfahren nach einem der Ansprüche 8 bis 13, welches darüber hinaus ein Empfangen von Bilddaten umfasst, welche dem Bild entsprechen.
Verfahren zum Bestimmen einer Blickrichtung bei Vorhandensein einer Blendung, wobei das Verfahren umfasst: Bestimmen einer Blickrichtung eines Objekts in einem Bild unter Verwendung einer Parallelverarbeitungsschaltung, wobei die Blickrichtung zumindest teilweise von einer Ausgabe eines oder mehrerer Modelle zum maschinellen Lernen bestimmt wird, welche als Eingaben Gesichtsorientierungsmerkmale, die einer Orientierung eines Gesichts des Objekts entsprechen, eine Schätzung der Blickrichtung und einen Abschnitt des Bildes, welcher mindestens einem Auge des Objekts entspricht, aufweisen; und Einleiten eines Vorgangs abhängig von der bestimmten Blickrichtung.
Verfahren nach Anspruch 15, wobei das Bestimmen darüber hinaus umfasst: Bestimmen von Augenrichtungsmerkmalen von einer Ausgabe eines ersten Satzes der Modelle zum maschinellen Lernen, welche als Eingabe den Abschnitt des Bildes aufweisen, welcher mindestens einem Auge des Objekts entspricht; Verwenden der Gesichtsorientierungsmerkmale, um die Augenrichtungsmerkmale zu ändern; und Bestimmen der Blickrichtung zumindest teilweise von den geänderten Augenrichtungsmerkmalen.
Verfahren nach Anspruch 16, wobei das Bestimmen der Blickrichtung darüber hinaus ein Bestimmen der Blickrichtung von den geänderten Augenrichtungsmerkmalen und der Schätzung der Blickrichtung umfasst.
Verfahren nach Anspruch 16 oder 17, wobei das Verwenden darüber hinaus ein Bestimmen von Gewichtungswerten von den Gesichtsorientierungsmerkmalen und ein Erzeugen der geänderten Augenrichtungsmerkmale durch ein Multiplizieren der Augenrichtungsmerkmale mit den Gewichtungswerten umfasst.
Verfahren nach einem der Ansprüche 15 bis 18, wobei das Bestimmen der Blickrichtung darüber hinaus ein Bestimmen der Gesichtsorientierungsmerkmale von Gesichtslandmarken des Objekts in dem Bild umfasst.
Verfahren nach einem der Ansprüche 15 bis 19, wobei das Einleiten darüber hinaus ein Einleiten eines Vorgangs eines Fahrzeugs abhängig von der bestimmten Blickrichtung umfasst.
Verfahren nach einem der Ansprüche 15 bis 20, welches darüber hinaus ein Empfangen von Bilddaten, welche dem Bild entsprechen, von einer Kamera umfasst.