DE102021206235A1

DE102021206235A1 - Maschinenlern-basierte sicherheitsgurt-detektion und benutzungserkennung unter verwenden von messmarkierung

Info

Publication number: DE102021206235A1
Application number: DE102021206235.0A
Authority: DE
Inventors: Feng Hu; Niranjan Avadhanam
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2020-06-18
Filing date: 2021-06-17
Publication date: 2021-12-23
Also published as: JP2022002947A; US20210394710A1; CN113815561A

Abstract

Systeme und Verfahren zur maschinenlern-basierter Sicherheitsgurt-Positionsdetektion und Klassifikation. Eine Anzahl von Messmarkierungen sind auf einen Fahrzeug-Sicherheitsgurt platziert. Eine Kamera oder ein anderer Sensor ist im Fahrzeug platziert, um Bilder oder andere Daten, die sich auf Positionen der Messmarkierungen beziehen, wenn der Sicherheitsgurt in Benutzung ist, aufzunehmen. Eine oder mehrere Modelle wie beispielsweise Maschinenlern-Modelle können dann die räumlichen Positionen der Messmarkierungen aus den aufgenommenen Bildinformationen bestimmen, und den Benutzungszustand des Sicherheitsgurtes bestimmen. Insbesondere kann das System bestimmen, ob der Sicherheitsgurt in einem oder mehreren inkorrekten Zuständen getragen wird, wie zum Beispiel nicht getragen oder in einer unsicheren oder gefährlichen Weise getragen, und wenn dies so ist, kann das System das Fahrzeug alarmieren, um eine korrigierende Aktion vorzunehmen. Auf diese Weise stellt das System konstantes und Realzeit-Monitoring von Sicherheitsgurten bereit, um die Sicherheitsgurtbenutzung und Sicherheit zu verbessern.

Description

HINTERGRUND DER ERFINDUNG
Ausführungsbeispiele der Offenbarung beziehen sich im Allgemeinen auf Maschinenlern-Systeme. Spezifischer beziehen sich Ausführungsbeispiele der Offenbarung auf maschinenlern-basierter Sicherheitsgurt-Positionsdetektion.
ZUSAMMENFASSUNG
Sicherheitsgurte spielen eine wichtige Rolle in der Verkehrssicherheit. Einige schätzen, dass die Verwendung von Sicherheitsgurten die Anzahl von mit Fahrzeugunfall verbundenen schweren Verletzungen und Todesfälle um näherungsweise die Hälfte reduziert, so dass mehr als zehntausend Leben alleine in den USA gerettet werden. Ungeachtet der Sicherheitsvorteile und davon, dass sie durch das Gesetz vorgeschrieben sind, ist die Verwendung nicht universell. Viele Fahrer und Passagiere versäumen es, Sicherheitsgurte anzulegen, ob unbeabsichtigt oder beabsichtigt. In anderen Fällen können die Fahrer und die Passagiere die Sicherheitsgurte anlegen, aber machen dies unsachgemäß. Unsachgemäße Verwendung eines Sicherheitsgurtes reduziert nicht nur den Sicherheitsvorteil des Sicherheitsgurtes, sondern kann sogar darin münden, dass der Träger durch den Sicherheitsgurt verletzt wird.
Demgemäß werden hierin Systeme und Verfahren für ein maschinenlern-basiertes System beschrieben, das die Position des Sicherheitsgurtes an dem Träger detektiert und bestimmt, ob der Sicherheitsgurt korrekt getragen wird. Spezifischer kann das System einen von vielen spezifischen Zuständen des Sicherheitsgurtes detektieren, einschließlich beispielsweise, ob der Sicherheitsgurt angelegt ist und korrekt getragen, inkorrekt unter der Schulter des Trägers getragen, nicht getragen oder unsauber hinter dem Körper des Trägers getragen wird. Diese und viele anderen Zustände können detektiert werden.
In einigen Ausführungsbeispielen der Offenbarung benutzt das System einen Sicherheitsgurt mit einer Anzahl von Messmarkierungen, die darauf angeordnet sind und auch einen Sensor, wie beispielweise eine Kamera, die positioniert ist, Bilder oder andere Messmarkierungs-Position- und Orientierungsinformationen aufzunehmen. Das System kann, wenn gewünscht, auch eine Beleuchtungsquelle umfassen, um die Sichtbarkeit der Messmarkierungen zu erhöhen. Dazu können die Sensoren von jedem Typ von Sensoren sein, die geeignet sind, um Messmarkierungs-Position- und/oder Orientierungsinformationen zu bestimmen, wie zum Beispiel ein Sensor oder eine Kamera für sichtbares Licht, ein oder mehrere Infrarot- oder Nahinfrarot-Sensoren oder ähnliches. Die Beleuchtungsquelle, wenn anwesend, kann somit eine Beleuchtungsquelle mit Wellenlänge sichtbaren Licht, eine Infrarot- oder Nahinfrarot-Lichtquelle oder ähnliches sein.
Um den Sicherheitsgurt-Tragezustand zu bestimmen, kann die Kamera oder der andere Sensor positioniert sein, um den Sicherheitsgurt des interessierenden Passagiers zu sehen, wie beispielweise hinter dem Fahrersitz oder auf dem Armaturenbrett und auf den Fahrer ausgerichtet. Der Sensor kann dann ein Bild der Messmarkierungen aufnehmen. Ein oder mehrere Modelle, wie zum Beispiel Maschinenlern-Modelle, können dann die Positionen der Messmarkierungen aus den aufgenommenen Bildinformationen bestimmen und den Tragezustand des Sicherheitsgurtes bestimmen. Wie oben können einige unterschiedliche Tragezustände bestimmt werden. Wenn der Sicherheitsgurt in einem inkorrekten Zustand ist, wie zum Beispiel nicht getragen oder in einer unsicheren oder gefährlichen Art getragen, kann das System das Fahrzeug alarmieren, eine korrigierende Aktion durchzuführen, wie beispielweise Alarmieren des Fahrers oder anderer Passagiere über eine hörbare oder sichtbare Warnung, Bremsen des Fahrzeugs, Ausstellen der Zündung oder auf andere Art Ausstellens eines oder mehrerer Fahrzeugsysteme, Einschalten eines Autopilotensystems oder ähnliches. Alle solche Fahrzeugaktionen werden in Erwägung gezogen.
Zusätzlich werden verschiedene Maschinenlern-Modelle in Erwägung gezogen. Zum Beispiel können ein oder mehrere Maschinenlern-Modelle die Sensordaten (z.B. Bilddaten) als Eingabe nehmen und die Positionen der Messmarkierungen als Ausgabe erzeugen, während andere Maschinenlern-Modelle diese Positionsinformationen als Eingabe nehmen und Klassifikationen der Messmarkierungs-Positionen als Ausgabe erzeugen. Diese Klassifikationen können zu den oben beschriebenen Sicherheitsgurt-Zuständen korrespondieren. Auf diese Weise können Systeme von Ausführungsbeispielen der Offenbarung automatisch den Zustand eines Sicherheitsgurtes eines Passagiers bestimmen von Bildern des Passagiers und seines oder ihres Sicherheitsgurtes und einen Alarm bezüglich einer inkorrekten Verwendung des Sicherheitsgurtes bereitstellen. Der Alarm kann für verschiedene Zielgruppen, einschließlich der Passagiere, des Fahrzeugs oder eines Remote-Servers, der die Nutzung des Sicherheitsgurtes mitloggt.
Ausführungsbeispiele der Offenbarung ziehen auch die Bestimmung von anderen Zuständen und Informationen aus den Sensordaten in Erwägung. Zum Beispiel können die Größe oder Positionen von verschiedenen Fahrzeugkomponenten, wie zum Beispiel Passagiersitze, Kindersitze oder Sitzerhöhungen, Inhalte des Fahrzeuginneren, usw. bestimmt werden. Das Fahrzeug kann dann, zum Beispiel die Airbags ausrichten oder die Lüftungsöffnungen entsprechend ausrichten oder auf inkorrekt positionierte Sitze hingewiesen werden. Als ein anderes Beispiel kann die Größe von Passagieren von den Konturen des Sicherheitsgurtes bestimmt werden, d.h. den Positionen der verschiedenen Messmarkierungen, da diese den Körper des Passagiers nachformen. Dies kann das System indirekt über das Gewicht des Passagiers informieren, und dadurch das Fahrzeug informieren, wenn oder wie zum Beispiel Airbags im Falle einer Kollision eingesetzt werden sollen. Als ein weiteres Beispiel, kann die Position oder Pose eines Passagiers mittels der Positionen der Messmarkierungen bestimmt werden, da diese sich mit den Passagieren decken, die sich in ihren Sitzen bewegen. Dies kann das Fahrzeug über, zum Beispiel, Passagiere informieren, die in ihren Sitzen rutschen, bis hin zu einem Punkt, an dem die Sicherheitsgurte inkorrekt oder gefährlich auf ihren Körpern platziert sind, Passagiere, die ihre Sicherheitsgurte lösen, während das Fahrzeug sich immer noch bewegt, Fahrer, die sich herumdrehen und daher nicht die Straße betrachten und ähnliches. Das Fahrzeug kann dann geeignete Aktionen durchführen, wie zum Beispiel, Warnen der Passagiere wieder in eine korrekte Position in ihren Sitzen zurückzukehren, Warnen des Fahrers auf die Straße zu achten und ähnliches.
In einigen Ausführungsbeispielen kann es für Systeme der Offenbarung wünschenswert sein, das Verdecken von zumindest einiger der Messmarkierungen effektiv handzuhaben, da es bei gewöhnlicher Verwendung oft Gelegenheiten von Verdeckungen gibt. Zum Beispiel kann Haar eines Passagiers über den Sicherheitsgurt fallen und daher Sensoren davon abhalten, die Messmarkierungen wahrzunehmen, lockere Kleidung oder Handgesten können auf ähnliche Weise die Messmarkierungen blockieren und ähnliches. Maschinenlern-Modelle von Ausführungsbeispielen der Offenbarung können daher trainiert werden, indem Bilder verwendet werden, in denen zumindest einige der Messmarkierungen teilweise oder ganz verdeckt sind. Das heißt, ein Teil des Trainingssets von Bildern, die in das/die Maschinenlern-Modell(e) von Ausführungsbeispielen der Offenbarung eingegeben werden, können Bilder sein, bei denen zumindest einige der Messmarkierungen teilweise oder komplett verdeckt sind. Auf diese Weise werden die Maschinenlern-Modelle von Ausführungsbeispielen der Offenbarung trainiert, Verdeckungen von Messmarkierungen handzuhaben, wodurch zuverlässigere Klassifikationsergebnisse bereitgestellt werden, die in einer Mannigfaltigkeit von Realwelt-Situationen akkurat bleiben.
Figurenliste
Die obigen und andere Ziele und Vorteile der Offenbarung werden offensichtlich werden, unter Berücksichtigung der folgenden detaillierten Beschreibung, wenn diese in Zusammenhang mit den begleitenden Zeichnungen genommen wird, durch welche hindurch ähnliche Bezugszeichen auf ähnliche Teile Bezug nehmen und in welchen:

1A abstrakt ein System für eine Detektion einer Sicherheitsgurtposition illustriert, gemäß Ausführungsbeispielen der Offenbarung;
1 B abstrakt eine Detektion einer inkorrekten Sicherheitsgurt-Konfiguration illustriert, gemäß Ausführungsbeispielen der Offenbarung;
1C abstrakt eine Detektion einer anderen inkorrekten Sicherheitsgurt-Konfiguration illustriert, gemäß Ausführungsbeispielen der Offenbarung;
1 D abstrakt eine Detektion einer weiteren inkorrekten Sicherheitsgurt-Konfiguration illustriert, gemäß Ausführungsbeispielen der Offenbarung;
2A ein Blockdiagramm-Repräsentation von Klassifikationsprozessen ist, gemäß Ausführungsbeispielen der vorliegenden Offenbarung;
2B ein Graph, der detektierte Messmarkierungs-Positionen illustriert, ist, gemäß Ausführungsbeispielen der vorliegenden Offenbarung;
2C ein Graph von Positionspunkten von 2B zum Illustrieren einer Bestimmung einer Sicherheitsgurt-Position ist, gemäß Ausführungsbeispielen der vorliegenden Offenbarung;
3 eine Blockdiagramm-Repräsentation eines Detektionssystems für eine Sicherheitsgurt-Position ist, gemäß Ausführungsbeispielen der vorliegenden Offenbarung;
4A eine Illustration eines beispielhaften autonomen Fahrzeugs ist, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
4B ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug von 4A zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
4C ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 4A ist, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
4D ein Systemdiagramm für die Kommunikation zwischen dem/den Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug von 4A ist, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung; und
5 ein Beispiel-Blockdiagramm für ein beispielhaftes Rechengerät ist, das für die Verwendung in der Implementierung von Ausführungsbeispielen der vorliegenden Offenbarung geeignet ist.
6 ein Flussdiagramm ist, welches Prozessschritte für eine Bestimmung einer Sicherheitsgurt-Position illustriert, gemäß Ausführungsbeispielen der Offenbarung; und
7 abstrakt Detektion und Korrektur von inkorrekten Sicherheitsgurt-Konfigurationen illustriert, gemäß Ausführungsbeispielen der Offenbarung.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
In einem Ausführungsbeispiel bezieht sich die Offenbarung auf Maschinenlern-Systeme und Verfahren zur maschinenlern-basierten Sicherheitsgurt-Position-Detektion und -Klassifikation. Eine Anzahl von Messmarkierungen werden auf einem Sicherheitsgurt eines Fahrzeugs platziert. Eine Kamera oder anderer Sensor wird innerhalb des Fahrzeugs platziert, um Bilder oder andere Daten, die sich auf Positionen von Messmarkierungen beziehen, aufzunehmen, wenn der Sicherheitsgurt in Benutzung ist. Ein oder mehrere Modelle, wie beispielsweise Maschinenlern-Modelle, können dann die räumlichen Positionen der Messmarkierungen aus den Informationen der aufgenommenen Bilder bestimmen, und den Anlegezustand des Sicherheitsgurtes bestimmen. Insbesondere kann das System bestimmen, ob der Sicherheitsgurt in einem oder mehreren inkorrekten Zuständen getragen wird, wie beispielsweise nicht angelegt, auf eine unsichere oder gefährliche Weise angelegt, und wenn dies so ist, kann das System zum Beispiel einen Alarm bereitstellen, so dass das Fahrzeug oder ein Passagier eine korrigierende Aktion durchführen kann. Auf diese Weise stellt das System eine konstante und Realtime-Überwachung von Sicherheitsgurten bereit, um den Sicherheitsgurtgebrauch und Sicherheit zu erhöhen.
1A illustriert abstrakt ein System für eine Detektion einer Sicherheitsgurt-Position, gemäß Ausführungsbeispielen der Offenbarung. Hier umfasst ein Detektionssystem 10 für eine Fahrzeug-Sicherheitsgurt-Position, einen Sicherheitsgurt 20 und einen Beckengurt 30, wobei der Sicherheitsgurt 20 eine Anzahl von Messmarkierungen 40 hat, die aufgedruckt oder auf andere Weise darauf positioniert sind. In diesem Ausführungsbeispiel sind die Messmarkierungen 40 so positioniert, dass sie sowohl oberhalb als auch unterhalb der Schulter von Fahrer 50 liegen, wenn der Sicherheitsgurt 20 korrekt getragen wird. Auf diese Weise ist es Positionen der Messmarkierungen 40 möglich, den oberen Körper von Fahrer 50 nachzubilden, und daher sowohl ihre Positionen als auch, zu einem gewissen Grad, Positionsinformationen von Teilen des oberen Körpers von Fahrer 50 zu übermitteln.
Das Fahrzeug von System 10 umfasst einen Sitz mit einem Rückenlehnen-Abschnitt 60, einem Sitzflächen-Abschnitt 70 und einem Gurtschloss 80 zum Anschnallen des Sicherheitsgurtes 20 und Beckengurtes 30. Der Sitz 60, 70 hilft den Fahrer 50 in einer komfortablen und korrekten Position zum Fahren zu halten. Der Sicherheitsgurt 20 erstreckt sich durch eine Rolle 120 hindurch und in einen Aufrollmechanismus, nicht gezeigt, der hilft, den Sicherheitsgurt 20 straff zu halten. Der Aufrollmechanismus kann ein bekannter Aufrollmechanismus sein, der mechanisch Zug an den Sicherheitsgurt 20 anlegt und aufrechterhält, oder kann ein Aufrollmechanismus sein, der in Reaktion auf bestimmte Positionen von Messmarkierungen 40, wie unten weiter beschrieben, Zug an den Sicherheitsgurt 20 anlegt. Die Rolle 120 ist an einem Anker 130 fixiert, der an eine Säule 50 oder einen anderen Abschnitt des Fahrzeugs gekoppelt ist.
Ein Sensor 100, der eine Kamera für sichtbares Licht oder irgendein anderer Sensor zum Detektieren von Positionen der Messmarkierungen 40 sein kann, wird auf oder in einem Armaturenbrett 90 positioniert, um Bilder von Sicherheitsgurt 20 und Messmarkierungen 40 aufzunehmen. Eine optionale Beleuchtungsquelle 110 kann auch auf oder im Armaturenbrett 90 positioniert sein, um Messmarkierungen 40 zu beleuchten und daher die Aufnahme von Bildern oder anderer Positionsdaten mittels Sensors 100 zu ermöglichen. Wie oben kann Sensor 100 jeder Sensor sein, der fähig ist, Informationen aufzunehmen, die ausreichend sind, um Positionsinformationen von Messmarkierungen 40 zu bestimmen, wie beispielsweise ein sichtbares Licht Sensor oder Kamera, oder ein Sensor zum Detektieren von irgendeiner anderen Lichtwellenlänge. Zum Beispiel kann der Sensor 100 ein Infrarot- oder Nahinfrarot-Sensor sein und die Beleuchtungsquelle 110 kann konfiguriert sein, um Licht bei korrespondierenden Wellenlängen zu emittieren.
Die Messmarkierungen 40 können irgendwelche Markierungen sein, die fähig sind, Positions- und, optional, Orientierungsinformationen zu übertragen. Hierzu können sie von jeder Form sein, die ein Aussehen hat, das mit unterschiedlicher, aber regulärer, räumlicher Orientierung oder Standort variiert. Beispiele können Buchstaben des Alphabets oder irgendwelche andere komplexen Markierungen, wie beispielsweise AprilTags oder ähnliches einschließen, aber sind nicht darauf beschränkt,
System 10 kann eingesetzt werden, um jede Position des Sicherheitsgurtes 20 zu detektieren, einschließlich solcher, die eine inkorrekte Verwendung des Sicherheitsgurtes 20 anzeigen. 1 B-1 D illustrieren abstrakt beispielhafte Positionen von Sicherheitsgurten 20, die System 10 detektieren und als inkorrekten Gebrauch kennzeichnen kann. In 1 B hat es der Fahrer 50 versäumt seinen oder ihren Sicherheitsgurt 20 anzulegen. Das heißt, 1 B illustriert einen Fall, in dem Sicherheitsgurt 20 nicht benutzt wird. Dies kann auftreten, wenn, zum Beispiel, Fahrer 50 vergessen hat, seinen oder ihren Sicherheitsgurt 20 zu tragen, oder wenn Sicherheitsgurt absichtlich nicht verwendet wird, vielleicht unter Verwendung von einem bekannten Sicherheitsgurt-Simulator 120, der in Gurtschloss 80 einrastet, um alle Fahrzeugalarme zu verhindern. Hier hängt Sicherheitsgurt 20 herunter anstelle von quer über den Fahrer 50, wobei die Messmarkierungen 40 daher charakteristischerweise in einer näherungsweise vertikalen Konfiguration, welche sich entlang der linken Seite von Fahrer 50 und herunter von Rolle 120 erstreckt, erscheinen,
1C illustriert einen anderen Fall, in dem Fahrer 50 den Sicherheitsgurt 20 verwendet, bei dem sich der Sicherheitsgurt 20 aber inkorrekt unterhalb seines oder ihres Armes erstreckt, anstatt über seine oder ihre linke Schulter. In diesem Fall, erstreckt sich Sicherheitsgurt 20 quer über Fahrer 50, wobei Messmarkierungen 40 niedriger positioniert sind, als wenn Sicherheitsgurt 20 korrekt weiter oben am Fahrer 50 über seine oder ihre Schulter getragen wird. Ferner würden, weil einige der Messmarkierungen 40 mittels der linken Schulter und des Oberarms des Fahrers 50 für den Blick von Sensor 40 blockiert sind, die Markierungen 40 für den Sensor 100 als ein unteres, abgewinkeltes Band von Markierungen 40 und ein diskontinuierliches, oberes und mehr vertikal orientiertes Band von Markierungen 40 erscheinen.
1 D illustriert einen weiteren Fall, in dem Fahrer 50 den Sicherheitsgurt 20 verwendet, bei dem sich aber Sicherheitsgurt 20 inkorrekt hinter dem Rücken von Fahrer 50 erstreckt, anstatt entlang seiner oder ihrer Vorderseite. In diesem Fall, werden die unteren Messmarkierungen mittels des Körpers von Fahrer 50 vor der Detektion blockiert. Daher erscheinen die Markierungen 40 für Sensor 100 als ein einzelnes, kurzes gewinkeltes Band von Markierungen 40, welches sich oberhalb der Schulter von Fahrer 50 erstreckt.
2A ist ein Blockdiagramm, welches die Operation von System 10 illustriert. Sensor 100 nimmt ein Bild oder andere Informationen, von denen Positionen von Messmarkierungen 40 abgeleitet werden können, auf und überträgt diese Informationen an Messmarkierungs-Bestimmungsmodul 210, das ein computerausgeführtes Modul ist, welches Instruktionen zum Bestimmen von räumlichen Positionen von den Messmarkierungen 40 ausführt, die in dem Bild oder anderen Informationen von Sensor 100 erscheinen. Die Messmarkierungs-Positionen werden dann in ein Mustererkennungs-Modul 220 eingegeben, das ein computerausgeführtes Modul ist, das Instruktionen zum Klassifizieren der räumlichen Positionen der Messmarkierungen 40 in vorgegebene Verwendungskonfigurationen für den Sicherheitsgurt 20 ausführt. Das heißt, das Mustererkennungs-Modul 220 gibt die Konfiguration des Sicherheitsgurtes 20, wie dieser durch den Fahrer 50 getragen wird, aus. Wie oben können die spezifischen Konfigurationen der Sicherheitsgurtbenutzungen alle Konfigurationen sein. In einem Ausführungsbeispiel können die Konfigurationen, in die das Mustererkennungs-Modul 220 die Sicherheitsgurtverwendungen klassifizieren kann, umfassen 1) ein korrekt getragener Sicherheitsgurt (1A), d.h. wobei sich der Schultergurt über die Schulter des Fahrers 50 erstreckt und sich diagonal herunter quer über den Torso des Trägers zu Gurtschloss 80 erstreckt, 2) ein Sicherheitsgurt, der ab ist (1B) oder nicht getragen wird (einschließlich der Verwendung von bekannten Sicherheitsgurt-Warnungsstoppern und ähnlichem), 3) ein Sicherheitsgurt, der korrekt geschlossen ist, der sich aber unter der Schulter und linken Arm von Fahrer 50 erstreckt (1C), anstatt über die Schulter des Trägers, wie es korrekt ist, und 4) einen Sicherheitsgurt, der korrekt geschlossen, der sich aber hinter dem Fahrer 50 erstreckt, anstatt sich korrekt über der Vorderseite von Fahrer 50 erstreckt (1D). Auf diese vier Fälle kann hierin Bezug genommen werden, als „Fall-An“, „Fall-Ab“, „Fall-Unter“ bzw. „Fall-Rücken“.
Das Messmarkierungs-Positions-Bestimmungsmodul 210 kann die räumlichen Positionen der Messmarkierungen 40 auf jegliche Art aus den eingegebenen Daten von Sensor 100 bestimmen. In einigen beispielhaften Ausführungsbeispielen kann Modul 210 bekannte Computer-Vision-basierte Detektionsprozesse einsetzen, die Objekte wie Messmarkierungen 40 detektieren ohne neuronale Netzwerke zu verwenden, wie zum Beispiel Kantendetektions-Verfahren, Feature-Such-Verfahren, probalistische-Gesichts-Modelle (probalistic face models), Graph-Matching, Histograms of oriented gradients (HOGs), die in Klassifizierer wie beispielsweise Support Vector Machines eingespeist werden, Haar Cascade Klassifizierer und ähnliches. Räumliche Positionen von detektierten Messmarkierungen 40 in einem Bild können dann in jeder Art detektiert oder geschätzt werden, wie beispielsweise via tabellierter Positionen, die zu jeder Pixelposition korrespondieren und gemäß einer Schätzung der Distanzen zwischen dem Sensor 100 und Positionen auf einem Modell oder simulierten Fahrer bestimmt werden. In einigen anderen beispielhaften Ausführungsbeispielen kann Modul 210 auf neuronalen Netzwerken basierte Objekterkennungs-Verfahren, wie solcher die Deep Neural Network (DNN) Objekterkennung und Positions-Bestimmungs-Schemata einsetzen, wie auch alle anderen, einsetzen. Zum Beispiel kann ein DNN trainiert werden, um Messmarkierungen 40 und deren Positionen zu erkennen, unter Verwenden eines Trainingssatzes von gelabelten Bildern von Messmarkierungen und deren räumlichen Positionsinformationen. Trainieren von solchen DNNs kann in bekannter Weise ausgeführt werden.
Das Mustererkennungs-Modul 220 kann die räumliche Positionsinformationen der Messmarkierungen 40, auf alle Arten, in die obigen Sicherheitsgurt-Position Fälle klassifizieren. In einigen beispielhaften Ausführungsbeispielen, kann das Modul 220 eine oder mehrere maschinenlernbasierte Klassifikationsverfahren einsetzen. 2B ist ein Graph, der detektierte Messmarkierungs-Positionen illustriert, die via Experiment bestimmt sind. Wie gesehen werden kann, liegen die Messmarkierungen 40 des Sicherheitsgurts typischerweise innerhalb gut definierter räumlichen Regionen, abhängig davon, welcher Benutzungsfall auftritt. Zum Beispiel liegt im Fall-An, wenn ein Sicherheitsgurt 20 korrekt getragen wird, seine Messmarkierungen 40 im Wesentlichen entlang eines diagonalen Bandes, welches sich von oben links des Fahrers 50 zu seinem oder ihrem unten rechts verläuft, wie es sich durch den diagonalen Cluster von Punkten zeigt, welcher sich vom Zentrum des Graphs von 2B nach unten links verläuft. Ähnlich im Fall-Ab, wird der Sicherheitsgurt 20 nicht getragen und hängt daher zur Linken des Fahrer 50 herab, wie es sich durch das herunter verlaufende Band von Punkten zeigt, welches im Wesentlichen vom Zentrum von 2B nach unten rechts verläuft.
In diesem Ausführungsbeispiel positionieren sich die Messmarkierungen 40 selber in gut definierten Clustern gemäß ihrer Verwendung. Es kann beobachtet werden, dass Sicherheitsgurt-Verwendungsfälle bestimmt werden können gemäß irgendeinem Verfahren zum Klassifizieren von Clustern von Punkten in einem Raum. Zum Beispiel kann ein Model von k-nächsten-Nachbarn trainiert werden, um zu bestimmen, ob Punkte der Messmarkierungen 40 zu irgendeinem der in 2B gezeigten Punkten gehören, da jedes Cluster zu einem spezifischen Fall korrespondiert. Alternativ kann jedes klassifikationsbasierte Modell eingesetzt werden, um räumliche Regionen zu bestimmen, die zu jedem der vier Fälle von 2B korrespondieren, wo eingegebene Positionen von Messmarkierungen 40 mittels Mustererkennungs-Modul 220 klassifiziert werden können, je nachdem in welche räumliche Region sie fallen. Ähnlich kann jedes regressionsbasierte Model eingesetzt werden, um jedes Cluster von Punkten entsprechend zu jedem spezifischen Fall zu charakterisieren, wo eingegebene Positionen von Messmarkierungen 40 klassifiziert werden können, je nachdem zu welchem charakterisierten Cluster sie am nächsten sind.
Als eine weitere Alternative können Positionen von Messmarkierungen 40 gemäß charakteristischen Verteilungen oder Bereiche ihrer Positionspunkte klassifiziert werden. 2C illustriert ein solches Beispiel. Hier werden die gleichen in 2B gezeigten Positionspunkte von Messmarkierungen 40 in einer anderen Form präsentiert, wobei die x-Achse von 2C die Position repräsentiert, wo die Tags in der x-Richtung von einem Eingabebild detektiert werden, und die y-Achse die Anzahl der Messmarkierungen 40 repräsentiert, die an dieser x-Position gefunden werden. Wie gesehen werden kann, hat jede Sicherheitsgurt-Verwendung eine charakteristische Verteilung, wenn die Positionen ihrer Messmarkierungen 40 auf diese Weise geplottet werden. Zum Beispiel, hat Fall-An eine unterscheidungsfähige Verteilung, bei der ein Cluster von Positionen von Markierungen 40 in näherungsweise dem Bereich von 620-820 und in dem Bereich von 1250-1600 fällt. Ähnlich hat der Fall-Ab sowohl einen Cluster von Positionen von Markierungen 40 in näherungsweise dem Bereich von 1000-1180 als auch eine diffusere Verteilung, die in dem Bereich von 1400-1780 liegt. Demgemäß können die Positionen von Markierungen 40 gemäß ihren Verteilungen klassifiziert werden, wenn diese wie in 2C geplottet werden. Daher kann zum Beispiel Sensor 100 ein Bild des Sicherheitsgurtes 20 und Messmarkierungen 40 aufnehmen und das Messmarkierungs-Positionierungs-Bestimmungsmodul 210 kann die Positionen von den Messmarkierungen 40 bestimmen, die im Bild aufgenommen wurden. Mustererkennungs-Modul 220 kann dann bestimmen, welche Verteilung von 2C am ähnlichsten zu der korrespondierenden Verteilung von Positionen von Markierungen 40 im eingegebenen Bild ist, und demgemäß das Bild klassifizieren, d.h. den aktuellen Zustand des Sicherheitsgurtes 20. Ähnlichkeit kann auf irgendeine Weise gemessen werden. Zum Beispiel können Mittel- oder Medianwerte für jede Verteilung oder irgendein anderer charakteristische Wert davon bestimmt werden und mit Mittel/Median oder anderen charakteristischen Werten von jeder in 2C gezeigten Verteilung verglichen werden. Die nächsten Vergleiche können dann als Klassifikation oder korrespondierender Fall für das eingegebene Bild ausgewählt werden.
3 ist eine Blockdiagrammrepräsentation eines beispielhaften Detektionssystems von Sicherheitsgurtpositionen von Ausführungsbeispielen der Offenbarung. Hier ist eine Rechenvorrichtung 300, die irgendeine elektronische Rechenvorrichtung sein kann, die Prozessier-Schaltkreise beinhaltet, die fähig sind, die Operationen der Sicherheitsgurtpositions-Detektionen von Ausführungsbeispielen der Offenbarung auszuführen, in elektronischer Kommunikation sowohl mit einer Kamera 310 als auch einem Sicherheitsgurtreagierenden System 320. In Operation nimmt Kamera 310 Bilder eines Subjekts auf und überträgt sie an Rechenvorrichtung 300, die dann Module 210 und 220 von 2A implementiert, was aus dem Bild der Kamera 310 den korrespondierenden Sicherheitsgurt-Benutzungsfall (z.B. Fall-An, Fall-Ab, Fall-Unter oder Fall-Rücken) bestimmt. Die Rechenvorrichtung 300 überträgt diesen Fall an das Sicherheitsgurt-reagierendes System 320, was eine Aktion ausführt oder in Reaktion eine oder mehrere Operationen durchführt.
Sicherheitsgurt-reagierendes System 320 kann jedes System sein, das fähig ist, eine oder mehrere Aktionen basierend auf dem Sicherheitsgurt-Benutzungsfall durchzuführen, den es von der Rechenvorrichtung 300 empfängt. Alle Konfigurationen von Kamera 310, Rechenvorrichtung 300 und betrachtungsunterstütztem System 320 werden in Erwägung gezogen. Als ein Beispiel, kann das Sicherheitsgurt-reagierende System 320 ein autonomes Fahrzeug sein, das fähig ist, auf den Sicherheitsgurt-Benutzungszustand von dem Fahrer oder dem anderen Passagier zu reagieren. In diesem Beispiel kann die Kamera 310 und die Rechenvorrichtung 300 innerhalb des Fahrzeugs positioniert sein, während das Sicherheitsgurt-reagierende System 320 das Fahrzeug selber repräsentieren kann. Die Kamera 310 kann zu Kamera 441 der 4A und 4C unten korrespondieren und kann an jeder Position innerhalb des Fahrzeugs positioniert werden, die es erlaubt, den Fahrer oder Passagier zu sehen. Demgemäß kann Kamera 310 Bilder vom Fahrer und seines oder ihres Sicherheitsgurts aufnehmen und diese an Rechenvorrichtung 300 übertragen, die die räumlichen Positionen der sichtbaren Messmarkierungen 40 berechnet und den korrespondierenden Sicherheitsgurt-Benutzungszustand des Fahrers bestimmt. Der Benutzungszustand kann dann zu, zum Beispiel, einem anderen Softwaremodul übertragen werden, das Aktionen, die das Fahrzeug in Reaktion daraufhin starten kann, bestimmt. Zum Beispiel kann das Fahrzeug bestimmen, dass der Sicherheitsgurt des Fahrers nicht getragen wird (Fall-Ab) oder inkorrekt getragen wird (Fall-Unter oder Fall-Rücken) und kann irgendeine Art von Operation in Reaktion darauf initiieren. Solche Operationen können jede Art von Warnung, die an den Fahrer ausgegeben wird (z.B. eine sichtbare oder hörbare Warnung, eine Warnung auf einem Head-up-Display oder ähnliches), Initiierung eines Autopiloten, eine Brems- oder Lenkoperation, Zündungsabschaltung oder irgendeine andere Aktion einschließen. Rechenvorrichtung 300 kann zu der Rechenvorrichtung 500 von 5 unten korrespondieren und kann innerhalb des Fahrzeugs von Sicherheitsgurt-reaktives System 320 als ein lokaler Prozessor positioniert sein, oder kann ein Remoteprozessor sein, der Bilder von Kamera 310 empfängt und Sicherheitsgurt-Verwendungsfälle oder -Zustände drahtlos an das Fahrzeug von Sicherheitsgurt-reaktives System 320 überträgt.
4A ist eine Darstellung eines Beispiels eines autonomen Fahrzeugs 400 gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das autonome Fahrzeug 400 (hier alternativ als „Fahrzeug 400“ bezeichnet) kann, ohne Einschränkung, ein Personenfahrzeug umfassen, wie z. B. einen Pkw, einen Lkw, einen Bus, ein Ersthelferfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrfahrzeug, ein Polizeifahrzeug, eine Ambulanz, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne und/oder eine andere Art von Fahrzeug (z. B. das unbemannt ist, oder das einen oder mehrere Fahrgäste aufnimmt). Autonome Fahrzeuge werden im Allgemeinen in Form von Automatisierungsstufen beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (Standard Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert werden. Das Fahrzeug 400 kann eine Funktionalität gemäß einem oder mehreren der Level 3 - Level 5 der autonomen Fahrstufen aufweisen. Beispielsweise kann das Fahrzeug 400 je nach Ausführungsbeispiel eine bedingte Automatisierung (Level 3), eine hohe Automatisierung (Level 4) und/oder eine vollständige Automatisierung (Level 5) aufweisen.
Das Fahrzeug 400 kann Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z. B. 2, 4, 6, 8, 18, usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs umfassen. Das Fahrzeug 400 kann ein Antriebssystem 450 umfassen, wie z. B. einen Verbrennungsmotor, ein Hybrid-Elektroaggregat, einen vollelektrischen Motor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 450 kann mit einem Antriebsstrang des Fahrzeugs 400 verbunden sein, der ein Getriebe umfassen kann, um den Vortrieb des Fahrzeugs 400 zu ermöglichen. Das Antriebssystem 450 kann in Reaktion auf den Empfang von Signalen von der Drosselklappe/Beschleunigungsvorrichtung 452 gesteuert werden.
Ein Lenksystem 454, das ein Lenkrad umfassen 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 Lenkaktuator 456 empfangen. Das Lenkrad kann bei der Funktionalität der Vollautomatisierung (Level 5) optional sein.
Das Bremssensorsystem 446 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf den Empfang von Signalen von den Bremsaktuatoren 448 und/oder Bremssensoren zu betätigen.
Die Steuerung(en) 436, die eine oder mehrere CPU(s), ein oder mehrere System-on-a-Chip (SoCs) 404 (4C) und/oder GPU(s) umfassen können, können Signale (z. B. repräsentativ für Befehle) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 400 senden. 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 ein oder mehrere OnBoard-(z. B. integrierte) Rechengeräte (z. B. Supercomputer) umfassen, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z. B. Signale, die Befehle repräsentieren), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Fahren des Fahrzeugs 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 Funktionalität der künstlichen Intelligenz (z. B. Computer Vision), eine vierte Steuerung 436 für Infotainment-Funktionalität, eine fünfte Steuerung 436 für Redundanz in Notfällen und/oder andere Steuerungen umfassen. In einigen Beispielen kann eine einzelne Steuerung 436 zwei oder mehr der oben genannten Funktionalitäten übernehmen, zwei oder mehr Steuerungen 436 können eine einzelne Funktionalität übernehmen 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 in Reaktion auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren empfangen werden (z. B. Sensoreingaben). Die Sensordaten können beispielsweise und ohne Einschränkung von (einem) Sensor(en) des globalen Navigationssatellitensystems 458 (z. B. Global Positioning System-Sensor(en)), RADAR-Sensor(en) 460, Ultraschallsensor(en) 462, LIDAR-Sensor(en) 464, Sensor(en) einer Trägheitsmesseinheit (IMU) 466 (z. B. Beschleunigungssensor(en), Gyroskop(en), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 496, Stereokamera(s) 468, Weitwinkelkamera(s) 470 (z. B, Fischaugenkameras), Infrarotkamera(s) 472, Umgebungskamera(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 anderen Sensortypen empfangen werden.
Eine oder mehrere der Steuerungen 436 können Eingaben (z. B. in Form von Eingabedaten) von einem Instrumentencluster 432 des Fahrzeugs 400 empfangen und Ausgaben (z. B. in Form von Ausgabedaten, Anzeigedaten, usw.) über eine Mensch-Maschine-Schnittstelle (HMI)-Anzeige 434, einen akustischen Signalgeber, 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 von 4C), Positionsdaten (z. B. die Position des Fahrzeugs 400, zum Beispiel auf einer Karte), Richtung, Position anderer Fahrzeuge (z. B. ein Belegungsraster), Informationen über Objekte und Status von Objekten, wie von der/den Steuerung(en) 436 wahrgenommen, usw. umfassen. Beispielsweise kann die HMI-Anzeige 434 Informationen über das Vorhandensein eines oder mehrerer Objekte anzeigen (z. B. ein Straßenschild, ein Warnschild, eine sich ändernde Ampel usw.) und/oder Informationen über Fahrmanöver, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z. B. jetzt die Spur wechseln, in zwei Meilen die Ausfahrt 34B nehmen, usw.).
Das Fahrzeug 400 umfasst weiterhin eine Netzwerkschnittstelle 424, die eine oder mehrere drahtlose Antenne(n) 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 usw. zu kommunizieren. Die drahtlose(n) Antenne(n) 426 kann/können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Geräte usw.) unter Verwenden von lokalen Netzwerken 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ührungsbeispielen der vorliegenden Offenbarung. Die Kameras und die jeweiligen Sichtfelder stellen ein exemplarisches Ausführungsbeispiel dar und sind nicht einschränkend gedacht. Beispielsweise können zusätzliche und/oder alternative Kameras umfasst sein und/oder die Kameras können sich an verschiedenen Kamerapositionen des Fahrzeugs 400 befinden.
Die Kameratypen für die Kameras können, sind aber nicht beschränkt auf, Digitalkameras umfassen, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 400 ausgebildet sein können. Die Kamera(s) kann/können auf der automobilen Sicherheitsintegritätsstufe (Autonomie Safety Integrity Level, ASIL) B und/oder einer anderen ASIL arbeiten. Die Kameratypen können je nach Ausführungsbeispiel eine beliebige Bildaufnahmerate erreichen, z. B. 60 Bilder pro Sekunde (fps), 120 fps, 240 fps usw.. Die Kameras können Rolling Shutter, Global Shutter, einen anderen Verschlusstyp oder eine Kombination davon verwenden. In einigen Beispielen kann das Farbfilter-Array ein Rot-Klar-Klar-Klar (RCCC) Farbfilter-Array, ein Rot-Klar-Klar-Blau (RCCB) Farbfilter-Array, ein Rot-Blau-Grün-Klar (RGBC) Farbfilter-Array, ein Foveon X3-Farbfilter-Array, ein Bayer-Sensor (RGGB) Farbfilter-Array, ein Monochrom-Sensor-Farbfilter-Array und/oder eine andere Art von Farbfilter-Array umfassen. In einigen Ausführungsbeispielen können Clear-Pixel-Kameras, wie z. B. Kameras mit einem RCCC-, einem RCCB- und/oder einem RBGC-Farbfilter-Array, verwendet werden, im Versuch die Lichtempfindlichkeit zu erhöhen.
In einigen Beispielen kann eine oder mehrere der Kamera(s) verwendet werden, um erweiterte Fahrerassistenzsystem (ADAS)-Funktionen auszuführen (z. B. als Teil eines redundanten oder ausfallsicheren Designs). So kann z. B. eine Multifunktions-Monokamera installiert werden, um Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung zu ermöglichen. Eine oder mehrere der Kamera(s) (z. B. alle Kameras) können simultan Bilddaten (z. B. Video) aufnehmen und bereitstellen.
Eine oder mehrere der Kameras können in einer Montagebaugruppe, wie z. B. einer kundenspezifisch gestalteten (3-D-gedruckten) Baugruppe, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z. B. Reflexionen vom Armaturenbrett, die sich in den Außenspiegeln der Windschutzscheibe spiegeln) auszuschalten, die die Bilddatenerfassungsfähigkeiten der Kamera stören könnten. In Bezug auf Seitenspiegel-Montagebaugruppen können die Seitenspiegel-Baugruppen kundenspezifisch 3-D-gedruckt werden, so dass die Kameramontageplatte zur Form des Seitenspiegels passt. In einigen Beispielen kann/können die Kamera(s) in den Seitenspiegel integriert werden. Bei Seitenkameras kann/können die Kamera(s) auch in die vier Säulen an jeder Ecke der Kabine integriert werden.
Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 400 umfasst (z. B. nach vorne gerichtete Kameras), können für die Rundumsicht verwendet werden, um dabei zu helfen, nach vorne gerichtete Wege und Hindernisse zu identifizieren, sowie mit Hilfe einer oder mehrerer Steuerungen 436 und/oder Steuer-SoCs Informationen bereitzustellen, die für die Erstellung eines Belegungsgitters und/oder das Bestimmen der bevorzugten Fahrzeugwege entscheidend sind. Nach vorne gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorne gerichtete Kameras können auch für ADAS-Funktionen und -Systeme wie Spurverlassenswarnungen (Lane Depature Warnings, LDW), autonome Geschwindigkeitsregelung (Autonomous Cruise Control, ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung verwendet werden.
Eine Vielzahl von Kameras kann in einer nach vorne gerichteten Konfiguration verwendet werden, umfassend beispielweise eine monokulare Kameraplattform, die einen CMOS (Complementary Metal Oxide Semiconductor)-Farbbildgeber umfasst. Ein weiteres Beispiel kann eine Weitwinkelkamera(s) 470 sein, die verwendet werden kann, um Objekte zu erkennen, die von der Peripherie ins Blickfeld kommen (z. B. Fußgänger, kreuzenden Verkehr oder Fahrräder). Obwohl in 4B nur eine Weitwinkelkamera gezeigt ist, kann sich eine beliebige Anzahl von Weitwinkelkameras 470 am Fahrzeug 400 befinden. Zusätzlich kann /können Fernbereichskamera(s) 498 (z. B. ein Fern-Stereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert wurde. Die Fernbereichskamera(s) 498 kann/können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
Eine oder mehrere Stereokameras 468 können auch in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 468 kann/können eine integrierte Steuereinheit umfassen, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (z. B. FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Eine solche Einheit kann dazu verwendet werden, eine 3D-Karte der Fahrzeugumgebung zu erzeugen, die eine Abschätzung der Entfernung für all die Punkte im Bild umfasst. Eine alternative Stereokamera(s) 468 kann einen kompakte Stereo-Vision-Sensor(en) umfassen, der zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip umfasst, der den Abstand zwischen dem Fahrzeug und dem Zielobjekt messen kann und die generierten Informationen (z. B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurverlassens-Warnfunktionen verwendet. Andere Typen von Stereokamera(s) 468 kann/können zusätzlich oder alternativ zu den hier beschriebenen verwendet werden.
Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 400 umfasst (z. B. Seitenkameras), können für die Umgebungsansicht verwendet werden, was Informationen liefert, die zum Erstellen und Aktualisieren des Belegungsrasters sowie zum Erzeugen von Seitenaufprall-Kollisionswarnungen verwendet werden. Beispielsweise kann/können die Umgebungskamera(s) 474 (z. B. vier Umgebungskameras 474 wie in 4B gezeigt) um das Fahrzeug 400 positioniert werden. Die Umgebungskamera(s) 474 kann/können Weitwinkelkamera(s) 470, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches umfassen. Beispielsweise können vier Fischaugenkameras an der Front, am Heck und an den Seiten des Fahrzeugs positioniert werden. In einer alternativen Anordnung kann das Fahrzeug drei Surround-Kamera(s) 474 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z. B. eine nach vorne gerichtete Kamera) als eine vierte Surround-View-Kamera einsetzen.
Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 400 umfasst (z. B. Rücksichtkameras), können für die Einparkhilfe, Umgebungssicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsrasters verwendet werden. Eine große Vielfalt von Kameras kann verwendet werden, einschließlich, aber nicht beschränkt auf, Kameras, die auch als nach vorne gerichtete Kamera(s) geeignet ist/sind (z. B. Fern- und/oder Mittelbereichskamera(s) 498, Stereokamera(s) 468), Infrarotkamera(s) 472, usw.), wie hier beschrieben.
Kameras mit einem Sichtfeld, das Teile des Inneren oder der Kabine von Fahrzeug 400 umfasst, können verwendet werden, um einen oder mehrere Zustände von Fahrern, Passagieren oder Objekten in der Kabine zu überwachen. Jede Art von Kamera kann verwendet werden, einschließlich, aber nicht darauf beschränkt, Kabinenkamera(s) 441, die jede Art von hierin beschriebener Kamera sein können, und die irgendwo an oder im Fahrzeug platziert werden können, was eine Ansicht der Kabine oder des Inneren davon bereitstellt. Zum Beispiel kann/können die Kabinenkamera(s) 441 innerhalb oder auf einem Teil des Armaturenbretts des Fahrzeuges 400, des Rückspiegels, der Seitenspiegel, Sitze oder Türen platziert sei und orientiert sein, um Bilder von allen Fahrern, Passagieren oder jedes anderen Objekts oder Teil des Fahrzeugs 400 aufzunehmen.
4C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 400 von 4A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Es sollte verstanden werden, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargelegt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen, usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter sind viele der hier beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene Funktionen, die hier als von Einheiten ausgeführt beschrieben werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Memory gespeicherte Anweisungen ausführt.
Jede der Komponenten, Merkmale und Systeme des Fahrzeugs 400 in 4C ist so gezeigt, dass sie über Bus 402 verbunden ist. Der Bus 402 kann eine CAN-Datenschnittstelle (Controller Area Network) umfassen (hier alternativ als ein „CAN-Bus“ bezeichnet). Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 400 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionalitäten des Fahrzeugs 400 verwendet wird, wie z. B. Betätigung von Bremsen, Beschleunigung, Bremsen, Lenkung, Scheibenwischern, usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten enthält, jeder mit seinem eigenen eindeutigen Identifikator (z. B. einer CAN-ID). Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, die Fahrgeschwindigkeit, die Drehzahl des Motors (RPM), die Tastenpositionen und/oder andere Fahrzeugstatusanzeigen zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
Obwohl der Bus 402 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung gedacht. Beispielsweise können zusätzlich oder alternativ zum CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Zusätzlich ist, obwohl eine einzelne Leitung zur Darstellung des Busses 402 verwendet wird, dies nicht als Einschränkung zu verstehen. Beispielsweise 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 Arten von Bussen, die ein anderes Protokoll verwenden, umfassen können. In einigen Beispielen können zwei oder mehr Busse 402 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder sie können zur Redundanz verwendet werden. So kann z. B. ein erster Bus 402 für die Funktionalität der Kollisionsvermeidung und ein zweiter Bus 402 für die Stellbewegungssteuerung verwendet werden. In 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. In einigen Beispielen kann jeder SoC 404, jede Steuerung 436 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf dieselben Eingabedaten (z. B. Eingaben von Sensoren des Fahrzeugs 400) haben und mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
Das Fahrzeug 400 kann eine oder mehrere Steuerung(en) 436 umfassen, solche wie sie hierin mit Bezug auf 4A beschrieben sind. Die Steuerung(en) 436 kann/können für eine Vielzahl von Funktionen verwendet werden. Die Steuerung(en) 436 kann/können an jede/jedes der verschiedenen anderen Komponenten und Systeme des Fahrzeugs 400 gekoppelt sein und kann/können für die Steuerung des Fahrzeugs 400, die künstliche Intelligenz des Fahrzeugs 400, das Infotainment für das Fahrzeug 400 und/oder Ähnliches verwendet werden.
Das Fahrzeug 400 kann ein oder mehrere System-on-a-Chip (SoC) 404 umfassen. Der SoC 404 kann CPU(s) 406, GPU(s) 408, Prozessor(en) 410, Cache(s) 412, Beschleuniger 414, Datenspeicher 416 und/oder andere nicht gezeigte Komponenten und Features umfassen. Der/die SoC(s) 404 kann/können für das Steuern des Fahrzeugs 400 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise kann der/die SoC(s) 404 in einem System (z. B. dem System des Fahrzeugs 400) mit einer HD-Karte 422 kombiniert werden, die Kartenauffrischungen und/oder -aktualisierungen über eine Netzwerkschnittstelle 424 von einem oder mehreren Servern (z. B. Server(n) 478 aus 4D) erlangen kann.
Die CPU(s) 406 kann/können einen CPU-Cluster oder CPU-Komplex umfassen (hier alternativ als „CCPLEX“ bezeichnet). Die CPU(s) 406 kann/können mehrere Kerne und/oder L2-Caches umfassen. In einigen Ausführungsbeispielen kann die CPU(s) 406 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In einigen Ausführungsbeispielen kann/können die CPU(s) 406 vier Dual-Core-Cluster umfassen, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z. B. einen 2 MB L2-Cache). Die CPU(s) 406 (z. B. der CCPLEX) kann/können so konfiguriert sein, dass sie einen simultanen Clusterbetrieb unterstützt/unterstützen, was jeder Kombination der Cluster der CPU(s) 406 ermöglicht, zu jedem gegebenen Zeitpunkt aktiv sein kann.
Die CPU(s) 406 kann/können Leistungsverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Features umfassen: einzelne Hardwareblöcke können im Leerlauf automatisch gegated werden, um dynamische Leistung zu sparen; jeder Kerntakt kann gegated werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig leistungs-gegated sein; jeder Kern-Cluster kann unabhängig takt-gegated sein, wenn alle Kerne takt-gegated oder leistungs-gegated sind; und/oder jeder Kern-Cluster kann unabhängig leistungs-gegated sein, wenn alle Kerne leistungs-gegated sind. Die CPU(s) 406 kann/können weiter einen verbesserten Algorithmus zur Verwaltung von Leistungszuständen implementieren, bei dem zulässige Leistungszustände und erwartete Aufwachzeiten spezifiziert werden und die/der Hardware/Mikrocode für den Kern, den Cluster und das CCPLEX den besten Leistungszustand zum Eintritt bestimmt. Die Prozessorkerne können vereinfachte Leistungszustands-Eintrittssequenzen in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
Die GPU(s) 408 kann/können eine integrierte GPU umfassen (hier alternativ als „iGPU“ bezeichnet). Die GPU(s) 408 kann/können programmierbar sein und für parallele Arbeitslasten effizient sein. Die GPU(s) 408 kann/können in einigen Beispielen einen verbesserten Tensor-Befehlssatz verwenden. Die GPU(s) 408 kann/können einen oder mehrere Streaming-Mikroprozessoren umfassen, wobei jeder Streaming-Mikroprozessor einen L1-Cache umfassen kann (z. B. einen L1-Cache mit einer Speicherkapazität von mindestens 96 KB), und zwei oder mehr der Streaming-Mikroprozessoren können gemeinsam einen L2-Cache nutzen (z. B. einen L2-Cache mit einer Speicherkapazität von 512 KB). In einigen Ausführungsbeispielen kann/können die GPU(s) 408 mindestens acht Streaming-Mikroprozessoren umfassen. Die GPU(s) 408 kann/können computerbasierte Programmierschnittstelle(n) (API(s)) verwenden. Außerdem können die GPU(s) 408 eine oder mehrere parallele Berechnungsplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
Die GPU(s) 408 kann/können für beste Performance in automobilen und eingebetteten Anwendungsfällen leistungsoptimiert sein. Die GPU(s) 408 kann/können z. B. auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Jedoch ist dies nicht als einschränkend gedacht und die GPU(s) 408 kann/können auch hergestellt werden, unter Verwenden von anderen Halbleiterfertigungsverfahren. Jeder Streaming-Mikroprozessor kann eine Anzahl von gemischt-präzisen Rechenkernen enthalten, die in mehrere Blöcke partitioniert sind. Beispielsweise und nicht einschränkend können 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke unterteilt sein. In einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32 Kerne, 8 FP64 Kerne, 16 INT32 Kerne, zwei gemischt-präzise NVIDIA TENSOR COREs für Deep Learning-Matrixarithmetik, ein L0-Befehls-Cache, ein Warp-Planer, eine Verteilungseinheit und/oder eine 64-KB-Registerdatei zugewiesen sein. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Fließkommadatenpfade umfassen, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnungen und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfähigkeit umfassen, um eine feinergranulare Synchronisation und Kooperation zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können einen kombinierten L1-Datencache und eine gemeinsam genutzte Speichereinheit umfassen, um die Performance zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
Die GPU(s) 408 kann/können einen Speicher hoher Bandbreite (high bandwidth memory, HBM) und/oder ein 16 GB HBM2 Speicher-Subsystem umfassen, um in einigen Beispielen um die 900 GB/Sekunde Spitzen Speicherbandbreite bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zu dem HBM-Speicher ein synchroner Graphik-Random-Access-Speicher (SGRAM) verwendet werden, wie zum Beispiel ein Graphik-Doppelraten-Typ5-synchronen-Random-Access-Speicher (Graphics Double Data Type Five Synchronous Random Access Memory, GDD5).
Die GPU(s) 408 kann/können eine Unified-Memory-Technologie umfassen, die Zugriffszähler umfasst, um eine genauere Migration von Speicherseiten zu dem Prozessor zu ermöglichen, der am häufigsten auf sie zugreift, wodurch die Effizienz für Speicherbereiche verbessert wird, die von den Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, damit die GPU(s) 408 direkt auf die Seitentabellen der CPU(s) 406 zugreifen kann/können. In solchen Beispielen kann, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 408 einen Fehlversuch erfährt, eine Adressübersetzungsanforderung an die CPU(s) 406 übertragen werden. Als Antwort kann/können die CPU(s) 406 in ihren Seitentabellen nach der virtuell zu physikalischen Zuordnung für die Adresse suchen und die Übersetzung zurück an die GPU(s) 408 übertragen. So 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/können die GPU(s) 408 einen Zugriffszähler umfassen, der die Häufigkeit der Zugriffe der GPU(s) 408 auf den Speicher anderer Prozessoren verfolgen kann. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
Der/die SoC(s) 404 kann/können eine beliebige Anzahl von Cache(s) 412 umfassen, einschließlich der hier beschriebenen. Zum Beispiel kann/können der/die Cache(s) 412 einen L3-Cache umfassen, der sowohl der/den CPU(s) 406 als auch der/den GPU(s) 408 zur Verfügung steht (z. B. der sowohl mit der/den CPU(s) 406 als auch mit der/den GPU(s) 408 verbunden ist). Der/die Cache(s) 412 kann/können einen Write-Back-Cache umfassen, der die Zustände von Zeilen nachverfolgen kann, z. B. durch Verwenden eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI, usw.). Der L3-Cache kann je nach Ausführungsbeispiel 4 MB oder mehr umfassen, obwohl auch kleinere Cache-Größen verwendet werden können.
Der/die SOC(s) 404 kann eine Arithmetik-Logik-Einheit (ALU(s)) umfassen, die beim Durchführen vom Prozessieren im Zusammenhang mit jeder der Vielfalt von Aufgaben und Operationen des Fahrzeugs 400, wie zum Beispiel Prozessieren der DNNs, eingesetzt werden kann. Zusätzlich kann/können der/die SoC(s) 404 eine Floating-Point-Einheit(en) (FPU(s)), oder andere mathematische Coprozessoren- oder numerische Coprozessoren-Typen, umfassen, zum Durchführen mathematischer Operationen innerhalb des Systems. Zum Beispiel kann/können der/die SoC(s) 44 einen oder mehr FPUs umfassen, die als Ausführungs-Einheiten innerhalb einer CPU(s) 406 und/oder GPU(s) 408 integriert sind.
Der/die SoC(s) 404 kann/können einen oder mehrere Beschleuniger 414 umfassen (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Der/die SoC(s) 404 kann/können z. B. einen HardwareBeschleunigungs-Cluster umfassen, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher umfassen kann. Der große On-Chip-Speicher (z. B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster in die Lage versetzen, neuronale Netzwerke und andere Berechnungen zu beschleunigen. Der Hardware-Beschleunigungscluster kann zur Ergänzung der GPU(s) 408 und zum Auslagern von einigen der Aufgaben der GPU(s) 408 verwendet werden (z. B. um mehr Zyklen der GPU(s) 408 für die Ausführung anderer Aufgaben freizugeben). Der/die Beschleuniger 414 kann/können beispielsweise für gezielte Arbeitslasten (z. B. Wahrnehmung, Faltungsneuronale Netze (convolutional neural networks, CNNs), usw.) verwendet werden, die stabil genug sind, um für die Beschleunigung geeignet zu sein. Der hier verwendete Begriff „CNN“ kann alle Arten von CNNs umfassen, einschließlich auf Bereichen basierender oder regionaler Faltungsneuronaler Netze (RCNNs) und Fast RCNNs (z. B. wie für Objekterkennung verwendet).
Der/die Beschleuniger 414 (z. B. der Hardware-Beschleunigungscluster) kann/können einen Deep-Learning-Beschleuniger (DLA) umfassen. Der/die DLA(s) kann/können eine oder mehrere Tensor Processing Units (TPUs) umfassen, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Operationen pro Sekunde für Deep Learning-Anwendungen und Inferenzieren bereitstellen. Die TPUs können Beschleuniger sein, die für die Ausführung von Bildverarbeitungsfunktionen konfiguriert und optimiert sind (z. B. für CNNs, RCNNs, usw.). Die DLA(s) können weiter für einen bestimmten Satz von neuronalen Netzwerktypen und Fließkommaoperationen sowie Inferenzieren optimiert sein. Das Design der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Universal-GPU und übertrifft die Leistung einer CPU bei weitem. Die TPU(s) kann/können mehrere Funktionen ausführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datentypen sowohl für Features als auch Gewichte sowie Postprozessorfunktionen unterstützt.
Der/die DLA(s) kann/können schnell und effizient neuronale Netze, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für jede von einer Vielfalt von Funktionen ausführen, einschließlich, zum Beispiel und ohne Einschränkung: ein CNN für die Objektidentifikation und -detektierung unter Verwenden von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwenden von Daten von Kamerasensoren; ein CNN für die Erkennung und Identifizierung von Notfallfahrzeugen und die Erkennung unter Verwenden von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und die Identifizierung des Fahrzeugbesitzers unter Verwenden von Daten von Kamerasensoren; und/oder ein CNN für sicherheits- und/oder schutzrelevante Ereignisse.
Der/die DLA(s) kann/können jede Funktion der GPU(s) 408 ausführen, und durch die Verwendung eines Inferenz-Beschleunigers kann ein Designer beispielsweise entweder den/die DLA(s) oder die GPU(s) 408 für eine beliebige Funktion vorherbestimmen. Beispielsweise kann der Designer die Verarbeitung von CNNs und Fließkommaoperationen auf den/die DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 408 und/oder anderen Beschleuniger(n) 414 überlassen.
Der/die Beschleuniger 414 (z. B. der Hardware-Beschleunigungscluster) kann/können (einen) programmierbare(n) Vision Beschleuniger (PVA) umfassen, der/die hier alternativ auch als ein Beschleuniger für Computer Vision bezeichnet werden kann/können. Der/die PVA(s) kann/können so designt und konfiguriert sein, dass er/sie Algorithmen für Computer Vision für fortschrittliche Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented Reality (AR) und/oder Virtual Reality (VR)-Anwendungen beschleunigt/beschleunigen. Der/die PVA(s) kann/können ein Ausgleich zwischen Performance und Flexibilität bieten. So kann jeder PVA zum Beispiel und ohne Einschränkung eine beliebige Anzahl von RISC-Kernen (Computer mit reduziertem Befehlssatz), direkten Speicherzugriff (Direct Memory Access, DMA) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren irgendeiner der hierin beschriebenen Kameras), Bildsignalprozessor(en) und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher umfassen. Die RISC-Kerne können, je nach Ausführungsbeispiel, jedes einer Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (real-time operating system, RTOS) ausführen. Die RISC-Kerne können mit einem oder mehreren integrierten Schaltkreisen, anwendungsspezifischen integrierten Schaltkreisen (ASICs) und/oder Speichermitteln implementiert werden. Die RISC-Kerne können z. B. einen Befehls-Cache und/oder einen eng gekoppelten (tightly coupled) RAM umfassen.
Der DMA kann es Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 406 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Features unterstützen, die verwendet werden, um eine Optimierung der PVA bereitzustellen, einschließlich, aber nicht beschränkt auf die Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. In einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die Blockbreite, Blockhöhe, Blocktiefe, horizontales Blockstepping, vertikales Blockstepping und/oder Tiefenstepping umfassen können.
Die Vektorprozessoren können programmierbare Prozessoren sein, die so gestaltet sein können, dass sie effizient und flexibel die Programmierung für Computer Visions-Algorithmen ausführen und Signalverarbeitungsfähigkeiten bereitstellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen umfassen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA Engine(s) (z. B. zwei DMA Engines) und/oder andere Peripheriegeräte umfassen. Das Vektorverarbeitungs-Subsystem kann als die primäre Verarbeitungs-Engine des PVA arbeiten und kann eine Vektorverarbeitungs-Einheit (VPU), einen Befehls-Cache und/oder einen Vektorspeicher (z. B. VMEM) umfassen. Ein VPU-Kern kann einen digitalen Signalprozessor umfassen, wie z. B. einen SIMD- (Single Instruction, Multiple Data), VLIW- (Very Long Instruction Word) digitalen Signalprozessor. Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit verbessern.
Jeder der Vektorprozessoren kann einen Befehls-Cache umfassen und kann mit einem dedizierten Speicher gekoppelt sein. Als ein Ergebnis kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren arbeitet. In anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA umfasst sind, so konfiguriert sein, dass sie Datenparallelität verwenden. Zum Beispiel kann in einigen Ausführungsbeispielen die Vielzahl von Vektorprozessoren, die in einem einzelnen PVA enthalten sind, denselben Algorithmus für Computer Vision ausführen, jedoch für unterschiedliche Bereiche eines Bildes. In anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, simultan verschiedene Computer Visions-Algorithmen auf demselben Bild ausführen, oder sogar verschiedene Algorithmen auf sequentiellen Bildern oder Teilen eines Bildes ausführen. Unter anderem kann der HardwareBeschleunigungs-Cluster eine beliebige Anzahl von PVAs umfassen, und in jedem PVA kann eine beliebige Anzahl von Vektorprozessoren enthalten sein. Darüber hinaus kann/können der/die PVA(s) zusätzlichen ECC-Speicher (Error Correcting Code) umfassen, um die Gesamt-System-Sicherheit zu verbessern.
Der/die Beschleuniger 414 (z. B. der Hardware-Beschleunigungscluster) kann/können ein Netzwerk für Computer Vision auf dem Chip und SRAM umfassen, um ein SRAM mit hoher Bandbreite und geringer Latenz für den/die Beschleuniger 414 bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM umfassen, der z. B. und ohne Einschränkung aus acht frei konfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine APB-Schnittstelle (advanced peripheral bus, erweiterter Peripheriebus), eine Konfigurations-Schaltungsanordnung, eine Steuerung und einen Multiplexer umfassen. Es kann jeder beliebige Typ von Speicher verwendet werden. Der PVA und der DLA können auf den Speicher über ein Backbone zugreifen, das dem PVA und dem DLA einen Hochgeschwindigkeitszugriff auf den Speicher ermöglicht. Der Backbone kann ein Netzwerk für Computer Vision auf dem Chip umfassen, das den PVA und den DLA mit dem Speicher verbindet (z. B. unter Verwenden des APB).
Das Netzwerk für Computer Vision auf dem Chip kann eine Schnittstelle umfassen, die vor der Übertragung von Steuersignalen/Adressen/Daten bestimmt, dass sowohl der PVA als auch der DLA einsatzbereite und gültige Signale liefern. Eine solche Schnittstelle kann sowohl separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten als auch eine Burst-Kommunikation für die kontinuierliche Datenübertragung vorsehen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, obwohl auch andere Normen und Protokolle verwendet werden können.
In einigen Beispielen kann der/die SoC(s) 404 einen Echtzeit-Raytracing-Hardwarebeschleuniger umfassen, wie er in der US-Patentanmeldung Nr. 16/101.232 , eingereicht am 4. August 2018, beschrieben ist. Der Echtzeit-Raytracing-Hardwarebeschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeit-Visualisierungssimulationen zu erzeugen, zur RADAR-Signal-Interpretation, zur Schallausbreitungssynthese und/oder -analyse, zur Simulation von SONAR-Systemen, zur allgemeinen Wellenausbreitungssimulation, zum Vergleich mit LIDAR-Daten zum Zwecke der Lokalisierung und/oder anderen Funktionen und/oder für andere Verwendungen. In einigen Ausführungsbeispielen können eine oder mehr Baum-Traversierungseinheiten (tree traversal units, TTUs) zum Ausführen einer oder mehreren Raytracing zugehörigen Operationen verwendet werden.
Der/die Beschleuniger 414 (z. B. der Hardware-Beschleuniger-Cluster) haben ein breites Array an Verwendungen für das autonome Fahren. Der PVA kann ein programmierbarer Visions-Beschleuniger sein, der für Schlüssel-Verarbeitungsstufen in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten des PVA passen gut zu algorithmischen Domänen, die eine vorhersagbare Verarbeitung bei geringer Leistung und niedriger Latenz benötigen. Mit anderen Worten: Der PVA eignet sich gut für halbdichte oder dichte reguläre Berechnungen, selbst bei kleinen Datensätzen, die vorhersagbare Laufzeiten mit geringer Latenz und geringe Leistung benötigen. Daher sind, im Kontext von Plattformen für autonome Fahrzeuge, die PVAs für die Ausführung klassischer Algorithmen für Computer Vision konzipiert, da sie effizient bei der Objekterkennung sind und mit ganzzahliger Mathematik arbeiten.
Zum Beispiel, gemäß einem Ausführungsbeispiel der Technologie, wird der PVA verwendet, um Computer-Stereo-Vision auszuführen. Ein semiglobaler auf Matching basierter Algorithmus kann in einigen Beispielen verwendet werden, obwohl dies nicht als einschränkend gedacht ist. Viele Anwendungen für Level 3-5 autonomes Fahren benötigen fliegendes Bewegungsschätzen/Stereo-Matching (z. B. Struktur von Bewegung, Fußgängererkennung, Spurdetektion, usw.). Der PVA kann eine Computer-Stereo-Vision-Funktion auf Eingaben von zwei monokularen Kameras durchführen.
In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Zum Beispiel kann der PVA verwendet werden, um Roh-RADAR-Daten zu verarbeiten (z. B. unter Verwenden einer 4D Fast Fourier Transformation), um ein verarbeitetes RADAR-Signal zu liefern, bevor der nächste RADAR-Puls emittiert wird. In anderen Beispielen wird der PVA für Laufzeit-Depth-Prozessieren verwendet, indem Roh-Laufzeitdaten verarbeitet werden, um verarbeitete Daten der Laufzeit bereitzustellen, zum Beispiel.
Der DLA kann verwendet werden, um jede Art von Netzwerk zu betreiben, um die Steuerung und die Fahrsicherheit zu verbessern, einschließlich z. B. eines neuronalen Netzwerks, das ein Maß für die Konfidenz für jede Objekterkennung ausgibt. Ein solcher Konfidenzwert kann als Wahrscheinlichkeit interpretiert werden oder als Bereitstellen eines relativen „Gewichts“ jeder Erkennung im Vergleich zu anderen Erkennungen. Dieser Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen eher als echt positive Erkennungen als als falsch positive Erkennungen betrachtet werden sollten. Zum Beispiel kann das System einen Schwellwert für die Konfidenz festlegen und nur die Erkennungen, die den Schwellenwert überschreiten, als echt positive Erkennungen betrachten. In einem automatischen Notbremssystem (AEB) würden falsch positive Erkennungen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was offensichtlich unerwünscht ist. Daher sollten nur die zuverlässigsten Erkennungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netz zur Regression des Konfidenzwertes verwenden. Das neuronale Netzwerk kann als Eingabe mindestens eine Teilmenge von Parametern verwenden, wie z. B. die Abmessungen der Bounding Box, die (z. B. von einem anderen Teilsystem) erhaltene Abschätzung der Bodenebene, die Ausgabe des Trägheitsmesseinheit-Sensors (IMU) 466, die mit der Orientierung des Fahrzeugs 400 korreliert, die Entfernung, die 3D-Positionsschätzungen des Objekts, die vom neuronalen Netzwerk und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 464 oder RADAR-Sensor(en) 460) erhalten werden, unter anderen.
Der/die SoC(s) 404 kann/können Datenspeicher 416 (z. B. ein Memory) umfassen. Der/die Datenspeicher 416 können On-Chip-Speicher des/der SoC(s) 404 sein, die neuronale Netzwerke speichern können, die auf der GPU und/oder dem DLA auszuführen sind. In einigen Beispielen kann die Kapazität des/der Datenspeicher(s) 416 groß genug sein, um mehrere Instanzen von neuronalen Netzen zur Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 416 kann/können L2 oder L3 Cache(s) 412 umfassen. Der Verweis auf den/die Datenspeicher 416 kann den Verweis auf den Speicher einschließen, der mit dem PVA, DLA und/oder anderen Beschleunigern 414 assoziiert ist, wie hier beschrieben.
Der/die SoC(s) 404 kann/können einen oder mehr Prozessor(en) 410 (z. B. eingebettete Prozessoren) umfassen. Der/die Prozessor(en) 410 kann/können einen Boot- und Leistungsverwaltungsprozessor umfassen, der ein dedizierter Prozessor und ein Subsystem sein kann, um die Boot-Leistung- und - Verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Leistungsverwaltungsprozessor kann ein Teil der Boot-Sequenz des/der SoC(s) 404 sein und kann Laufzeit-Leistungsverwaltungsdienste bereitstellen. Der Boot-Leistungsversorgungs- und -Verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Systemübergängen mit niedrigem Leistungszustand, Verwaltung von thermischen und Temperatursensoren von SoC(s) 404, und/oder Verwaltung der Leistungszustände von SoC(s) 404 bieten. Jeder Temperatursensor kann als ein Ringoszillator implementiert sein, dessen Ausgabefrequenz proportional zur Temperatur ist, und der/die SoC(s) 404 kann/können die Ringoszillatoren verwenden, um Temperaturen der CPU(s) 406, GPU(s) 408 und/oder des/der Beschleuniger(s) 414 zu erkennen. Wenn bestimmt wird, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Leistungsverwaltungsprozessor in eine Temperaturfehlerroutine eintreten und den/die SoC(s) 404 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 400 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen (z. B. das Fahrzeug 400 zu einem sicheren Halt bringen).
Der/die Prozessor(en) 410 kann/können weiter einen Satz von eingebetteten Prozessoren umfassen, die als Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audio-Subsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen und eine breite und flexible Palette von Audio-E/A-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
Der/die Prozessor(en) 410 kann/können weiter eine „always on“-Prozessor-Engine umfassen, die die notwendigen Hardware-Features zur Unterstützung von Niedrig-Leistungs-Sensormanagement- und von Aufweck-Anwendungsfällen bereitstellen kann. Die „always on“-Prozessor-Engine kann einen Prozessorkern, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z. B. Timer und Interrupt-Controller), verschiedene I/O-Controller-Peripheriegeräte und eine Weiterleitungslogik umfassen.
Der/die Prozessor(en) 410 kann/können weiter eine Sicherheits-Cluster-Engine umfassen, die ein dediziertes Prozessor-Subsystem umfasst, um das Sicherheitsmanagement von Automobilanwendungen handzuhaben. Die Sicherheits-Cluster-Engine kann zwei oder mehr Prozessorkerne, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z. B. Timer, eine Interrupt-Steuerung usw.) und/oder Routing-Logik umfassen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Lockstep-Modus arbeiten und als ein einziger Kern mit Vergleichslogik funktionieren, um jedwede Unterschiede zwischen ihren Operationen zu erkennen.
Der/die Prozessor(en) 410 kann/können ferner eine Realtime-Kamera-Engine umfassen, die ein dediziertes Prozessor-Subsystem für das Handhaben von Realtime-Kamera-Management umfassen kann.
Der/die Prozessor(en) 410 kann/können ferner einen High-Dynamic-Range-Signalprozessor umfassen, der einen Bildsignalprozessor umfassen kann, der eine Hardware-Engine ist, die Teil der Kamera-Verarbeitungs-Pipeline ist.
Der/die Prozessor(en) 410 kann/können einen Videobildkompositor umfassen, bei dem es sich um einen Verarbeitungsblock (z. B. auf einem Mikroprozessor implementiert) handeln kann, der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das finale Bild für das Abspielfenster zu erzeugen. Der Videobildkompositor kann eine Linsenverzerrungskorrektur an der/den Weitwinkelkamera(s) 470, an der/den Surround-Kamera(s) 474 und/oder an kabineninternen Überwachungskamerasensoren durchführen. Ein kabineninterner Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netzwerk überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein kabineninternes System kann Lippenlesen durchführen, um Autotelefondienste zu aktivieren und einen Telefonanruf zu tätigen, Emails zu diktieren, das Fahrzeugziel zu ändern, das Infotainmentsystem des Fahrzeugs zu aktivieren oder zu ändern und seine Einstellungen zu ändern, oder um stimmenaktiviertes Netzsurfen bereitzustellen. Bestimmte Funktionen sind für den Fahrer nur verfügbar, wenn das Fahrzeug in einem autonomen Modus operiert, und sind sonst gesperrt.
Der Videobildkompositor kann eine verbesserte temporale Rauschunterdrückung sowohl für räumliche als auch temporale Rauschunterdrückung umfassen. Zum Beispiel, wenn in einem Video Bewegung auftritt, gewichtet die Rauschreduktion die Informationen angemessen, verringert das Gewicht von Informationen, die von benachbarten Frames bereitgestellt werden. Wenn ein Bild oder ein Teil eines Bildes keine Bewegung umfasst, kann die temporale Rauschunterdrückung, die vom Videobildkompositor durchgeführt wird, Informationen vom vorherigen Bild verwenden, um Rauschen im aktuellen Bild zu reduzieren.
Der Videobildkompositor kann auch so konfiguriert sein, dass er eine Stereobildentzerrung an Eingabe-Frames der Stereolinse durchführt. Der Videobildkompositor kann weiter für die Komposition der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 408 nicht benötigt wird, um ständig neue Oberflächen zu rendern. Selbst wenn die GPU(s) 408 eingeschaltet ist und aktiv 3D-Rendering durchführt, kann der Videobildkompositor verwendet werden, um die GPU(s) 408 zu entlasten, um die Performance und Reaktionsfähigkeit zu verbessern.
Der/die SoC(s) 404 kann/können weiterhin eine Mobile-Industry-Processor-Interface (MIPI)-Kamera-serielle-Schnittstelle zum Empfang von Video und Eingabe von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock umfassen, was für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Der/die SoC(s) 404 kann/können weiter eine Eingabe/Ausgabe-Steuerung(en) umfassen, die per Software gesteuert werden kann/können und für den Empfang von E/A-Signalen verwendet werden kann, die keiner bestimmten Rolle zugeordnet sind. Der/die SoC(s) 404 kann/können weiter eine Vielzahl von Peripherieschnittstellen umfassen, um die Kommunikation mit Peripheriegeräten, Audiocodecs, Leistungsverwaltung und/oder anderen Geräten zu ermöglichen. Der/die SoC(s) 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. Der/die SoC(s) 404 kann/können weiter dedizierte Hochleistungs-Massenspeicher-Steuerungen umfassen, die ihre eigenen DMA-Engines umfassen können und die verwendet werden können, um die CPU(s) 406 von routinemäßigen Datenverwaltungsaufgaben zu befreien.
Der/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 einsetzt und effizient nutzt für Diversität und Redundanz, und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack bereitstellt zusammen mit Deep Learning-Hilfsmitteln. Der/die SoC(s) 404 kann/können schneller, zuverlässiger und sogar energie- und platzeffizienter sein als herkömmliche Systeme. Zum Beispiel kann/können der/die Beschleuniger 414, wenn kombiniert mit der/den CPU(s) 406, der/den GPU(s) 408 und dem/den Datenspeicher(n) 416 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Level 3-5 bilden.
Die Technologie stellt daher Fähigkeiten und Funktionalität bereit, welche nicht durch konventionelle Systeme erlangt werden können. Zum Beispiel können Computer Vision Algorithmen auf CPUs ausgeführt werden, die unter Verwenden einer High-Level Programmiersprachen wie die C Programmiersprache konfiguriert sein können, um eine breite Vielfalt von Prozessieralgorithmen über eine breite Vielfalt von visuellen Daten auszuführen. Jedoch sind CPUs oft unfähig, die Performanceansprüche von vielen Computer Vision Anwendungen zu erfüllen, wie die, die mit Ausführzeit und Leistungsverbrauch in Beziehung stehen, zum Beispiel. Insbesondere sind viele CPUs unfähig komplexe Objektdetektionsalgorithmen in Realtime auszuführen, was ein Erfordernis von fahrzeuginternen ADAS-Anwendungen und ein Erfordernis für autonome Fahrzeuge von praktisch Level 3-5 ist.
Im Gegensatz zu konventionellen Systemen erlaubt, mittels Bereitstellens eines CPU-Komplexes, GPU-Komplexes und eines Hardwarebeschleunigungs-Clusters, die hierin beschriebene Technologie, dass mehrere neuronale Netzwerke simultan und/oder sequentiell betrieben werden und dass die Ergebnisse miteinander kombiniert werden, um Level 3-5 autonomes Fahren Funktionalität zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder dGPU (z. B. die GPU(s) 420) ausgeführt wird, eine Text- und Worterkennung umfassen, was es dem Supercomputer erlaubt, Verkehrsschilder zu lesen und zu verstehen, einschließlich Zeichen für die das neuronale Netzwerk nicht spezifisch trainiert wurde. Der DLA kann ferner ein neuronales Netzwerk umfassen, das fähig ist, das Schild zu identifizieren, zu interpretieren und semantisches Verständnis bereitzustellen und das semantische Verständnis an die Wegplanungsmodule, die auf dem CPU-Komplex laufen, weiterzugeben.
Als ein anderes Beispiel können mehrere neuronale Netzwerke simultan laufen, wie dies für Level 3, 4 oder 5 Fahren erforderlich ist. Zum Beispiel kann ein Warnschild, welches aus „Achtung: Blinkende Lichter zeigen Eisbedingungen an“ zusammen mit einem elektrischen Licht besteht, unabhängig oder kollektiv mittels mehrerer neuronaler Netzwerke interpretiert werden. Das Zeichen selbst kann mittels eines ersten eingesetzten neuronalen Netzwerkes (z. B. ein neuronales Netzwerk, das trainiert wurde) als ein Verkehrsschild identifiziert werden, der Text „Blinkende Lichter zeigen Eisbedingungen an“ kann mittels eines zweiten eingesetzten neuronalen Netzwerks interpretiert werden, das die Wegplanungssoftware (vorzugsweise auf dem CPU-Komplex ausgeführt) des Fahrzeugs informiert, dass, wenn blinkende Lichter detektiert werden, Eisbedingungen vorhanden sind. Das blinkende Licht kann mittels Betreibens eines dritten eingesetzten neuronalen Netzwerks über mehrere Frames identifiziert werden, was die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Abwesenheit) von blinkenden Lichtern informiert. Alle drei neuronalen Netzwerke können gleichzeitig laufen, zum Beispiel innerhalb des DLA und/oder des/der GPU(s) 408.
In einigen Ausführungsbeispielen, kann ein CNN für Gesichtserkennung und Fahrzeugbesitzeridentifikation Daten von Kamerasensoren verwenden, um die Präsenz eines autorisierten Fahrers und/oder Besitzer des Fahrzeugs 400 zu identifizieren. Die „always-on“-Sensor-Prozessier-Engine kann verwendet werden, das Fahrzeug aufzuschließen, wenn sich der Besitzer der Fahrertür nähert, und die Lichter anzuschalten, und, im Sicherheitsmodus, das Fahrzeug zu sperren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgt/sorgen der/die SoC(s) 404 für Schutz gegen Diebstahl und/oder Carjacking.
In einem anderen Beispiel kann ein CNN für eine Notfallfahrzeug-Detektion und Identifikation Daten von Mikrophonen 496 verwenden, um Notfallfahrzeug-Sirenen zu detektieren und identifizieren. Im Gegensatz zu konventionellen Systemen, die generelle Klassifizierer verwenden, um Sirenen zu detektieren, und manuell Features extrahieren, verwendet/verwenden der/die SoC(s) 404 das CNN zum Klassifizieren sowohl von Umgebungs- und Stadtgeräuschen als auch zum Klassifizieren von visuellen Daten. In einem bevorzugten Ausführungsbeispiel ist das CNN, das auf dem DLA läuft, trainiert, um die relative Annäherungsgeschwindigkeit des Notfallfahrzeugs (z. B. unter Verwenden des Dopplereffekts) zu identifizieren. Das CNN kann auch trainiert sein, um Notfallfahrzeuge spezifisch für die lokale Gegend, in der das Fahrzeug operiert, wie mittels des/der GNSS Sensoren 458 identifiziert, zu identifizieren. Daher wird, zum Beispiel, wenn es in Europa operiert, das CNN versuchen, europäische Sirenen zu detektieren, und wenn es in den Vereinigten Staaten ist, wird das CNN versuchen, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Notfallfahrzeug detektiert wird, kann ein Steuerprogramm verwendet werden, um eine Notfallfahrzeug-Sicherheitsroutine auszuführen, abbremsen des Fahrzeugs, auf die Seite der Straße fahren, parken des Fahrzeugs und/oder das Fahrzeug im Leerlauf laufen lassen, unter Assistenz von Ultraschallsensoren 462 bis das/die Notfallfahrzeug(e) vorbei sind.
Das Fahrzeug kann eine CPU(s) 418 (z. B. diskrete CPU(s) oder dCPU(s)) umfassen, die an die SoC(s) 404 mittels eines Hochgeschwindigkeits-Interconnects (z. B. PCle) gekoppelt ist. Die CPU(s) 418 kann/können zum Beispiel einen X86 Prozessor umfassen. Die CPU(s) 418 kann/können verwendet werden, um jede von einer Vielfalt an Funktionen durchzuführen, einschließlich Vermitteln bei potentiell inkonsistenten Ergebnissen zwischen ADAS Sensoren und der/den SoC(s) 404 und/oder Überwachen des Status und Gesundheit der Steuerung(en) 436 und/oder der Infotainment-SoC 430, zum Beispiel.
Das Fahrzeug 400 kann eine GPU(s) 420 (z. B. diskrete GPU(s) oder dGPU(s)) umfassen, die an die SoC(s) 404 mittels eines Hochgeschwindigkeits-Interconnects (z. B. NVLINK von NVIDIA)) gekoppelt sein kann. Die GPU(s) 420 kann/können zusätzliche künstliche-Intelligenz-Funktionalität, wie zum Beispiel mittels Ausführens redundanter und/oder unterschiedlicher neuronaler Netzwerke, bereitstellen und kann/können verwendet werden, um neuronale Netzwerke, basierend auf Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 400, zu trainieren und/oder upzudaten.
Das Fahrzeug 400 kann weiterhin die Netzwerkschnittstelle 424 umfassen, die eine oder mehrere drahtlose Antennen 426 umfassen 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 Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Rechengeräten (z. B. Client-Geräten von Fahrgästen) zu ermöglichen. Um mit anderen Fahrzeugen zu kommunizieren, kann eine direkte Verbindung zwischen den beiden Fahrzeugen hergestellt werden und/oder es kann eine indirekte Verbindung (z. B. über Netzwerke und das Internet) hergestellt werden. 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 Geschwindigkeitsregelungsfunktionalität des Fahrzeugs 400 sein.
Die Netzwerkschnittstelle 424 kann eine SoC umfassen, die Modulations- und Demodulationsfunktionalität bereitstellt und der/den Steuerung(en) 436 ermöglicht/ermöglichen, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 424 kann ein Funkfrequenz-Frontend für die Aufwärtskonvertierung vom Basisband auf Funkfrequenz und die Abwärtskonvertierung von Funkfrequenz auf Basisband umfassen. Die Frequenzumwandlungen können durch bekannte Verfahren durchgeführt werden und/oder können mit Super-Heterodyn-Verfahren durchgeführt werden. In einigen Beispielen kann die Funktionalität des Hochfrequenz-Frontend durch einen separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann drahtlose Funktionalität zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle umfassen. Das Fahrzeug 400 kann weiter einen oder mehrere Datenspeicher 428 umfassen, die einen Speicher außerhalb des Chips (z. B. außerhalb der SoC(s) 404) umfassen können. Der/die Datenspeicher 428 kann/können ein oder mehrere Speicherelemente umfassen, einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte, die mindestens ein Datenbit speichern können.
Das Fahrzeug 400 kann weiterhin GNSS-Sensor(en) 458 umfassen (z. B. GPS- und/oder unterstützte GPS-Sensoren), um die Funktionen Kartierung, Wahrnehmung, Erzeugung von Belegungsrastern und/oder Pfadplanung zu unterstützen. Es kann eine beliebige Anzahl von GNSS-Sensor(en) 458 verwendet werden, die z. B. und ohne Einschränkung ein GPS umfassen, das einen USB-Anschluss mit einer Ethernet-zu-Seriell (RS-232)-Brücke verwendet. Das Fahrzeug 400 kann weiterhin RADAR-Sensor(en) 460 umfassen. Der/die RADAR-Sensor(en) 460 kann/können vom Fahrzeug 400 zur Lang-Reichweiten-Fahrzeugdetektion verwendet werden, auch bei Dunkelheit und/oder schlechten Wetterbedingungen. Die funktionalen RADAR-Sicherheitsstufen können ASIL B sein. Der/die RADAR-Sensor(en) 460 kann/können den CAN und/oder den Bus 402 (z. B. zur Übertragung von dem/den RADAR-Sensor(en) 460 erzeugten Daten), zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, mit Zugriff auf Ethernet, um auf Rohdaten zuzugreifen, in einigen Beispielen. Es kann eine Vielzahl von RADAR-Sensortypen verwendet werden. Beispielsweise und ohne Einschränkung kann der/die RADAR-Sensor(en) 460 für die Verwendung als Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen wird/werden Puls-Doppler-RADAR-Sensor(en) verwendet.
Der/die RADAR-Sensor(en) 460 kann/können verschiedene Konfigurationen umfassen, wie z. B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit weitem Sichtfeld, seitliche Abdeckung kurzer Reichweite, usw. In einigen Beispielen kann RADAR mit großer Reichweite für die adaptive Geschwindigkeitsregelungsfunktionalität verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein weites Sichtfeld bieten, das durch zwei oder mehr unabhängige Scans realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 460 kann/können bei der Unterscheidung zwischen statischen und sich bewegenden Objekten helfen und kann/können von ADAS-Systemen für Notbremsassistenten und Vorwärtskollisionswarnungen verwendet werden. Langstrecken-RADAR-Sensoren können monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle umfassen. In einem Beispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Strahlenmuster erzeugen, das so gestaltet ist, dass es die Umgebung des Fahrzeugs mit höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den angrenzenden Fahrspuren erfasst. Die beiden anderen Antennen können das Sichtfeld erweitern, so dass Fahrzeuge, die in die Fahrspur des Fahrzeugs 400 einfahren oder diese verlassen, schnell erkannt werden können.
RADAR-Systeme mit mittlerer Reichweite können z. B. eine Reichweite von bis zu 460 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 450 Grad (hinten) umfassen. RADAR-Systeme mit kurzer Reichweite können, ohne Einschränkung, RADAR-Sensoren umfassen, die für die Installation an beiden Enden des hinteren Stoßfängers ausgelegt sind. Wenn ein solches RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers installiert ist, kann es zwei Strahlen erzeugen, die ständig den toten Winkel im hinteren Bereich und nahe dem Fahrzeug überwachen.
RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Toter-Winkel-Detektion und/oder als Spurwechselassistent verwendet werden.
Das Fahrzeug 400 kann weiterhin Ultraschallsensor(en) 462 umfassen. Der/die Ultraschallsensor(en) 462, der/die an der Vorderseite, an der Rückseite und/oder an 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 große Vielzahl von Ultraschallsensoren 462 verwendet werden, und es können unterschiedliche Ultraschallsensoren 462 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 LIDAR-Sensor(en) 464 umfassen. 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 funktionale Sicherheitsstufe ASIL B sein. In einigen Beispielen kann das Fahrzeug 400 mehrere LIDAR-Sensoren 464 umfassen (z. B. zwei, vier, sechs, usw.), die Ethernet verwenden können (z. B. um Daten an einen Gigabit-Ethernet-Switch zu liefern).
In einigen Beispielen kann/können der/die LIDAR-Sensor(en) 464 in der Lage sein, eine Liste von Objekten und deren Abstände für ein 360-Grad-Sichtfeld zu liefern. Kommerziell erhältliche(r) LIDAR-Sensor(en) 464 kann/können eine bekanntgemachte Reichweite von ca. 100 m haben, mit einer Genauigkeit von 2 cm-3 cm und mit Unterstützung für eine 100 Mbps Ethernet-Verbindung, zum Beispiel. In einigen Beispielen kann/können ein oder mehrere nicht vorspringende LIDAR-Sensoren 464 verwendet werden. In solchen Beispielen kann der/die LIDAR-Sensor(en) 464 als kleines Gerät implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 400 eingebettet werden kann. Der/die LIDAR-Sensor(en) 464 kann/können in solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von 35 Grad bieten, mit einer Reichweite von 200 m selbst für Objekte mit geringer Reflektivität. Frontmontierte(r) LIDAR-Sensor(en) 464 kann/können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert werden.
In einigen Beispielen können auch LIDAR-Technologien, wie 3D-Blitz-LIDAR, verwendet werden. 3D-Blitz-LIDAR verwendet einen Laserblitz als Sendequelle, um die Fahrzeugumgebung bis zu einer Entfernung von ca. 200 m zu beleuchten. Eine Blitz-LIDAR-Einheit umfasst einen Rezeptor, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum dem Bereich vom Fahrzeug zu den Objekten entspricht. Blitz-LIDAR kann erlauben mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebungen zu erzeugen. In einigen Beispielen können vier Blitz-LIDAR Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 400. Erhältliche 3D-Blitz-LIDAR Systeme umfassen eine Festkörper 3D-starrendes-Array-LIDAR-Kamera mit keinen beweglichen Teilen außer einem Lüfter (z. B. eine nicht scannende LIDAR-Vorrichtung). Die Blitz-LIDAR-Vorrichtung kann einen fünf Nanosekunden Klasse I (augensicheren) Laserpuls je Frame verwenden und kann das reflektierte Laserlicht in der Form von 3D Reichweitenpunkte-Wolken und mitregistrierten Intensitätsdaten aufnehmen. Durch Verwenden von Blitz-LIDAR, und weil Blitz-LIDAR eine Festkörper-Vorrichtung ohne bewegliche Teile ist, kann/können der/die LIDAR Sensor(en) 464 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Erschütterungen sein.
Das Fahrzeug kann weiterhin IMU-Sensor(en) 466 umfassen. Der/die IMU-Sensor(en) 466 kann/können in 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 umfassen. In einigen Beispielen, wie z. B. bei sechsachsigen Anwendungen, können der/die IMU-Sensor(en) 466 Beschleunigungsmesser und Gyroskope umfassen, während bei neunachsigen Anwendungen der/die IMU-Sensor(en) 466 Beschleunigungsmesser, Gyroskope und Magnetometer umfassen können.
In einigen Ausführungsbeispielen 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 Abschätzungen von Position, Geschwindigkeit und Lage zu liefern. Als solches kann/können in einigen Beispielen der/die IMU-Sensor(en) 466 das Fahrzeug 400 in die Lage versetzen, den Kurs abzuschätzen, ohne dass eine Eingabe von einem Magnetsensor erforderlich ist, mittels direkten Beobachtens und Korrelierens der Änderungen in Geschwindigkeit vom GPS mit dem/den IMU-Sensor(en) 466. In einigen Beispielen können der/die IMU-Sensor(en) 466 und der/die GNSS-Sensor(en) 458 in einer einzigen integrierten Einheit kombiniert werden. Das Fahrzeug kann Mikrofon(e) 496 umfassen, die im und/oder um das Fahrzeug 400 herum angebracht sind. Das/die Mikrofon(e) 496 kann/können u. a. zum Detektieren und Identifizieren von Notfallfahrzeugen verwendet werden.
Das Fahrzeug kann weiterhin eine beliebige Anzahl von Kameratypen umfassen, die Stereokamera(s) 468, Weitwinkelkamera(s) 470, Infrarotkamera(s) 472, Umgebungskamera(s) 474, Fern- und/oder Mittelbereichskamera(s) 498 und/oder andere Kameratypen einschließen. Die Kameras können zur Erfassung von Bilddaten rund um einen gesamten Umfang des Fahrzeugs 400 verwendet werden. Die verwendeten Kameratypen hängen von den Ausführungsbeispielen und Anforderungen für 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ührungsbeispiel unterschiedlich sein. Das Fahrzeug kann z. B. sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras umfassen. Die Kameras können, als Beispiel und ohne Einschränkung, Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kamera(s) wird hierin mit Bezug auf 4A und 4B detaillierter beschrieben.
Das Fahrzeug 400 kann weiterhin den/die Vibrationssensor(en) 442 umfassen. 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. In 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 Fahrbahnoberfläche zu bestimmen (z. B. wenn der Unterschied in der Vibration zwischen einer angetriebenen Achse und einer frei rotierenden Achse besteht).
Das Fahrzeug 400 kann ein ADAS-System 438 umfassen. Das ADAS-System 438 kann in einigen Beispielen eine SoC umfassen. Das ADAS-System 438 kann eine autonome/adaptive/automatische Geschwindigkeitsreglung (ACC), eine kooperative adaptive Geschwindigkeitsreglung (CACC), eine Auffahrwarnung (FCW), eine automatische Notbremsung (AEB), Spurverlassenswarnungen (LDW), einen Spurhalteassistenten (LKA), einen Toter-Winkel-Warner (BSW), einen rückwärtigen-Querverkehrswarner (rear cross-traffic warning, RCTW), ein Kollisionswarnsystem (CWS), eine Spurenzentrierung (LC) und/oder andere Features und Funktionalitäten umfassen.
Die ACC-Systeme können RADAR-Sensor(en) 460, LIDAR-Sensor(en) 464 und/oder eine Kamera(s) verwenden. Die ACC-Systeme können Längs-ACC und/oder Quer-ACC umfassen. Der Längs-ACC überwacht und regelt den Abstand zum unmittelbar vorausfahrenden Fahrzeug 400 und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Der Quer-ACC führt die Abstandshaltung durch und empfiehlt dem Fahrzeug 400, die Spur zu wechseln, wenn dies erforderlich ist. Quer-ACC ist mit anderen ADAS-Anwendungen wie LC und CWS verwandt.
CACC nutzt Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 424 und/oder die Funkantenne(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 (V2V)-Kommunikationsverbindung bereitgestellt werden, während indirekte Verbindungen eine Infrastruktur-zu-Fahrzeug (12V)-Kommunikationsverbindung sein können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Informationen über die unmittelbar vorhergehenden Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem Fahrzeug 400 und auf derselben Spur wie dieses befinden), während das 12V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr liefert. CACC-Systeme können entweder irgendeine der beiden oder beide 12V- und V2V-Informationsquellen umfassen. Aufgrund der Informationen über die Fahrzeuge vor dem Fahrzeug 400 kann CACC zuverlässiger sein und es hat das Potenzial, den Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
FCW-Systeme sind so konstruiert, dass sie den Fahrer vor einer Gefahr warnen, so dass er eine korrigierende Handlung vornehmen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 460, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung ausgeben, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
AEB-Systeme detektieren eine drohende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines spezifizierten Zeit- oder Abstandsparameters korrigierend eingreift. AEB-Systeme können nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 460 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr detektiert, warnt es typischerweise zuerst den Fahrer, damit er eine korrigierende Maßnahme ergreift, um die Kollision zu vermeiden, und wenn der Fahrer keine korrigierende Maßnahme ergreift, kann das AEB-System automatisch die Bremsen betätigen, in einem Versuch die Auswirkungen der vorhergesagten Kollision zu verhindern oder zumindest abzuschwächen. AEB-Systeme können Techniken wie eine dynamische Bremsunterstützung und/oder eine Bremsung bei bevorstehenden Unfall umfassen.
LDW Systeme stellen optische, hörbare und/oder taktile Warnungen, wie zum Beispiel Lenkrad- oder Sitzvibrationen, bereit, um den Fahrer zu alarmieren, wenn das Fahrzeug 400 Spurmarkierungen überfährt. Ein LDW System aktiviert nicht, wenn der Fahrer mittels Aktivierens des Blinkers ein absichtliches Spurverlassen anzeigt. LDW Systeme können zur Vorderseite gerichtete Kameras verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
LKA Systeme sind eine Abwandlung von LDW Systemen. LKA Systeme stellen eine Lenkeingabe oder Bremsen bereit, um das Fahrzeug 400 zu korrigieren, wenn das Fahrzeug beginnt, die Spur zu verlassen. BSW Systeme detektieren und warnen den Fahrer vor Fahrzeugen im toten Winkel eines Fahrzeugs. BSW Systeme können optische, hörbare und/oder taktile Warnungen bereitstellen, um anzuzeigen, dass ein Zusammenführen oder Wechseln von Spuren unsicher ist. Das System kann eine zusätzliche Warnung bereitstellen, wenn der Fahrer einen Blinker verwendet. BSW Systeme können zur Rückseite gerichtete Kameras und/oder RADAR Sensor(en) 460 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
RCTW Systeme können optische, hörbare und/oder taktile Benachrichtigungen bereitstellen, wenn ein Objekt außerhalb des Rückkamerabereichs detektiert wird, wenn das Fahrzeug 400 rückwärts fährt. Einige RCTW Systeme umfassen AEB, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. RCTW Systeme können ein oder mehrere rückwärts gerichtete RADAR Sensor(en) 460 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
Herkömmliche ADAS Systeme können anfällig für falsch positive Ergebnisse sein, was ärgerlich und störend für einen Fahrer sein kann, aber typischerweise nicht katastrophal ist, weil ADAS Systeme den Fahrer alarmieren und dem Fahrer erlauben, zu entscheiden, ob eine Sicherheitskondition wirklich vorhanden ist und entsprechend zu handeln. Jedoch muss in einem autonomen Fahrzeug 400 das Fahrzeug 400 selber, im Falle von widersprüchlichen Ergebnissen, entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. einer ersten Steuerung 436 oder einer zweiten Steuerung 436) beachtet. Zum Beispiel kann in einigen Ausführungsbeispielen das ADAS System 438 ein Backup und/oder sekundärer Computer zum Bereitstellen von Wahrnehmungsinformation an ein Backup-Computer Rationalitäts-Modul (rationality module) sein. Auf dem Backup-Computer Rationalitäts-Monitor kann eine redundante diversitäre Software auf Hardwarekomponenten laufen, um Fehler in der Wahrnehmung und dynamischen Fahraufgaben zu detektieren. Ausgaben des ADAS System 438 können einer überwachenden MCU bereitgestellt werden. Wenn Ausgaben des primären Computers und des sekundären Computers in Konflikt sind, muss die überwachende MCU entscheiden, wie der Konflikt beizulegen ist, um sichere Operation zu gewährleisten.
In einigen Ausführungsbeispielen kann der primäre Computer konfiguriert sein, der überwachenden MCU einen Konfidenzwert bereitzustellen, der die Konfidenz des primären Computers in das gewählte Ergebnis anzeigt. Wenn der Konfidenzwert einen Schwellwert überschreitet, kann die überwachende MCU der Richtung des primären Computers folgen, unabhängig ob der sekundäre Computer ein widersprechendes oder inkonsistentes Ergebnis bereitstellt. Wo der Konfidenzwert nicht den Schwellwert erfüllt, und wo der primäre Computer und der sekundäre Computer unterschiedliche Ergebnisse liefern (z. B. der Konflikt), kann das überwachende MCU zwischen den Computern vermitteln, um die adäquate Folge zu bestimmen.
Die überwachende MCU kann konfiguriert sein, ein neuronales Netzwerk(e) auszuführen, das trainiert und konfiguriert ist, um, basierend auf Ausgaben vom primären Computer und vom sekundären Computer, Bedingungen, unter denen der sekundäre Computer Fehlalarme bereitstellt, zu bestimmen. Daher kann das/die neuronalen Netzwerk(e) in der überwachenden MCU lernen, wann der Ausgabe des sekundären Computers vertraut werden kann und wann nicht. Zum Beispiel kann, wenn der sekundäre Computer ein RADAR-basiertes FCW System ist, ein neuronales Netzwerk(e) in der überwachenden MCU lernen, wann das FCW System metallische Objekte identifiziert, die tatsächlich keine Gefahren sind, wie ein Ablaufgitter oder ein Gullydeckel, die einen Alarm triggern. Ähnlich kann, wenn der sekundäre Computer ein kamerabasiertes LDW System ist, ein neuronales Netzwerk in der überwachenden MCU lernen, sich über das LDW hinwegzusetzen, wenn Fahrradfahrer oder Fußgänger anwesend sind und ein Spurwechseln tatsächlich das sicherste Manöver ist. In Ausführungsbeispielen die ein Laufenlassen von (einem) neuronalen Netzwerk(en) auf der überwachenden MCU umfassen, kann die überwachende MCU zumindest eines von einem DLA oder GPU, geeignet zum Laufenlassen des/der neuronalen Netzwerk(e), mit assoziierten Speicher, umfassen. In bevorzugten Ausführungsbeispielen, kann die überwachende MCU eine Komponente der SoC(s) 404 aufweisen und/oder als eine Komponente der SoC(s) 404 eingefügt sein.
In anderen Beispielen kann das ADAS System 438 einen sekundären Computer umfassen, der ADAS Funktionalität durchführt, unter Verwenden von traditionellen Regeln von Computer Vision. Als solches kann der sekundäre Computer klassische Computer Visionsregeln (if-then) verwenden und das Vorhandensein eines neuronalen Netzwerks/e in der überwachenden MCU kann die Zuverlässigkeit, Sicherheit und Performance verbessern. Zum Beispiel macht die verschiedenartige Implementierung und die beabsichtigte Nicht-Gleichheit das Gesamtsystem fehlertoleranter insbesondere gegenüber Fehlern durch Software (oder Software-Hardware-Schnittstelle)-Funktionalität. Zum Beispiel kann, wenn es einen Softwarebug oder Fehler in der Software, die auf dem primären Computer läuft, gibt, und der Nicht-Gleiche Softwarecode, der auf dem sekundären Computer läuft, stellt das gleiche Gesamtergebnis bereit, die überwachende MCU größeres Vertrauen haben, dass das Gesamtergebnis korrekt ist und der Bug in der Software oder Hardware, die durch den primären Computer verwendet wird, verursacht keinen materiellen Fehler.
In einigen Beispielen kann die Ausgabe des ADAS Systems 438 in den Wahrnehmungsblock (perception block) des primären Computers und/oder den dynamischen Fahr-Aufgaben-Block (dynamic driving task block) des primären Computers gegeben werden. Zum Beispiel kann, wenn das ADAS System 438 wegen eines Objekts unmittelbar voraus eine Vorwärts-Auffahrunfallwarnung anzeigt, der Wahrnehmungsblock diese Information nutzen, wenn Objekte identifiziert werden. In anderen Beispielen, kann der sekundäre Computer sein eigenes neuronales Netzwerk haben, das trainiert ist und daher das Risiko von Falsch-Positiven verringern, wie hierin beschrieben.
Das Fahrzeug 400 kann weiter die Infotainment-SoC 430 umfassen (z. B. ein fahrzeuginternes Infotainment-System (IVI)). Obwohl als SoC gezeigt und beschrieben, mag das Infotainment-System keine SoC sein und kann zwei oder mehr diskrete Komponenten umfassen. Die Infotainment-SoC 430 kann eine Kombination aus Hardware und Software umfassen, die zur Bereitstellung von Audio (z. B. Musik, einem persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio, usw.), Video (z. B. TV, Filme, Streaming, usw.), Telefon (z. B. Freisprechen), Netzwerkkonnektivität (z. B., LTE, WiFi, usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Rückwärts-Einparkhilfe, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremsflüssigkeitsstand, Ölstand, Tür offen/zu, Luftfilterinformationen, usw.) an das Fahrzeug 400 verwendet wird. Die Infotainment-SoC 430 kann z. B. Radios, CD-Spieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, WiFi, Audiobedienelemente am Lenkrad, freihändige Stimmensteuerung, ein Heads-up-Display (HUD), eine HMI-Anzeige 434, ein Telematikgerät, ein Steuerungspaneel (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Feature und/oder Systemen) und/oder andere Komponenten umfassen. Die Infotainment-SoC 430 kann ferner verwendet werden, um einen Benutzer(n) des Fahrzeugs Informationen (z. B. visuell und/oder hörbar) bereitzustellen, wie beispielsweise Informationen vom ADAS System 438, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Informationen zur umliegenden Umgebung (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen, usw.) und/oder andere Informationen.
Die Infotainment-SoC 430 kann GPU-Funktionalität umfassen. Die Infotainment-SoC 430 kann über den Bus 402 (z. B. CAN-Bus, Ethernet, usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 400 kommunizieren. In einigen Beispielen kann die Infotainment-SoC 430 mit einer Überwachungs-MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige selbstfahrende Funktionen ausführen kann, wenn die primäre(n) Steuerung(en) 436 (z. B. die primären und/oder Backup-Computer des Fahrzeugs 400) ausfallen. In einem solchen Beispiel kann die Infotainment-SoC 430 das Fahrzeug 400 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen, wie hier beschrieben.
Das Fahrzeug 400 kann weiterhin ein Instrumentencluster 432 umfassen (z. B. ein digitales Armaturenbrett, ein Elektronisches-Instrument Cluster, ein Digitales-Instrument Panel usw.). Das Instrumentencluster 432 kann eine Steuerung und/oder einen Supercomputer umfassen (z. B. eine diskrete Steuerung oder einen Supercomputer). Das Instrumentencluster 432 kann einen Satz von Instrumentation umfassen, wie z. B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltpositionsanzeige, Sicherheitsgurt-Warnleuchte(n), Feststellbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Airbag (SRS)-Systeminformationen, Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen, usw. In einigen Beispielen können die Informationen angezeigt und/oder vom Infotainment-SoC 430 und dem Instrumentencluster 432 gemeinsam genutzt werden. Mit anderen Worten, das Instrumentencluster 432 kann als Teil des Infotainment-SoC 430 eingefügt sein oder umgekehrt.
4D ist ein Systemdiagramm für die Kommunikation zwischen dem/den Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug 400 von 4A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das System 476 kann den/die Server 478, das/die Netzwerk(e) 490 und die Fahrzeuge, einschließlich des Fahrzeugs 400, umfassen. 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) umfassen. Die GPUs 484, die CPUs 480 und die PCIe-Switches können über Hochgeschwindigkeits-Interconnects miteinander verbunden sein, wie z. B. und ohne Einschränkung die von NVIDIA entwickelten NVLink-Schnittstellen 488 und/oder PCIe-Verbindungen 486. In einigen Beispielen sind die GPUs 484 über NVLink und/oder NVSwitch SoC und die GPUs 484 und die PCIe-Switches 482 über PCIe-Interconnects verbunden. Obwohl acht GPUs 484, zwei CPUs 480 und zwei PCIe-Switches gezeigt werden, ist dies nicht als Einschränkung zu verstehen. Je nach Ausführungsbeispiel kann jeder der Server 478 eine beliebige Anzahl von GPUs 484, CPUs 480 und/oder PCIe-Switches umfassen. Der/die Server 478 kann/können beispielsweise jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 484 umfassen.
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, z. B. kürzlich begonnene Straßenarbeiten. Der/die Server 478 kann/können über das/die Netzwerk(e) 490 und an die Fahrzeuge neuronale Netzwerke 492, aktualisierte neuronale Netze 492 und/oder Karteninformationen 494 übertragen, einschließlich Informationen zu Verkehrs- und Straßenbedingungen. Die Aktualisierungen der Karteninformationen 494 können Aktualisierungen für die HD-Karte 422 umfassen, z. B. Informationen zu Baustellen, Schlaglöchern, Umleitungen, Überschwemmungen und/oder anderen Hindernissen. In einigen Beispielen können die neuronalen Netzwerke 492, die aktualisierten neuronalen Netzwerke 492 und/oder die Karteninformationen 494 aus neuem Training und/oder Erfahrungen resultieren, die in Daten dargestellt sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder basierend auf Training, das an einem Rechenzentrum durchgeführt wurde (z. B. unter Verwenden des/der Server(s) 478 und/oder anderer Server).
Der/die Server 478 kann/können verwendet werden, um Modelle für maschinelles Lernen (z. B. neuronale Netzwerke) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen erzeugt werden und/oder können in einer Simulation erzeugt werden (z. B. unter Verwenden einer Game Engine). In einigen Beispielen werden die Trainingsdaten mit Tags versehen (z. B. wenn das neuronale Netzwerk von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B. wenn das neuronale Netzwerk kein überwachtes Lernen benötigt). Training kann gemäß irgendeiner oder mehrerer Klassen von Maschinenlerntechniken durchgeführt werden, einschließlich und ohne Beschränkung Klassen wie: überwachtes Lernen, teilüberwachtes Lernen, unüberwachtes Lernen, Selbstlernen, bestärkendes Lernen, föderales Lernen, Transfer Learning, Feature-Learning (einschließlich Hauptkomponenten und Clusteranalyse), Multilinear-Subspace-Learning, Nichtlineare dimensionale Reduktion (manifold learning), Repräsentationslernen (representation learning) (einschließlich Ersatz-Wörterbuch-Lernen), regelbasiertes Maschinenlernen, Anomalie-Detektion und alle Varianten oder Kombinationen dafür. Sobald die maschinellen Lernmodelle trainiert sind, können die maschinellen Lernmodelle von den Fahrzeugen verwendet werden (z. B. über das/die Netzwerk(e) 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 zu überwachen.
In einigen Beispielen kann/können der/die Server 478 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle Echtzeit neuronale Netzwerke für intelligentes Inferenzieren in Echtzeit anwenden. Der/die Server 478 kann/können Deep Learning-Supercomputer und/oder dedizierte KI-Computer umfassen, die von GPU(s) 484 angetrieben werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX Station-Maschinen. In einigen Beispielen kann/können der/die Server 478 jedoch eine Deep Learning-Infrastruktur umfassen, die nur CPU-betriebene Rechenzentren verwendet.
Die Deep Learning-Infrastruktur des/der Server(s) 478 kann zu schnellem Echtzeit Inferenzieren fähig sein und kann diese Fähigkeit nutzen, um den Zustand der Prozessoren, der Software und/oder der assoziierten Hardware im Fahrzeug 400 zu evaluieren und zu verifizieren. Beispielsweise kann die Deep Learning-Infrastruktur periodische Updates vom Fahrzeug 400 erhalten, wie 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 maschinenlern Objektklassifizierungstechniken). Die Deep Learning-Infrastruktur kann ihr eigenes neuronales Netzwerk ausführen, um die Objekte zu identifizieren und sie mit den vom 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/können der/die Server 478 ein Signal an das Fahrzeug 400 senden, was einen ausfallsicheren Computer des Fahrzeugs 400 anweist, die Steuerung zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver zu komplettieren.
Zum Inferenzieren kann/können der/die Server 478 die GPU(s) 484 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT von NVIDIA) umfassen. Die Kombination aus GPU-betriebenen Servern und Inferenz-Beschleunigung kann eine Echtzeit-Reaktionsfähigkeit ermöglichen. In anderen Beispielen, z. B. wenn die Performance weniger kritisch ist, können mit CPUs, FPGAs und anderen Prozessoren betriebene Server zum Inferenzieren verwendet werden.
5 ist ein Blockdiagramm eines beispielhaften Rechengeräts 500, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist. Das Rechengerät 500 kann ein Interconnect-System 502 umfassen, das direkt oder indirekt die folgenden Geräte koppelt: Speicher 504, eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 506, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 508, eine Kommunikationsschnittstelle 510, Eingabe-/Ausgabe-(E/A-)Ports 512, Eingabe-/Ausgabekomponenten 514, eine Leistungsversorgung 516 und eine oder mehrere Präsentationskomponenten 518 (z. B. Anzeige(n)), und eine oder mehrere Logikeinheiten 520.
Obwohl die verschiedenen Blöcke in 5 als über das Interconnect-System 502 mit Leitungen verbunden dargestellt sind, ist dies nicht als einschränkend zu verstehen und dient nur der Übersichtlichkeit. In einigen Ausführungsbeispielen kann z. B. eine Präsentationskomponente 518, wie ein Anzeigegerät, als E/A-Komponente 514 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als ein anderes Beispiel können die CPUs 506 und/oder GPUs 508 Speicher umfassen (z. B. kann der Speicher 504 ein Speichergerät zusätzlich zum Speicher der GPUs 508, der CPUs 506 und/oder anderer Komponenten darstellen). Mit anderen Worten ist das Rechengerät von 5 lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“, „Erweiterte Realität-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da alle als im Umfang der Rechenvorrichtung von 5 liegend in Betracht gezogen werden.
Das Interconnect-System 502 kann einen oder mehrere Links oder Busse repräsentieren, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Interconnect-System 502 kann einen oder mehrere Bus- oder Linktypen umfassen, z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect express), und/oder einen anderen Typ von Bus oder Link. In einigen Ausführungsbeispielen, gibt es direkte Verbindungen zwischen Komponenten. Zum Beispiel kann die CPU 506 direkt an den Speicher 504 verbunden sein. Ferner kann die CPU 506 direkt an die GPU 508 verbunden sein. Wo es eine direkte, oder point-to-point, Verbindung zwischen Komponenten gibt, kann das Interconnect-System 502 einen PCIe Link umfassen, um die Verbindung auszuführen. In diesen Beispielen braucht ein PCI Bus nicht in dem Rechengerät 500 enthalten zu sein.
Der Speicher 504 kann jedes von einer Vielzahl von computerlesbaren Medien umfassen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Rechengerät 500 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entfernbare und nicht-entfernbare Medien umfassen. Beispielhaft und ohne Einschränkung können die computerlesbaren Medien Computer-Speichermedien und Kommunikationsmedien umfassen.
Die Computer-Speichermedien können sowohl flüchtige als auch nicht flüchtige Medien und/oder entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen, wie z. B. computerlesbare Anweisungen, Datenstrukturen, Programmmodulen und/oder andere Datentypen, implementiert sind. Beispielsweise kann der Speicher 504 computerlesbare Anweisungen speichern (z. B., die ein oder mehrere Programme und/oder ein oder mehrere Programmelemente darstellen, wie z. B. ein Betriebssystem). Computerspeichermedien können RAM, ROM, EEPROM, Flash-Speicher oder eine andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf die das Rechengerät 500 zugreifen kann, umfassen, sind aber nicht darauf beschränkt. Wie hier verwendet, umfasst der Begriff „Computer-Speichermedien“ nicht Signale per se.
Das Computerspeichermedium kann computerlesbare Befehle, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal verkörpern wie beispielsweise eine Trägerwelle oder einem anderen Transportmechanismus und umfasst jedes Informations-Übergabe-Medium. Der Term „moduliertes Datensignal“ kann sich auf ein Signal beziehen, das ein oder mehr seiner Charakteristiken in solch einer Weise gesetzt oder geändert hat, um Information in das Signal zu kodieren. Auf dem Wege eines Beispiels und nicht Beschränkung kann das Computerspeichermedium drahtgebundene Medien, wie ein drahtgebundenes Netzwerk oder eine Direkt-Draht-Verbindung und drahtlose Medien, wie akustische, RF, Infrarot und andere drahtlose Medien umfassen. Kombinationen von allen oben genannten sollen ebenfalls innerhalb des Umfangs von computerlesbaren Medien umfasst sein.
Die CPU(s) 506 kann/können so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten des Rechengeräts 500 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 506 kann/können jeweils einen oder mehrere Kerne umfassen (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.), die in der Lage sind, eine Vielzahl von Software-Threads simultan zu verarbeiten. Die CPU(s) 506 kann/können jede Art von Prozessor umfassen und je nach Art des implementierten Rechengeräts 500 unterschiedliche Typen von Prozessoren umfassen (z. B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Zum Beispiel kann, je nach Art des Rechengeräts 500, der Prozessor ein ARM-Prozessor (Advanced RISC Machines Processor) sein, der mit einem reduzierten Befehlssatz (RISC) implementiert ist, oder ein x86-Prozessor, der mit komplexem Befehlssatz (Complex Instruction Set Computing, CISC) implementiert ist. Das Rechengerät 500 kann eine oder mehrere CPUs 506 umfassen, zusätzlich zu einem oder mehreren Mikroprozessoren oder Zusatz-Coprozessoren, wie z. B. mathematischen Coprozessoren.
Zusätzlich oder alternativ zu der/den CPU(s) 506 kann/können die GPU(s) 508 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten des Rechengeräts 500 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehr der GPU(s) 508 kann/können eine integrierte GPU (z. B. mit einem oder mehr der CPU(s) 506) sein und/oder eine oder mehr der GPU(s) 508 kann/können eine diskrete GPU sein. In Ausführungsbeispielen kann/können eine oder mehr der GPU(s) 508 ein Coprozessor von einer oder mehr der CPU(s) 506 sein. Die GPU(s) 508 kann/können von dem Rechengerät 500 zum Rendern von Grafiken (z. B. 3D-Grafiken) verwendet werden oder Universalberechnungen durchführen. Zum Beispiel kann/können die GPU(s) 508 zum Universalberechnen auf GPU(s) (GPGPU) verwendet werden. Die GPU(s) 508 kann/können hunderte oder tausende von Kernen umfassen, die in der Lage sind, hunderte oder tausende von Software-Threads simultan zu verarbeiten. Die GPU(s) 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/können einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder irgendwelchen anderen geeigneten Daten, wie zum Beispiel GPGPU Daten, umfassen. Der Anzeigespeicher kann als Teil des Speichers 504 eingefügt sein. Die GPU(s) 508 kann/können zwei oder mehr GPUs umfassen, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt (z. B. unter Verwenden von NVLINK) verbinden oder kann die GPUs durch einen Switch (z. B. NVSwitch) verbinden. Wenn zusammen kombiniert kann jede GPU 508 Pixeldaten oder GPGPU Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben erzeugen (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher umfassen oder Speicher gemeinsam mit anderen GPUs nutzen.
Zusätzlich oder alternativ zu der/den CPU(s) 506 und/oder der/den (GPU(s) 508 kann/können die Logikeinheit(en) 520 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt/ausführen, um eine oder mehrere Komponenten des Rechengeräts 500 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsbeispielen kann/können die CPU(s) 506, die GPU(s) 508 und/oder die Logikeinheit(en) 520 einzeln oder zusammen jede Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehr der Logikeinheiten 520 kann/können Teil von und/oder in eine oder mehr der CPU(s) 506 und/oder der GPU(s) 508 integriert sein und/oder eine oder mehr der Logikeinheiten 520 kann/können diskrete Komponenten oder auf andere Weise extern zu der/den CPU(s) 506 und/oder der/den GPU(s) 508 sein. In Ausführungsbeispielen kann/können eine oder mehr der Logikeinheiten 520 ein Coprozessor von einer oder mehr der CPU(s) 506 und/oder einer oder mehr der GPU(s) 508 sein.
Beispiele für die Logikeinheit(en) 520 umfassen einen oder mehr Prozessorkerne und/oder Komponenten davon, wie beispielsweise Tensorkerne (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphikprozessorcluster (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Baum-Traversierungseinheiten (Tree Traversal Units, TTUs), künstliche Intelligenz Beschleuniger (Artificial Intelligence Accelerators, AlAs), Deep Learning Beschleuniger (DLAs), Arithmetisch-logische Einheiten (ALUs), Anwendungsspezifische integrierte Schaltungen (ASICs), Gleitkommaeinheiten (FPUs), E/A Elemente, Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Express (PCle) Elemente, und/oder ähnliche.
Die Kommunikationsschnittstelle 510 kann einen oder mehrere Empfänger, Sender und/oder Transceiver umfassen, die es dem Rechengerät 500 ermöglichen, mit anderen Rechengeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikationen. Die Kommunikationsschnittstelle 510 kann Komponenten und Funktionalitäten umfassen, die eine Kommunikation über jedes von einer Anzahl von verschiedenen Netzwerken ermöglichen, wie z. B. drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weitverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet.
Die E/A-Anschlüsse 512 können es ermöglichen, dass das Rechengerät 500 mit anderen Geräten logisch gekoppelt ist, einschließlich der E/A-Komponenten 514, der Präsentationskomponente(n) 518 und/oder anderer Komponenten, von denen einige in das Rechengerät 500 eingebaut (z. B. integriert in) sein können. Beispielhafte E/A-Komponenten 514 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, eine Spielsteuerung, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die E/A-Komponenten 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 Eingaben zur weiteren Verarbeitung an ein entsprechendes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten in größeren Detail beschrieben) in Verbindung mit einer Anzeige des Rechengeräts 500 implementieren. Das Rechengerät 500 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestendetektion und -erkennung umfassen. Zusätzlich kann das Rechengerät 500 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) umfassen, die eine Bewegungserkennung ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von dem Rechengerät 500 verwendet werden, um immersive Augmented Reality oder virtuelle Realität zu rendern.
Die Leistungsversorgung 516 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon umfassen. Die Stromversorgung 516 kann das Rechengerät 500 mit Strom versorgen, um den Betrieb der Komponenten des Rechengeräts 500 zu ermöglichen.
Die Präsentationskomponente(n) 518 kann/können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 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 ein Bild, Video, Ton usw.).
6 ist ein Flussdiagramm, das Prozessschritte zum Bestimmen von Sicherheitsgurt-Positionszuständen gemäß Ausführungsbeispielen der Offenbarung illustriert. Hier empfängt die Rechenvorrichtung 300 zuerst Sensordaten von einem Sensor, der den Sicherheitsgurt 20 auf Fahrer 50 (z.B. Kamera 310) überwacht (Schritt 600). Wie oben sind diese Sensordaten alle Daten, die verwendet werden können, um die räumliche Positionen von Messmarkierungen 40 zu bestimmen, wie Bilddaten von Kamera 310. Rechenvorrichtung 300 bestimmt dann die Position von Sicherheitsgurt 20 (Schritt 610), beispielsweise ob die Position des Sicherheitsgurtes 20 unter einen der oben beschriebenen Nutzungsfälle fällt. Insbesondere kann das Messmarkierungs-Bestimmungsmodul 416 die Positionen von jeder Messmarkierung in seinem Eingabebild oder anderen Daten bestimmen, und Mustererkennungs-Modul 418 kann dann eine spezifische Klassifikation oder einen Sicherheitsgurt-Benutzungszustand (z.B. Fall-An, Fall-Ab, Fall-Unter, oder Fall-Rücken) aus den ermittelten Positionen der Markierungen 40 auswählen.
Optional kann die Rechenvorrichtung 300 auch andere Größen neben dem Sicherheitsgurt-Benutzungszustand (Schritt 620) bestimmen. Zum Beispiel kann Vorrichtung 300 auch die Größe oder Position von verschiedenen Fahrzeugkomponenten bestimmen. Messmarkierungen 40 können an jeder Fahrzeugkomponente oder jedem Objekt innerhalb des Fahrzeugs platziert werden, und der Sensor 100 kann orientiert werden, um Bilder oder Positionsinformationen von diesen zusätzlichen Messmarkierungen 40 aufzunehmen. Vorrichtung 300 kann dann die Positionszustände von diesen Komponenten oder Objekten wie oben bestimmen, wobei sie in verschiedene Zustände, wenn zweckdienlich, klassifiziert werden. Zum Beispiel können die Messmarkierungen 40 an dem Rückenlehnen-Abschnitt 60 und/oder dem Sitzflächen-Abschnitt 70 von einem Fahrzeugsitz platziert werden, und Vorrichtung 300 kann zum Beispiel die Benutzungszustände des Sitzes des Fahrers (oder anderer Passagiere) bestimmen. Auf diese Weise kann die Vorrichtung 300 zum Beispiel bestimmen, ob der Fahrersitz in einem zurückgelehnten Zustand ist, oder weit nach vorne oder weit nach hinten bewegt wurde, und kann das Fahrzeug informieren, verschiedene Aktionen durchzuführen, wie Umorientieren von Heiz/Kühl-Öffnungen oder Alarmieren des Fahrers, dass sein oder ihr Sitz in einer ungeeigneten Position zum Fahren ist. Messmarkierungen 40 können auch auf Objekten innerhalb des Fahrzeugs, wie zum Beispiel Kindersitzen oder Sitzerhöhungen, platziert werden. Vorrichtung 300 kann dann die Positionen von diesen Objekten innerhalb des Fahrzeugs bestimmen, gemäß Ausführungsbeispielen der Offenbarung, wobei zum Beispiel bestimmt wird, ob Objekte innerhalb eines Sitzes und/oder korrekt orientiert sind, gemäß von charakteristischen Verteilungen von Positionen von Messmarkierungen 40, wenn das Objekt angemessen positioniert ist. Daher kann die Vorrichtung 300 zum Beispiel bestimmen, ob Kinderautositze oder Sitzerhöhungen angemessen installiert sind, sich über die Zeit in der Position geändert haben oder ähnliches, und das Fahrzeug entsprechend informieren. In einem anderen Ausführungsbeispiel kann die Vorrichtung 300 bestimmen, ob Fracht innerhalb des Fahrgastinnenraumes sicher positioniert ist.
Als anderes Beispiel kann die Vorrichtung 300 die Größe vom Passagier oder Fahrer bestimmen. Insbesondere kann die Größe von Passagieren von den Sicherheitsgurtkonturen bestimmt werden, d.h. der Positionen von den verschiedenen Messmarkierungen 40, wenn sie die Kontur des Körpers des Fahrers oder Passagieren nachformen. Zum Beispiel können Maschinenlern-Modelle vom Messmarkierungs-Positions-Bestimmungsmodul 416 trainiert werden, um Cluster von Positionen von Messmarkierungen 40 für Fahrer/Passagiere von unterschiedlichen Gewicht, Dimensionen oder Volumen zu klassifizieren. Positionen von Markierungen 40 in Eingabebildern können daher gemäß dem Fahrer/Passagier-Gewicht klassifiziert werden, entsprechend dem Cluster mit dem sie am besten matchen. Dies kann das System über das ungefähre Gewicht von dem Fahrer/Passagier informieren, daher wird das Fahrzeug informiert, ob, zum Beispiel, im Falle einer Kollision Airbags eingesetzt werden sollen. Alternativ kann das Fahrzeug die Informationen verwenden, um zu regeln, zu was für einem Ausmaß oder wie ein Airbag eingesetzt wird. Zum Beispiel können verschiedene Teile eines Fahrzeug-Kokon-Airbags eingesetzt oder nicht eingesetzt werden basierend auf der Passagiergröße. Um bei einer genaueren Bestimmung der Fahrer/Passagier-Größe zu assistieren, können Messmarkierungen 40 in zusätzlichen Positionen an dem Sicherheitsgurt-Schultergurt platziert werden, wie beispielsweise an Beckengurt 30 und/oder Sitz-Rückenlehnen-Abschnitt 60.
Als ein weiteres Beispiel kann die Position oder die Pose eines Passagiers bestimmt werden mittels der Positionen der Messmarkierungen, wie diese sich an Passagiere anpassen, die sich in ihren Sitzen herumbewegen. Zum Beispiel können Maschinenlern-Modelle vom Messmarkierungs-Positions-Bestimmungsmodul 416 trainiert werden, um Cluster von Positionen von Messmarkierungen 40 für Fahrer/Passagiere in verschiedenen Posen zu klassifizieren. Positionen von Markierungen 40 in Eingabebildern können daher gemäß der Fahrer/Passagier-Pose klassifiziert werden, entsprechend dem Cluster mit dem sie am besten matchen. Dies kann das Fahrzeug hinsichtlich, zum Beispiel, Fahrern/Passagieren informieren, die eingeschlafen sind und daher in ihren Sitzen zusammengesackt sind, Kindern die versucht haben, in ihren Sitzen aufzustehen, Fahrer, die sich umgedreht haben und daher nicht die Straße betrachten und ähnliches. Mittels Trainierens der Maschinenlern-Modelle vom Messmarkierungs-Positions-Bestimmungsmodul 416 unter Verwenden von Bildern von jeder Fahrer/Passagier-Position oder Pose von Interesse kann die Vorrichtung 300 jede Fahrer/Passagier-Position bestimmen, auf die aus der Sitzgut-Position zurückgeschlossen werden kann.
In einigen Ausführungsbeispielen der Offenbarung ist Schritt 620 optional und kann, wenn gewünscht, weggelassen werden. Wenn der Sicherheitsgurt-Benutzungszustand ausgewählt wurde und/oder irgendeine andere Quantität von Fahrer oder Passagier bestimmt wurden, d.h. nach Vollendung von entweder Schritt 610 oder Schritt 620, kann System 300 dann eine Fahrzeugoperation entsprechend initiieren (Schritt 620). Wie oben, kann jede Fahrzeugoperation initiiert werden. Solche Fahrzeugoperationen können einen Airbag-Einsatz oder Einstellung (z.B. eine Deaktivierung des Airbag-Einsatzes, wenn ein kleiner Passagier wie beispielweise ein Kind detektiert wurde), jede hörbare oder sichtbare Warnung, wie ein Warnanzeigelicht, Alarmglocke oder anderes Signale oder eine sprach- oder textbasierte Warnung umfassen. In dringenderen Situationen, z.B. sicherlich wenn ein Sicherheitsgurt plötzlich entfernt oder losgeschnallt wird, können die Fahrzeugoperationen Bremsen, Zündung-Ausstellen oder Motor-Ausschalten, Anschalten des Autopiloten oder ähnliches umfassen. In einigen Ausführungsbeispielen können die Sicherheitsgurt-Benutzungszustände vom Fahrzeug weg übermittelt werden. Zum Beispiel kann es im Flotten-Verwaltungs-Situationen wichtig sein, zu wissen, wenn Fahrer ihren Sicherheitsgurt tragen oder ob sie ihren Sicherheitsgurt korrekt tragen. Andere Situationen würden auch von solch einer Lösung profitieren, zum Beispiel kann das Überwachen von sicheren Fahrverhalten und Sicherheitsgurt-Benutzung wichtig für Versicherungsgesellschaften oder Eltern sein.
Es wird angemerkt, dass Ausführungsbeispiele der Offenbarung die Detektion der Sicherheitsgurt-Position und der Benutzung sowohl für die Fahrer als auch für andere Passagiere erlauben. Das heißt, alle detektierten Quantitäten und alle resultierenden Operationen von allen Ausführungsbeispielen der Offenbarung können sowohl auf Fahrer als auch auf alle anderen Fahrzeuginsassen angewendet werden. Daher können, während 1A die Detektion der Sicherheitsgurt-Position oder Benutzung für einen Fahrer zeigt, die offenbarten Verfahren und Prozesse gleichfalls auch auf alle anderen Passagiere angewendet werden. Zum Beispiel, können Messmarkierungen auf jeden Passagier-Sicherheitsgurt platziert werden und ein Sensor 100 kann geeignet platziert werden, um Bilder dieser Markierungen aufzunehmen, woraufhin Bilder oder andere Sensordaten eingesetzt werden können, um die Sicherheitsgurt-Position und Benutzung von solchen Passagieren zu bestimmen. Auf diese Weise können Systeme von Ausführungsbeispielen der Offenbarung bestimmen, ob ein Passagier-Sicherheitsgurt korrekt getragen wird oder ob ein oder mehrere Passagiere einen inkorrekt getragenen Sicherheitsgurt haben, woraufhin das Fahrzeug eine Warnung oder andere Nachricht an diesen Passagier oder zu anderen in dem Fahrzeug ausgeben kann.
Es wird auch angemerkt, dass die Messmarkierungen 40 von jedem Typ und Form von Markierung sein können, die geeignet sind, um eine räumliche Positionsinformation zu übermitteln. Als ein Beispiel können die Messmarkierungen von jeder Form und Größe sein und können auf jede Weise geformt sein. Zum Beispiel können die Markierungen 40 sichtbare Patches oder andere sichtbare Objekte oder Gebilde sein, die klebend angebracht, genäht, gedruckt, gesprüht, hervorstehend oder auf andere Weise an Sicherheitsgurt 20 geformt sind. Als ein anderes Beispiel können Messmarkierungen 40 in irgendeinem Lichtbereich sichtbar sein. Daher können zum Beispiel die Messmarkierungen 40 Markierungen sein, die bei Frequenzen von sichtbaren Licht erkennbar sind, z.B. sichtbare Patches oder andere Kennungen. Alternativ können die Markierungen nur bei Frequenzen außerhalb des Spektrums sichtbaren Lichts erkennbar sein. Zum Beispiel können die Markierungen 40 ultraviolette, infrarote oder nah-infrarote Markierungen sein. Als ein Beispiel können die Messmarkierungen zuerst mit einer schwarzen Tinte gedruckt sein, die im infraroten und nah-infraroten sichtbar ist. Diese schwarze Tinte kann dann mit einer anderen Tintenschicht beschichtet werden, die im sichtbaren Licht schwarz aussieht aber durchsichtig im infraroten und/oder nah-infraroten Licht. Messmarkierungen die auf diese Weise geformt werden, sind daher unsichtbar für Passagiere und Fahrer aber durch Systeme gemäß Ausführungsbeispielen gemäß der Offenbarung erkennbar.
Es wird ferner angemerkt, dass Maschinenlern-Modelle vom Mustererkennungs-Modul 220 Messmarkierungs-Positionen in andere Sicherheitsgurt-Benutzungsfälle neben den vier in Zusammenhang mit den 2B-2C spezifizierten klassifiziert. Als ein Beispiel kann ein zusätzlicher Fall hinzugefügt werden, um den Fall einzufangen, in dem Fahrer 50 oder Passagier einen Abschnitt des Sicherheitsgurtes 20 mit seiner oder ihrer Hand wegdrückt. Hier können die Maschinenlern-Modelle vom Mustererkennungs-Modul 220 an einem Eingabesatz von Bildern trainiert werden, der Bilder von einem Fahrer/Passagier umfasst, der einen Abschnitt seines oder ihres Sicherheitsgurtes wegdrückt, wobei vielleicht korrespondierende räumlichen Positionen von seinen Messmarkierungen 40 gekennzeichnet sind.
Zusätzlich können Maschinenlern-Modelle von Ausführungsbeispielen der Offenbarung trainiert werden, zumindest teilweise Verdeckung von einer oder mehreren Messmarkierungen 40 handzuhaben. Von solcher Verdeckung wird erwartet, ein möglicher wenn nicht gar gewöhnlicher Vorfall zu sein. Zum Beispiel kann Haar vom Passagier drüber fallen und daher Sensor 100 vom Erkennen der Messmarkierungen 40 abhalten, lose Kleidung oder Handgesten können die Messmarkierungen 40 ähnlich blockieren, oder ähnliches. Maschinenlern-Modelle von sowohl Messmarkierungs-Positions-Bestimmungsmodul 210 als auch Mustererkennungs-Modul 220 können daher trainiert werden unter Verwenden von Bildern, in denen zumindest einige der Messmarkierungen teilweise oder komplett verdeckt sind, und/oder Messmarkierung-Positionsinformation teilweise bzw. inkomplett ist. Als ein Beispiel kann ein Teil des Trainingssatzes von Bildern, die in das/die Maschinenlern-Modell(e) der Ausführungsbeispiele der Offenbarung eingegeben werden, Bilder sein, in denen zumindest einige der Messmarkierungen teilweise oder komplett verdeckt sind. Auf diese Weise werden die Maschinenlern-Modelle von Ausführungsbeispielen der Offenbarung trainiert, Verdeckung von Messmarkierungen handzuhaben, wodurch sie verlässlichere Klassifikationsergebnisse bereitstellen, die in einer Vielfalt von Realwelt-Situationen akkurat bleiben.
Ferner wird angemerkt, dass Ausführungsbeispiele der Offenbarung zusätzlich automatisierte Sicherheitsgurt-Platzierungsoperationen initiieren oder leiten, vielleicht in Reaktion auf Eigenschaften, die aus einer detektierten Sicherheitsgurt-Position bestimmt werden. Wie oben können detektierte Sicherheitsgurt-Positionsinformationen eingesetzt werden, um auf Passagier- oder Fahrergröße und/oder -gewicht rückzuschließen. Ausführungsbeispiele der Offenbarung ziehen ferner in Erwägung eine Initiierung von automatisierten Fahrzeuganpassungen in Reaktion auf Fahrer- oder Passagiergröße/gewicht. Zum Beispiel können Sicherheitsgurte 20 und/oder Sitze mit bekannten Einstellmechanismen ausgestattet werden, die konfiguriert sind, um Sicherheitsgurte automatische zu straffen oder zu lockern oder die Sitze in eine spezifische Richtung zu bewegen. Demgemäß können ein oder mehrere Prozessoren von Ausführungsbeispielen der Offenbarung bestimmen, dass ein Kind anwesend ist und sein oder ihr Sicherheitsgurt einstellen, um einen kleineren Körper besser aufzunehmen, z.B. absenken oder straffen des Sicherheitsgurtes, Anheben des Sitzes oder ähnliches. Als ein anderes Beispiel können Prozessoren von Ausführungsbeispielen der Offenbarung aus der Position des Sicherheitsgurtes 20 bestimmen, dass ein Passagier inkorrekt in seinem Sitz positioniert ist. Wenn sich der Passagier auf die Warnung hin für einige Zeit nicht aus seiner inkorrekten Position bewegt hat, kann der Sitz oder Sicherheitsgurt 20 des Passagiers auf die inkorrekte Position des Passagiers eingestellt werden, wie beispielsweise mittels Einstellens des Sitzes, um den Sicherheitsgurt 20 in korrekte Position oder Zug oder dergleichen zu platzieren. Jede Einstellung von irgendeiner Komponente von einem Fahrzeug kann für jede Größe oder jedes Gewicht des detektierten Passagiers oder Fahrer durchgeführt werden.
7 illustriert beispielhafte automatische Sicherheitsgurt-Platzierungsoperationen gemäß Ausführungsbeispielen der Offenbarung. Hier kann der Sicherheitsgurt 20 mit einem bekannten Sicherheitsgurt-Einzugsmechanismus zum Einziehen des Sicherheitsgurtes 20 ausgerüstet sein, z.B. in der Richtung von den oberen Pfeilen in 7. Ähnlich kann Sitz 60, 70 mit bekannten Betätigungsmechanismen ausgerüstet sein, um den Sitz 60, 70 vorwärts/rückwärts und links/rechts in die Richtung von den unteren rechten Pfeilen zu bewegen. Zusätzlich kann ferner Gurtschloss 80 mit einem Betätigungsmechanismus ausgerüstet sein zur vorwärts/rückwärst und rechts/links Bewegung, in die Richtung von den unteren linken Pfeilen. Anker 130 kann separat oder zusätzlich mit einem Betätigungsmechanismus ausgerüstet sein zur hoch/runter und vorwärts/rückwärts Bewegung, in die Richtung der unteren Pfeile.
Auf diese Weise kann Sicherheitsgurt 20 automatisch angepasst werden, um alle detektierten inkorrekten Fahrzeuginsassen-Positionen zu kompensieren. Zum Beispiel, wie in 7 gezeigt, kann Sensor 100 Sicherheitsgurt 20 detektieren, wie er in einer allzu losen Konfiguration ist, gemäß einem Muster von Messmarkierungen 40, das sich eher nahezu senkrecht entlang eines signifikanten Abschnitts von der Vorderansicht von Fahrer 50 erstreckt als diagonal quer über den Fahrer 50, wie es korrekt wäre. In Reaktion kann das Fahrzeug irgendeine Betätigungs-Operation von Sicherheitsgurt 20, Sitz 60, 70, Gurtschloss 80 oder Anker 130 durchführen, um Sicherheitsgurt 20 auf seine korrekte Position einzustellen. Diese Operationen können eines oder mehrere von Einziehen des Sicherheitsgurtes 20, um die losen und lockeren Abschnitte aufzunehmen, die sich entlang der Vorderseite von Fahrer 50 erstrecken, nach unten und/oder hinten Betätigen des Gurtschlosses 80, um Sicherheitsgurt 20 zu straffen, nach vorne Betätigen des Sitzes 60, 70, um den Sicherheitsgurt 20 ähnlich zu straffen, Betätigen nach oben und/oder nach hinten des Ankers 130, um ebenso den Sicherheitsgurt 20 zu straffen, jede Kombination von allen diesen Betätigungsoperationen, oder jedes automatische Bewegen von jedem anderen Fahrzeug-Abschnitt, das den Sicherheitsgurt 20 straffen kann. Ausführungsbeispiele der Offenbarung ziehen Detektion und Charakterisieren von jeder Position des Sicherheitsgurtes 20, die als inkorrekt aufgefasst werden kann, in Erwägung mittels Verfahren und Prozessen der Offenbarung, wie die oben, und Kompensation oder Einstellen von diesen inkorrekten Positionen des Sicherheitsgurtes 20 mittels Einstellens von irgendeiner oder mehreren Fahrzeugkomponenten.
Ausführungsbeispiele der Offenbarung ziehen ferner das Verwenden von anderen Sensoren zusätzlich zu Sensor 100 in Erwägung, zum Erzeugen von jeder Art von Informationen, die in Verbindung mit ermittelten Sicherheitsgurt-Positionen von Ausführungsbeispielen der Offenbarung verwendet werden können, um irgendwelche Fahrzeugoperationen zu initiieren. Irgendeiner oder mehrere Sensoren von allen Typen werden in Erwägung gezogen. Zum Beispiel können Gewichts- oder Drucksensoren innerhalb des Sitzflächen-Abschnitts 70 unter Fahrer 50 platziert werden, um das Gewicht des Fahrers 50, seine oder ihre Position innerhalb des Sitzes, seine oder ihrer Gewichtsverteilung oder ähnliches zu messen. Ähnlich können andere Gewichts- oder Drucksensoren innerhalb anderer Sitze platziert werden, um Gewichte von Passagieren zu messen. Systeme von Ausführungsbeispielen der Offenbarung können daher bestimmen, welche Sitze besetzt sind, und die Gewichte der Passagiere oder Fahrer, die Sitze besetzen, bestimmen. Gewicht und Positionsinformationen von Sicherheitsgurt 20 können dann zusammen verwendet werden, um den geeigneten Zug für Sicherheitsgurt 20 zu bestimmen, woraufhin das Fahrzeug den Sicherheitsgurt mittels Einstellens der Positionen von beispielsweise Gurtschloss 80, Anker 130 und/oder Sitz 60/70 automatisch auf den Zug einstellt.
Alle Quantitäten können in Verbindung mit Positionen des Sicherheitsgurtes 20 bestimmt und eingesetzt werden, um alle Quantitäten zu bestimmen und alle Operation in Reaktion zu initiieren. Als ein Beispiel können die Verteilung vom Passagiergewicht und seine Positionen, wie bestimmt aus den Positionen der Messmarkierungen 40, zusammen verwendet werden, um zu bestimmen, dass ein Passagier inkorrekt im Sitz sitzt, z.B. zu sehr zu einer Seite oder zu weit nach vorne sitzend oder lehnend, ein Kindersitz inkorrekt platziert ist (vielleicht unter Verwenden von Messmarkierungen 40, die an dem Kindersitz platziert sind), oder ähnliches. In Reaktion kann das Fahrzeug verschiedene Operationen initiieren, wie beispielsweise den Sicherheitsgurt 20 straffen, um den Passagier oder Fahrer zurück in Position zu ziehen, Justieren des Sitzes 60, 70, um den Passagier oder Fahrer in die korrekte Position zu bewegen, oder ähnliches. Als ein anderes Beispiel können das Gewicht und die Positionen der Messmarkierungen 40 eines Fahrers 50 oder eines anderen Passagiers verwendet werden, um ihre körperlichen Dimensionen, z.B. Höhe und Weite, zu bestimmen. Das Fahrzeug kann dann die Positionen von Anker 130, Gurtschloss 80, oder ähnlichem einstellen, um den Sicherheitsgurt 20 korrekter auf dem Fahrer/Passagier zu positionieren, wie beispielsweise durch Anheben des Ankers 130, um größere Fahrer aufzunehmen, Bewegen des Ankers 139 nach rechts (in der Ansicht von 7), um den Sicherheitsgurt 20 für Fahrer mit breiten Schultern einzustellen, oder ähnliches. Auf diese Weise können Fahrer- oder Passagiereigenschaften, wie Höhe oder andere Dimensionen, von sowohl Positionen von Messmarkierungen 40 als auch anderen Sensordaten, wie zum Beispiel Gewicht, abgeleitet werden, und Sicherheitsgurte 20 können automatisch eingestellt werden, um sich optimaler diesen spezifischen Fahrer/Passagier-Dimensionen anzugleichen. Daher ermöglichen Ausführungsbeispiele der Offenbarung Sicherheitsgurte 20, die sich automatisch (und, wenn gewünscht, kontinuierlich) auf korrektere Positionen auf jeden Fahrer oder Passagier einstellen, wodurch die Sicherheit während des Fahrzeugbetriebs verbessert wird.
Ausführungsbeispiele der Offenbarung ziehen zusätzlich Bestimmung von Eigenschaften, wie Fahrzeugvibrationen, aus ermittelten Positionen von Messmarkierungen 40, in Erwägung. Spezifischer können die Frequenz und die Magnitude von Vibrationen aus der über die Zeit aufgenommenen Bewegung der Messmarkierungen 40 bestimmt werden. Fahrzeugvibrationen können aus der Bewegung vom Messmarkierung 40 auf jegliche Art bestimmt werden, wie beispielsweise mittels anfänglicher Bestimmung einer Grundlinie oder neutralen Satzes von Positionen von Markierung 40, und nachfolgendem Tracking der Relativbewegung von dieser Grundlinie als eine Funktion der Zeit. Positionen von Markierung 40 können über jeden Ansatz bestimmt werden, wie zum Beispiel mittels bekannter Computer-Vision-Verfahren zum Identifizieren eines Objekts und Bestimmen seiner räumlichen Position, maschinenlern-Methoden, die ein oder mehrere Maschinenlern-Modelle einsetzen, die trainiert sind, um die Position von spezifischen Objekten zu identifizieren und zu bestimmen, oder ähnliches.
Ermittelte Fahrzeugvibration kann auf jede Weise verwendet werden. Zum Beispiel können auf bekannte Weise Komponenten-Frequenzen, und deren korrespondierenden Magnituden, aus der ermittelten Vibration identifiziert und eingesetzt werden, um verschiedene Aspekte der Fahrzeugfunktion oder Ladung zu bestimmen. Daher können beispielsweise die Frequenzen und Magnituden der Grundlinie identifiziert und aufgenommen werden, wie oben, und gewisse Frequenzen können als zu Quellen korrespondierend identifiziert werden, wie beispielsweise Grundlinien Motoroperation, Straßengeräusch, oder ähnliches. Systeme von Ausführungsbeispielen der Offenbarung können dann das Fahrzeug oder Passagiere warnend auf Abweichungen von solchen Grundlinien hinweisen. Auf diese Weise können Systeme von Ausführungsbeispielen von dieser Offenbarung Auftritte von abnormalen Motoroperationen, Ausfälle von Fahrzeugkomponenten, Fahrzeugschaden, gefährlichen oder potentiell schädigenden Straßenbedingungen, oder ähnlichem identifizieren und das Fahrzeug oder den Fahrer alarmieren, um korrigierende Aktionen auszuführen.
Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen beschrieben werden, einschließlich computerausführbarer Anweisungen, wie z. B. Programmmodule, die von einem Computer oder einer anderen Maschine, wie z. B. einem Personal Data Assistant oder einem anderen Handheld-Gerät, ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf Codes, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, Universalcomputern, spezielleren Rechengeräten, usw. Die Offenbarung kann auch in verteilten Rechenumgebungen angewendet werden, in denen Aufgaben von entfernt arbeitenden Geräten ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind.
Wenn hier von „und/oder“ in Bezug auf zwei oder mehr Elemente die Rede ist, so ist damit nur ein Element oder eine Kombination von Elementen gemeint. Beispielsweise kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C umfassen. Darüber hinaus kann „zumindest eines von Element A oder Element B“ zumindest eines von Element A, zumindest eines von Element B oder zumindest eines von Element A und zumindest eines von Element B umfassen. Weiter kann „zumindest eines von Element A und Element B“ zumindest eines von Element A, zumindest eines von Element B oder zumindest eines von Element A und zumindest eines von Element B umfassen.
Der Gegenstand der vorliegenden Offenbarung wird hierin spezifisch beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch nicht den Umfang der vorliegenden Offenbarung einschränken. Vielmehr haben die Erfinder in Erwägung gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden kann, um verschiedene Schritte oder Kombinationen von Schritten ähnlich den in diesem Dokument beschriebenen in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente von verwendeten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbart dargestellten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.
Die vorstehende Beschreibung nutzte, zum Zwecke der Erläuterung, eine spezifische Nomenklatur, um ein umfassendes Verständnis der Offenbarung bereitzustellen. Jedoch wird es einem Fachmann klar werden, dass die spezifischen Details nicht notwendig sind, um die Verfahren und Systeme der Offenbarung zu praktizieren. Daher werden die vorstehenden Beschreibungen von spezifischen Ausführungsbeispielen der vorliegenden Erfindung zum Zwecke der Illustration und Beschreibung präsentiert. Sie sich nicht erschöpfend gedacht oder um die Erfindung auf die präzise offenbarten Formen zu beschränken. Viele Modifikationen und Variationen sind Angesichts der obigen Lehren möglich. Zum Beispiel können jegliche Messmarkierungen von jeglicher Größe und oder Form, und sichtbar bei jeglicher Lichtwellenlänge verwendet werden. Positionen der Messmarkierung können auf jegliche Art bestimmt werden und resultierende Sicherheitsgurt-Benutzungsfälle können auf jegliche Weise klassifiziert werden, um jegliche gewünschte Klassifizierung zu ergeben. Die Ausführungsbeispiele wurden gewählt und beschrieben, um am besten die Prinzipien der Erfindung und ihre praktische Anwendung zu erklären, um es dadurch anderen Fachleute zu ermöglichen, die Verfahren und Systeme von der Offenbarung am besten zu nutzen, und verschiedene Ausführungsbeispiele mit verschiedenen Modifikationen sind für die spezifische in Erwägung gezogene Verwendung geeignet. Zusätzlich können verschiedene Merkmale von verschiedenen Ausführungsbeispielen, offenbart oder anders, gemischt und gepaart oder anderweitig kombiniert werden, um so weitere Ausführungsbeispiele zu erzeugen, die durch die Offenbarung in Erwägung gezogen werden.
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 16/101232 [0068]

Claims

Ein System zum Bestimmen der Position eines Sicherheitsgurtes, wobei das System aufweist: einen Sicherheitsgurt, der darauf eine Mehrzahl von Messmarkierungen angeordnet hat; einen Sensor, der positioniert ist, um Daten zu erzeugen, die die Messmarkierungen des Sicherheitsgurtes repräsentieren; und parallelprozessierende Schaltkreise in elektronischer Kommunikation mit dem Sensor, wobei die parallelprozessierenden Schaltkreise dazu konfiguriert sind: die Daten, die mittels des Sensors erzeugt werden, zu empfangen; aus den Daten eine Position des Sicherheitsgurtes zu bestimmen; und eine Operation des Fahrzeugs zumindest zum Teil gemäß der bestimmten Position des Sicherheitsgurtes zu initiieren.
Das System nach Anspruch 1, wobei die bestimmte Position des Sicherheitsgurtes eine ist von: einer ersten Position, in der sich der Sicherheitsgurt über eine Schulter des Passagiers erstreckt; einer zweiten Position, in der sich der Sicherheitsgurt unter der Schulter des Passagiers erstreckt; einer dritten Position, in der der Sicherheitsgurt nicht vom Passagier getragen wird; oder einer vierten Position, in der sich der Sicherheitsgurt hinter dem Passagier erstreckt.
Das System nach Anspruch 1 oder 2, wobei die parallelprozessierenden Schaltkreise ferner konfiguriert sind, um die Position des Sicherheitsgurtes zumindest teilweise gemäß einem oder mehreren Maschinenlern-Modellen zu bestimmen, wobei das eine oder die mehreren Maschinenlern-Modelle eines oder mehrere umfassen von: ein erstes Maschinenlern-Modell, das die Daten als Eingabe hat und als Ausgabe die Positionen der Messmarkierungen hat; oder ein zweites Maschinenlern-Modell, das als Eingabe die Positionen der Messmarkierungen hat und als Ausgabe eine oder mehrere Klassifikationen der Positionen der Messmarkierungen hat.
Das System nach Anspruch 3, wobei das eine oder die mehreren Maschinenlern-Modelle unter Verwenden von Daten trainiert sind, die einen oder mehrere der verdeckten welchen der Messmarkierungen repräsentieren.
Das System nach irgendeinem der vorherigen Ansprüche, wobei die parallelprozessierenden Schaltkreise ferner konfiguriert sind, um eines oder mehreres durchzuführen von: Bestimmen einer Größe oder einer Position von einer Komponente des Fahrzeuges aus der Position des Sicherheitsgurtes; Bestimmen einer Größe eines Passagiers, der den Sicherheitsgurt trägt, aus der Position des Sicherheitsgurtes; oder Bestimmen einer Position oder einer Pose des Passagiers, der den Sicherheitsgurt trägt, aus der Position des Sicherheitsgurtes.
Das System nach Anspruch 5, wobei die parallelprozessierenden Schaltkreise ferner dazu konfiguriert sind, die Operation des Fahrzeuges gemäß einem oder mehreren von der bestimmten Größe oder Position der Komponente, der bestimmten Größe des Passagiers oder der bestimmten Position oder Pose des Passagiers zu initiieren.
Das System nach irgendeinem der vorherigen Ansprüche, wobei der Sensor eine Kamera ist und die Daten Bilddaten sind.
Das System nach irgendeinem der vorherigen Ansprüche, wobei die Operation irgendeine ist von Auslösen eines Airbags, einer hörbaren Warnung, einer sichtbaren Warnung, einer Bremsoperation, einem Zündung-Abstellen, oder einem Bewegen von irgendeinem oder mehreren von einem Sicherheitsgurtanker, einem Sicherheitsgurtschloss, oder zumindest eines Abschnitts von einem Sitz.
Das System nach irgendeinem der vorherigen Ansprüche, welches ferner eine Beleuchtungsquelle aufweist, die positioniert ist, um die Messmarkierungen zu beleuchten, während der Sensor die Daten erzeugt.
Das System nach Anspruch 9, wobei die Beleuchtungsquelle eine Infrarot-Beleuchtungsquelle ist und der Sensor ein Infrarot-Sensor ist.
Das System nach irgendeinem der vorherigen Ansprüche, wobei verschiedene welche von den Messmarkierungen entlang einer Länge eines Schultergurtes des Sicherheitsgurtes verteilt sind, um so die Bestimmung von Positionen von der Länge des Schultergutes zu ermöglichen.
Ein Verfahren zum Bestimmen der Position eines Sicherheitsgurtes, wobei das Verfahren aufweist: Empfangen von Daten von einem Sensor, wobei die Daten indikativ für Messmarkierungen sind, die an einer mehreren Komponenten von einem Fahrzeug positioniert sind, wobei die Komponenten des Fahrzeugs einen Sicherheitsgurt des Fahrzeugs einschließen; Bestimmen, unter Verwenden von parallelprozessierenden Schaltkreisen, von Positionen der Komponenten des Fahrzeugs aus den Daten; Verwenden von einem oder mehreren Maschinenlern-Modellen zum Bestimmen einer Position eines Sicherheitsgurtes aus den Positionen der Messmarkierungen; und Initiieren einer Operation des Fahrzeuges zumindest zum Teil gemäß der bestimmten Position des Sicherheitsgurtes.
Verfahren nach Anspruch 12, wobei die Position des Sicherheitsgurtes eine ist von: einer ersten Position, in der sich der Sicherheitsgurt über eine Schulter des Passagiers erstreckt; einer zweiten Position, in der sich der Sicherheitsgurt unter der Schulter des Passagiers erstreckt; einer dritten Position, in der der Sicherheitsgurt nicht vom Passagier getragen wird; oder einer vierten Position, in der sich der Sicherheitsgurt hinter dem Passagier erstreckt.
Das Verfahren nach Anspruch 12 oder 13, ferner aufweisend Trainieren des einen oder mehreren Maschinenlern-Modells gemäß Daten, die indikativ für eine mehrere verdeckte welche der Messmarkierungen sind.
Das Verfahren nach einem der Ansprüche 12 bis 14, wobei die Operation eine ist von Auslösen eines Airbags, einer hörbaren Warnung, einer sichtbaren Warnung, einer Bremsoperation, einem Zündung-Abstellen, oder einem Bewegen von irgendeinem oder mehreren von einem Sicherheitsgurtanker, einem Sicherheitsgurtschloss, oder zumindest eines Abschnitts von einem Sitz.
Das Verfahren nach einem der Ansprüche 12 bis 15, wobei die Messmarkierungen ferner auf einem Sitz des Fahrzeugs positioniert sind und wobei das Bestimmen ferner ein Bestimmen einer Position des Sitzes des Fahrzeugs aufweist.
Das Verfahren nach einem der Ansprüche 12 bis 16, ferner aufweisend eines oder mehreres von: Bestimmen einer Größe oder einer Position von einem Abschnitt des Fahrzeuges, aus der Position des Sicherheitsgurtes; Bestimmen einer Größe eines Passagiers, der den Sicherheitsgurt trägt, aus der Position des Sicherheitsgurtes; oder Bestimmen einer Position oder einer Pose des Passagiers, aus der Position des Sicherheitsgurtes.
Das Verfahren nach Anspruch 17, wobei das Initiieren ferner aufweist, Initiieren der Operation des Fahrzeuges gemäß einem oder mehreren von der bestimmten Größe oder Position des Abschnittes des Fahrzeugs, der bestimmten Größe des Passagiers oder der bestimmten Position oder Pose des Passagiers.
Das Verfahren nach irgendeinem der Ansprüche 12 bis 18, wobei der Sensor eine Kamera ist und die Daten Bilddaten sind.
Das Verfahren nach irgendeinem der Ansprüche 12 bis 19, ferner aufweisend Aktivieren einer Beleuchtungsquelle, um die Messmarkierungen zu beleuchten, während der Sensor die Daten erzeugt.
Das Verfahren nach Anspruch 20, wobei die Beleuchtungsquelle eine Infrarot-Beleuchtungsquelle ist und der Sensor ein Infrarot-Sensor ist.
Das Verfahren nach irgendeinem der Ansprüche 12 bis 21, wobei die Messmarkierungen entlang einer Länge eines Schultergurtes des Sicherheitsgurtes verteilt sind, um so die Bestimmung von Positionen von der Länge des Schultergutes zu ermöglichen.