DE112019000279T5

DE112019000279T5 - Steuern autonomer fahrzeuge anhand sicherer ankunftszeiten

Info

Publication number: DE112019000279T5
Application number: DE112019000279.1T
Authority: DE
Inventors: David Nister; Anton Vorontsov
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-02-09
Filing date: 2019-02-07
Publication date: 2020-08-27
Also published as: US20190250622A1; US11789449B2; US20230418299A1; CN111133448A; WO2019157193A1

Abstract

Bei verschiedenen Beispielen werden Sensordaten, welche für ein Gesichtsfeld von mindestens einem Sensor eines Fahrzeugs in einer Umgebung repräsentativ sind, von dem mindestens einen Sensor erhalten. Basierend zumindest teilweise auf den Sensordaten werden Parameter eines Objekts, welches sich in der Umgebung befindet, bestimmt. Trajektorien des Objekts werden basierend zumindest teilweise auf den Parametern des Objekts zu Zielpositionen modelliert. Von den Trajektorien werden sichere Zeitintervalle (und/oder sichere Ankunftszeiten) berechnet, während welchen das Fahrzeug die mehreren Zielpositionen einnimmt, ohne dass es zu einer Kollision mit dem Objekt kommt. Basierend zumindest teilweise auf den sicheren Zeitintervallen (und/oder sicheren Ankunftszeiten) und einer Position des Fahrzeugs in der Umgebung kann eine Trajektorie für das Fahrzeug erzeugt und/oder analysiert werden.

Description

HINTERGRUND DER ERFINDUNG
Um sicher betrieben zu werden, sollten autonome Fahrzeuge in der Lage sein, einen Weg bzw. Pfad durch eine Umgebung zu durchfahren, ohne mit anderen Objekten (z.B. Fahrzeugen, Personen, Bäumen, Tieren, Gebäuden usw.) zu kollidieren. Um dies zu erreichen, sollten autonome Fahrzeuge bei der Planung von Wegen durch die Umgebung die anderen Objekte berücksichtigen. Konventionelle Ansätze zur Planung eines Weges für ein autonomes Fahrzeug weisen ein Erzeugen einer Heatmap um das autonome Fahrzeug herum für eine bestimmte Zeit in der Umgebung und ein Planen eines Weges für das Fahrzeug unter Verwendung der Heatmap auf. Zur Erzeugung der Heatmap können die Standorte anderer Objekte bestimmt werden, und die Wahrscheinlichkeit, dass das Fahrzeug an bestimmten Standorten mit den anderen Objekten kollidiert, kann zumindest teilweise auf der Grundlage der Objektstandorte bestimmt werden. Die Wahrscheinlichkeiten können durch die Heatmap dargestellt werden und können andere Informationen wie die Unsicherheit der Objektstandorte berücksichtigen.
Die oben beschriebenen konventionellen Ansätze berücksichtigen jedoch mögliche Änderungen der Bewegung oder des Zustands von Objekten in der Umgebung (z.B. Drehzahl, Geschwindigkeit, Beschleunigung usw.) an einem oder mehreren Punkten entlang des Weges nicht. Infolgedessen berücksichtigt ein für ein autonomes Fahrzeug mit diesen konventionellen Ansätzen erzeugter Weg mögliche Kollisionen zwischen dem Fahrzeug und den Objekten möglicherweise nicht vollständig. Dies kann verschiedene Probleme mit sich bringen, die Systeme, die auf diesen Ansätzen beruhen, unsicher machen können. Beispielsweise kann ein Weg bei Verwendung dieser konventionellen Ansätze rasch unsicherer werden, je länger er befahren wird, was dazu führen kann, dass ein System kurze Wege verwenden und die kurzen Wege häufig aktualisieren oder erzeugen muss. Daher können Systeme, die sich auf diese konventionellen Ansätze stützen, unter Umständen nicht genügend Voraussicht aufweisen, um die Systeme so informiert auszugestalten, wie es für ein vollständig autonomes Fahren erforderlich ist. Da die Wege unter Umständen so häufig aktualisiert und/oder erzeugt werden müssen, können zudem erhebliche Rechenressourcen erforderlich sein. Beispielsweise können große Umfänge an Rechenleistung, Energie und Bandbreite erforderlich sein, um die Wege mit einer Rate zu aktualisieren und/oder zu erzeugen, die einen sicheren und effektiven Betrieb von autonomen Fahrzeugen ermöglicht.
ZUSAMMENFASSUNG DER ERFINDUNG
Ausführungsformen der vorliegenden Offenbarung beziehen sich auf ein Steuern von Fahrzeugen (z.B. autonomen Fahrzeugen) anhand sicherer Ankunftszeiten. Im Gegensatz zu konventionellen Ansätzen, wie den oben beschriebenen, berücksichtigt das aktuelle System potenzielle Änderungen der Bewegung und/oder des Zustands von Objekten in einer Umgebung (z.B. Drehzahl, Geschwindigkeit, Orientierung, Beschleunigung usw.), wenn ein Weg für ein Fahrzeug generiert wird, dem es folgen soll, oder wenn die Sicherheit eines vorgeschlagenen Weges analysiert wird. Offenbarte Ansätze können die Planung und Erprobung von Trajektorien für Fahrzeuge in dem Zeit-Raum-Bereich ermöglichen und gleichzeitig potentielle Änderungen bezüglich der Bewegung von Objekten in der Umgebung berücksichtigen. Infolgedessen ist das Vertrauen, dass ein Fahrzeug an keinem Punkt entlang einer Trajektorie für das Fahrzeug mit Objekten in der Umgebung kollidiert, groß. Daher kann das System im Vergleich zu konventionellen Ansätzen längere Wege verwenden, die Wege weniger häufig aktualisieren oder generieren und/oder letztlich sicherere Wege für autonome Fahrzeuge erzeugen.
Bei einigen Beispielen können Sensordaten, die für ein Sichtfeld mindestens eines Sensors in einer Umgebung repräsentativ sind, zur Bestimmung von Parametern eines oder mehrerer in der Umgebung befindlicher Objekte verwendet werden. Aus den Trajektorien können sichere Zeitintervalle berechnet werden, in denen das Fahrzeug, das Zielpositionen einnimmt, nicht mit dem Objekt kollidieren würde. Bei einigen Ausführungsformen wird ein Bild erzeugt, das Datenwerte (z.B. Farbwerte) aufweist, die repräsentativ für sichere Zeitintervalle sind (z.B. für sichere Ankunftszeiten der sicheren Zeitintervalle). Das Bild kann analysiert werden (z.B. unter Verwendung einer oder mehrerer GPUs), um eine Trajektorie durch die Umgebung zu erzeugen, bei der es unwahrscheinlich ist, dass das Fahrzeug mit einem anderen Objekt kollidiert, und/oder um zu prüfen, ob eine vorgeschlagene Trajektorie oder ein vorgeschlagener Weg für das Fahrzeug wahrscheinlich nicht zu einer Kollision mit einem anderen Objekt führt. Bei anderen Ausführungsformen können sichere Zeitintervalle und Trajektorien direkt aus Positionsdaten von Objekten in der Umgebung berechnet werden, ohne ein Bild oder eine andere grafische Darstellung zu erzeugen. Bei weiteren Ausführungsformen kann eine graphische Visualisierung, die Daten aufweist, die eine oder mehrere Linien bzw. Konturen darstellen - wie z.B., ohne Einschränkung, eine Konturkarte bzw. Linienkarte - generiert werden, die repräsentativ für die Zielpositionen und die entsprechenden sicheren Zeitintervalle und/oder sicheren Ankunftszeiten innerhalb der sicheren Zeitintervalle ist. Unter Verwendung der Liniendaten bzw. Konturdaten kann eine Trajektorie für das Fahrzeug erzeugt und/oder analysiert werden, um ein starkes Vertrauen bereitzustellen, dass das Fahrzeug zu keinem Zeitpunkt mit Objekten kollidiert, wenn das Fahrzeug der Trajektorie folgt. Bei einigen Beispielen werden die Konturdaten oder das Bild als Visualisierung auf einem Anzeigegerät, z.B. auf einem HMI-Display (Human Machine Interface) und/oder auf einem Armaturenbrett des Fahrzeugs, dargestellt.
Figurenliste
Die gegenwärtigen Systeme und Verfahren zum Steuern autonomer Fahrzeuge unter Verwendung sicherer Ankunftszeiten werden nachstehend unter Bezugnahme auf die beigefügten Zeichnungen ausführlich beschrieben.

1A ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung, die ein Beispiel für ein System mit sicherer Ankunftszeit bzw. ein System zur Bestimmung einer sicheren Ankunftszeit zeigt.
1B ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung eines Beispiels einer Betriebsumgebung für ein System mit sicherer Ankunftszeit.
2 zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung, die zur Beschreibung von Beispielen von Bewegungsprofilen verwendet wird.
3A ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung, die eine beispielhafte Trajektorie zeigt.
3B ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung eines Teils einer Konturkarte, die sichere Ankunftszeiten repräsentiert.
3C ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung einer Konturkarte, die sichere Ankunftszeiten repräsentiert.
4A ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung einer Visualisierung von sicheren Ankunftszeiten.
4B ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung einer Visualisierung von sicheren Ankunftszeiten.
4C ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung einer Visualisierung von sicheren Ankunftszeiten.
5 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung, die ein Beispiel einer Trajektorie mit einer Visualisierung von sicheren Ankunftszeiten zeigt.
6A ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Datenflussdiagramm, das ein beispielhaftes Verfahren zum Erzeugen einer Trajektorie unter Verwendung von Daten über sichere Ankunftszeiten darstellt.
6B ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung, die ein oder mehrere beispielhafte Modelle für maschinelles Lernen zeigt.
7 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zur Steuerung von autonomen Fahrzeugen unter Verwendung von sicheren Ankunftszeiten zeigt.
8 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zur Steuerung von autonomen Fahrzeugen unter Verwendung von sicheren Ankunftszeiten zeigt.
9 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zur Steuerung von autonomen Fahrzeugen unter Verwendung von sicheren Ankunftszeiten zeigt.
10 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zur Steuerung von autonomen Fahrzeugen unter Verwendung von sicheren Ankunftszeiten zeigt.
11 ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren zur Steuerung von autonomen Fahrzeugen unter Verwendung von sicheren Ankunftszeiten zeigt.
12A ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung eines beispielhaften autonomen Fahrzeugs.
12B zeigt gemäß einigen Ausführungsformen der vorliegenden Offenbarung beispielhafte Kamerastandorte und Sichtfelder für das beispielhafte autonome Fahrzeug der 12A.
12C ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug der 12A.
12D ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Systemdiagramm für eine Kommunikation zwischen Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug von 12A.
13 ist ein Blockdiagramm einer beispielhaften Computervorrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es werden Systeme und Verfahren im Zusammenhang mit der Steuerung autonomer Fahrzeuge anhand sicherer Ankunftszeiten offenbart. Die vorliegende Offenlegung kann mit Bezug auf ein Beispiel für ein autonomes Fahrzeug 140 (hier alternativ als „Fahrzeug 140“ oder „autonomes Fahrzeug 140“ bezeichnet) beschrieben werden, von dem hier ein Beispiel mit Bezug auf die 12A-12D ausführlicher beschrieben wird. Obwohl die vorliegende Offenbarung in erster Linie Beispiele mit autonomen Fahrzeugen enthält, können andere Arten von Objekten unter Verwendung sicherer Ankunftszeiten gesteuert werden. Darüber hinaus können die hier beschriebenen sicheren Ankunftszeiten, sicheren Zeitintervalle und Visualisierungen für andere Zwecke als die Steuerung autonomer Fahrzeuge verwendet werden. Beispielsweise kann eine Visualisierung auf einem HMI-Display und/oder auf einem Armaturenbrett (z.B. des Fahrzeugs) dargestellt werden, ohne zur Steuerung eines autonomen Fahrzeugs verwendet zu werden.
Bei der Wegplanung können konventionelle Systeme eine Heatmap um ein autonomes Fahrzeug für eine bestimmte Zeit in einer Umgebung erzeugen und mit Hilfe der Heatmap einen Weg für das Fahrzeug planen. Zu diesem Zweck können die Positionen anderer Objekte bestimmt werden, und die Wahrscheinlichkeit, dass das Fahrzeug an bestimmten Positionen mit den anderen Objekten kollidiert, kann auf der Grundlage der Objektpositionen bestimmt werden. Die Wahrscheinlichkeiten können durch die Heatmap dargestellt werden und andere Informationen wie die Unsicherheit der Objektpositionen berücksichtigen. Diese konventionellen Ansätze berücksichtigen jedoch keine Änderungen bezüglich der Bewegung von Objekten in der Umgebung (z.B. Drehzahl, Geschwindigkeit, Beschleunigung usw.) an irgendeinem Punkt entlang des Weges, wodurch mögliche Kollisionen zwischen dem Fahrzeug und den Objekten nicht vollständig berücksichtigt werden.
Im Gegensatz dazu ermöglichen die offenbarten Ansätze das Planen und Prüfen von Wegen in einem Zeit-Raum-Bereich unter Berücksichtigung möglicher Änderungen der Bewegung von Objekten in der Umgebung. Als Ergebnis der hier beschriebenen Ansätze gibt es eine größere Gewissheit, dass ein Fahrzeug Kollisionen (die z.B., wie hier verwendet, einem tatsächlichen Kontakt oder einer Annäherung an ein Objekt ohne tatsächlichen Kontakt entsprechen können) mit Objekten in der Umgebung an jedem Punkt entlang eines Weges für das Fahrzeug vermeiden wird.
Im Vergleich zu konventionellen Ansätzen kann das hier beschriebene System längere Wege verwenden, die Wege weniger häufig aktualisieren oder generieren und/oder sicherere Wege für autonome Fahrzeuge verwenden. Beispielsweise können konventionelle Ansätze im Allgemeinen erfassen, wie wahrscheinlich es wäre, dass ein Fahrzeug mit einem Objekt kollidiert, wenn sich das Fahrzeug unter den gegenwärtigen Bedingungen an bestimmten Positionen in der Umgebung befindet. Im Gegensatz dazu können die hier beschriebenen Ansätze verwendet werden, um die gegenwärtigen Bedingungen unter Verwendung eines oder mehrerer Zukunftsszenarien (z.B. eines Worst-Case-Szenarios) zu extrapolieren, um bestimmte Zeiten bzw. Zeitpunkte genau zu definieren, zu denen es sicher oder anderweitig wünschenswert wäre, dass das Fahrzeug diese Positionen erreicht. Diese Positionen und Zeiten können zeitbasierte Gradienten (ähnlich wie Potenzialfelder) um Objekte herum bilden, die die Beziehung zwischen den Positionen und genauen Zeitpunkten erfassen, zu denen ein Fahrzeug diese Positionen sicher oder anderweitig wünschenswert erreicht.
Bei einigen Beispielen können Sensordaten, die für ein Sichtfeld mindestens eines Sensors in einer Umgebung repräsentativ sind, zur Bestimmung von Parametern eines oder mehrerer in der Umgebung befindlicher Objekte verwendet werden. Nicht einschränkende Beispiele für die Parameter weisen einen Ort, eine Pose bzw. Orientierung, eine Geschwindigkeit, eine Abmessung, eine Beschleunigung, eine Masse, eine Klasse des Objekts (z.B. Lastwagen, Person, Limousine usw.) oder einen Typ des Objekts (z.B. Marke und/oder Modell) auf. Unter Verwendung der Parameter des Objekts können die Trajektorien des Objekts zu Zielpositionen in der Umgebung unter einem oder mehreren Szenarien modelliert werden. Jede Trajektorie kann z.B. ein Szenario, in dem das Objekt direkt auf eine bestimmte Zielposition zusteuert, eine Reaktionszeit, nach der das Objekt abzubremsen beginnt (z.B. sobald das Objekt das Fahrzeug erkennt), und/oder einen Zeitpunkt, zu dem das Objekt vollständig zum Stillstand kommt (z.B. ohne das Fahrzeug zu treffen oder zu berühren), modellieren.
Aus den Trajektorien können sichere Zeitintervalle berechnet werden, in denen das Fahrzeug, das die Zielpositionen einnimmt, nicht zu einer Kollision mit dem Objekt führen würde. Beispielsweise kann ein sicheres Zeitintervall für jede Zielposition zu einem bestimmten Zeitpunkt beginnen und zu dem Zeitpunkt enden, zu dem das Objekt vor der Kollision mit dem Fahrzeug gegebenenfalls vollständig zum Stillstand kommt. Unter Verwendung der sicheren Zeitintervalle und einer Position des Fahrzeugs in der Umgebung kann eine Trajektorie für das Fahrzeug generiert und/oder analysiert werden, um eine starke Sicherheit zu bieten, dass das Fahrzeug an jedem Punkt (der Trajektorie) eine Kollision mit Objekten vermeidet, wenn das Fahrzeug der Trajektorie folgt. Die Trajektorie kann beispielsweise erzeugt oder analysiert werden, um sicherzustellen, dass das Fahrzeug an jeder der Zielpositionen innerhalb der korrespondierenden sicheren Zeitintervalle ankommt, bei denen das Fahrzeug, das die Zielpositionen einnimmt, nicht in eine Kollision verwickelt wäre.
Bei einigen Beispielen wird ein Bild erzeugt, das Datenwerte (z.B. Farbwerte) aufweist, die zumindest für Teile der sicheren Zeitintervalle repräsentativ sind, zu denen ein Fahrzeug, das Zielpositionen besetzt, nicht zu einer Kollision führen würde. Beispielsweise kann jeder Datenwert (z.B. ein Pixelwert) ein sicheres Zeitintervall oder eine oder mehrere sichere Ankunftszeiten innerhalb des sicheren Zeitintervalls und eine oder mehrere entsprechende Zielpositionen repräsentieren. Das Bild kann analysiert werden (z.B. unter Verwendung einer oder mehrerer GPUs), um eine Trajektorie durch die Umgebung zu erzeugen, bei der es unwahrscheinlich ist, dass das Fahrzeug mit einem anderen Objekt kollidiert, und/oder um zu prüfen, ob eine vorgeschlagene Trajektorie oder ein vorgeschlagener Weg für das Fahrzeug wahrscheinlich nicht zu einer Kollision mit einem anderen Objekt führt. Beispielsweise können die Datenwerte repräsentativ für bestimmte sichere Ankunftszeiten innerhalb der sicheren Zeitintervalle für bestimmte Zielpositionen in der Umgebung sein. Bei anderen Ausführungsformen können sichere Zeitintervalle und/oder Trajektorien unter Verwendung von Positionsdaten erzeugt werden, die mit Hilfe von Sensordaten (z.B. LIDAR-Informationen) berechnet wurden, ohne dass ein Bild oder eine Referenz auf Daten oder Pixelwerte erzeugt wird. Die Trajektorie für das Fahrzeug kann im Zeitbereich und im Raumbereich aufgetragen werden, um sicherzustellen, dass alle geplanten oder vorgeschlagenen Ankunftszeiten des Fahrzeugs auf der Trajektorie zu den Zielpositionen vor den jeweiligen Zeiten liegen, wodurch eine starke Sicherheit gegeben ist, dass das Fahrzeug an keinem Punkt (der Trajektorie) mit Objekten in der Umgebung kollidiert, wenn das Fahrzeug der Trajektorie folgt.
Bei jedem Beispiel kann eine graphische Darstellung, die Daten für eine oder mehrere Linien (z.B. in einer Konturkarte) aufweist, erzeugt und/oder bestimmt werden, die repräsentativ für die Zielpositionen und die entsprechenden sicheren Zeitintervalle und/oder sicheren Ankunftszeiten innerhalb der sicheren Zeitintervalle ist. Zum Beispiel kann jede Linie bzw. Kontur einer Gruppe von Zielpositionen und einer bestimmten sicheren Ankunftszeit des Fahrzeugs entsprechen. Bei Beispielen, die Datenwerte (z.B. eines Bildes) zur Darstellung der Konturkarte verwenden, können die Datenwerte für Zielpositionen, die eine gleiche sichere Ankunftszeit (und/oder ein sicheres Zeitintervall) haben, den gleichen Wert haben. Unter Verwendung der Konturdaten und einer Position eines Fahrzeugs in der Umgebung kann eine Trajektorie für das Fahrzeug generiert und/oder analysiert werden, um eine starke Sicherheit zu bieten, dass das Fahrzeug an keinem Punkt (der Trajektorie) mit Objekten kollidiert, wenn das Fahrzeug der Trajektorie folgt.
Dies kann beispielsweise das Erzeugen und/oder Analysieren der Trajektorie enthalten, um sicherzustellen, dass das Fahrzeug zu den entsprechenden geplanten oder vorgeschlagenen Ankunftszeiten des Fahrzeugs auf der Trajektorie keine der Konturen schneidet. Bei einigen Beispielen wird die Konturenkarte als Visualisierung angezeigt, z.B. auf einem HMI-Display und/oder einem Armaturenbrett des Fahrzeugs.
Unter Bezugnahme auf 1A zeigt 1A gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung, die ein Beispiel für das System 100 mit sicheren Ankunftszeiten zeigt. Es ist klar, dass diese und andere hier beschriebene Vorkehrungen nur als Beispiele aufgeführt sind. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Ordnungen und Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können aus Gründen der Klarheit ganz weggelassen werden. Darüber hinaus 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 an jeder geeigneten Stelle implementiert werden können. Verschiedene hier beschriebene Funktionen, die von einer oder mehreren Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können einige Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt.
Das System 100 mit sicheren Ankunftszeiten kann Sensordaten 102 empfangen, die für eine Umgebung 126 repräsentativ sind, und die Sensordaten 102 verwenden, um mindestens eine sichere Ankunftszeit für ein autonomes Fahrzeug, wie z.B. ein Fahrzeug 140, an mindestens einer Position in der Umgebung 126 zu berechnen. Bei einigen Beispielen kann die mindestens eine sichere Ankunftszeit verwendet werden, um Fahrzeug-Trajektorieninformationen 124 (z.B. Daten, die für eine Trajektorie 144 repräsentativ sind) für das autonome Fahrzeug zu generieren und/oder um die Fahrzeug-Trajektorieninformationen 124 zu analysieren, die für eine vorgeschlagene Trajektorie oder einen Weg 144 für das autonome Fahrzeug repräsentativ sind. Die mindestens eine sichere Ankunftszeit kann in den Daten zur sicheren Ankunftszeit 120 erfasst werden, die im gezeigten Beispiel ein Bild umfassen. Die mindestens eine sichere Ankunftszeit kann jedoch in einer anderen Form erfasst werden, ohne vom Umfang der vorliegenden Offenlegung abzuweichen.
Bei einer oder mehreren Ausführungsformen weist das System 100 mit sicheren Ankunftszeiten z.B. einen Kommunikationsmanager 104, einen Objektanalysator 106, einen Objektmodellierer 108, einen Objekttrajektorienanalysator 110, einen Visualisierungsgenerator 112, einen Analysator 114 für einen vorgeschlagenen Weg oder für eine vorgeschlagene Trajektorie und einen Weg- oder Trajektoriengenerator 116 auf.
Als Übersicht kann der Kommunikationsmanager 104 so ausgestaltet sein, dass er Kommunikationen verwaltet, die von dem System 100 mit sichere Ankunftszeiten empfangen (z.B. die Sensordaten 102 und/oder die Fahrzeugtrajektorieninformationen 124 umfassen) und/oder von dem System 100 mit sicheren Ankunftszeiten bereitgestellt werden (z.B. die Daten 120 für sichere Ankunftszeiten und/oder die Fahrzeugtrajektorieninformationen 124 umfassen). Der Objektanalysator 106 kann so ausgestaltet sein, dass er Objekte in der Umgebung unter Verwendung der Sensordaten 102 analysiert. Der Objektmodellierer 108 kann so ausgestaltet sein, dass er Objekte, wie z.B. die Trajektorien der Objekte in der Umgebung 126, zumindest teilweise auf der Grundlage der vom Objektanalysator 106 durchgeführten Analyse modelliert. Der Objekttrajektorienanalysator 110 kann so ausgestaltet sein, dass er Trajektorien von Objekten analysiert, wie z.B. Trajektorien, die vom Objektmodellierer 108 modelliert werden, um die sicheren Ankunftszeiten für das Fahrzeug 140 zu berechnen. Der Visualisierungsgenerator 112 kann mindestens eine Visualisierung erzeugen, die zumindest teilweise auf den sicheren Ankunftszeiten basiert, wie z.B. das Bild, das durch die Daten der sicheren Ankunftszeit 120 dargestellt wird. Der Analysator 114 des vorgeschlagenen Wegs oder der vorgeschlagenen Trajektorie kann so ausgestaltet sein, dass er eine vorgeschlagene Trajektorie oder einen vorgeschlagenen Weg (z.B. dargestellt durch die Fahrzeug-Trajektorieninformationen 124) unter Verwendung der Daten der sicheren Ankunftszeiten 120 (z.B. das Bild, das durch die Daten der sicheren Ankunftszeiten 120 dargestellt wird) analysiert. Der Weg- oder Trajektoriengenerator 116 kann so ausgestaltet sein, dass er eine Trajektorie (z.B. dargestellt durch die Fahrzeug-Trajektorieninformationen 124) unter Verwendung der Daten 120 der sicheren Ankunftszeiten (z.B. das durch die Daten 120 der sicheren Ankunftszeiten dargestellte Bild) erzeugt.
Das System 100 mit sicheren Ankunftszeiten kann in einer beispielhaften Betriebsumgebung 130 von 1B gemäß einigen Ausführungsformen der vorliegenden Offenbarung implementiert werden. Neben anderen nicht abgebildeten Komponenten weist die Betriebsumgebung 130 ein oder mehrere Client-Gerät(e) 132, ein oder mehrere Netzwerk(e) 134, ein oder mehrere Server-Gerät(e) 136, einen oder mehrere Sensoren 138 und einen oder mehrere Datenspeicher 146 auf. Es ist klar, dass die in 1B dargestellte Betriebsumgebung 130 ein Beispiel für eine geeignete Betriebsumgebung ist. Jede der in 1B gezeigten Komponenten kann durch jede Art von Rechenvorrichtung implementiert werden, wie z.B. eine oder mehrere der in Verbindung mit 13 beschriebenen Rechenvorrichtungen bzw. Rechengeräten 1300. Diese Komponenten können über das Netzwerk 134 miteinander kommunizieren, das drahtgebunden, drahtlos oder beides sein kann. Das Netzwerk 134 kann mehrere Netzwerke oder ein Netzwerk von Netzwerken aufweisen, wird jedoch in einfacher Form dargestellt, um Aspekte der vorliegenden Offenbarung nicht zu verdecken. Beispielsweise kann das Netzwerk 134 ein oder mehrere Wide Area Networks (WANs), ein oder mehrere Local Area Networks (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein oder mehrere private Netzwerke aufweisen. Wenn das Netzwerk 134 ein drahtloses Telekommunikationsnetzwerk aufweist, können Komponenten wie eine Basisstation, ein Kommunikationstower oder sogar Zugangspunkte (wie auch andere Komponenten) eine drahtlose Verbindung bereitstellen. Bei jedem Beispiel kann mindestens ein Netzwerk 134 dem (den) Netzwerk(en) 1290 von 12D entsprechen, das (die) im Folgenden beschrieben wird (werden).
Es ist klar, dass im Rahmen der vorliegenden Offenbarung eine beliebige Anzahl der Client-Geräte 132, der Server-Geräte 136, der Sensoren 138 und der Datenspeicher 146 innerhalb der Betriebsumgebung 130 eingesetzt werden können. Jedes kann als Einzelgerät oder als mehrere Geräte ausgestaltet sein, die in einer verteilten Umgebung zusammenarbeiten.
Das (die) Client-Gerät(e) 132 kann (können) zumindest einige der Komponenten, Merkmale und Funktionen der hier in Bezug auf 13 beschriebenen beispielhaften Rechenvorrichtung 1300 aufweisen. Als Beispiel und nicht als Einschränkung kann ein Client-Gerät 132 als ein Personal Computer (PC), ein Laptop-Computer, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smart-Uhr, ein tragbarer Computer, ein persönlicher digitaler Assistent (PDA), ein MP3-Player, ein globales Positionsbestimmungssystem (GPS) oder Gerät, ein Videoabspielgerät, ein tragbares Kommunikationsgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeug-Computersystem, ein Steuergerät für eingebettete Systeme, eine Fernbedienung, ein Apparat, ein Gerät der Unterhaltungselektronik, eine Arbeitsstation, eine beliebige Kombination dieser beschriebenen Geräte oder jedes andere geeignete Gerät ausgestaltet sein. Bei jedem Beispiel kann mindestens ein Client-Gerät 132 Teil eines Fahrzeugs sein, wie z.B. des Fahrzeugs 140 der 12A-12D, das hier näher beschrieben wird.
Das (die) Client-Gerät(e) 132 kann (können) einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien aufweisen. Die computerlesbaren Medien können computerlesbare Anweisungen aufweisen, die von dem einen oder den mehreren Prozessoren ausgeführt werden können. Die Anweisungen können, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, eine beliebige Kombination und/oder einen beliebigen Teil der hier beschriebenen Verfahren auszuführen und/oder einen beliebigen Teil der Funktionalität des Systems 100 mit sicheren Ankunftszeiten von 1A zu implementieren.
Das (die) Servergerät(e) 136 kann (können) auch einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien aufweisen. Die computerlesbaren Medien weisen computerlesbare Anweisungen auf, die von dem einen oder den mehreren Prozessoren ausgeführt werden können. Die Anweisungen können, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, eine beliebige Kombination und/oder einen beliebigen Teil der hier beschriebenen Verfahren auszuführen und/oder einen beliebigen Teil der Funktionalität des Systems 100 mit sicheren Ankunftszeiten von 1A zu implementieren. Bei jedem Beispiel kann mindestens ein Server-Gerät 136 dem/den Server(n) 1278 aus 12D entsprechen, die hier näher beschrieben sind.
Der (die) Datenspeicher 146 kann (können) ein oder mehrere computerlesbare Medien umfassen. Die computerlesbaren Medien können computerlesbare Anweisungen aufweisen, die von einem oder mehreren Prozessoren ausgeführt werden können. Die Anweisungen können, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, eine beliebige Kombination und/oder einen beliebigen Teil der hier beschriebenen Verfahren auszuführen und/oder einen beliebigen Teil der Funktionalität des Systems 100 mit sicheren Ankunftszeiten von 1A zu implementieren. Der (die) Datenspeicher 146 (oder Computerdatenspeicher) wird (werden) als eine einzelne Komponente dargestellt, kann (können) jedoch als ein oder mehrere Datenspeicher (z.B. Datenbanken) ausgestaltet sein und sich zumindest teilweise in der Cloud befinden. Einer oder mehrere der Datenspeicher 146 können mit einem oder mehreren der Datenspeicher von 12C übereinstimmen.
Obwohl sie außerhalb des/der Server-Gerätes/e 136 und des/der Client-Gerätes/e 132 dargestellt sind, kann/können der/die Datenspeicher 146 zumindest teilweise in jeder beliebigen Kombination des/der Server-Gerätes/e 136 und/oder des/der Client-Gerätes/e 132 enthalten sein (z.B. als Speicher 1304 (13)). Beispielsweise können einige Informationen auf einem oder mehreren Client-Gerät(en) 132 gespeichert sein, und andere und/oder doppelte Informationen können extern (z.B. auf einem oder mehreren Server-Geräten 136) gespeichert sein. Daher ist klar, dass Informationen in dem/den Datenspeicher(n) 146 auf jede geeignete Art und Weise über einen oder mehrere Datenspeicher zur Speicherung (die extern gehostet werden können) verteilt werden können. Zum Beispiel kann der/die Datenspeicher 146 mindestens einen Teil des einen oder der mehreren computerlesbaren Medien des/der Server-Gerätes/e 136 und/oder mindestens einen Teil des einen oder der mehreren computerlesbaren Medien des/der Client-Gerätes/e 132 umfassen.
Der (die) Sensor(en) 138 umfassen mindestens einen Sensor, der in der Lage ist, Sensordaten zu erzeugen, die repräsentativ für mindestens einen Aspekt einer Umgebung sind. Der/die Sensor(en) 138 kann/können zum Beispiel die Sensordaten 102 von 1A erzeugen. Der/die Sensor(en) 138 kann/können eine beliebige Kombination sein aus einem/mehreren GNSS-Sensor(en) (z.B. Global Positioning System (GPS) Sensor(en)), RADAR-Sensor(en), Ultraschallsensor(en), LIDAR-Sensor(en), Inertial Measurement Unit (IMU) Sensor(en) (z.B. Beschleunigungsmesser(n), Gyroskop(e), Magnetkompass(e), Magnetometer(n) usw.), Mikrofon(e), Stereokamera(s), Weitwinkelkamera(s) (z.B. Fisheye-Kameras), Infrarotkamera(s), Surround-Kamera(s) (z.B. 360-Grad-Kameras), Fern- und/oder Mittelbereichskamera(s), Geschwindigkeitssensor(en) (z.B. zur Messung der Geschwindigkeit des Fahrzeugs 140), Vibrationssensor(en), Lenksensor(en), Bremssensor(en) (z.B. als Teil des Bremssensorsystems) und/oder andere Sensortypen.
Bei einigen Beispielen können die Sensordaten 102 von nach vorn und/oder zur Seite gerichteten Kameras erzeugt werden, wie z.B. einer oder mehreren Weitwinkelkameras 1270, einer oder mehreren Surround-Kameras 1274, einer oder mehreren Stereokameras 1268 und/oder einer oder mehrerer Fern- oder Mittelbereichskameras 1298. Bei einigen Beispielen kann mehr als eine Kamera oder ein anderer Sensor verwendet werden, um mehrere Sichtfelder zu erfassen (z.B. das Sichtfeld der Fernkamera(s) 1298, der nach vorn gerichteten Stereokamera(s) 1268 und/oder der nach vorn gerichteten Weitwinkelkamera(s) 1270 von Fig.. 12B).
Die Komponenten von 1A können im Allgemeinen mit einer beliebigen Kombination aus Client-Gerät(en) 132 und Server-Gerät(en) 136 implementiert werden. Es ist daher zu berücksichtigen, dass das System 100 mit sicheren Ankunftszeiten über mehrere in einer verteilten Umgebung angeordnete Geräte bereitgestellt werden kann, die zusammen die hier beschriebene Funktionalität bieten, oder in einer einzigen Ausführungsform (z.B. dem Fahrzeug 140) enthalten sein kann. Während sich also einige Beispiele, die zur Beschreibung des Systems 100 mit sicheren Ankunftszeitsystems 100 verwendet werden, auf bestimmte Vorrichtungen und/oder Konfigurationen beziehen können, wird in Betracht gezogen, dass diese Beispiele allgemeiner auf die oben beschriebenen möglichen Kombinationen von Vorrichtungen und Konfigurationen anwendbar sein können. Beispielsweise können bei einigen Ausführungsformen mindestens einige der Sensoren 138, die zur Erzeugung eines oder mehrerer Teile der Sensordaten 102 verwendet werden, auf mehrere Fahrzeuge und/oder Objekte in der Umgebung verteilt sein, und/oder mindestens einer der Sensoren 138 kann in dem Fahrzeug 140 vorhanden sein.
Wie vorab erwähnt ist, kann der Kommunikationsmanager 104 so ausgestaltet sein, dass er Kommunikationen verwaltet, die von dem System 100 mit sicheren Ankunftszeiten empfangen (z.B. die Sensordaten 102 und/oder die Fahrzeug-Trajektorieninformationen 124 umfassen) und/oder von dem System 100 mit sicheren Ankunftszeiten bereitgestellt werden (z.B. die sichere Ankunftszeitdaten 120 und/oder die Fahrzeug-Trajektorieninformationen 124 umfassen).
Wenn eine Kommunikation als Netzkommunikation empfangen und/oder bereitgestellt wird, kann der Kommunikationsmanager 104 eine Netzschnittstelle umfassen, die eine oder mehrere drahtlose Antenne(n) 1226 und/oder Modem(s) zur Kommunikation über ein oder mehrere Netze verwenden kann. Die Netzschnittstelle kann z.B. die Kommunikation über Long-Term Evolution (LTE), Wideband Code-Division Multiple Access (WCDMA), Universal Mobile Telecommunications Service (UMTS), Global System for Mobile Communications (GSM), CDMA2000 usw. ermöglichen. Die Netzschnittstelle kann auch die Kommunikation zwischen Objekten in der Umgebung (z.B. Fahrzeuge, mobile Geräte usw.) unter Verwendung von lokalen Netzen wie Bluetooth, Bluetooth Low Energy (LE), Z-Wave, Zig-Bee usw. und/oder Low Power Wide Area Network(s) (LPWANs) wie Long Range Wide Area Network (LoRaWAN), SigFox usw. ermöglichen. Der Kommunikationsmanager 104 braucht jedoch keine Netzwerkschnittstelle aufzuweisen, z.B. wenn das System 100 mit sicheren Ankunftszeiten vollständig in einem autonomen Fahrzeug (z.B. dem Fahrzeug 140) implementiert ist. Bei einigen Beispielen kann eine oder können mehrere der hier beschriebenen Kommunikationen zwischen den Komponenten einer Rechenanlage 1300 über einen Bus 1302 von 13 erfolgen.
Die Sensordaten 102 können unter Verwendung einer beliebigen Kombination der Sensoren 138 erzeugt werden. Die Sensordaten 102 können z.B. Bilddaten aufweisen, die ein Bild (Bilder) repräsentieren, Bilddaten, die ein Video repräsentieren (z.B. Schnappschüsse von einem Video), und/oder Sensordaten, die Sichtfelder von Sensoren repräsentieren (z.B. LIDAR-Sensor(en) 1264, RADAR-Sensor(en) 1260, eine Kamera (Kameras) von 12B, usw.). Im gezeigten Beispiel enthalten die Sensordaten 102 Bilddaten, die die Sichtfelder der jeweiligen Kameras des Fahrzeugs 140 darstellen, die ein oder mehrere Bilder 118A, 118B und 118C aufweisen können. Die Bilder 118A, 118B und 118C können Regionen der Umgebung 126 darstellen, wobei die Regionen eine beliebige Anzahl von Objekten aufweisen können. Beispiele hierfür sind die Objekte 128A, 128B, 128C und 128D. Die Objekte können jede beliebige Kombination von Fahrzeugen, Personen (z.B. Fußgänger), Motorrädern, Radfahrern, Bäumen, Tieren, Gebäuden, Schildern oder anderen Strukturen, Objekten oder Hindernissen aufweisen, mit denen das Fahrzeug 140 innerhalb der Umgebung 126 kollidieren kann.
Die Sensordaten 102 können dem Objektanalysator 106 zur Verfügung gestellt und von dem Objektanalysator 106 zur Analyse von Objekten in der Umgebung 126 verwendet werden. Beispielsweise kann der Objektanalysator 106 eines oder mehrere der Objekte 128A, 128B, 128C und 128D erkennen, das eine oder die mehreren Objekte identifizieren und/oder Parameter des einen oder der mehreren Objekte unter Verwendung der Sensordaten 102 bestimmen. Zu diesem Zweck kann der Objektanalysator 106 ein oder mehrere Modelle des maschinellen Lernens verwenden. Beispielsweise und ohne Einschränkung kann (können) das (die) Modell(e) des maschinellen Lernens jede Art von Modell(en) des maschinellen Lernens aufweisen, wie z.B. ein (oder mehrere) Modell(e) des maschinellen Lernens mit linearer Regression, logistischer Regression, Entscheidungsbäumen, Support Vector Machines (SVM), Naive Bayes, k-nearest neighbor (Knn), K-Means-Clustering, Random Forest, Dimensionalitätsreduktionsalgorithmen, Gradientenverstärkungsalgorithmen, neuronale Netze (z.B, Autocodierer, Faltungsalgorithmen, wiederkehrende Algorithmen, Perceptrons, Lang-/Kurzzeitgedächtnis/LSTM, Hopfield, Boltzmann, Deep Believe, Entfaltungsalgorithmen, generativ kontradiktorische Algorithmen, Liquid State Machine, usw.) und/oder andere Arten von Modellen zum maschinellen Lernen.
Beispiele für Parameter eines Objekts, die der Objektanalysator 106 mit Hilfe der Sensordaten 102 bestimmen kann, weisen einen oder mehrere auf von einem Ort (z.B. in der Umgebung 126, wie z.B. Ortskoordinaten), einer Pose, einer aktuellen und/oder beobachteten Geschwindigkeit, einer maximalen Geschwindigkeit, einer vorhergesagten Geschwindigkeit, mindestens einer Abmessung (z.B, physikalische Abmessungen, wie eine Länge, eine Breite, eine Standfläche, eine Höhe, usw.), eine aktuelle und/oder beobachtete Beschleunigung oder Verzögerung, eine maximale Beschleunigung oder Verzögerung, eine vorhergesagte Beschleunigung oder Verzögerung, eine Masse, eine Reaktionszeit und/oder andere Parameter, wie z.B., aber nicht beschränkt auf die hier beschriebenen. Einer oder mehrere der Parameter können eine beobachtete Eigenschaft des Objekts (z.B. einen Ort/eine Position) und einer oder mehrere der Parameter können eine abgeleitete Eigenschaft des Objekts (z.B. maximale Beschleunigung) darstellen.
Bei einigen Beispielen kann/können (ein) Parameter eines Objekts eine/mehrere Ausgabe(n) eines Modells zum maschinellen Lernen sein, wie z.B. eines faltenden neuronalen Netzes, das zumindest einen Teil der Sensordaten 102 als Eingabe(n) erhält. Bei weiteren Beispielen kann der Objektanalysator 106 mindestens ein oder mehrere Modelle des maschinellen Lernens verwenden, um eines oder mehrere der von den Sensordaten 102 erfassten Objekte zu klassifizieren. Beispiele für Klassifikationen weisen stationäre oder sich bewegende Fahrzeuge, Pkw, Lkw, Fußgänger, Radfahrer, Motorräder usw. auf.
Der Objektanalysator 106 kann die Klassifikationen verwenden, um einen oder mehrere der Parameter zu bestimmen. Beispielsweise kann eine Klassifikation als eine Eingabe für ein oder mehrere Modelle des maschinellen Lernens bereitgestellt werden, die zur Bestimmung eines oder mehrerer Parameter verwendet werden. Als weiteres Beispiel können eine oder mehrere Klassifikationen und/oder andere Objektinformationen (z.B. andere Parameter) auf eine Nachschlagetabelle(n) angewandt oder anderweitig verwendet werden, um einen oder mehrere der Parameter nachzuschlagen, zu bestimmen und/oder zu berechnen. Als Beispiel kann eine Klassifikation ein Fahrzeugmodell oder einen Fahrzeugtyp (z.B. Limousine, LKW, Motorrad, SUV) aufweisen, das/der eine oder mehrere vorbestimmte Formen und/oder Abmessungen, Bremsfähigkeiten, Handlingeigenschaften, Beschleunigungsfähigkeiten, maximale Geschwindigkeit, maximale Beschleunigung usw. hat, die zur Definition eines oder mehrerer Parameter verwendet werden können. Bei einigen Beispielen kann (können) ein (oder mehrere) Modell(e) des maschinellen Lernens, wie z.B. ein faltendes neuronales Netz, trainiert werden, um gleichzeitig eine Klassifizierung eines Objekts und einen oder mehrere Parameter des Objekts auszugeben.
Als Beispiel kann der Objektanalysator 106 die Objektwahrnehmung mit Hilfe eines oder mehrerer Modelle des maschinellen Lernens (z.B. ein oder mehrere neuronale Netze) implementieren, die spezifisch ausgestaltet (z.B. trainiert) sein können, um bestimmte Objekte und/oder Merkmale der Objekte zu erkennen. Ein oder mehrere trainierte maschinelle Lernmodelle (z.B. trainiert und eingesetzt für die Verwendung durch das System 100 mit sicheren Ankunftszeiten), die vom Objektanalysator 106 verwendet werden, können das Vorhandensein und/oder die Position eines Objekts (z.B. X- und Y-Koordinaten), die Pose (φ) des Objekts, die Abmessungen des Hindernisses (z.B. Breite und Länge) und/oder eine Klassifizierung für das Objekt bestimmen. Darüber hinaus kann ein trainiertes Modell zum maschinellen Lernen (z.B. ein oder mehrere neuronale Netze) verwendet werden, um die maximale Beschleunigung (A_MAX+) und die maximale Verzögerung (A_MAX-) des Objekts zu bestimmen.
Als weitere Beispiele kann die Reaktionszeit eines Objekts (T_REACT) mit Hilfe eines trainierten Modells zum maschinellen Lernen (z.B. eines neuronalen Netzes oder neuronaler Netze) bestimmt werden, das den Objekttyp (z.B. eine Objektklassifikation) identifiziert oder ausgibt und/oder eine entsprechende Reaktionszeit zuweist. Die Reaktionszeit eines Objekts kann einen zukünftigen Zeitpunkt darstellen, ab dem oder bis zu dem die Bewegung des Objekts durch die Anwesenheit eines anderen Objekts, wie z.B. des Fahrzeugs 140, in der Umgebung 126 beeinflusst wird. Dies kann damit übereinstimmen, dass das Objekt wahrnimmt, bemerkt und/oder feststellt, dass an einer Zielposition in der Umgebung eine Kollision mit dem anderen Objekt stattfinden kann. Zum Beispiel kann ein Fußgänger, der auf sein Smartphone starrt, eine lange Reaktionszeit T_REACT haben. Ebenso kann ein Radfahrer oder Motorradfahrer, der von der Zielposition weg schaut, eine längere Reaktionszeit T_REACT haben als z.B. ein aufmerksamer Fahrer. Im Gegensatz dazu kann ein Objekt, das ein autonomes Fahrzeug ist (z.B. ein Robot-Taxi), eine kurze Reaktionszeit T_REACT haben, da ein autonomes Fahrzeug weniger anfällig für Ablenkung ist und davon ausgegangen werden kann, dass es Objekte auf seinem Weg überwacht und schneller auf die Objekte reagiert als ein menschlicher Fahrer.
Der Objektanalysator kann beispielsweise eines oder mehrere der Objekte 128A, 128B, 128C und 128D erkennen, eines oder mehrere der Objekte 128A, 128B, 128C und 128D identifizieren und/oder Parameter und/oder Klassifikationen des einen oder der mehreren Objekte 128A, 128B, 128C und 128D bestimmen (z.B. ausgeführt auf dem Fahrzeug 140 und/oder dem/den Server(n) 1278) unter Verwendung der Sensordaten 102 und/oder anderer Informationen, die von einem oder mehreren der Objekte 128A, 128B, 128C und 128D, dem/den Sensor(en) 138 und/oder dem/den Client-Gerät(en) 132 in der Betriebsumgebung 130 empfangen werden. Zum Beispiel kann der Kommunikationsmanager 104 entsprechende Daten über das/die Netzwerk(e) 134 empfangen. Darüber hinaus kann der Objektanalysator 106 ein oder mehrere Objekte erkennen, identifizieren und/oder Parameter und/oder Klassifikationen bestimmen, die möglicherweise nicht direkt durch die Sensordaten 102 repräsentiert werden, jedoch vom Objektanalysator 106 hergeleitet, vorhergesagt oder anderweitig als vorhanden oder potentiell vorhanden bestimmt werden können (z.B. zumindest teilweise auf der Grundlage der Sensordaten 102). Dies kann verwendet werden, um blinde Ecken oder Flecken bei der Wahrnehmung durch das System 100 mit sicheren Ankunftszeiten zu berücksichtigen.
Der Objektmodellierer 108 kann so ausgestaltet sein, dass er eines oder mehrere der Objekte 128A, 128B, 128C und 128D in der Umgebung 126 zumindest teilweise auf der Grundlage der vom Objektanalysator 106 durchgeführten Analyse modelliert (z.B. zumindest teilweise auf der Grundlage des einen oder der mehreren Parameter, die mit dem/den Objekt(en) verbunden sind). Zusätzlich oder alternativ kann der Objektmodellierer 108 eines oder mehrere der Objekte 128A, 128B, 128C und 128D aus der Modellierung herausfiltern (z.B. aus der Trajektorienmodellierung). Beispielsweise kann der Objektmodellierer 108 ein Objekt zumindest teilweise auf der Grundlage einer Klassifizierung des Objekts (z.B. als stationär) und/oder zumindest teilweise auf der Grundlage eines Objekttyps herausfiltern. Zusätzlich oder alternativ dazu kann der Objektmodellierer 108 eines oder mehrere der Objekte 128A, 128B, 128C und 128D herausfiltern, zumindest teilweise auf der Grundlage eines oder mehrerer Parameter des Objekts/der Objekte, wie z.B. auf einem oder mehreren Parametern, die von dem Objektanalysator 106 bestimmt wurden (z.B. Herausfiltern von Objekten, zumindest teilweise auf der Grundlage von Positionen der gefilterten Objekte, die sich jenseits einer Schwellenentfernung von dem Fahrzeug 140 befinden). Diese Filterung kann die zur Bestimmung sicherer Ankunftszeiten verwendete Rechenleistung verringern und kann ferner zur Verbesserung der Trajektorienmodellierung und -generierung bei Fahrspur-Fahrszenarien mit Fahrzeugen, die parallel zu dem interessierenden Fahrzeug auf benachbarten Fahrspuren fahren, oder in Bezug auf einen Gegenverkehr verwendet werden.
Der Objektmodellierer 108 kann jeden geeigneten Ansatz zur Modellierung der Objekte in der Umgebung 126 verwenden, z.B. durch Darstellung jedes Objekts z.B. als eine radiale Distanzfunktion oder durch eine Liste bekannter Positionen des Objekts in der Umgebung 126 (z.B. dargestellt als eine Ebene). Die Darstellung eines Objekts kann z.B. durch mindestens einen Abmessungsparameter (z.B. Breite, Länge), einen Lageparameter (z.B. X, Y in der Umgebung 126) und/oder eine mit dem Objektanalysator 106 ermittelte Pose bzw. Ausrichtung des Objekts definiert werden. Optional kann ein Sicherheitspuffer in der Darstellung eines Objekts (z.B. durch Erweiterung seiner Abmessungen) enthalten sein. Ein Modell für ein Objekt kann ferner einen oder mehrere Bewegungsvektoren des Objekts aufweisen, wie z.B. aktuelle und/oder momentane Bewegungsvektoren (z.B. beobachtete Bewegungsvektoren, die aus den Sensordaten 102 abgeleitet werden). Beispielsweise kann jedes Objekt einen Bewegungsvektor und einen Beschleunigungsvektor haben, die unter Verwendung mindestens eines Parameters definiert sind, der mit Hilfe des Objektanalysators 106 für das Objekt bestimmt wurde (z.B. unter Verwendung der Pose, Beschleunigung/Verzögerung und Geschwindigkeit des Objekts). Der Objektmodellierer 108 kann ferner ein Objekt unter Verwendung seiner maximalen Beschleunigungs- und/oder Verzögerungsparameter, seines maximalen Geschwindigkeitsparameters und/oder seines Masseparameters modellieren.
Der Objektmodellierer 108 kann eine oder mehrere Trajektorien eines Objekts mit Hilfe einer Darstellung oder eines Modells des Objekts modellieren. Zu diesem Zweck kann der Objektmodellierer 108 ein oder mehrere Bewegungsprofile auf die Darstellung des Objekts anwenden, um die Geschwindigkeit und Beschleunigung des Objekts zu bestimmten Zeiten und an bestimmten Orten entlang einer Trajektorie für das Objekt in der Umgebung 126 zu definieren.
Unter Bezugnahme auf 2 weist 2 ein Diagramm 200 auf, das Beispiele von Bewegungsprofilen aufweist, die zur Definition modellierter Trajektorien von Objekten verwendet werden können. Das Diagramm 200 weist ein Diagramm 210 auf, das einem Bewegungsprofil entsprechen kann, das die Bewegung eines Objekts über die Zeit gemäß einer Trajektorie definiert. Der Objektmodellierer 108 kann z.B. ein Bewegungsprofil darstellen, indem er eine oder mehrere Funktionen (z.B. eine kontinuierliche Funktion) und/oder Regeln verwendet, die zur Definition des Diagramms 210 für ein Objekt verwendet werden.
Das Bewegungsprofil, das das Diagramm 210 definiert, kann eine Reihe von Phasen aufweisen, wie z.B. eine Phase, in der das Objekt einer auf eine Zielposition in der Umgebung 126 gerichteten Trajektorie mit maximaler Beschleunigung A_MAX+ folgt (z.B. auch wenn sich das Objekt gerade vom Objekt wegbewegt), optional begrenzt durch die maximale Geschwindigkeit V_MAX, oder eine Geschwindigkeitsobergrenze V_CAP, eine Phase, in der das Objekt mit der maximalen Verzögerung A_MAX- (die optional die gleiche wie A_MAX+ sein kann) abzubremsen beginnt, bis das Objekt vollständig zum Stillstand kommt, und/oder eine Phase, in der das Objekt stehen bleibt. Ein Bewegungsprofil kann einen Parameter aufweisen, den der Objektmodellierer 108 verwendet, um die Zeit festzustellen, zu der das Objekt in dem Bewegungsprofil abzubremsen beginnt, wie z.B. die Reaktionszeit T_REACT (z.B. wie es hier beschrieben ist). Eine beobachtete Beschleunigung A_OBS kann anstelle der maximalen Beschleunigung A_MAX+ oder der maximalen Abbremsung A_MAX- verwendet werden und kann durch einen Sicherheitsfaktor angepasst werden, um der Möglichkeit Rechnung zu tragen, dass die beobachtete Beschleunigung ungenau ist, und/oder um der Möglichkeit Rechnung zu tragen, dass die Beschleunigung zunehmen kann.
Das Bewegungsprofil, das 2 entspricht, kann zur Darstellung von Worst-Case-Szenarien für die Sicherheit eines Fahrzeugs verwendet werden, die so berechnet werden, als ob sich das Fahrzeug 140 zu einem oder mehreren Zeitpunkten an der Zielposition befände. Die Reaktionszeit T_REACT in diesen Szenarien kann die Zeit darstellen, die eine Bedienperson (z.B. ein Fahrer) eines Objekts (z.B. eines anderen Fahrzeugs) benötigt, um das Fahrzeug an der Zielposition zu bemerken und zu versuchen, eine Kollision an der Zielposition zu vermeiden. Der Objektmodellierer 108 kann jedoch auch andere Bewegungsprofile verwenden, um eine oder mehrere Trajektorien eines der verschiedenen Objekte zu modellieren, die eine beliebige Anzahl von Phasen aufweisen können. Außerdem können eines oder mehrere der Bewegungsprofile komplexer sein als das beschriebene Bewegungsprofil, einschließlich von Bedingungen oder Regeln für den Eintritt in Phasen oder während Phasen, die die Bewegung eines Objekts zumindest teilweise auf der Grundlage der Analyse und Anwendung von Variablen, die repräsentativ für verschiedene Merkmale eines Zustands (von Zuständen) der Umgebung 126 zu einem bestimmten Zeitpunkt (zu bestimmten Zeitpunkten) sind, durch den Objektmodellierer 108 variieren.
Eine durch den Objektmodellierer 108 modellierte Trajektorie kann eine Startzeit T_S, die für eine Startzeit der Trajektorie repräsentativ ist, und eine Endzeit T_E, die für eine Endzeit der Trajektorie repräsentativ ist, aufweisen. 2 zeigt ein besonderes Beispiel dafür, dass die Startzeit T_s eine Startgeschwindigkeit Vs und eine Startbeschleunigung A_s aufweist. Der Objektmodellierer 108 kann die Startgeschwindigkeit V_s und die Startbeschleunigung A_s auf die aktuellen, beobachteten und/oder momentanen Geschwindigkeits- und Beschleunigungsparameter einstellen, die vom Objektanalysator 106 geliefert werden, oder die Startgeschwindigkeit V_s und/oder die Startbeschleunigung A_s können aus diesen Werten abgeleitet werden.
Das Beispiel in 2 zeigt, dass zum Startzeitpunkt T_s der Trajektorie die Startgeschwindigkeit Vs und die Startbeschleunigung A_s des Objekts relativ zu dem Fahrzeug 140 positiv sind, d.h. das Objekt bewegt sich mit zunehmender Geschwindigkeit auf das Fahrzeug 140 zu. Würde sich das Objekt jedoch zum Startzeitpunkt T_s zunächst von dem Fahrzeug 140 wegbewegen, dann sind die Startgeschwindigkeit V_s und/oder die Startbeschleunigung As des Objekts relativ zu dem Fahrzeug 140 negativ. Bei anderen Beispielen kann entweder die Startgeschwindigkeit V_s oder die Startbeschleunigung A_s gleich Null sein. Dies kann von der Phase des Bewegungsprofils abhängen, in der sich das Objekt während der Startzeit T_s befindet.
2 zeigt auch ein besonderes Beispiel dafür, dass die Endzeit T_E eine Endgeschwindigkeit V_E und eine Endbeschleunigung A_E hat. Die Endgeschwindigkeit V_E und die Endbeschleunigung A_E können, wie gezeigt, relativ zum Fahrzeug 140 Null sein, was anzeigt, dass das Objekt am Ende der Trajektorie vollständig zum Stillstand gekommen ist. Bei anderen Beispielen können jedoch die Endgeschwindigkeit V_E und/oder die Endbeschleunigung A_E am Ende der Trajektorie positiv oder negativ sein. Zum Beispiel kann die Startzeit T_s einer beliebigen Position auf der Kurve 210 entsprechen, je nachdem, in welcher Phase sich das Objekt in dem Bewegungsprofil am Anfang der Trajektorie befindet, und ebenso kann die Endzeit T_E einer beliebigen Position auf der Kurve 210 nach der Startzeit T_S entsprechen, je nachdem, in welcher Phase sich das Objekt in dem Bewegungsprofil am Ende der Trajektorie befindet (z.B. kann das Objekt noch nicht vollständig zum Stillstand gekommen sein). Wenn der Objektmodellierer 108 außerdem Trajektorien für mehrere Objekte unter Verwendung desselben Bewegungsprofils modelliert, können sich verschiedene Objekte gleichzeitig in verschiedenen Phasen des Bewegungsprofils befinden. Beispielsweise kann ein Objekt zum Startzeitpunkt T_s auf seiner modellierten Trajektorie bis zum Stillstand abgebremst sein und für eine Zeitspanne bis zum Endzeitpunkt T_E stehen bleiben, während ein zweites Objekt zum Startzeitpunkt T_S auf seiner modellierten Trajektorie auf das Fahrzeug 140 zusteuert und sich zum Endzeitpunkt T_E mit der maximalen Geschwindigkeit V_MAX bewegt.
2 veranschaulicht, dass in einigen Beispielen ein Bewegungsprofil von dem Objektmodellierer 108 unter Verwendung der maximalen Geschwindigkeit V_MAX eines Objekts, der maximalen Beschleunigung A_MAX+ des Objekts oder der maximalen Abbremsung A_MAX- des Objekts angewendet werden kann. Diese Werte können Grenzen für die Bewegungsfähigkeit des Objekts darstellen, und jeder dieser Werte kann Parametern entsprechen, die für das Objekt mit Hilfe des Objektanalysators 106, wie hier beschrieben, bestimmt wurden. Als Beispiel weist die Kurve 210 den Bereich 220 auf, in dem das Objekt derart modelliert wird, dass es die maximale Geschwindigkeit V_MAX während der modellierten Trajektorie erreicht. Bei anderen Trajektorien erreicht das Objekt jedoch möglicherweise nicht die maximale Geschwindigkeit V_MAX, die maximale Beschleunigung A_MAX+ oder die maximale Abbremsung A_MAX- während der Trajektorie, oder der Objektmodellierer 108 verwendet einen oder mehrere dieser Faktoren nicht bei der Anwendung eines Bewegungsprofils.
2 veranschaulicht auch die Geschwindigkeitsobergrenze V_CAP, die bei einer modellierten Trajektorie berücksichtigt werden kann. Die Geschwindigkeitsobergrenze V_CAP kann größer als die maximale Geschwindigkeit V_MAX sein und kann einer beobachteten Geschwindigkeit des Objekts entsprechen, die größer als die maximale Geschwindigkeit V_MAX ist. Beispielsweise kann die Geschwindigkeitsgrenze V_CAP einem Parameter entsprechen, den der Objektanalysator 106 aus den Sensordaten 102 ermittelt und der angibt, dass sich das Objekt schneller als die maximale Geschwindigkeit V_MAX bewegt oder in der Lage ist, sich schneller als die maximale Geschwindigkeit V_MAX zu bewegen. Beispielsweise kann der Objektanalysator 108 bei der Anwendung eines Bewegungsprofils für ein Objekt zunächst die maximale Geschwindigkeit V_MAX verwenden, um eine Trajektorie des Objekts zu modellieren. Nachdem festgestellt wurde, dass sich das Objekt schneller als die maximale Geschwindigkeit V_MAX bewegt oder bewegt hat, kann der Objektmodellierer 108 stattdessen die Geschwindigkeitsobergrenze V_CAP verwenden, um die modellierte Trajektorie zu aktualisieren oder eine andere Trajektorie für das Objekt zu modellieren. Ein ähnlicher Ansatz kann für die maximale Beschleunigung oder Abbremsung verwendet werden.
Unter Bezugnahme auf 3A ist 3A gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung, die eine beispielhafte Trajektorie 302 aufweist. Die Trajektorie 302 kann der modellierten Trajektorie entsprechen, die in Bezug auf 2 beschrieben ist. Der Objektmodellierer 108 kann die Trajektorie 302 eines Objekts Y₁ unter Verwendung einer Startposition X_S des Objekts modellieren, die einem Ort oder einer Position des Objekts Y₁ in der Umgebung 126 zu der Startzeit T_S entspricht. Der Objektmodellierer 108 kann auch die Trajektorie 302 unter Verwendung einer Endposition X₁ des Objekts Y₁ modellieren, die einem Ort oder einer Position des Objekts Y₁ in der Umgebung 126 zu dem Endzeitpunkt T_E entspricht.
Die Startposition X_S des Objekts Y₁ kann einem Positionsparameter entsprechen, der mit dem Objektanalysator 106 bestimmt wurde. Der Positionsparameter kann z.B. in Echtzeit oder nahezu in Echtzeit durch den Objektanalysator 106 bestimmt werden, so dass die Startposition eine im wesentlichen aktuelle Position des Objekts Y₁ in der Umgebung 126 darstellt. Die Startposition X_S kann jedoch in einigen Beispielen eine vorhergesagte aktuelle oder zukünftige Position eines Objekts in der Umgebung sein, z.B. wenn das Objekt Y₁ vor einem Erfassen durch den/die Sensor(en) 138 verdeckt ist, wobei das Objekt Y₁ nicht notwendigerweise in der Umgebung existiert, sondern so modelliert wird, dass es als unübersichtliche Kurve oder blinder Fleck bei der Wahrnehmung durch das System 100 mit sicheren Ankunftszeiten oder anderen Szenarien berücksichtigt wird.
In 3A kann der Objektmodellierer 108 die Trajektorie 302 so modelliert haben, dass sie direkt auf die Endposition X₁ des Objekts Y₁ zuläuft (z.B. eine Zielposition in der Umgebung 126, für die eine sichere Ankunftszeit bestimmt wird), wie es dargestellt ist. Dieser Ansatz kann von dem Objektmodellierer 108 in Verbindung mit dem oben beschriebenen Bewegungsprofil verwendet werden, um ein Worst-Case-Szenario zu modellieren, in dem die Bedienperson des Objekts Y₁ versucht, die Endposition X₁ so schnell und direkt wie möglich zu erreichen. Der Objektmodellierer 108 kann einen ähnlichen Ansatz verwenden, um sichere Ankunftszeiten für jede Zielposition in der Umgebung 126 und jedes modellierte Objekt in der Umgebung zu bestimmen, oder eine oder mehrere Trajektorien können anderen Wegen folgen und/oder andere Bewegungsprofile verwenden. In einigen Beispielen kann der Objektmodellierer 108 die Bestimmung vornehmen, um einen Standardweg und/oder ein Standardbewegungsprofil zur Modellierung einer Trajektorie zu verwenden (z.B. den Bewegungspfad entsprechend der Kurve 210 und einen direkten Weg), und in anderen Fällen kann der Objektmodellierer 108 die Bestimmung vornehmen, um einen anderen Weg und/oder ein anderes Bewegungsprofil zur Modellierung einer Trajektorie zu verwenden (z.B. wenn eine geplante Trajektorie für ein Objekt bekannt ist, z.B. nachdem sie von dem Objekt bereitgestellt wurde).
Der Objekttrajektorienanalysator 110 kann so ausgestaltet sein, dass er die von dem Objektmodellierer 108 modellierten Trajektorien analysiert, um eine oder mehrere sichere Ankunftszeiten und/oder sichere Zeitintervalle für das Fahrzeug (z.B. das Fahrzeug 140) zu berechnen. Beispielsweise kann der Objekttrajektorienanalysator 110 modellierte Trajektorien verwenden, um zu bestimmen, wo sich ein Objekt in der Umgebung 126 befinden wird oder zu einer bestimmten Zeit in der Umgebung 126 befinden kann, sowie die Geschwindigkeit und Beschleunigung des Objekts an diesen Positionen zu bestimmen. Auf diese Weise kann der Objekttrajektorienanalysator 110 berechnen, zu welchen Zeiten ein Fahrzeug (z.B. das Fahrzeug 140) diese Positionen sicher einnehmen kann, ohne eine Kollision mit dem Objekt zu verursachen. Diese Zeiten können als sichere Ankunftszeiten für das Fahrzeug an diesen Positionen bezeichnet werden. Eine sichere Ankunftszeit kann jedoch alternativ auch nach anderen Kriterien bestimmt werden, z.B. dass eine resultierende Kollision weniger als einen Schwellenwert für die Aufprallwirkung aufweist, der zumindest teilweise auf der Grundlage der modellierten Masse und Geschwindigkeit des Objekts berechnet werden kann, oder dass die Kollision eine Eintrittswahrscheinlichkeit aufweist, welche kleiner als ein Schwellenwert ist.
Um bei einigen Beispielen mindestens eine sichere Ankunftszeit für die Endposition X₁ zu bestimmen, modelliert der Objektmodellierer die Trajektorie 302 zu der Endposition X₁. Basierend zumindest teilweise auf der Berechnung, dass das Objekt Y₁ bei (oder in anderen Beispielen vor) der Endzeit T_E der Trajektorie 302 vollständig zum Stillstand kommt, kann der Objekttrajektorienanalysator 110 bestimmen, dass die Endzeit T_E und/oder jeder Zeitpunkt vor der Endzeit T_E auf der Trajektorie 302 eine sichere Ankunftszeit des Fahrzeugs bei der Endposition X₁ ist. Beispielsweise kann bei einer Zielposition P in der Umgebung, da festgestellt werden kann, dass die Endposition X₁ eine Endzeit T_E aufweist, zu der das Objekt Y₁ bei einem Worst-Case-Szenario für die Trajektorie des Objekts an der Zielposition P anhalten kann, die Endzeit T_E als sichere Ankunftszeit für die Zielposition P angesehen werden. Somit können die Startzeit T_s und die Endzeit T_E der Trajektorie 302 ein sicheres Zeitintervall für das Fahrzeug in Bezug auf das Objekt Y₁ und die Zielposition P darstellen. Bei anderen Beispielen kann es vorkommen, dass das Objekt Y₁ vor der Endzeit T_E der Trajektorie 302 nicht vollständig zum Stillstand kommt und stattdessen eine Endposition X₁' aufweist. Der Objekttrajektorienanalysator 110 kann diesen Zustand überprüfen, indem er prüft, ob das Maximum einer quadratischen Parabel mindestens einen Punkt des modellierten Objekts weiter als eine Startstrecke zwischen dem mindestens einen Punkt und der Endposition X₁' annimmt. In diesem Fall kann bestimmt werden, dass die sichere Ankunftszeit für die Zielposition P und das Objekt Y₁ gleich Null ist, weil es möglich ist, dass sich das Objekt Y₁ in einen Zustand versetzt, in dem es bereits darauf festgelegt ist, die Zielposition P zu passieren.
Ein anderer Fall, in dem die gleiche Ankunftszeit auf Null gesetzt werden kann, kann darin bestehen, dass das Objekt Y₁ von Anfang an auf die Zielposition P festgelegt ist und die Beschleunigungsparabel in der entgegengesetzten Richtung durch die Zielposition P verläuft. Dies kann z.B. passieren, wenn das Fahrzeug 140 dem Objekt Y₁ folgt, das ein Führungsfahrzeug ist, das sich mit hohem Tempo von dem Fahrzeug 140 entfernt (ein Beispiel dafür ist in 3A dargestellt). In diesem Fall kann das Fahrzeug 140 unweigerlich einige Positionen vor ihm passieren (und durchfährt sie in der Regel). Hier kann es klar sein, dass die Parabel für ein Zeitintervall (z.B. ein unsicheres Zeitintervall) hinter der Zielposition P liegt.
Es folgt ein nicht einschränkendes Beispiel zur Berechnung einer sicheren Ankunftszeit in Bezug auf das Objekt Y₁ an einem Hindernispunkt Y (z.B. der Startposition X_S in einer Ebene) und einem Zielpunkt X (z.B. der Zielposition P in der Ebene). Unter der Annahme, dass das Objekt Y₁ an dem Hindernispunkt Y einen Geschwindigkeitsvektor V (z.B. die Startgeschwindigkeit Vs in der Ebene), eine skalare Maximalgeschwindigkeit v_max (z.B. die Maximalgeschwindigkeit V_MAX), eine skalare Maximalbeschleunigung a_max (z.B. die Maximalbeschleunigung A_MAX) und eine Reaktionszeit T_react (z.B. die Reaktionszeit T_REACT) aufweist, kann eine skalare Distanz d berechnet werden als $d = | X - Y |$
und eine skalare (vorzeichenbehaftete) Geschwindigkeit V kann berechnet werden als $v = d o t (V, \frac{X - Y}{d}) .$
Bei einigen Beispielen kann dies auf jede Funktion verallgemeinert werden, die eine maximale Startgeschwindigkeit in jede Richtung verteilt, wobei das Punktprodukt einen konkreten Vorschlag für eine solche Funktion darstellt. Eine sichere Ankunftszeit t_lsa (z.B. eine späteste sichere Ankunftszeit („latest safe arrival time“)) für das Objekt Y₁ an dem Hindernispunkt Y kann durch die folgenden Formeln berechnet werden: $\begin{array}{l} \begin{array}{l} v_{c a p} = max (v, v_{m a x}) \\ A = d + \frac{v^{2}}{2 a_{m a x}} \\ t_{p r e} = {\begin{matrix} \sqrt{\frac{A}{a_{m a x}}}, & A a_{m a x} < v_{c a p}^{2} \\ \frac{A}{v_{c a p}}, & s o n s t \end{matrix} \end{array} \\ t_{l s a} = max (0, t_{p r e} - \frac{v}{a_{m a x}} - τ_{r e a c t}) . \end{array}$
Für jede Zielposition in der Ebene kann das Minimum aller sicheren Ankunftszeiten t_lsa von allen Objekten (z.B. Punkten) parallel berechnet werden. Wenn die Eingabe eine radiale Distanzfunktion ist, kann die Zeit für alle Punkte auf den Strahlen, die weiter entfernt sind als die radiale Distanzfunktion, auf Null gesetzt werden. Dieser Ansatz kann von dem Visualisierungsgenerator 112 verwendet werden, um eine Visualisierung (z.B. ein Bild) zu erzeugen. Darüber hinaus kann bei einigen Beispielen jede der sicheren Ankunftszeiten t_lsa für jedes der Objekte zu jeder geeigneten Zeit berechnet werden, z.B. um Wege und/oder Trajektorien zu testen und/oder zu generieren (z.B. nach Bedarf, was nicht unbedingt die Erzeugung einer Visualisierung beinhaltet).
Bei jedem Beispiel können der Objektmodellierer 108 und der Objekttrajektorienanalysator 110 zusätzliche Faktoren berücksichtigen, die zur Bestimmung sicherer Ankunftszeiten verwendet werden. Beispielsweise kann eine Steigung oder ein Gefälle zur Zielposition P unter Verwendung der Sensordaten 102, die vom Objektanalysator 102 empfangen und verarbeitet werden, geschätzt werden. Eine Steigung zu dem Zielpunkt kann als ein Faktor verwendet werden, um die Beschleunigungen (oder die Verzögerungen) zu dem Zielpunkt zu reduzieren (oder zu erhöhen). In ähnlicher Weise kann ein Fahrbahnoberflächenkoeffizient µ unter Verwendung von Informationen geschätzt werden, die z.B. von einem Wahrnehmungsblock des Fahrzeugs 140 empfangen und verarbeitet werden (z.B. ähnlich der Objektwahrnehmung, die vom Objektanalysator 106 durchgeführt werden kann). Beispielsweise kann (können) ein (mehrere) trainierte(s) neuronale(s) Netz(e) das Vorhandensein von Eis, Schnee oder schmierigen Straßen erkennen und einen Straßenoberflächenkoeffizienten µ zurückgeben, der als ein Faktor verwendet werden kann, der die maximale Verzögerung zu der Zielposition P reduziert.
3A zeigt auch die Endpositionen X₂, X₃ und X₄ anderer Trajektorien, die der Objektmodellierer 108 modellieren kann, wie z.B. die Verwendung des Bewegungsprofils, das der Darstellung 210 entspricht, oder eines anderen Bewegungsprofils bzw. anderer Bewegungsprofile und/oder eines direkten Weges zu jeder der Endpositionen X₂, X₃ und X₄ (oder eines anderen Wegtyps). Die Endpositionen X₂, X₃ und X₄ sind als Beispiele für Positionen in Trajektorien vorgesehen, die mindestens eine sichere Ankunftszeit (und ein potenziell sicheres Zeitintervall) gemeinsam aufweisen. Dies kann in 3A dargestellt werden, wobei die Endpositionen X₁, X₂, X₃ und X₄ in einem Zeit-Raum-Bereich aufgetragen sind, der Punkte einer Linie bzw. Kontur 306 bildet, welche die sichere Ankunftszeit darstellt, die die Positionen in der Umgebung 126 gemeinsam aufweisen. Die Kontur 306 kann zusätzlich oder alternativ repräsentativ für ein gemeinsames sicheres Zeitintervall der Positionen sein (z.B. wenn die Kontur 306 eine Endzeit des Intervalls darstellt). Wie im Folgenden beschrieben ist, kann die Kontur 306 von dem System 100 mit der sicheren Ankunftszeit verwendet werden, um zu bestimmen, ob es für das Fahrzeug 140 sicher wäre, eine Position bzw. Positionen zu einer bestimmten Zeit (zu bestimmten Zeiten) einzunehmen. Beispielsweise kann das System 100 mit der sicheren Ankunftszeit die Kontur 306 verwenden, um eine potenzielle Überschneidung des Fahrzeugs 140 mit der Kontur 306 in dem Zeit-Raum-Bereich zu erkennen, die angibt, dass die gegebene(n) Zeit(en) und die gegebene(n) Position(en) unsicher wären, da es zu einer Kollision kommen könnte.
Während 3A in Bezug auf den Objekttrajektorienanalysator 110 beschrieben ist, der Positionen und Zeiten in Bezug auf ein einzelnes Objekt Y₁ analysiert, kann der Objekttrajektorienanalysator 110 bei der Berechnung einer oder mehrerer sicherer Ankunftszeiten und/oder sicherer Zeitintervalle für ein Fahrzeug eine beliebige Anzahl von Objekten berücksichtigen, wie z.B. jedes der verschiedenen Objekte, die mit Hilfe der Sensordaten 102 modelliert wurden. Zum Beispiel zeigen die 3B und 3C Konturen, die repräsentativ für sichere Ankunftszeiten sind und mehrere Objekte in der Umgebung berücksichtigen.
In 3B kann das Objekt Y₁ dem Objekt 128A von 1A entsprechen, das Objekt Y₂ kann dem Objekt 128B von 1A entsprechen und das Objekt Y₃ kann einem Objekt entsprechen, das nicht in den Sensordaten 102 dargestellt ist, sondern mit dem Objektmodellierer 108 modelliert wird (oder dem Objekt 128C entsprechen kann). Für jede der Zielpositionen P₁, P₂, P₃, P₄, P₅, P₆ und P₇ kann der Objekttrajektorienanalysator 110 die sichere Ankunftszeit und/oder das sichere Zeitintervall des Objekts verwenden, das unter den modellierten Objekten und Trajektorien für eine bestimmte Zielposition am frühesten auftritt. Beispielsweise kann der Objekttrajektorienanalysator 110 für die Zielposition P₁ die sichere Ankunftszeit für das Objekt Y₁ verwenden, da diese vor den sicheren Ankunftszeiten der Objekte Y₂ und Y₃ für die Zielposition P₁ liegt.
Die sicheren Ankunftszeiten und/oder sicheren Zeitintervalle, die von dem Objektmodellierer 108 für die Zielpositionen P₁, P₂ und P₃ verwendet werden, können in 3B dargestellt werden, indem sie in einem Zeit-Raum-Bereich aufgetragen werden, wobei Punkte einer Kontur 308 gebildet werden, die die sichere Ankunftszeit T1 (und/oder das sichere Zeitintervall) entlang entsprechender Positionen in der Umgebung 126 (z.B. ähnlich wie die Kontur 306) darstellt, aber mehrere Objekte berücksichtigt. In ähnlicher Weise können die sicheren Ankunftszeiten und/oder sicheren Zeitintervalle, die von dem Objektmodellierer 108 für die Zielpositionen P₄, P₅, P₆ und P₇ verwendet werden, in 3B dargestellt werden, die in dem Zeit-Raum-Bereich dargestellt sind und Punkte einer Kontur 310 bilden, die die sichere Ankunftszeit T2 (und/oder das sichere Zeitintervall) entlang Positionen in der Umgebung 126 darstellt.
3C zeigt eine Konturkarte 300, die zusätzliche Teile der Konturen 308 und 310 von 3B sowie andere Konturen für verschiedene sichere Ankunftszeiten und/oder sichere Zeitintervalle und Positionen in der Umgebung 126 umfasst. Eine Region 330 in 3C kann der Region 330 in 3B entsprechen. Obwohl die Konturen von 3C mehreren Objekten entsprechen, kann in anderen Beispielen jede dieser Konturen einem einzigen Objekt entsprechen. Darüber hinaus kann eine unendliche Anzahl von Konturen existieren, von denen jede einer anderen sicheren Ankunftszeit und/oder einem anderen sicheren Zeitintervall (falls vorhanden) entspricht. Bei jedem Beispiel können die Daten 120 zur sicheren Ankunftszeit repräsentativ für eine oder mehrere der Konturen, Teile der Konturen und/oder entsprechende Zielpositionen und sichere Ankunftszeiten sein. Darüber hinaus können in einigen Beispielen die Daten 120 zur sicheren Ankunftszeit Bilddaten umfassen, die repräsentativ für ein Bild bzw. Bilder sind, die eine oder mehrere der vorausgehenden Informationen erfassen. Das Bild kann z.B. dem in 1A dargestellten Bild ähnlich sein. Der Visualisierungsgenerator 112 kann das Bild als eine Visualisierung erzeugen, die zumindest teilweise auf den sicheren Ankunftszeiten basiert. Datenwerte eines Bildes (z.B. Pixelwerte, Vektorgrafikwerte, Analogwerte, Digitalwerte usw.), die als Visualisierung verwendet werden, können parallel berechnet werden, z.B. durch Parallelverarbeitung, die auf einer oder mehreren Grafikverarbeitungseinheiten (GPUs) erfolgen kann, wie z.B. die eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1308 von 13, die GPU(s) 1208 von 12C und/oder die GPU(s) 1220 von 12C.
Das in 1A dargestellte Bild weist Datenwerte (z. B. Pixelwerte, Vektorgrafikwerte, Analogwerte, Digitalwerte usw.), die zumindest für Teile von sicheren Zeitintervallen repräsentativ sind, auf. Beispielsweise kann der Visualisierungsgenerator 112 ein oder mehrere Pixel oder Punkte einer Visualisierung verwenden, um sichere Ankunftszeiten darzustellen, z.B. durch eine Einstellung von Helligkeitswerten, Farbwerten und/oder anderen Werten, die den Pixeln oder Punkten zugeordnet sind oder zur Erzeugung der Pixel oder Punkte verwendet werden. Jeder Punkt oder Pixel einer von dem Visualisierungsgenerator 112 erzeugten Visualisierung kann eine sichere Ankunftszeit und eine Position in der Umgebung 126 darstellen. Die Position des Punktes oder Pixels in der Visualisierung kann der Position in der Umgebung 126 entsprechen, und die Farbgebung oder andere Eigenschaften des Punktes oder Pixels in der Visualisierung können der sicheren Ankunftszeit für die Position entsprechen.
In dem Bild von 1A kann jede sichere Ankunftszeit und jeder sichere Punkt/Pixel und jede Position einer Endzeit eines sicheren Zeitintervalls entsprechen, und alle sicheren Zeitintervalle können die gleiche Startzeit haben. Bei diesem Ansatz können die Datenwerte (z.B. Farbwerte) der Pixel oder Punkte eine Konturkarte bilden, die einen Konturgradienten aufweisen, wie es in 1A dargestellt ist. In dem dargestellten Beispiel haben weiße Pixel oder Punkte einen Wert für ein unendlich sicheres Zeitintervall, was anzeigt, dass diese Positionen als sicher gelten, unabhängig davon, wann das Fahrzeug 140 an ihnen ankommt (z.B. können entsprechende Objekte immer vor der Kollision mit dem Fahrzeug anhalten, wenn sich das Fahrzeug an diesen Stellen befände). Im Gegensatz dazu haben schwarze Pixel oder Punkte einen Wert für das sichere Zeitintervall von Null, was anzeigt, dass diese Positionen als unsicher angesehen werden, unabhängig davon, wann das Fahrzeug 140 an ihnen ankommt (z.B. können entsprechende Objekte niemals vor der Kollision mit dem Fahrzeug anhalten, wenn sich das Fahrzeug an diesen Stellen befände). Der Gradient der Pixel- oder Punktwerte, die sich von Schwarz nach Weiß bewegen, kann einer Zunahme der sicheren Zeitintervalle von Null bis unendlich entsprechen. Der Visualisierungsgenerator 112 kann den Datenwert für eine Position bestimmen, indem er die sichere Ankunftszeit für diese Position auf eine Funktion anwendet, die z.B. eine lineare Beziehung zwischen der sicheren Ankunftszeit und dem Datenwert aufweisen kann.
Wie dargestellt ist, kann ein Pfeil 150 (nicht Teil der Daten der sicheren Ankunftszeit 120) eine Position des Fahrzeugs 140 zu der Startzeit der sicheren Zeitintervalle anzeigen. Als Beispiel können die sicheren Ankunftszeiten relativ zu der Position des Fahrzeugs 140 und zu der Startzeit aufgetragen werden. Der Pfeil 152 (nicht Teil der Daten zur sicheren Ankunftszeit 120) kann eine Position des Objekts 128A zu der Startzeit und ein Pfeil 154 (nicht Teil der Daten zur sicheren Ankunftszeit 120) kann eine Position des Objekts 128B zu der Startzeit anzeigen.
4A, 4B und 4C zeigen weitere Beispiele für die Visualisierungen 402, 404 und 406 von sicheren Ankunftszeiten gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Bei einigen Beispielen kann der Visualisierungsgenerator 112 eine oder mehrere der Visualisierungen 402, 404 oder 406 zusätzlich zu oder anstelle der in 1A gezeigten Visualisierung erzeugen. Der Visualisierungsgenerator 112 kann bestimmen, ob Positionen in der Umgebung jeweils eine sichere Ankunftszeit aufweisen, die in einen bestimmten Zeitbereich fällt. Der Visualisierungsgenerator 112 kann die Pixel oder Punkte, die diesen Positionen mit demselben Datenwert entsprechen bzw. in denselben Zeitbereich fallen, so einstellen, dass sie den bestimmten Zeitbereich repräsentieren. Pixel oder Punkte für unterschiedliche Zeitbereiche können auf unterschiedliche Datenwerte eingestellt werden. Wenn also die Visualisierung von 1A mit 4A und 4B verglichen wird, können benachbarte Pixel oder Punkte, die einen Teil eines Konturgradienten in 1A bilden, stattdessen den/die gleichen Datenwert(e) aufweisen (z.B. die gleiche Farbe, die gleiche Helligkeit usw.), wodurch sie zu einer einzigen Kontur gruppiert werden. Bei einigen Beispielen kann der Visualisierungsgenerator 112 unter Verwendung der in 1A gezeigten Visualisierung eine Visualisierung erzeugen, die der Visualisierung 402 ähnlich ist.
Der Visualisierungsgenerator 112 kann unter Verwendung eines ähnlichen Verfahrens die Visualisierung 402 von 4A und die Visualisierung 404 von 4B erzeugen. Der Objekttrajektorienanalysator 110 kann jedoch sichere Ankunftszeiten für diese Visualisierungen unter anderen Einschränkungen oder Annahmen hinsichtlich dessen, was als sichere Ankunftszeit gilt, bestimmt haben. Als Beispiel kann die Visualisierung 402 zumindest teilweise auf der Einschränkung beruhen, dass jede Position in der Umgebung, die ein Objekt in einer modellierten Trajektorie gemäß dem/den Bewegungsprofil(en) einnehmen kann, unsicher ist. Sichere Ankunftszeiten, die mit diesem Ansatz berechnet werden, können als späteste sichere Ankunftszeiten ((Latest Safe Arrival time) LSA) bezeichnet werden. Diese Beschränkung kann jedoch bei anderen Ansätzen gelockert werden. Beispielsweise können sichere Ankunftszeiten für die Visualisierung 404 unter Verwendung eines ähnlichen Ansatzes wie für die Visualisierung 402 berechnet werden, jedoch ohne die Einschränkung, dass jede Position in der Umgebung, die ein Objekt in einer modellierten Trajektorie gemäß dem/den Bewegungsprofil(en) einnehmen kann, unsicher ist. Daher können sichere Ankunftszeiten, die mit diesem Ansatz berechnet werden, früher als die entsprechenden LSAs auftreten und können als früheste sichere Ankunftszeiten ((Earliest Safe Arrival times) ESAs) bezeichnet werden. Beispielsweise kann eine ESA den frühesten Zeitpunkt darstellen, zu dem das Fahrzeug 140 eine Zielposition einnehmen kann, ohne dass es zu einer Kollision mit einem Objekt kommt.
Beispielsweise kann der Objekttrajektorienanalysator 116 bei einer ESA eine Zielposition nicht als unsicher betrachten, wenn das Objekt von Anfang an auf die Zielposition P festgelegt ist und die Beschleunigungsparabel in der entgegengesetzten Richtung durch die Zielposition verläuft. Dies kann z.B. passieren, wenn das Fahrzeug 140 dem Objekt folgt, bei dem es sich um ein Führungsfahrzeug handelt, das sich mit hoher Geschwindigkeit von dem Fahrzeug 140 wegbewegt. In diesem Fall kann, obwohl die Parabel für ein Zeitintervall hinter der Zielposition liegt, dieses Zeitintervall immer noch einem ESA-Intervall entsprechen. Zur Berechnung einer ESA kann der Trajectorienmodellierer 302 ein Bewegungsprofil verwenden, bei dem das Objekt plötzlich und mit maximaler Kraft abbremst (z.B. bei maximaler Abbremsung A_MAX+ oder unter Verwendung der beobachteten Beschleunigung A_OBS optional mit einer Sicherheitsfaktoranpassung). Mit dieser modellierten Trajektorie kann der Objekttrajektorienanalysator 116 bestimmen, wann (falls überhaupt) das Objekt einen Sicherheitsabstand von einer Zielposition entfernt sein wird, so dass das Fahrzeug 140 die Zielposition sicher erreichen kann. Diese Zeit kann als ESA-Intervall verwendet werden. Auf diese Weise kann eine ESA-Konturkarte erstellt werden, die ESAs (und optional ESA-Intervalle) an jeder Zielposition darstellt.
Bei jedem Beispiel kann eine Beschränkung einer sicheren Ankunftszeit aufweisen, dass sich das autonome Fahrzeug 140 immer in einem Zustand befindet, in dem das Fahrzeug 140 mindestens ein maximales Bremsprofil anwenden kann, um ohne Kollision zum Stillstand zu kommen. Anstelle des maximalen Bremsprofits wird bei einigen Beispielen ein Komfortbremsprofil verwendet. Bei einigen Beispielen stehen mehrere Bremsprofile zur Verfügung und können als Randbedingung unter verschiedenen Szenarien verwendet werden (z.B. ausgewählt durch den Objekttrajektorienanalysator auf der Grundlage eines oder mehrerer wahrgenommener Zustände der Umgebung).
Der Visualisierungsgenerator 112 kann die Visualisierung 406 von 4C unter Verwendung von sicheren Ankunftszeiten erzeugen, die unter verschiedenen Einschränkungen oder Annahmen generiert werden. Beispielsweise kann die Visualisierung 406 unter Verwendung sowohl von LSAs als auch ESAs für Zielpositionen in der Umgebung erzeugt werden. Bei dem dargestellten Beispiel entsprechen Pixel oder Punkte mit einem ersten Datenwert (z.B. einem ersten Farbwert), dargestellt als weiße Region in 4C, gemäß jeder der Einschränkungen oder Annahmen (z.B. von sowohl ESAs als auch LSAs) Positionen in der Umgebung, wo es für ein Fahrzeug möglich ist, die Positionen zumindest während einigen Zeiten sicher einzunehmen, ohne dass es zu einer Kollision kommt. Pixel oder Punkte mit einem zweiten Datenwert (z.B. einem zweiten Farbwert), die in 4C als schattierte Region dargestellt sind, entsprechen gemäß jeder der Einschränkungen oder Annahmen (z.B. sowohl von ESAs als auch von LSAs) Positionen in der Umgebung, bei denen festgestellt wird, dass es für das Fahrzeug nicht möglich ist, die Positionen zumindest während einigen Zeiten sicher einzunehmen, ohne dass es zu einer Kollision kommt.
Zum Beispiel bei 4A-4C können Regionen der Visualisierung unter Verwendung von sicheren Zeitbereichen t₀, t₁, t₂, t₃ und t₄ bezeichnet werden. Die sicheren Zeitbereiche t₀, t₁, t₂, t₃ und t₄ können bezüglich der Zeit von links nach rechts ansteigen und zusammen einen kontinuierlichen Zeitbereich bilden, der einen Anfangszeitpunkt des sicheren Zeitbereichs t₀ bis zu einem Endzeitpunkt des sicheren Zeitbereichs t₄ umfasst. Da z.B. Positionen, die einer Region 412 der Visualisierung 404 von 4B entsprechen, ESAs entsprechen, die nach LSAs von entsprechenden Positionen in einer Region 410 der Visualisierung 402 von 4A auftreten, kann bestimmt werden, dass keine Zeit bei diesen Positionen sowohl die LSA- als auch die ESA-Beschränkungen oder Annahmen bezüglich der Sicherheit der Besetzung der Positionen erfüllen kann (z.B. kommt der sichere Zeitbereich t₂ der Region 410 in 4A vor dem sicheren Zeitbereich t₃ der Region 412 in 4B).
Bei den hier beschriebenen Beispielen, in denen eine für sichere Ankunftszeiten repräsentative Visualisierung analysiert wird, um die Sicherheit von Zeiten und Positionen eines Fahrzeugs zu testen, kann die Visualisierung 406 als Maskierung verwendet werden, um Regionen der Visualisierung und entsprechende Positionen in der Umgebung 126 anzuzeigen, die nicht als Kandidaten für Positionen eines Fahrzeugs analysiert werden müssen. Dies kann die Verarbeitungszeit für die Analyse und/oder Generierung von Trajektorien unter Verwendung mehrerer Ansätze für sichere Ankunftszeiten reduzieren. Beispielsweise kann die Visualisierung 402 mit der Visualisierung 406 maskiert und zur Analyse oder Generierung einer Trajektorie für ein Fahrzeug verwendet werden, und/oder die Visualisierung 404 kann mit der Visualisierung 406 maskiert und zur Analyse oder Generierung einer Trajektorie für ein Fahrzeug verwendet werden.
Visualisierungen, die mit dem Visualisierungsgenerator 112 erzeugt wurden, können für verschiedene Zwecke verwendet werden. Zum Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien so konfiguriert werden, dass er eine vorgeschlagene Trajektorie oder einen vorgeschlagenen Weg (z.B. dargestellt durch die Fahrzeug-Trajektorieninformation 124) unter Verwendung der Daten 120 zur sicheren Ankunftszeit (z.B. das durch die Daten 120 zur sicheren Ankunftszeit dargestellte Bild) analysiert. Der Weg- oder Trajektoriengenerator 116 kann so konfiguriert werden, dass er eine Trajektorie (z.B. dargestellt durch die Fahrzeug-Trajektorieninformation 124) unter Verwendung der Daten 120 zur sicheren Ankunftszeit (z.B. das durch die Daten 120 zur sicheren Ankunftszeit dargestellte Bild) erzeugt. Entweder der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien oder der Weg- oder Trajektoriengenerator 116 kann eine beliebige Kombination der oben beschriebenen Visualisierungen verwenden, um diese Verfahren auszuführen. Bei einigen Beispielen kann jedoch entweder der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien oder der Weg- oder Trajektoriengenerator 116 die Daten 120 zur sicheren Ankunftszeit in einer anderen Form verwenden, und der Objekttrajektorienanalysator 110 kann je nach Bedarf sichere Ankunftszeiten und/oder sichere Zeitintervalle für Positionen in der Umgebung 126 berechnen.
Die Fahrzeug-Trajektorieninformationen 124 können in einigen Beispielen einen oder mehrere Trajektorienpunkt(e) 142 (z.B. dargestellt durch (x-, y-) Koordinaten) entlang der Trajektorie 144 aufweisen. Bei einigen Beispielen kann nur ein einziger Trajektorienpunkt (z.B. der nächste Trajektorienpunkt für das Fahrzeug 140 in einer Folge von diskretisierten Trajektorienschritten) durch den Analysator 114 von vorgeschlagenen Wegen oder Trajektorien analysiert und/oder durch den Weg- oder Trajektoriengenerator 116 erzeugt werden. Bei anderen Beispielen kann mehr als ein Trajektorienpunkt analysiert und/oder generiert werden. Als weiteres Beispiel kann eine gesamte Trajektorie analysiert und/oder generiert werden, die aus zwei oder mehr Trajektorienpunkten 142 extrapoliert werden kann (z.B. unter Verwendung eines Splines).
Bei jedem Beispiel kann die Trajektorie 144 einen Radius der Trajektorie 144 bilden oder einen inversen Radius der Trajektorie 144 bilden. Die Trajektorie 144 und/oder der (die) Trajektorienpunkt(e) 142 darauf kann (können) von einer Steuerkomponente(n) verwendet werden, um die zur Steuerung des Fahrzeugs 140 gemäß der Trajektorie 144 erforderlichen Steueranweisungen zu bestimmen. Die Steuerkomponente(n) kann (können) beispielsweise eine oder mehrere Anweisungen an eine oder mehrere Betätigungsvorrichtungen senden (z.B. Betätigungsvorrichtungen, die von einer Betätigungsschicht des Softwarestacks zum autonomen Fahren gesteuert werden). Die Betätigungsvorrichtungen können eine oder mehrere Komponenten oder Merkmale des Bremssensorsystems 1246, des Antriebssystems 1250, des Lenksystems 1254 und/oder anderer Systeme aufweisen. Bei anderen Beispielen können die Fahrzeugtrajektorieninformationen 124 die Anweisungen zur Steuerung des Fahrzeugs entsprechend der Trajektorie 144 aufweisen.
Unter Bezugnahme auf 5 ist 5 eine Darstellung, die ein Beispiel für eine Trajektorie 502 für ein Fahrzeug 140 mit einer Visualisierung 510 von sicheren Ankunftszeiten gemäß einigen Ausführungsformen der vorliegenden Offenbarung aufweist. Das Fahrzeug 140 kann dem Fahrzeug 140 von 1A entsprechen. Die Trajektorie 502 kann eine vorgeschlagene Trajektorie sein, die der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien gemäß sicheren Ankunftszeiten und/oder sicheren Zeitintervallen für Positionen in der Umgebung auf Sicherheit prüft (z.B. optional unter Verwendung der Visualisierung 510). Die Trajektorie 502 kann von einem anderen System oder einer anderen Komponente (z.B. einem separaten Verhaltensplaner des Fahrzeugs 140) erzeugt worden sein, die möglicherweise die sicheren Ankunftszeiten und/oder die sicheren Zeitintervalle, als Beispiel, nicht berücksichtigt haben. Darüber hinaus kann die Trajektorie 502 der Trajektorie 144 entsprechen und kann durch jeden geeigneten Ansatz dargestellt werden, einschließlich der Ver wendung des/der oben beschriebenen Trajektorienpunktes/-punkte 142 und/oder einer Spline-Funktion.
Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann die Trajektorie 502 mit einem Bewegungsprofil des Fahrzeugs 140 prüfen, das die Trajektorie 502 definiert. Als Beispiel kann das Bewegungsprofil ein maximales Bremsprofil des Fahrzeugs 140 oder ein Komfortbremsprofil des Fahrzeugs 140 aufweisen. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann ein Profil des Fahrzeugs 140 nehmen und das Bremsprofil oder ein anderes Bewegungsprofil annehmen. Das Bremsprofil kann einen aktuellen Beschleunigungs- und Geschwindigkeitszustand des Fahrzeugs 140 aufweisen, der das Bewegungsprofil während der Reaktionszeit verursacht. Darauf kann ein optional durch eine Ruckbegrenzung begrenzter Bremsrampenhochlauf, und schließlich eine maximale Abbremsung des Profils, bis zum Stillstand, wenn überhaupt, während einer dieser Phasen folgen. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann jede beliebige Form des Fahrzeugs 140 zuzüglich eines optionalen Sicherheitsabstands voraussetzen und diese Form mit den sicheren Ankunftszeiten an jeder Zielposition (z.B. unter Verwendung der Visualisierung 510) während des Bremsprofils entlang eines zu prüfenden Weges 506 überprüfen.
Indem sichergestellt wird, dass der Weg 506 sicher mit einem Bremsprofil verwendet werden kann, kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien sicherstellen, dass eine dem Weg 506 folgende Trajektorie (die die Trajektorie 502 sein kann oder auch nicht) zumindest sicher genug ist, um rechtzeitig zu bremsen, falls das Bremsprofil angesteuert werden sollte. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann den Weg 506 als unsicher einstufen, wenn festgestellt wird, dass zumindest das Komfortbremsprofil zu einer Kollision führen würde, und insbesondere, wenn er feststellt, dass das Profil zum maximalen Bremsen zu einer Kollision führen würde. Bei einigen Beispielen können beide Profile für dasselbe Fahrzeug 140 getestet werden, aber für unterschiedliche Zwecke verwendet werden. Beispielsweise kann das Profil zum maximalen Bremsen als Ausfallsicherung verwendet werden, um Trajektorien vor dem Einsatz zu testen, während das Komfortbremsprofil für die Planung auf höherer Ebene verwendet werden kann.
Zum Beispiel kann das Fahrzeug 140 die Bremsprofile verwenden, um effektiv eine Sicherheitszone um das Fahrzeug 140 herum festzulegen, darauf zu testen und sich mit einem maximalen Bremsen beschäftigen (z.B. mit Einrasten, wie z.B. Einrasten bei einem Schmidt-Trigger), wenn der Test nicht bestanden wird (z.B. auf dem Weg, der dem am nächsten kommt, bei dem der Test bestanden wird). Dies kann dem Fahrzeug 140 Sicherheit vor einer Kollision bieten. Um auch für einen Komfort zu sorgen, kann auch ein etwas strengerer Test durchgeführt werden und ein klassischerer Regler (z.B. ein PID-Regler (Proportional-Integral-Derivative-Regler)) kann verwendet werden, um die Geschwindigkeit des Fahrzeugs 140 so zu regeln, so dass es innerhalb der Grenzen des strengeren Tests bleibt und den Weg unter einer Reihe von Wegen (z.B. die Reihe von Wegen, die nicht zu weit von einem nominalen Pfad abweichen) einhält, der dem Bestehen des Tests am nächsten kommt. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann bei verschiedenen Beispielen einen vorgeschlagenen Weg und/oder eine vorgeschlagene Trajektorie von einem Langzeitplaner testen.
Um die Sicherheit der Trajektorie 502 zu testen, kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien die Trajektorie 502 analysieren, um festzustellen, ob es während der Trajektorie 502 einen Zeitpunkt gibt, zu dem das Fahrzeug 140 eine Position(en) in der Umgebung 126 außerhalb eines sicheren Zeitintervalls (sicherer Zeitintervalle) für die Position(en) einnehmen würde. Zum Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien eine vorgeschlagene Ankunftszeit für das Fahrzeug bezüglich einer Position auswerten, um zu bestimmen, ob die vorgeschlagene Ankunftszeit eine sichere Ankunftszeit für die Position ist. Wenn der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien feststellt, dass die vorgeschlagene Ankunftszeit keine sichere Ankunftszeit ist, kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien Daten erzeugen, die repräsentativ dafür sind, dass die Trajektorie 502 den Test nicht bestanden hat, andernfalls kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien immer noch Daten erzeugen, die repräsentativ dafür sind, dass die Trajektorie 502 den Test bestanden hat (z.B. unter der Annahme, dass alle anderen vorgeschlagenen Ankunftszeiten in ähnlicher Weise als sicher befunden werden).
Als weiteres Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien ein Sicherheitsniveau oder einen Sicherheitsgrad für eine Zielposition bestimmen, das bzw. der repräsentativ dafür ist, wie nahe eine Ankunftszeit für die Trajektorie 502 an der Zielposition an einer sicheren Ankunftszeit für die Zielposition liegt. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann die Trajektorie 502 als unsicher einstufen, wenn das Sicherheitsniveau oder der Sicherheitsgrad für mindestens eine Zielposition unter einem Schwellenwert liegt. Wenn alle Zielpositionen innerhalb des Schwellenwertes für die Trajektorie 502 liegen, kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien die Trajektorie 502 immer noch als sicher erachten. Als weiteres Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien der gesamten Trajektorie 502 ein Sicherheitsniveau oder einen Sicherheitsgrad zuweisen, das/der dem Sicherheitsniveau oder Sicherheitsgrad an mehreren Zielpositionen entsprechen kann (z.B. ein ungünstigstes Sicherheitsniveau oder ein ungünstigster Sicherheitsgrad, ein durchschnittliches Sicherheitsniveau oder ein durchschnittlicher Sicherheitsgrad, ein Sicherheitsniveau oder Sicherheitsgrad, das/der andernfalls statistisch aus mehreren Zielpositionen abgeleitet wird, usw.).
Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann verschiedene Ansätze verwenden, um die Sicherheit der Trajektorie 502 zu testen. Bei einigen Beispielen kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien eine Anzahl von Proben 504 der Trajektorie 502 entlang des Weges 506 der Trajektorie 502 testen. In 5 kann jede Probe durch eine Linie dargestellt werden, die senkrecht zum Pfad 506 verläuft. Eine Probe kann z.B. (eine) vorgeschlagene Ankunftszeit(en) der Trajektorie 502 und (eine) Position(en) des Fahrzeugs 140 auf dem Weg 506 bei der vorgeschlagenen Ankunftszeit(en) umfassen. Um die Probe zu testen, kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien die vorgeschlagene(n) Ankunftszeit(en) und die Position(en) analysieren, um festzustellen, ob irgendein Teil der Probe (z.B. ein oder mehrere Paare von Position/vorgeschlagenen Ankunftszeiten) nicht einer sicheren Ankunftszeit entspricht. Wenn z.B. der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien feststellt, dass eine vorgeschlagene Ankunftszeit für eine Position keine sichere Ankunftszeit für diese Position ist, kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien bestimmen, dass die Trajektorie 502 unsicher ist, und die Trajektorie kann den Test nicht bestehen.
Als Beispiele können die Positionen einer Probe durch die Linie dargestellt werden, die senkrecht zu dem Weg 506 verläuft, oder eine Probe kann eine einzelne Position der Linie aufweisen. Als weiteres Beispiel können die Positionen eine zweidimensionale Form bilden, wie z.B. ein Begrenzungsrechteck um das Fahrzeug 140. Als weiteres Beispiel können die Positionen eine beliebige Anzahl von Punkten aufweisen, die zumindest zum Teil dem Umriss des Fahrzeugs 140 entsprechen. Bei jedem Beispiel können die Positionen zumindest teilweise auf einer Form des Fahrzeugs basieren. Darüber hinaus kann die Form der Proben unter Verwendung eines oder mehrerer Parameter bestimmt werden, die vom Objektanalysator 106 bereitgestellt werden. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann gemäß einem weiteren Beispiel einen Sicherheitspuffer zu den für eine Probe verwendeten Positionen aufweisen oder hinzufügen, so dass die Positionen eine Fläche repräsentieren, die in mindestens einer Dimension größer ist als das Fahrzeug 140.
Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann mehrere vereinfachende Annahmen beim Testen der Sicherheit der Trajektorie 502 (und/oder des Weges 506) anwenden. Zum Beispiel kann eine vereinfachende Annahme erkennen, dass, sobald ein Punkt an dem Fahrzeug 140 (z.B. der vordere Stoßfänger) an der Zielposition ankommt, die dahinter folgenden Punkte nicht geprüft werden müssen. Mit anderen Worten, wenn das Fahrzeug 140 einen vorderen Stoßfänger hat, der bereits an einer Zielposition angekommen ist, besteht möglicherweise kein Grund, eine zusätzliche Sicherheitsprüfung durchzuführen, um festzustellen, wann andere Punkte an dem Fahrzeug 140 (Motorhaube, vordere Windschutzscheibe) die Zielposition erreichen. Daher können die geprüften Proben bei einigen Beispielen oder für einige Proben im Wesentlichen nur mit der Vorderkante des Fahrzeugs übereinstimmen. Daher kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien das Fahrzeug 140 so behandeln, als würde es ungefähr durch die Zielpositionen gleiten. Es kann nur ein Balken senkrecht zu dem Weg 504 (z.B. eine Linie oder Kontur eines vorderen, hinteren oder anderen Teils des Fahrzeugs 140) mit den Ausmaßen der Breite des Fahrzeugs 140 (zuzüglich eines optionalen Sicherheitsabstands) geprüft werden. Dieser Balken kann an dem hinteren Teil des Fahrzeugs 140 beginnen und sich während der Zeit Null um den Sicherheitsabstand vorwärts bewegen und sich dann im Laufe der Zeit gemäß dem Bewegungsprofil (z.B. genau gemäß dem Bewegungsprofil) vorwärts bewegen.
Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann also entweder einen Weg mit einem 2D- oder reduzierten Satz von Vorgängen oder, wenn das Fahrzeug 140 überwiegend in die Hauptfahrtrichtung zeigt und die Balken als parallel betrachtet werden, mehrere annähernd parallele Wege mit einem 2D- oder reduzierten Satz von Vorgängen prüfen.
Ein weiteres Beispiel für die Vereinfachung der Prüfung (z.B. im Falle des Arbeitens mit einer radialen Abstandsfunktion) kann sein, dass der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien zunächst die sicheren Ankunftszeiten vorverarbeitet, so dass die sicheren Ankunftszeiten entlang radialer Strahlen von dem Fahrzeug 140 monoton abnehmen (z.B. immer abnehmen), und dann die Endpunkte der Balken und den letzten Balken prüft, da bei einer Verletzung diese auch am Umfang der Form auftreten würde, die der Balken in der Ebene der Umgebung 126 nachzeichnet.
5 zeigt die Trajektorie 502, die der Visualisierung 510 überlagert ist. Die Visualisierung 510 kann z.B. der Visualisierung 402 von 4A entsprechen, wobei Regionen und/oder Pixel oder Punkte der Visualisierung 510 repräsentativ für sichere Ankunftszeiten für diese Positionen sind. Bei anderen Beispielen kann die Visualisierung 510 jedoch der Visualisierung 404 oder einer Visualisierung entsprechen, die unter anderen Einschränkungen der Annahmen bezüglich sicherer Ankunftszeiten erzeugt wurde. Bei irgendeinem Beispiel kann die Visualisierung 510 zum Testen und/oder Generieren einer Trajektorie verwendet werden und kann der Visualisierung von 1A ähnlich sein, im Gegensatz zu verschiedenen sicheren Ankunftszeiten, die in Zeitbereiche gruppiert sind. Darüber hinaus kann die Visualisierung bei einigen Beispielen nicht generiert oder verwendet werden, um eine Trajektorie oder einen Weg zu testen und/oder zu generieren. Insbesondere kann bei dieser Beschreibung jede der sicheren Ankunftszeiten und/oder sicheren Zeitintervalle, die zum Testen und/oder Generieren einer Trajektorie oder eines Weges (oder für andere Zwecke) verwendet werden, aus Sensordaten oder einer Visualisierung der Sensordaten (z.B. einem Bild) stammen oder nicht. Beispielsweise kann die Verwendung von Datenwerten aus einer Visualisierung zur Bestimmung sicherer Ankunftszeiten oder sicherer Zeitintervalle für Positionen in der Umgebung (z.B. Proben) in einigen Fällen die Vermeidung oder Minimierung von Diskretisierungsfehlern erschweren.
Als Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien sichere Ankunftszeiten verwenden (z.B. dargestellt an Positionen in der Visualisierung 510), um die entsprechenden Positionen des Fahrzeugs 140 und die vorgeschlagenen Ankunftszeiten an diesen Positionen entlang der Trajektorie 502 zu testen. Wie vorab erwähnt ist, können die Pixel oder Punkte der Visualisierung 510 LSAs in der Visualisierung 510 entsprechen, wobei jedes Pixel oder jeder Punkt ein LSA-Intervall darstellt, das bei der sicheren Ankunftszeit endet, die durch einen oder mehrere Datenwerte des Pixels oder Punkts dargestellt wird. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann feststellen, dass die Trajektorie 502 sicher ist, indem er bestimmt, dass jede vorgeschlagene Ankunftszeit jeder Probe innerhalb der entsprechenden sicheren Zeitintervalle liegt, die den Positionen des Fahrzeugs 140 zugeordnet sind. Zum Beispiel kann für eine LSA eine vorgeschlagene Ankunftszeit und Position als sicher angesehen werden, abhängig zumindest teilweise davon, dass die vorgeschlagene Ankunftszeit bei oder vor der sicheren Ankunftszeit für die Position liegt (z.B. dargestellt durch ein Pixel oder einen Punkt). Im Gegensatz dazu kann bei einer ESA eine vorgeschlagene Ankunftszeit und -position als sicher angesehen werden, wenn die vorgeschlagene Ankunftszeit bei oder nach der sicheren Ankunftszeit für die Position liegt (z.B. dargestellt durch ein Pixel).
Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann die Sicherheit unter Verwendung anderer Kriterien in Bezug auf die vorgeschlagenen Ankunftszeiten und die entsprechenden sicheren Ankunftszeiten bewerten. Bei einigen Beispielen können die sicheren Ankunftszeiten, die von dem Analysator 114 von vorgeschlagenen Wegen oder Trajektorien verwendet werden, zu jedem geeigneten Zeitpunkt generiert werden, wie z.B. zumindest teilweise in einer Visualisierung oder einem anderen Format vor dem Testen einer Trajektorie durch den Analysator 114 von vorgeschlagenen Wegen oder Trajektorien und/oder nach Bedarf oder parallel zum Testen und/oder Generieren einer Trajektorie (z.B. ohne Generierung oder Verwendung einer Visualisierung, wie es hier beschrieben ist).
Bei einigen Beispielen kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien mehrere Tests an denselben oder verschiedenen Proben der Trajektorie 502 unter Verwendung mehrerer sicherer Ankunftszeiten durchführen, die unter verschiedenen Annahmen oder Bedingungen erzeugt wurden. Zum Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien prüfen, ob eine vorgeschlagene Ankunftszeit für eine Position sowohl mit der LSA als auch mit der ESA für diese Position übereinstimmt. Dies kann z.B. durch Testen einer ersten Visualisierung, die LSAs erfasst (z.B. die Visualisierung 402), und einer zweiten Visualisierung, die ESAs erfasst (z.B. die Visualisierung 404), erreicht werden. Als weiteres Beispiel kann eine einzelne Visualisierung, die getestet wird, sowohl LSAs als auch ESAs für zumindest einen Teil der Umgebung kodieren 126. Bei weiteren Beispielen können die sicheren Ankunftszeiten oder sicheren Zeitintervalle berechnet und verwendet werden, ohne eine Visualisierung zu verwenden. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann feststellen, dass die Trajektorie 502 unsicher ist, zumindest teilweise abhängig davon, dass eine vorgeschlagenen Ankunftszeit für eine Position für beide Tests nicht mit der sicheren Ankunftszeit übereinstimmt, und kann feststellen, dass die Trajektorie 502 sicher ist, zumindest teilweise abhängig davon, dass die vorgeschlagene Ankunftszeit für jeden Test mit einer sicheren Ankunftszeit übereinstimmt. Als weitere Beispiele kann ein Sicherheitsniveau oder -grad für eine Trajektorie und/oder Position auf mehreren sicheren Ankunftszeiten basieren (z.B. sowohl einer LSA als auch einer ESA).
Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann bei einigen Beispielen relativ geradlinig verlaufende Bremsprofile testen. Zu diesem Zweck können sowohl LSA als auch ESA getestet werden. Bei weiteren Beispielen kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien sowohl die LSA als auch die ESA verwenden, um eine Prüfung der Wegewahl durchzuführen. Zum Beispiel können LSA und ESA verwendet werden, um den sichersten Weg von einer aktuellen Position aus zu ermitteln. Der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien kann den Weg- oder Trajektoriengenerator 116 verwenden, um den sichersten Weg und/oder die sicherste Trajektorie zu bestimmen, und kann einen vorgeschlagenen Weg oder eine vorgeschlagene Trajektorie mit dem sichersten Weg und/oder der sichersten Trajektorie vergleichen (z.B. um ein Sicherheitsniveau oder einen Sicherheitsgrad für den Weg oder die Trajektorie, wie es vorab beschrieben ist, zu bestimmen). Zu diesem Zweck kann der Weg- oder Trajektoriengenerator 116 einen Gradientenanstieg anwenden (oder einen Abfall, angesichts der multiplikativen Umkehrung einer Visualisierung) und die Kurve an fahrdynamische Einschränkungen anpassen. Die Gauß-Newton-Optimierung kann schneller sein, als dem Gradienten zu folgen, aber die Idee ist die gleiche. Bei einigen Beispielen müssen nicht mehrere Arten von Visualisierungen oder Ansätzen zur Berechnung sicherer Ankunftszeiten verwendet werden, um den sichersten Weg und/oder die sicherste Trajektorie zu bestimmen.
Bei einigen Ausführungsformen umfasst der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien ein oder mehrere Modelle zum maschinellen Lernen, die zur Analyse einer vorgeschlagenen Trajektorie oder eines Weges unter Verwendung einer oder mehrerer Visualisierungen (z.B. einer der hier beschriebenen Visualisierungen) verwendet werden. Das Modell zum maschinellen Lernen kann z.B. Eingaben erhalten, die mindestens eine Visualisierung und mindestens eine vorgeschlagene Trajektorie oder einen vorgeschlagenen Weg umfassen. Das (die) Modell(e) zum maschinellen Lernen kann (können) trainiert werden, um die mindestens eine vorgeschlagene Trajektorie oder den mindestens einen vorgeschlagenen Weg unter Verwendung der mindestens einen Visualisierung auf Sicherheit zu testen. Eine Ausgabe(n) des Modells (der Modelle) zum maschinellen Lernen kann (können) repräsentativ sein für ein Sicherheitsniveau (hier alternativ als „Niveau einer Sicherheit“ oder „Grad einer Sicherheit“ bezeichnet) einer vorgeschlagenen Trajektorie oder Weges (oder eines Teils oder Punktes davon), bereitgestellt als eine Eingabe (z.B. entsprechend einem binären Wert oder Sicherheitsgrad). Das (die) Modell(e) zum maschinellen Lernen kann (können) ein oder mehrere neuronale Netze (z.B. tiefe neuronale Netze) umfassen, die einen oder mehrere der Eingaben empfangen und einen oder mehrere der Ausgaben erzeugen. Die Visualisierung(en) kann (können) zum Beispiel von einem oder mehreren faltenden neuronalen Netzen empfangen werden. Eine Visualisierung kann eine vorgeschlagene Trajektorie oder einen Weg aufweisen, oder die vorgeschlagene Trajektorie oder der Weg kann getrennt von einer Visualisierung für das/die Modell(e) zum maschinellen Lernen bereitgestellt werden.
Mit Bezug zu 6A ist 6A ein Datenflussdiagramm, das ein beispielhaftes Verfahren 600 zur Erzeugung einer Trajektorie unter Verwendung von Daten zur sicheren Ankunftszeit in Übereinstimmung mit einigen Ausführungsformen der vorliegenden Offenbarung darstellt.
Eine beliebige Anzahl von Eingaben, einschließlich, aber nicht beschränkt auf Daten 604 zur sicheren Ankunftszeit, kann in ein oder mehrere Modelle 616 zum maschinellen Lernen eingegeben werden. Die Daten 604 zur sicheren Ankunftszeit können den Daten 120 zur sicheren Ankunftszeit von 1A entsprechen.
Das (die) Modell(e) 616 zum maschinellen Lernen kann (können) dem Weg- oder Trajektoriengenerator 116 entsprechen und/oder als Merkmal oder Funktionalität desselben enthalten sein und kann (können) eine beliebige Anzahl von Ausgaben erzeugen oder berechnen, einschließlich, aber nicht beschränkt auf die Fahrzeug-Trajektorieninformation 620 (z.B. die Fahrzeug-Trajektorieninformation 124 von 1A). Die Fahrzeug-Trajektorieninformation 620 kann an eine oder mehrere Steuerkomponente(n) des autonomen Fahrzeugs 140 übertragen oder gesendet werden und kann optional mit dem Analysator 114 von vorgeschlagenen Wegen oder Trajektorien auf Sicherheit getestet werden. Die Steuerkomponente(n) kann (können) dann die Fahrzeug-Trajektorieninformation 620 (oder die aus der Fahrzeug-Trajektorieninformation 620 generierte Information) verwenden, um das Fahrzeug 140 entsprechend der Fahrzeug-Trajektorieninformation 620 zu steuern.
Die in das (die) Modell(e) 616 zum maschinellen Lernen eingegebenen Daten zur sicheren Ankunftszeit 604 können eine beliebige Anzahl von hierin beschriebenen Visualisierungen (z.B. Bilder) aufweisen oder eine oder mehrere sichere Ankunftszeiten auf andere Weise darstellen. Die Daten 604 zur sicheren Ankunftszeit können, wie oben beschrieben, unter Verwendung von Sensordaten, wie z.B. den Sensordaten 102, generiert werden. Andere potenzielle Sensorinformationen, die aus den Sensordaten von einem oder mehreren der Sensoren 138 generiert werden, können auf das/die Modell(e) 616 zum maschinellen Lernen angewendet werden. Die Sensorinformationen können Sensordaten von jedem der Sensoren des Fahrzeugs 140 (und/oder anderer Fahrzeuge, bei einigen Beispielen) aufweisen. Bei einigen Beispielen weisen die Eingaben Fahrzeugzustandsinformationen auf, die für den Zustand des Fahrzeugs 140 repräsentativ sind, wie z.B. Drehzahl, Geschwindigkeit, Beschleunigung, Abbremsung, Orientierung oder Pose, Lage oder Position (z.B. relativ zu den Daten 604zur sicheren Ankunftszeit) in der Umgebung 126 und/oder andere Zustandsinformationen. Diese Daten können von einem oder mehreren Sensoren des Fahrzeugs 140, wie z.B. einem oder mehreren IMU-Sensor(en) 1266, Drehzahlsensor(en) 1244, Lenksensor(en) 1240, Schwingungssensor(en) 1242 und/oder einem oder mehreren Sensoren des Bremssensorsystems 1246, des Antriebssystems 1250 und/oder des Lenksystems 1254 erfasst und/oder von diesen empfangen werden. Die Zustandsinformationen (z.B. Drehzahl, Orientierung usw.) können für das (die) Modell(e) 616 zum maschinellen Lernen bei der Berechnung der Fahrzeug-Trajektorieninformationen 620 wertvoll sein.
Das (die) Modell(e) 616 zum maschinellen Lernen kann (können) jede Art von Modellen zum maschinellen Lernen aufweisen, wie z.B. Modelle zum maschinellen Lernen unter Verwendung von linearer Regression, logistischer Regression, Entscheidungsbäumen, Support-Vector-Machines (SVM), Naive Bayes, k-nächster Nachbar (Knn), K-Means-Clustering, Random Forest, Dimensionalitätsreduktionsalgorithmen, Gradientenverstärkungsalgorithmen, neuronale Netze (z.B. Auto-Encoder, Faltungsalgorithmen, wiederkehrende Algorithmen, Perceptrons, Lang-/Kurzzeitgedächtnis, Hopfield, Boltzmann, Deep Believe, Dekonvolutionsalgorithmen, generativ kontradiktorische Algorithmen, Liquid State Machine, usw.), und/oder andere Arten von Modellen zum maschinellen Lernen.
Mit Bezug zu 6B ist 6B gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine Darstellung, die ein oder mehrere beispielhafte Modelle 616 zum maschinellen Lernen aufweist. Das (die) Modell(e) 616 zum maschinellen Lernenvon 6B kann (können) ein Beispiel für ein (mehrere) Modell(e) zum maschinellen Lernen sein, das (die) in dem Verfahren 600 verwendet werden kann (können). Das (die) Modell(e) 616 zum maschinellen Lernen von 6B ist (sind) jedoch nicht als Einschränkung gedacht, und das (die) Modell(e) 616 zum maschinellen Lernen kann (können) zusätzliche und/oder andere Modelle zum maschinellen Lernen aufweisen als das (die) Modell(e) 616 zum maschinellen Lernen von 6B. Das/die Modell(e) 616 zum maschinellen Lernen von 6B kann/können ein faltendes neuronales Netz aufweisen und kann/können daher hier alternativ als faltendes neuronales Netz 616 oder faltendes Netz 616 bezeichnet werden.
Das faltende Netz 616 weist die Daten 604 zur sicheren Ankunftszeit auf, die repräsentativ für eine oder mehrere Visualisierungen sicherer Ankunftszeiten sind (z.B. LSA- und/oder ESA-basierte Visualisierungen). Bei einigen Beispielen kann das faltende Netz 616 auch andere Eingaben aufweisen, wie z.B. Bilddaten, die von einer oder mehreren Kameras erzeugt werden (z.B. eine oder mehrere der hier beschriebenen Kameras in Bezug auf 12A-12C). Die Daten 604 zur sicheren Ankunftszeit und möglicherweise andere Bilddaten können in den Faltungsstrom/die Faltungsströme 626 des faltenden Netzes 616 eingegeben werden. Beispielsweise können die Bilddaten für jedes Bild einem eigenen Faltungsstrom 626 entsprechen.
Ein Faltungsstrom 626 kann eine beliebige Anzahl von Schichten aufweisen, wie z.B. die Schichten 632A-632C. Eine oder mehrere dieser Schichten können eine Eingabeschicht aufweisen. Die Eingabeschicht kann Werte enthalten, die mit den Bilddaten verknüpft sind. Beispielsweise kann die Eingabeschicht Werte enthalten, die für die Rohpixelwerte des Bildes/der Bilder repräsentativ sind, die in das faltende Netz 616 als Volumen eingegeben werden (z. B. Breite, Höhe und Farbkanäle (z. B. RGB), wie 32 × 32 × 3).
Eine oder mehrere Schichten können Faltungsschichten aufweisen. Die Faltungsschichten können die Ausgabe von Neuronen berechnen, die mit lokalen Regionen in einer Eingabeschicht (z.B. der Eingabeschicht) verbunden sind, wobei jede ein Skalarprodukt zwischen ihren Gewichten und einer kleinen Region, mit der sie im Eingabevolumen verbunden sind, berechnet. Ein Ergebnis der Faltungsschichten kann ein anderes Volumen sein, wobei eine der Dimensionen zumindest teilweise von der Anzahl der angewandten Filter abhängt (z.B. die Breite, die Höhe und die Anzahl der Filter, z.B. 32 × 32 × 12, wenn 12 die Anzahl der Filter ist).
Eine oder mehrere der Schichten können eine ReLU-Schicht (Rectified Linear Unit) aufweisen. Die ReLU-Schicht(en) kann (können) eine elementweise Aktivierungsfunktion anwenden, wie z.B. die max (0, x), mit einem Schwellenwert bei Null. Das resultierende Volumen einer ReLU-Schicht kann das gleiche Volumen wie das Eingabevolumen der ReLU-Schicht sein.
Eine oder mehrere der Schichten können eine Poolingschicht aufweisen. Die Poolingschicht kann entlang der räumlichen Abmessungen (z. B. Höhe und Breite) eine Abwärtsabtastung durchführen, was zu einem kleineren Volumen als das Eingabevolumen der Poolingschicht führen kann (z. B. 16 × 16 × 12 aus dem 32 × 32 × 12 Eingabevolumen).
Eine oder mehrere der Schichten können eine vollständig verbundene Schicht aufweisen. Jedes Neuron in der/den vollständig verbundenen Schicht(en) kann mit jedem der Neuronen in dem vorherigen Volumen verbunden sein. Die vollständig verbundene Schicht kann Klassenbewertungen berechnen, und das resultierende Volumen kann 1 × 1 × Anzahl der Klassen betragen. Bei einigen Beispielen kann der Faltungsstrom (die Faltungsströme) 626 eine vollständig verbundene (v. v.) Schicht aufweisen, während bei anderen Beispielen eine vollständig verbundene Schicht 634 des faltenden Netzes 616 die vollständig verbundene Schicht für den Faltungsstrom (die Faltungsströme) 626 sein kann.
Obwohl hier Eingabeschichten, Faltungsschichten, Pooling-Schichten, ReLU-Schichten und vollständig verbundene Schichten in Bezug auf den Faltungsstrom/die Faltungsströme 626 diskutiert werden, ist dies nicht als Einschränkung zu verstehen. Beispielsweise können im Faltungsstrom/den Faltungsströmen 626 zusätzliche oder alternative Schichten verwendet werden, wie z.B. Normalisierungsschichten, SoftMax-Schichten und/oder andere Schichttypen. Ferner ist die Reihenfolge und Anzahl der Schichten des faltenden Netzes 616 und/oder des Faltungsstroms 626 nicht auf eine bestimmte Architektur beschränkt.
Darüber hinaus können einige der Schichten Parameter (z.B. Gewichte) aufweisen, wie z.B. die Faltungsschichten und die vollständig verbundenen Schichten, andere hingegen nicht, wie z.B. die ReLU-Schichten und Poolingschichten. Bei einigen Beispielen können die Parameter durch den Faltungsstrom 626 und/oder die vollständig verbundene(n) Schicht(en) 634 während des Trainings erlernt werden. Darüber hinaus können einige der Schichten zusätzliche Hyperparameter aufweisen (z.B. Lernrate, Schrittweite, Epochen usw.), wie z.B. die Faltungsschichten, die vollständig verbundenen Schichten und die Poolingschichten, während dies bei anderen Schichten, wie z.B. den ReLU-Schichten, nicht der Fall ist. Die Parameter und Hyperparameter sind nicht eingeschränkt und können je nach Ausführungsform unterschiedlich sein.
Der Ausgang des Faltungsstroms/der Faltungsströme 626 kann in die vollständig verbundene(n) Schicht(en) 634 des faltenden Netzes 616 eingegeben werden. Zusätzlich zu der Ausgabe des (der) Faltungsstroms (Faltungsströme) 626 kann (können) die Variable(n) 614, von der (denen) zumindest einige repräsentativ für die Fahrzeugzustandsinformationen und/oder einen oder mehrere Parameter für ein oder mehrere Objekte sein können, die vom Objektanalysator 106 geliefert werden, in die vollständig verbundene(n) Schicht(en) 634 eingegeben werden.
Das (die) Modell(e) 616 zum maschinellen Lernen kann (können) anhand von Beispieltrajektorien für gegebene Eingaben in das Modell 616 zum maschinellen Lernen trainiert werden. Bei einigen Beispielen können die Beispieltrajektorien aus tatsächlichen Trajektorien eines Fahrzeugs (von Fahrzeugen), das (die) von menschlichen und/oder autonomen Fahrern gelenkt wird (werden), erfasst und aus Sensordaten extrahiert werden, die von einem Sensor (von Sensoren) des Fahrzeugs (der Fahrzeuge) erzeugt werden. In ähnlicher Weise können die Eingaben für Beispieltrajektorien aus Sensordaten extrahiert werden, die von einem Sensor / Sensoren des Fahrzeugs/der Fahrzeuge erzeugt werden. Beispielsweise kann eine Visualisierung für die Daten 604 zur sicheren Ankunftszeit mit den hier beschriebenen Ansätzen erzeugt und als Trainingsdaten für eine Beispieltrajektorie verwendet werden. Bei einigen Beispielen können die Trainingsdaten einem virtuellen Fahrzeug entsprechen, z.B. einem Fahrzeug, das in einer virtuellen Simulation gefahren wird, die eine virtuelle Umgebung umfasst.
Mit Bezug zu 7 ist 7 gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren 700 zur Steuerung von Fahrzeugen unter Verwendung sicherer Ankunftszeiten zeigt. Jeder Block des hier beschriebenen Verfahrens 700 umfasst einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software ausgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt. Das Verfahren kann auch in Form von einem Computer verwertbaren Anweisungen ausgestaltet sein, welche auf Computerspeichermedien gespeichert sind. Das Verfahren kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige Varianten zu nennen. Die hier beschriebenen Verfahren können zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen, und sind nicht auf bestimmte Beispiele beschränkt.
Das Verfahren 700, bei Block B702, weist ein Empfangen von Sensordaten auf. Zum Beispiel kann der Kommunikationsmanager 104 die Sensordaten 102 von mindestens einem Sensor des Fahrzeugs 140 empfangen.
Das Verfahren 700, bei Block B704, weist ein Bestimmen von Parametern von Objekt(en) auf. Beispielsweise kann der Objektanalysator 106, zumindest teilweise auf der Grundlage der Sensordaten 102, Parameter des Objekts 128A, das sich in der Umgebung 126 befindet, und, bei einigen Beispielen, mindestens ein weiteres Objekt, wie z.B. das Objekt 128B und das Objekt 128C, bestimmen.
Das Verfahren 700, bei Block B706, weist ein Modellieren von Trajektorien des Objekts/der Objekte in Richtung der Zielpositionen auf. Beispielsweise kann der Objektmodellierer 108 die Trajektorien des Objekts 128A zu jeder der Zielpositionen P₁, P₂, P₃, P₄, P₅, P₆ und P₇ von 3B zumindest teilweise auf der Grundlage der Parameter des Objekts 128A modellieren. Der Objektmodellierer 108 kann bei einigen Beispielen auch Trajektorien des Objekts 128B zu jeder der Zielpositionen P₁, P₂, P₃, P₄, P₅, P₆ und P₇ von 3B, zumindest teilweise auf der Grundlage der Parameter des Objekts 128B, und Trajektorien des Objekts 128C zu jeder der Zielpositionen P₁, P₂, P₃, P₄, P₅, P₆ und P₇ von 3B, zumindest teilweise auf der Grundlage der Parameter des Objekts 128C, modellieren.
Bei einigen Beispielen kann das Objekt 128A dem Objekt Y₁ von 3B entsprechen, und eine Trajektorie 320 kann einer der für das Objekt 128A modellierten Trajektorien entsprechen. Außerdem kann das Objekt 128B dem Objekt Y₂ aus 3B entsprechen, und eine Trajektorie 322 kann einer der für das Objekt 128B modellierten Trajektorien entsprechen. Außerdem kann das Objekt 128C dem Objekt Y₃ aus 3B entsprechen, und eine Trajektorie 324 kann einer der für das Objekt 128C modellierten Trajektorien entsprechen.
Das Verfahren 700, bei Block B708, weist ein Berechnen von sicheren Zeitintervallen von den Trajektorien auf, während denen es zu keiner Kollision mit dem/den Objekt(en) kommen würde. Beispielsweise kann der Objekttrajektorienanalysator 110 von den Trajektorien sichere Zeitintervalle berechnen, während denen das Fahrzeug 140, das die Zielpositionen P₁, P₂, P₃, P₄, P₅, P₆ und P₇ einnimmt, zumindest mit dem Objekt 128A keine Kollision verursachen würde. Zum Beispiel kann der Objekttrajektorienanalysator 110 die Trajektorie 320 analysieren, die dem Bewegungsprofil entsprechen kann, das dem Diagramm 200 von 2 entspricht. Wenn die Endzeit T_E der Trajektorie 320 eine sichere Ankunftszeit für das Fahrzeug 140 ist (z.B. wenn der Objekttrajektorienanalysator 110 feststellt, dass sich das Objekt 128A in einem vollständigen Stillstand befindet), kann der Objekttrajektorienanalysator 110 die Endzeit T_E der Trajektorie 320 als eine Endzeit eines sicheren Zeitintervalls und die Startzeit T_s der Trajektorie 320 als eine Startzeit des sicheren Zeitintervalls verwenden (in anderen Beispielen kann jeder beliebige Zeitbereich innerhalb der Trajektorie als sicheres Zeitintervall berechnet werden). Der Objekttrajektorienanalysator 110 kann in ähnlicher Weise sichere Ankunftszeiten für andere modellierte Trajektorien des Objekts Y₁ zu den Zielpositionen P₂, P₃, P₄, P₅, P₆ und P₇ berechnen. Bei Beispielen, die mehrere Objekte berücksichtigen, können sichere Ankunftszeiten in ähnlicher Weise für das Objekt Y₂ und jede der Zielpositionen P₂, P₃, P₄, P₅, P₆ und P₇ sowie für das Objekt Y₃ und jede der Zielpositionen P₂, P₃, P₄, P₅, P₆ und P₇ berechnet werden.
Das Verfahren 700, bei Block B710, weist ein Erzeugen einer Trajektorie für ein Fahrzeug auf. Zum Beispiel kann der Weg- oder Trajektoriengenerator 116, zumindest teilweise auf der Grundlage der sicheren Zeitintervalle und einer Position des Fahrzeugs 140 in der Umgebung 126, die Fahrzeugtrajektorieninformation 124 erzeugen, die für mindestens einen Teil der Trajektorie 144 für das Fahrzeug 140 repräsentativ ist.
Das Verfahren 700, bei Block B712, weist ein Analysieren einer vorgeschlagenen Trajektorie oder eines vorgeschlagenen Weges für ein Fahrzeug auf. Zum Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien, zumindest teilweise auf der Grundlage der sicheren Zeitintervallen und einer Position des Fahrzeugs 140 in der Umgebung 126, die Fahrzeug-Trajektorieninformation 124 analysieren, die für mindestens einen Teil der Trajektorie 144 für das Fahrzeug 140 repräsentativ ist.
Bei einigen Beispielen kann das Verfahren 700 nur einen der Blöcke B710 und B712 aufweisen. Ferner kann eine im Block B710 erzeugte Trajektorie im Block B712 analysiert werden.
8 ist ein Flussdiagramm, das gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Verfahren 800 zur Steuerung von Fahrzeugen unter Verwendung sicherer Ankunftszeiten zeigt. Jeder hier beschriebene Block des Verfahrens 800 umfasst einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software ausgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt. Das Verfahren kann auch in Form von einem Computer verwertbaren Anweisungen ausgestaltet sein, welche auf Computerspeichermedien gespeichert sind. Das Verfahren kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige zu nennen.
Das Verfahren 800, bei Block B802, weist ein Bestimmen der Parameter von Objekt(en) auf. Beispielsweise kann der Objektanalysator 106, zumindest teilweise auf der Grundlage der Sensordaten 102, Parameter des Objekts 128A bestimmen, das sich in der Umgebung 126 befindet, und in einigen Beispielen mindestens ein weiteres Objekt, wie z.B. das Objekt 128B und das Objekt 128C. Bei einigen Beispielen empfängt der Objektanalysator 106 einen oder mehrere der Parameter von einem anderen Fahrzeug oder System, z.B. unter Verwendung des Kommunikationsmanagers 104.
Das Verfahren 800, bei Block B804, weist ein Berechnen von sicheren Zeitintervallen auf, während denen es zu keiner Kollision mit dem/den Objekt(en) kommen würde. Beispielsweise kann der Objektmodellierer 108 Trajektorien des Objekts 128A und bei einigen Beispielen mindestens eines der Objekte 128B oder 128C modellieren, und der Objekttrajektorienanalysator 110 kann aus Trajektorien, die dem Objekt 128A, dem Objekt 128B oder dem Objekt 128C zugeordnet sind, zumindest teilweise auf der Grundlage des einen oder der mehreren Parameter sichere Zeitintervalle berechnen, während denen das Fahrzeug 140, das die Zielpositionen P₁, P₂, P₃, P₄, P₅, P₆ und P₇ einnimmt, keine Kollision mit dem Objekt 128A, dem Objekt 128B oder dem Objekt 128C verursachen würde.
Das Verfahren 800 weist bei Block B806 ein Erzeugen eines Bildes auf, das Datenwerte aufweist, die zumindest für Teile der sicheren Zeitintervalle repräsentativ sind. Beispielsweise kann der Visualisierungsgenerator 112 ein Bild mit Datenwerten erzeugen, die zumindest für Teile der sicheren Zeitintervalle repräsentativ sind. Bei Beispielen, die die sicheren Zeitintervalle verwenden, die mit dem Objekt 128A und dem Objekt 128B verbunden sind, kann das Bild ähnlich dem sein, was für die Daten 120 zur sicheren Ankunftszeit in 1A dargestellt ist. Als andere Beispiele kann das Bild ähnlich wie die Visualisierung 402 von 4A oder die Visualisierung 404 von 4B erscheinen.
Das Verfahren 800, bei Block B808, weist ein Erzeugen einer Trajektorie für ein Fahrzeug auf. Zum Beispiel kann der Weg- oder Trajektoriengenerator 116, zumindest teilweise auf der Grundlage des Bildes und einer Position des Fahrzeugs 140 in der Umgebung 126, die Fahrzeugtrajektorieninformation 124 erzeugen, die mindestens einen Teil der Trajektorie 144 für das Fahrzeug 140 beschreibt.
Das Verfahren 800, bei Block B810, weist ein Analysieren einer vorgeschlagenen Trajektorie oder eines vorgeschlagenen Weges für ein Fahrzeug auf. Zum Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien, zumindest teilweise auf der Grundlage des Bildes und einer Position des Fahrzeugs 140 in der Umgebung 126, die Fahrzeugtrajektorieninformation 124 analysieren, die für mindestens einen Teil der Trajektorie 144 für das Fahrzeug 140 repräsentativ ist.
Bei einigen Beispielen kann das Verfahren 800 nur einen der Blöcke B808 und B810 aufweisen. Ferner kann eine in dem Block B808 erzeugte Trajektorie in dem Block B810 analysiert werden.
Mit Bezug zu 9 ist 9 gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Flussdiagramm, das ein Verfahren 900 zum Steuern von Fahrzeugen unter Verwendung sicherer Ankunftszeiten darstellt. Jeder Block des hier beschriebenen Verfahrens 900 umfasst einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software ausgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt. Das Verfahren kann auch in Form von durch einen Computer verwertbaren Anweisungen ausgestaltet sein, welche auf Computerspeichermedien gespeichert sind. Das Verfahren kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige Varianten zu nennen.
Das Verfahren 900, bei Block B902, weist ein Bestimmen von Parametern von (einem) Objekt(en) auf. Beispielsweise kann der Objektanalysator 106, zumindest teilweise auf der Grundlage der Sensordaten 102, Parameter des Objekts 128A bestimmen, das sich in der Umgebung 126 befindet, und bei einigen Beispielen von mindestens einem weiteren Objekt, wie z.B. von dem Objekt 128B und dem Objekt 128C.
Das Verfahren 900, bei Block B904, weist ein Bestimmen sicherer Ankunftszeiten für Zielpositionen auf, die nicht zu einer Kollision mit dem/den Objekt(en) führen würden. Beispielsweise kann der Objekt-Trajektorienanalysator 110, zumindest teilweise auf der Grundlage der Parameter des Objekts 128A, des Objekts 128B und/oder des Objekts 128C, sichere Ankunftszeiten bestimmen, zu denen das Fahrzeug 140, das die Zielpositionen P₁, P₂, P₃ von 3B und/oder andere Punkte in der Umgebung einnimmt, die der Kontur 308 entsprechen, keine Kollision mit dem Objekt 128A, dem Objekt 128B und/oder dem Objekt 128C verursachen würde.
Das Verfahren 900, bei Block B906, weist ein Erzeugen einer Kontur auf, die repräsentativ für eine Gruppe der Zielpositionen und eine zugehörige Gruppe der sicheren Ankunftszeiten ist. Beispielsweise kann der Visualisierungsgenerator 112 die Kontur 308 erzeugen, die zumindest einen Teil einer grafischen Darstellung der Umgebung 126 bildet. Die Kontur 308 kann in jeder hierin beschriebenen geeigneten Visualisierung enthalten sein und kann in den Daten 120 zur sicheren Ankunftszeit in jeder geeigneten Form repräsentiert werden, wie z.B. in einer Bildform (z.B. gerastert oder vektoriell) und/oder in einer mathematischen Form.
Das Verfahren 900, bei Block B908, weist ein Erzeugen einer Trajektorie für ein Fahrzeug auf. Zum Beispiel kann der Pfad- oder Trajektoriengenerator 116, zumindest teilweise auf der Grundlage der Kontur und einer Position des Fahrzeugs 140 in der Umgebung 126, die Fahrzeug-Trajektorieninformation 124 erzeugen, die für mindestens einen Teil der Trajektorie 144 für das Fahrzeug 140 repräsentativ ist.
Das Verfahren 900, bei Block B910, weist ein Analysieren einer vorgeschlagenen Trajektorie oder eines vorgeschlagenen Weges für ein Fahrzeug auf. Zum Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien, zumindest teilweise auf der Grundlage der Kontur und einer Position des Fahrzeugs 140 in der Umgebung 126, die Fahrzeug-Trajektorieninformation 124 analysieren, die für mindestens einen Teil der Trajektorie 144 für das Fahrzeug 140 repräsentativ ist.
Bei einigen Beispielen kann das Verfahren 900 nur einen der Blöcke B908 und B910 aufweisen. Ferner kann eine in dem Block B908 erzeugte Trajektorie in dem Block B910 analysiert werden.
Mit Bezug zu 10 ist 10 ein Flussdiagramm, das gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Verfahren 1000 zum Steuern von Fahrzeugen mittels sicherer Ankunftszeiten darstellt. Jeder Block des hier beschriebenen Verfahrens 1000 umfasst einen Rechenprozess, der mit einer beliebigen Kombination von Hardware, Firmware und/oder Software ausgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt. Das Verfahren kann auch in Form von einem Computer verwertbare Anweisungen ausgestaltet sein, welche auf Computerspeichermedien gespeichert sind. Das Verfahren kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige Varianten zu nennen.
Das Verfahren 1000, bei Block B1002, weist ein Empfangen einer Visualisierung von mindestens einer sicheren Ankunftszeit oder von mindestens einem sicheren Zeitintervall auf. Zum Beispiel kann der Weg- oder Trajektoriengenerator 116 die Daten 604 zur sicheren Ankunftszeit von 6A von dem Visualisierungsgenerator 112 erhalten.
Das Verfahren 1000, bei Block B1004, weist ein Bereitstellen der Visualisierung als eine Eingabe für ein oder mehrere Modelle zum maschinellen Lernen auf. Zum Beispiel kann der Weg- oder Trajektoriengenerator 116 die Daten 604 zur sicheren Ankunftszeit als Eingabe für das/die Modell(e) 616 zum maschinellen Lernen liefern.
Das Verfahren 1000, bei Block B1006, weist ein Empfangen einer vorgeschlagenen Trajektorie oder eines vorgeschlagenen Weges für ein Fahrzeug von dem/den Modell(en) zum maschinellen Lernen auf. Beispielsweise kann der Visualisierungsgenerator 112 von dem/den maschinellen Lernmodell(en) 616 die Fahrzeug-Trajektorieninformationen 620 erhalten.
Mit Bezug zu 11 ist 11 ein Flussdiagramm, das gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Verfahren 1100 zum Steuern von Fahrzeugen mittels sicherer Ankunftszeiten darstellt. Jeder Block des hier beschriebenen Verfahrens 1100 umfasst einen Rechenprozess, der mit einer beliebigen Kombination von Hardware, Firmware und/oder Software ausgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt. Das Verfahren kann auch in Form von einem Computer verwertbare Anweisungen ausgestaltet sein, welche auf Computerspeichermedien gespeichert sind. Das Verfahren kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige Varianten zu nennen.
Das Verfahren 1100, bei Block B1102, weist ein Empfangen einer Visualisierung von mindestens einer sicheren Ankunftszeit oder von mindestens einem sicheren Zeitintervall auf. Zum Beispiel kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien die Daten 120 zur sicheren Ankunftszeit von dem Visualisierungsgenerator 112 erhalten.
Das Verfahren 1100, bei Block B1104, weist ein Bereitstellen der Visualisierung und einer vorgeschlagenen Trajektorie oder eines vorgeschlagenen Wegs als Eingabe für ein oder mehrere Modelle zum maschinellen Lernen auf. Beispielsweise kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien die Daten zur sicheren Ankunftszeit 604 und die Fahrzeug-Trajektorieninformationen 124 als Eingaben für das/die Modell(e) zum maschinellen Lernen liefern.
Das Verfahren 1100, bei Block B1106, weist ein Erhalten von Daten von dem/den Modell(en) zum maschinellen Lernen auf, die repräsentativ für ein Sicherheitsniveau für die vorgeschlagene Trajektorie oder den vorgeschlagenen Weg sind. Beispielsweise kann der Analysator 114 von vorgeschlagenen Wegen oder Trajektorien von dem/den Modell(en) zum maschinellen Lernen ein Sicherheitsniveau für die vorgeschlagene Trajektorie oder den vorgeschlagenen Pfad erhalten, wie z.B. einen Sicherheitsgrad.
Beispiel Autonomes Fahrzeug
12A ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Beispiel für ein autonomes Fahrzeug 1200. Das autonome Fahrzeug 1200 (hier alternativ als „Fahrzeug 1200“ bezeichnet) kann ein Personenfahrzeug sein, wie z.B. ein Pkw, ein Lkw, ein Bus und/oder ein anderer Fahrzeugtyp, der einen oder mehrere Fahrgäste aufnimmt. Autonome Fahrzeuge werden im Allgemeinen anhand des Automatisierungsgrades beschrieben, der 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“ (Norm Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Norm Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieser Norm) definiert wird. Das Fahrzeug 1200 kann in Übereinstimmung mit einer oder mehreren der Stufe 3 - Stufe 5 der Stufen zum autonomen Fahren funktionsfähig sein. Zum Beispiel kann das Fahrzeug 1200 in Abhängigkeit von der Ausführungsform eine bedingte Automatisierung (Stufe 3), eine hohe Automatisierung (Stufe 4) und/oder eine Vollautomatisierung (Stufe 5) aufweisen.
Das Fahrzeug 1200 kann Komponenten wie ein Fahrgestell, einen Fahrzeugaufbau, Räder (z.B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs aufweisen. Das Fahrzeug 1200 kann ein Antriebssystem 1250 aufweisen, wie z.B. einen Verbrennungsmotor, ein Hybrid-Elektromotor, einen vollelektrischen Motor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 1250 kann mit einem Antriebsstrang des Fahrzeugs 1200 verbunden sein, der ein Getriebe aufweisen kann, um den Antrieb des Fahrzeugs 1200 zu ermöglichen. Das Antriebssystem 1250 kann als Reaktion auf den Empfang von Signalen von der Drosselklappe/dem Beschleuniger 1252 gesteuert werden.
Ein Lenksystem 1254, das ein Lenkrad aufweisen kann, kann verwendet werden, um das Fahrzeug 1200 zu lenken (z.B. entlang eines gewünschten Weges oder einer gewünschten Route), wenn das Antriebssystem 1250 in Betrieb ist (z.B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 1254 kann Signale von einem Lenkstellglied 1256 empfangen. Das Lenkrad kann bei einer vollständige Automatisierung (Stufe 5) optional sein.
Das Bremssensorsystem 1246 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf den Empfang von Signalen von den Bremsaktuatoren 1248 und/oder Bremssensoren zu betätigen.
Steuergerät(e) 1236, das/die ein oder mehrere Systeme on Chip (SoCs) 1204 (12C) und/oder GPU(s) aufweisen kann/können, kann/können Signale (z.B. repräsentativ für Befehle) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 1200 liefern. Zum Beispiel kann (können) das (die) Steuergerät(e) Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 1248, zur Betätigung des Lenksystems 1254 über einen oder mehrere Lenkaktuatoren 1256, zur Betätigung des Antriebssystems 1250 über einen oder mehrere Gashebel/Beschleuniger 1252 senden. Das (die) Steuergerät(e) 1236 kann (können) ein oder mehrere bordeigene (z.B. integrierte) Rechengeräte (z.B. Supercomputer) aufweisen, die Sensorsignale verarbeiten und Betriebsbefehle (z.B. Signale, die Befehle darstellen) ausgeben, um ein autonomes Fahren zu ermöglichen und/oder um einen menschlichen Fahrer beim Lenken des Fahrzeugs 1200 zu unterstützen. Das/die Steuergerät(e) 1236 kann/können ein erstes Steuergerät 1236 für autonome Fahrfunktionen, ein zweites Steuergerät 1236 für funktionale Sicherheitsfunktionen, ein drittes Steuergerät 1236 für Funktionen der künstlichen Intelligenz (z.B. Computersehen), ein viertes Steuergerät 1236 für Infotainmentfunktionen, ein fünftes Steuergerät 1236 für Redundanz in Notfällen und/oder andere Steuergeräte aufweisen. Bei einigen Beispielen kann eine einzige Steuerung 1236 zwei oder mehr der oben genannten Funktionalitäten handhaben, zwei oder mehr Steuerungen 1236 können eine einzelne Funktionalität und/oder eine beliebige Kombination davon handhaben.
Das (die) Steuergerät(e) 1236 kann (können) die Signale für die Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 1200 als Reaktion auf Sensordaten liefern, die von einem oder mehreren Sensoren (z.B. Sensoreingänge) empfangen werden. Die Sensordaten können z.B. und ohne Einschränkung von dem/den Sensor(en) 1258 des globalen Satellitennavigationssystems (z.B. Sensor(en) des globalen Positionierungssystems), RADAR-Sensor(en) 1260, Ultraschallsensor(en) 1262, LIDAR-Sensor(en) 1264, Inertial Measurement Unit (IMU)-Sensor(en) 1266 empfangen werden (z.B. Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer(n) usw.), Mikrofon(e) 1296, Stereokamera(s) 1268, Weitwinkelkamera(s) 1270 (z.B. Fisheye-Kameras), Infrarotkamera(s) 1272, Surround-Kamera(s) 1274 (z.B. 360-Grad-Kameras), Fern- und/oder Mittelbereichskamera(s) 1298, Geschwindigkeitssensor(en) 1244 (z.B. zur Messung der Geschwindigkeit des Fahrzeugs 1200), Vibrationssensor(en) 1242, Lenksensor(en) 1240, Bremssensor(en) (z.B. als Teil des Bremssensorsystems 1246) und/oder andere Sensortypen.
Eines oder mehrere der Steuergeräte 1236 können Eingaben (z.B. dargestellt durch Eingabedaten) von einem Kombiinstrument 1232 des Fahrzeugs 1200 empfangen und Ausgaben (z.B. dargestellt durch Ausgabedaten, Anzeigedaten usw.) über eine Mensch-Maschine-Schnittstelle (HMI) Anzeige 1234, einen akustischen Signalgeber, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 1200 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z.B. die HD-Karte 1222 von 12C), Ortsdaten (z.B. die Position des Fahrzeugs 1200, wie auf einer Karte), Richtung, Position anderer Fahrzeuge (z.B. ein Belegungsraster), Informationen über Objekte und den Zustand von Objekten, wie sie von dem/den Steuergerät(en) 1236 wahrgenommen werden, usw. aufweisen. Die HMI-Anzeige 1234 kann z.B. Informationen über die Anwesenheit eines oder mehrerer Objekte (z.B. ein Straßenschild, Warnschild, Ampelwechsel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, durchführt oder durchführen wird (z.B. Spurwechsel jetzt, Ausfahrt 34B in zwei Meilen, usw.).
Das Fahrzeug 1200 weist ferner eine Netzwerkschnittstelle 1224 auf, die eine oder mehrere Funkantenne(n) 1226 und/oder Funkmodem(s) zur Kommunikation über ein oder mehrere Netze aufweisen kann. Zum Beispiel kann die Netzwerkschnittstelle 1224 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. zu kommunizieren. Die Funkantenne(n) 1226 kann(n) auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Geräte usw.) ermöglichen, wobei lokale Netzwerke wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Weitverkehrsnetzwerke mit geringer Leistung (LPWANs) wie LoRaWAN, SigFox usw. verwendet werden können.
12B ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Beispiel für Kamerapositionen und Sichtfelder für das Beispiel des autonomen Fahrzeugs 1200 von 12A. Die Kameras und die entsprechenden Sichtfelder sind eine beispielhafte Ausführungsform und stellen keine Einschränkung dar. Zum Beispiel können zusätzliche und/oder alternative Kameras vorhanden sein und/oder die Kameras können sich an verschiedenen Orten an dem Fahrzeug 1200 befinden.
Die Kameratypen für die Kameras können unter anderem Digitalkameras aufweisen, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 1200 angepasst werden können. Die Kamera(s) können auf der Sicherheitsintegritätsstufe (ASIL) B und/oder einer anderen Stufe (ASIL) betrieben werden. Die Kameratypen können je nach Ausführungsform jede beliebige Bildaufnahmerate erreichen, z. B. 60 Bilder pro Sekunde (fps), 1220 fps, 240 fps usw. Die Kameras können Rolling Shutter, Global Shutter, einen anderen Typ von Shutter oder eine Kombination davon verwenden. Bei einigen Beispielen kann das Farbfilterarray ein Rot-Klar-Klar-Klar-Farbfilterarray (RCCC), ein Rot-Klar-Klar-Blau-Farbfilterarray (RCCB), ein Rot-Blau-Grün-Klar-Farbfilterarray (RBGC), ein Foveon X3-Farbfilterarray, ein Bayer-Sensoren-Farbfilterarray (RGGB), ein Monochrom-Sensor-Farbfilterarray und/oder eine andere Art von Farbfilterarray aufweisen. Bei einigen Ausführungsformen können Kameras mit klaren Pixeln, wie z.B. Kameras mit einem RCCC, einem RCCB und/oder einer RBGC-Farbfilteranordnung, verwendet werden, um die Lichtempfindlichkeit zu erhöhen.
Bei einigen Beispielen können eine oder mehrere der Kamera(s) zur Ausführung von ADAS-Funktionen (Advanced Driver Assistance Systems) verwendet werden (z.B. als Teil eines redundanten oder ausfallsicheren Designs). Beispielsweise kann eine Multifunktions-Monokamera installiert werden, um Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und eine intelligente Scheinwerfersteuerung aufzuweisen. Eine oder mehrere der Kamera(s) (z.B. alle Kameras) können Bilddaten (z.B. ein Video) gleichzeitig aufzeichnen und bereitstellen.
Eine oder mehrere der Kameras können in einer Anordnung, z.B. einer kundenspezifischen (3-D-gedruckten) Anordnung, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z.B. Reflexionen von dem Armaturenbrett, die in den Windschutzscheibenspiegeln reflektiert werden), die die Bilddatenerfassung der Kamera stören könnten, auszuschließen. In Bezug auf am Außenspiegel angebrachten Anordnungen können die am Außenspiegel angebrachten Anordnungen kundenspezifisch 3-D-gedruckt sein, so dass die Kameramontageplatte der Form des Außenspiegels entspricht. Bei einigen Beispielen können die Kamera(s) in den Außenspiegel integriert sein. Bei Seitensichtkameras kann/können die Kamera(s) auch in die vier Säulen an jeder Ecke der Fahrzeugkabine integriert sein.
Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 1200 enthält (z.B. nach vorn gerichtete Kameras), können für die Surround-Sicht verwendet werden, um nach vorn gerichtete Wege und Hindernisse zu identifizieren, sowie mit Hilfe eines oder mehrerer Steuergeräte 1236 und/oder Steuer-SoCs, die wichtige Informationen zur Erzeugung eines Belegungsrasters und/oder zur Bestimmung der bevorzugten Fahrzeugwege liefern. Nach vorn gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorn gerichtete Kameras können auch für ADAS-Funktionen und -Systeme verwendet werden, einschließlich Spurhalteassistenten („LDW“), autonomer Geschwindigkeitsregler („ACC“) und/oder anderer Funktionen wie Verkehrszeichenerkennung.
Eine Vielzahl von Kameras kann in einer nach vorn gerichteten Konfiguration verwendet werden, einschließlich z.B. einer monokularen Kameraplattform, die einen CMOS-Farbbildsensor (komplementärer Metalloxid-Halbleiter) aufweist. Ein weiteres Beispiel kann/können eine Weitwinkelkamera(s) 1270 sein, die zur Wahrnehmung von Objekten verwendet werden kann/können, die von der Peripherie aus gesehen werden (z.B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl in 12B nur eine Weitwinkelkamera abgebildet ist, können beliebig viele Weitwinkelkameras 1270 an dem Fahrzeug 1200 vorhanden sein. Darüber hinaus können Weitwinkelkamera(s) 1298 (z.B. ein Weitwinkel-Stereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert wurde. Die Kamera(s) 1298 mit großer Reichweite kann/können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
Eine oder mehrere Stereokameras 1268 können auch in einer nach vorn ausgerichteten Konfiguration enthalten sein. Die Stereokamera(s) 1268 kann/können eine integrierte Steuereinheit aufweisen, die eine skalierbare Verarbeitungseinheit umfasst, die einen programmierbaren Logikbaustein (FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Eine solche Einheit kann verwendet werden, um eine 3D-Karte der Fahrzeugumgebung zu erzeugen, die eine Entfernungsschätzung für alle Punkte in dem Bild aufweist. Eine alternative Stereokamera(s) 1268 kann/können einen/mehrere kompakte(n) Stereovisionssensor(en) aufweisen, der/die zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip aufweisen kann/können, der die Entfernung von dem Fahrzeug zu dem Zielobjekt messen und die erzeugten Informationen (z.B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurhaltewarnfunktionen verwenden kann. Andere Arten von Stereokamera(s) 1268 können zusätzlich zu oder alternativ zu den hier beschriebenen verwendet werden.
Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 1200 aufweist (z.B. Seitensichtkameras), können für die Surround-Sicht verwendet werden und Informationen liefern, die zur Erstellung und Aktualisierung des Belegungsrasters sowie zur Erzeugung von Seitenaufprall-Kollisionswarnungen verwendet werden. Zum Beispiel können Surround-Kamera(s) 1274 (z.B. vier Surround-Kameras 1274, wie sie in 12B dargestellt sind) an dem Fahrzeug 1200 angeordnet sein. Die Surround-Kamera(s) 1274 kann/können Weitwinkelkamera(s) 1270, Fischaugen-Kamera(s), 360-Grad-Kamera(s) und/oder ähnliches aufweisen. Zum Beispiel können vier Fischaugen-Kameras an der Vorderseite, am Heck und an den Seiten des Fahrzeugs angebracht sein. Bei einer alternativen Anordnung kann das Fahrzeug drei Surround-Kamera(s) 1274 (z.B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z.B. eine nach vorn gerichtete Kamera) als vierte Surround-Sicht-Kamera einsetzen.
Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 1200 aufweist (z.B. Rückfahrkameras), können für eine Einparkhilfe, eine Surround-Sicht, eine Warnung vor einem Heckaufprall und eine Erstellung und Aktualisierung des Belegungsrasters verwendet werden. Eine Vielzahl von Kameras kann verwendet werden, einschließlich, aber nicht beschränkt auf Kameras, die auch als nach vorn gerichtete Kamera(s) geeignet sind (z.B. Fern- und/oder Mittelbereichskamera(s) 1298, Stereokamera(s) 1268, Infrarotkamera(s) 1272 usw.), wie es hier beschrieben ist.
12C ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 1200 von 12A. Es sei darauf hingewiesen, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Darüber hinaus sind viele der hier beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Lage implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt.
Jede der Komponenten, Merkmale und Systeme des Fahrzeugs 1200 in 12C sind so dargestellt, dass sie über den Bus 1202 verbunden sind. Der Bus 1202 kann eine Datenschnittstelle für ein Controller Area Network (CAN) aufweisen (hier alternativ als „CAN-Bus“ bezeichnet). Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 1200 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 1200 dient, wie z.B. Bremsbetätigung, Beschleunigung, Bremsen, Lenkung, Scheibenwischer usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Netzknoten aufweist, von denen jeder seinen eigenen eindeutigen Identifizierer (z.B. eine CAN-ID) hat. Auf den CAN-Bus kann zugegriffen werden, um Lenkradwinkel, Fahrgeschwindigkeit, Motordrehzahl (RPMs), Knopfpositionen und/oder andere Fahrzeugzustandsanzeigen zu finden. Der CAN-Bus kann ASIL B-konform sein.
Obwohl der Bus 1202 hier als ein CAN-Bus beschrieben wird, soll dies keine Einschränkung darstellen. Zum Beispiel können zusätzlich oder alternativ zu dem CAN-Bus, FlexRay und/oder Ethernet verwendet werden. Auch wenn eine einzelne Leitung zur Darstellung des Busses 1202 verwendet wird, soll dies keine Einschränkung darstellen. Beispielsweise kann es eine beliebige Anzahl von Bussen 1202 geben, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Arten von Bussen mit einem anderen Protokoll aufweisen können. Bei einigen Beispielen können zwei oder mehr Busse 1202 zur Ausführung verschiedener Funktionen und/oder zur Redundanz verwendet werden. Beispielsweise kann ein erster Bus 1202 für die Kollisionsvermeidungsfunktionalität und ein zweiter Bus 1202 für die Betätigungssteuerung verwendet werden. Bei jedem Beispiel kann jeder Bus 1202 mit jeder der Komponenten des Fahrzeugs 1200 kommunizieren, und zwei oder mehr Busse 1202 können mit den gleichen Komponenten kommunizieren. Bei einigen Beispielen kann jedes SoC 1204, jedes Steuergerät 1236 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf die gleichen Eingabedaten haben (z.B. Eingaben von Sensoren des Fahrzeugs 1200) und an einen gemeinsamen Bus, z.B. den CAN-Bus, angeschlossen sein.
Das Fahrzeug 1200 kann ein oder mehrere Steuergerät(e) 1236 aufweisen, wie z.B. die hier in Bezug auf 12A beschriebenen. Das (die) Steuergerät(e) 1236 kann (können) für eine Vielzahl von Funktionen verwendet werden. Das (die) Steuergerät(e) 1236 kann (können) mit verschiedenen anderen Komponenten und Systemen des Fahrzeugs 1200 gekoppelt sein und kann (können) für die Steuerung des Fahrzeugs 1200, die künstliche Intelligenz des Fahrzeugs 1200, das Infotainment für das Fahrzeug 1200 und/oder ähnliches verwendet werden.
Das Fahrzeug 1200 kann ein oder mehrere Systeme auf einem Chip (SoC) 1204 aufweisen. Das SoC 1204 kann eine oder mehrere CPU(s) 1206, eine oder mehrere GPU(s) 1208, einen oder mehrere Prozessoren 1210, einen oder mehrere Cache(s) 1212, einen oder mehrere Beschleuniger 1214, einen oder mehrere Datenspeicher 1216 und/oder andere nicht abgebildete Komponenten und Merkmale aufweisen. Das (die) SoC(s) 1204 kann (können) zur Steuerung des Fahrzeugs 1200 in einer Vielzahl von Plattformen und Systemen verwendet werden. Zum Beispiel kann/können das/die SoC(s) 1204 in einem System (z.B. dem System des Fahrzeugs 1200) mit einer HD-Karte 1222 kombiniert sein, die Kartenaktualisierungen und/oder -updates über eine Netzschnittstelle 1224 von einem oder mehreren Servern (z.B. Server 1278 von 12D) erhalten kann.
Die CPU(s) 1206 kann/können ein CPU-Cluster oder CPU-Komplex aufweisen (hier alternativ als „CCPLEX“ bezeichnet). Die CPU(s) 1206 kann/können mehrere Kerne und/oder L2-Caches aufweisen. Bei einigen Ausführungsformen kann/können die CPU(s) 1206 beispielsweise acht Kerne in einer kohärenten Multiprozessor-Konfiguration aufweisen. Bei einigen Ausführungsformen kann/können die CPU(s) 1206 vier Dual-Core-Cluster aufweisen, wobei jedes Cluster über einen eigenen L2-Cache (z. B. einen 2 MB großen L2-Cache) verfügt. Die CPU(s) 1206 (z.B. CCPLEX) kann/können so konfiguriert sein, dass sie einen gleichzeitigen Cluster-Betrieb unterstützen, so dass jede beliebige Kombination der Cluster der CPU(s) 1206 zu jedem beliebigen Zeitpunkt aktiv sein kann.
Die CPU(s) 1206 kann/können Energieverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Merkmale aufweisen: einzelne Hardware-Blöcke können im Leerlauf automatisch taktgesteuert werden, um dynamische Energie zu sparen; jeder Kern-Takt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen keine Befehle aktiv ausführt; jeder Kern kann unabhängig leistungsgesteuert sein; jedes Kern-Cluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder leistungsgesteuert sind; und/oder jedes Kern-Cluster kann unabhängig leistungsgesteuert sein, wenn alle Kerne leistungsgesteuert sind. Die CPU(s) 1206 kann/können darüber hinaus einen erweiterten Algorithmus zur Verwaltung von Leistungszuständen implementieren, wobei zulässige Leistungszustände und erwartete Aufwachzeiten angegeben werden und die Hardware / der Mikrocode den besten Leistungszustand bestimmt, der für den Kern, das Cluster und CCPLEX einzugeben ist. Die Verarbeitungskerne können vereinfachte Eingabesequenzen für den Leistungszustand in Software unterstützen, wobei die Arbeit auf den Mikrocode verlagert ist.
Die GPU(s) 1208 kann/können eine integrierte Gpu aufweisen (hier alternativ als „iGPU“ bezeichnet). Die Gpu8S9 1208 kann/können programmierbar und für parallele Arbeitslasten effizient sein. Die GPU(s) 1208 kann/können bei einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Die GPU(s) 1208 kann/können einen oder mehrere Streaming-Mikroprozessoren aufweisen, wobei jeder Streaming-Mikroprozessor einen L1-Cache (z. B. einen L1-Cache mit mindestens 96 KB Speicherkapazität) aufweisen kann, und zwei oder mehrere der Streaming-Mikroprozessoren sich einen L2-Cache (z. B. einen L2-Cache mit 512 KB Speicherkapazität) teilen können. Bei einigen Ausführungsformen kann/können die GPU(s) 1208 mindestens acht Streaming-Mikroprozessoren aufweisen. Die GPU(s) 1208 kann/können Compute Application Programming Interface(s) (API(s)) verwenden. Darüber hinaus kann/können die GPU(s) 1208 eine oder mehrere Plattformen zum parallelen Rechnen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
Die GPU(s) 1208 kann/können leistungsoptimiert sein, um die beste Leistung in Automobil- und Embedded-Anwendungsfällen zu erzielen. Die GPU(s) 1208 kann/können beispielsweise auf einem Fin-Feldeffekttransistor (FinFET) hergestellt werden. Dies ist jedoch nicht als Einschränkung gedacht, und die GPU(s) 1208 kann/können mit anderen Halbleiterherstellungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von mit unterschiedlicher Genauigkeit arbeitenden Verarbeitungskernen enthalten, die in mehrere Blöcke unterteilt sind. Zum Beispiel und ohne Einschränkung können 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke partitioniert sein. Bei einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei mit unterschiedlicher Genauigkeit arbeitende NVIDIA TENSOR-Kerne für eine Matrixarithmetik zum tiefen Lernen, ein L0-Befehlscache, ein Warp-Scheduler, eine Dispatcher-Einheit und/oder eine 64 KB-Registerdatei zugewiesen werden. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Integer- und Fließkomma-Datenpfade aufweisen, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Rechen- und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können die Fähigkeit zur unabhängigen Thread-Planung aufweisen, um eine feinkörnigere Synchronisierung und Zusammenarbeit zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können einen kombinierten L1-Daten-Cache und eine gemeinsame Speichereinheit aufweisen, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
Die GPU(s) 1208 können einen Speicher mit hoher Bandbreite (HBM) und/oder ein 16 GB HBM2-Speichersubsystem aufweisen, um bei einigen Beispielen eine maximale Speicherbandbreite von etwa 900 GB/Sekunde zu erreichen. Bei einigen Beispielen kann zusätzlich zu dem oder alternativ zu dem HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) verwendet werden, z. B. ein synchroner Grafik-Doppel-Datenraten-Speicher vom Typ fünf (GDDR5).
Die GPU(s) 1208 kann/können eine einheitliche Speichertechnologie einschließlich Zugriffszähler aufweisen, 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, die von mehreren Prozessoren gemeinsam genutzt werden, verbessert wird. Bei einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) genutzt werden, um der/den GPU(s) 1208 den direkten Zugriff auf die Seitentabellen der CPU(s) 1206 zu ermöglichen. Wenn bei solchen Beispielen die Speicherverwaltungseinheit (MMU) der GPU(s) 1208 einen Fehlzugriff erfährt, kann eine Adressübersetzungsanforderung an die CPU(s) 1206 übertragen werden. Als Antwort darauf kann die CPU(s) 1206 in ihren Seitentabellen nach der Abbildung von der virtuellen Adresse auf die physikalische Adresse suchen und die Übersetzung zurück an die GPU(s) 1208 übertragen. Als solche kann die Unified Memory-Technologie einen einzigen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 1206 als auch der GPU(s) 1208 ermöglichen, wodurch die Programmierung der GPU(s) 1208 und die Portierung von Anwendungen auf die GPU(s) 1208 vereinfacht wird.
Darüber hinaus kann die GPU(s) 1208 einen Zugriffszähler aufweisen, der die Häufigkeit des Zugriffs der GPU(s) 1208 auf den Speicher anderer Prozessoren verfolgen kann. Der Zugriffszähler kann dazu beitragen, sicherzustellen, dass Speicherseiten in den physischen Speicher des Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
Das (die) SoC(s) 1204 kann (können) eine beliebige Anzahl von Cache(s) 1212 aufweisen, einschließlich der hier beschriebenen. Der/die Cache(s) 1212 kann/können beispielsweise einen L3-Cache aufweisen, der sowohl der/den CPU(s) 1206 als auch der/den GPU(s) 1208 zur Verfügung steht (d.h. der/die sowohl mit der/den CPU(s) 1206 als auch mit der/den GPU(s) 1208 verbunden ist/sind). Der/die Cache(s) 1212 kann/können einen Zurückkopier-Cache aufweisen, der den Zustand von Zeilen verfolgen kann, z. B. durch Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann je nach Ausführungsform 4 MB oder mehr aufweisen, wobei auch kleinere Cache-Größen verwendet werden können.
Die/das SoC(s) 1204 kann/können einen oder mehrere Beschleuniger 1214 aufweisen (z.B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Das/die SoC(s) 1204 kann/können beispielsweise ein Hardware-Beschleunigungs-Cluster aufweisen, das optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher enthalten kann. Der große On-Chip-Speicher (z.B. 4 MB SRAM) kann es dem Hardware-Beschleunigungs-Cluster ermöglichen, neuronale Netze und andere Berechnungen zu beschleunigen. Das Hardwarebeschleunigungs-Cluster kann zur Ergänzung des/der GPU(s) 1208 und zur Entlastung einiger der Tasks der GPU(s) 1208 verwendet werden (z.B. um mehr Zyklen der GPU(s) 1208 für die Ausführung anderer Tasks freizugeben). Der/die Beschleuniger 1214 kann/können z.B. für gezielte Arbeitslasten (z.B. Wahrnehmung, faltende neuronale Netze (CNNs) usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der Begriff „CNN“, wie er hier verwendet wird, kann alle Arten von CNNs beinhalten, einschließlich regionsbasierter oder regionaler faltender neuronaler Netze (RCNNs) und schneller RCNNs (z.B. wie sie zur Objekterkennung verwendet werden).
Der/die Beschleuniger 1214 (z.B. das Hardware-Beschleunigungscluster) kann/können einen/mehrere Beschleuniger zum tiefen Lernen (DLA) aufweisen. Der/die DLA(s) kann/können eine oder mehrere Tensorverarbeitungseinheiten (TPUs) aufweisen, die so konfiguriert werden können, dass sie zusätzliche zehn Billionen Operationen pro Sekunde für Anwendungen mit tiefem Lernen und Inferencing bereitstellen. Bei den TPUs kann es sich um Beschleuniger handeln, die so konfiguriert und optimiert sind, dass sie Bildverarbeitungsfunktionen ausführen (z. B. für CNNs, RCNNs usw.). Die DLA(s) können darüber hinaus für einen bestimmten Satz von Typen von neuronalen Netzen und Gleitkommaoperationen sowie für das Inferencing optimiert sein. Das Design der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Allzweck-GPU bereitstellt und übertrifft bei weitem die Leistung einer CPU. Die TPU(s) kann/können mehrere Funktionen aufweisen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datentypen sowohl für Merkmale und Gewichte als auch für Postprozessor-Funktionen unterstützt.
Der/die DLA(s) können schnell und effizient neuronale Netze, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, darunter z.B. und ohne Beschränkung: ein CNN zur Objektidentifizierung und -erkennung unter Verwendung von Daten von Kamerasensoren; ein CNN zur Entfernungsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN zur Erkennung und Identifizierung eines Einsatzfahrzeugs unter Verwendung von Daten von Mikrofonen; ein CNN zur Gesichtserkennung und Fahrzeughalteridentifizierung unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsrelevante Ereignisse.
Der/die DLA(s) kann/können jede Funktion der GPU(s) 1208 ausführen, und mit Hilfe eines Inferenzbeschleunigers kann ein Designer beispielsweise für jede Funktion entweder den/die DLA(s) oder den/die GPU(s) 1208 entsprechend ändern. Der Designer kann z.B. die Verarbeitung von CNNs und Gleitkommaoperationen auf den/die DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 1208 und/oder anderen Beschleuniger(n) 1214 überlassen.
Der/die Beschleuniger 1214 (z.B. das Hardware-Beschleunigungs-Cluster) kann/können einen/mehrere programmierbare(n) Vision-Beschleuniger (PVA) aufweisen, der/die hier alternativ als Computer-Vision Accelerator bezeichnet werden kann/können. Der (die) PVA(s) kann (können) so ausgelegt und ausgestaltet sein, dass er (sie) die Algorithmen für die computergestützte Sicht für die fortgeschrittenen Fahrerassistenzsysteme (ADAS), das autonome Fahren und/oder Anwendungen der erweiterten Realität (AR) und/oder der virtuellen Realität (VR) beschleunigt/en. Der/die PVA(s) kann/können ein Gleichgewicht zwischen Leistung und Flexibilität bieten. Zum Beispiel kann jeder PVA und ohne Beschränkung eine beliebige Anzahl von RISC-Kernen (Computer mit reduziertem Befehlssatz), direkten Speicherzugriff (DMA) und/oder eine beliebige Anzahl von Vektorprozessoren aufweisen.
Die RISC-Kerne können mit Bildsensoren (z.B. den Bildsensoren jeder der hier beschriebenen Kameras), Bildsignalprozessor(en) und/oder ähnlichem interagieren. Jeder der RISC-Kerne kann einen beliebig großen Speicher aufweisen. Die RISC-Kerne können je nach Ausführungsform eines von mehreren Protokollen verwenden. Bei einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. Die RISC-Kerne können mit einem oder mehreren integrierten Schaltkreisbausteinen, anwendungsspezifischen integrierten Schaltkreisen (ASICs) und/oder Speicherbausteinen implementiert werden. Beispielsweise können die RISC-Kerne einen Befehlscache und/oder ein eng gekoppeltes RAM aufweisen.
Der DMA kann es Komponenten des/der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 1206 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Funktionen unterstützen, die zur Optimierung des PVA verwendet werden, einschließlich, aber nicht beschränkt auf die Unterstützung mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. Bei einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, was eine Blockbreite, Blockhöhe, Blocktiefe, horizontale Blockschrittweite, vertikale Blockschrittweite und/oder Tiefenschrittweite beinhalten kann.
Bei den Vektorprozessoren kann es sich um programmierbare Prozessoren handeln, die so ausgelegt sein können, dass sie die Programmierung von Algorithmen für die Bildverarbeitung effizient und flexibel ausführen und Signalverarbeitungsfunktionen bereitstellen. Bei einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen aufweisen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA-Maschine(n) (z.B. zwei DMA-Maschinen) und/oder andere Peripheriegeräte aufweisen. Das Vektorverarbeitungs-Subsystem kann als primäre Verarbeitungsmaschine des PVA arbeiten und eine Vektorverarbeitungseinheit (VPU), einen Befehlscache und/oder einen Vektorspeicher (z. B. VMEM) aufweisen. Ein VPU-Kern kann einen digitalen Signalprozessor aufweisen, wie z.B. einen digitalen Signalprozessor für eine einzelne Anweisung, mehrere Daten (SIMD) oder ein sehr langes Anweisungswort (VLIW). Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
Jeder der Vektorprozessoren kann einen Befehlscache aufweisen und mit einem bestimmten Speicher gekoppelt sein. Folglich kann bei einigen Beispielen jeder der Vektorprozessoren so ausgestaltet sein, dass er unabhängig von den anderen Vektorprozessoren ausgeführt wird. Bei anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, so ausgestaltet sein, dass sie Datenparallelität verwenden. Bei einigen Ausführungsformen kann z.B. die Mehrzahl der Vektorprozessoren, die in einem einzigen PVA enthalten sind, denselben Computer-Vision-Algorithmus ausführen, jedoch in verschiedenen Regionen eines Bildes. Bei anderen Beispielen können die Vektorprozessoren, die in einem bestimmten PVA enthalten sind, gleichzeitig verschiedene Algorithmen für die computergestützte Bildverarbeitung für dasselbe Bild oder sogar verschiedene Algorithmen für aufeinanderfolgende Bilder oder Teile eines Bildes ausführen. Unter anderem kann eine beliebige Anzahl von PVAs in dem Hardware-Beschleunigungs-Cluster enthalten sein und eine beliebige Anzahl von Vektorprozessoren kann in jedem der PVAs enthalten sein. Darüber hinaus können die PVA(s) zusätzlichen ECC-Speicher (Error Correction Code) aufweisen, um die Gesamtsystemsicherheit zu erhöhen.
Der/die Beschleuniger 1214 (z.B. das Hardware-Beschleunigungs-Cluster) kann ein Computer-Vision-Network on-Chip und einen SRAM aufweisen, um ein SRAM mit hoher Bandbreite und niedriger Latenz für den/die Beschleuniger 1214 bereitzustellen. Bei einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM aufweisen, das z. B. und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl von dem PVA als auch von dem DLA zugegriffen werden kann. Jedes Speicherblockpaar kann eine APB-Schnittstelle (Advanced Peripheral Bus), eine Konfigurationsschaltung, eine Steuerung und einen Multiplexer aufweisen. Jede Art von Speicher kann verwendet werden. Der PVA und der DLA können über ein Backbone, der dem PVA und dem DLA Hochgeschwindigkeitszugriff auf den Speicher ermöglicht, auf den Speicher zugreifen. Das Backbone kann ein Computer-Vision-Network on-Chip aufweisen, das den PVA und den DLA mit dem Speicher verbindet (z.B. unter Verwendung des APB).
Das Computer-Vision-Network on-Chip kann eine Schnittstelle aufweisen, die vor der Übertragung von Steuersignalen/Adressen/Daten bestimmt, dass sowohl der PVA als auch der DLA betriebsbereite und gültige Signale liefern. Eine solche Schnittstelle kann separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie Burst-Kommunikationen für die kontinuierliche Datenübertragung vorsehen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 612508 entsprechen, es können jedoch auch andere Normen und Protokolle verwendet werden.
Bei einigen Beispielen kann/können das/die SoC(s) 1204 einen Echtzeit-Raytracing-Hardwarebeschleuniger aufweisen, wie er in der am 10. August 2018 eingereichten U.S. Patentanmeldung Nr. 16/101,1232 beschrieben ist. Der Echtzeit-Raytracing-Hardwarebeschleuniger kann zur schnellen und effizienten Bestimmung der Positionen und Ausdehnungen von Objekten (z.B. innerhalb eines Weltmodells), zur Erzeugung von Echtzeit-Visualisierungssimulationen, zur RADAR-Signalinterpretation, zur Schallausbreitungssynthese und/oder -analyse, zur Simulation von SONAR-Systemen, zur allgemeinen Wellenausbreitungssimulation, zum Vergleich mit LIDAR-Daten zum Zweck der Lokalisierung und/oder anderer Funktionen und/oder für andere Zwecke verwendet werden.
Der/die Beschleuniger 1214 (z.B. das Hardware-Beschleuniger-Cluster) haben ein breites Anwendungsspektrum für autonomes Fahren. Der PVA kann ein programmierbarer Bildbearbeitungsbeschleuniger sein, der für wichtige Verarbeitungsstufen in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten der PVA eignen sich gut für algorithmische Bereiche, die eine vorhersagbare Verarbeitung bei niedriger Leistung und niedriger Latenz erfordern. Mit anderen Worten, der PVA arbeitet gut bei halbdichten oder dichten regelmäßigen Berechnungen, selbst bei kleinen Datensätzen, die vorhersagbare Laufzeiten mit geringer Latenz und niedriger Leistung erfordern. Im Zusammenhang mit Plattformen für autonome Fahrzeuge sind die PVAs so konzipiert, dass sie klassische Algorithmen für die Computerbildverarbeitung ausführen können, da sie effizient bei der Objekterkennung sind und mit ganzzahliger Mathematik arbeiten.
Gemäß einer Ausführungsform der Technologie wird der PVA beispielsweise zur Durchführung von Computer-Stereovision verwendet. Bei einigen Beispielen kann ein auf semi-globalem Matching basierender Algorithmus verwendet werden, obwohl dies keine Beschränkung darstellen soll. Viele Anwendungen für autonomes Fahren der Stufe 3-5 erfordern eine unmittelbare Bewegungsschätzung/Stereoanpassung (z.B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Der PVA kann bei Eingaben von zwei monokularen Kameras eine Computer-Stereobilderkennungsfunktion ausführen.
Bei einigen Beispielen kann der PVA zur Verarbeitung eines dichten optischen Flusses verwendet werden. Entsprechend der Verarbeitung von RADAR-Rohdaten (z.B. unter Verwendung einer 4D-Fast-Fourier-Transformation) zur Bereitstellung von verarbeiteten RADAR-Daten. Bei anderen Beispielen wird der PVA zur Verarbeitung der Flugzeittiefe verwendet, indem z.B. Flugzeit-Rohdaten verarbeitet werden, um verarbeitete Flugzeitdaten bereitzustellen.
Der DLA kann verwendet werden, um jede Art von Netzwerk zur Verbesserung der Steuerung und Fahrsicherheit zu betreiben, einschließlich z.B. eines neuronalen Netzes, das für jede Objekterkennung ein Vertrauensmaß ausgibt. Ein solcher Vertrauenswert kann als Wahrscheinlichkeit interpretiert werden oder als relative „Gewichtung“ jeder Erkennung im Vergleich zu anderen Erkennungen. Dieser Vertrauenswert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Entdeckungen als echte positive Entdeckungen und nicht als falsch positive Entdeckungen angesehen werden sollten. Beispielsweise kann das System einen Schwellenwert für das Vertrauen festlegen und nur die Entdeckungen, die den Schwellenwert überschreiten, als echte positive Entdeckungen betrachten. Bei 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 ein AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netz zur Regression des Vertrauenswerts betreiben.
Das neuronale Netz kann als Eingabe mindestens eine Teilmenge von Parametern verwenden, wie z.B. Abmessungen des Begrenzungsrechtecks, eine Schätzung der Grundplatte (z.B. von einem anderen Subsystem), eine Ausgabe eines Sensors 1266 des Inertial Measurement Post (IMU)-Sensors 1266, die mit der Ausrichtung des Fahrzeugs korreliert 1200, eine Entfernung, 3D-Standortschätzungen des Objekts, die vom neuronalen Netz und/oder anderen Sensoren (z.B. LIDAR-Sensor(en) 1264 oder RADAR-Sensor(en) 1260) unter anderem erhalten werden.
Das/die SoC(s) 1204 kann/können Datenspeicher 1216 (z.B. Speicher) aufweisen. Bei dem/den Datenspeicher(n) 1216 kann es sich um einen On-Chip-Speicher des SoC(s) 1204 handeln, in dem/denen neuronale Netze gespeichert werden können, die auf der GPU und/oder dem DLA ausgeführt werden sollen. Bei einigen Beispielen kann/können der/die Datenspeicher 1216 groß genug sein, um aus Redundanz- und Sicherheitsgründen mehrere Instanzen von neuronalen Netzen zu speichern. Der/die Datenspeicher 1212 kann/können L2- oder L3-Cache(s) 1212 umfassen. Ein Verweis auf den/die Datenspeicher 1216 kann einen Verweis auf den mit dem PVA, dem DLA und/oder anderen Beschleunigern 1214 verbundenen Speicher aufweisen, wie es hier beschrieben ist.
Das/die SoC(s) 1204 kann/können einen oder mehrere Prozessor(en) 1210 (z.B. eingebettete Prozessoren) aufweisen. Der/die Prozessor(en) 1210 kann/können einen Boot- und Power-Management-Prozessor aufweisen, bei dem es sich um einen bestimmten Prozessor und ein Subsystem handeln kann, die die Boot-Leistung und die Management-Funktionen und die damit verbundene Sicherheitsdurchsetzung übernehmen. Der Boot- und Power-Management-Prozessor kann ein Teil der Boot-Sequenz des/der SoC(s) 1204 sein und zur Laufzeit Power-Management-Dienste bereitstellen. Der Boot-Power- und Managementprozessor kann eine Takt- und Spannungsprogrammierung, eine Unterstützung bei Zustandsübergängen im System mit niedrigem Stromverbrauch, eine Verwaltung der thermischen und Temperatursensoren des/der SoC(s) 1204 und/oder eine Verwaltung der Stromversorgungszustände des/der SoC(s) 1204 bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und das/die SoC(s) 1204 kann/können die Ringoszillatoren verwenden, um Temperaturen der CPU(s) 1206, der GPU(s) 1208 und/oder des/der Beschleuniger(s) 1214 zu erfassen. Wenn festgestellt wird, dass die Temperaturen einen Schwellenwert überschreiten, können der Boot- und der Leistungssteuerungsprozessor in eine Temperaturfehlerroutine eintreten und die SoC(s) 1204 in einen Zustand geringerer Leistung versetzen und/oder das Fahrzeug 1200 in einen Chauffeur-Modus oder Modus zum sicheren Halten bringen (z.B. das Fahrzeug 1200 in einen sicheren Halt bringen).
Der/die Prozessor(en) 1210 kann/können ferner einen Satz eingebetteter Prozessoren aufweisen, die als Audioverarbeitungsmaschine dienen können. Bei der Audioverarbeitungsmaschine kann es sich um ein Audio-Subsystem handeln, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen sowie eine breite und flexible Palette von Audio-E/A-Schnittstellen ermöglicht. Bei einigen Beispielen ist die Audioverarbeitungsmaschine ein bestimmter Prozessorkern mit einem digitalen Signalprozessor mit einem bestimmten RAM.
Der/die Prozessor(en) 1210 kann/können darüber hinaus eine ständig eingeschaltete Prozessormaschine aufweisen, die die notwendigen Hardware-Funktionen zur Unterstützung von einem Sensormanagement mit geringem Stromverbrauch und Anwendungsfällen zum Aufwecken bereitstellt. Die ständig eingeschaltete Prozessormaschine kann einen Prozessorkern, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z.B. Timer und Interrupt-Controller), verschiedene E/A-Controller-Peripheriegeräte und Routing-Logik aufweisen.
Der/die Prozessor(en) 1210 kann/können ferner eine Sicherheits-Cluster-Maschine aufweisen, die ein bestimmtes Prozessor-Subsystem zur Handhabung des Sicherheitsmanagements für Automobilanwendungen aufweist. Die Sicherheits-Cluster-Maschine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Zeitgeber, einen Interrupt-Controller usw.) und/oder Routing-Logik aufweisen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Gleichschritt-Modus arbeiten und als ein einziger Kern mit Vergleichslogik zur Erkennung von Unterschieden zwischen ihren Operationen fungieren.
Der/die Prozessor(en) 1210 kann/können darüber hinaus eine Echtzeit-Kamera-Maschine aufweisen, die ein bestimmtes Prozessor-Subsystem zur Handhabung des Echtzeit-Kameramanagements aufweisen kann.
Der (die) Prozessor(en) 1210 kann (können) ferner einen Signalprozessor mit hohem Dynamikbereich aufweisen, der einen Bildsignalprozessor aufweisen kann, bei dem es sich um eine Hardware-Maschine handelt, die Teil der Kamera-Verarbeitungspipeline ist.
Der/die Prozessor(en) 1210 kann/können einen Videobildkompositor aufweisen, bei dem es sich um einen Verarbeitungsblock handeln kann (z. B. auf einem Mikroprozessor implementiert), der Video-Nachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Playerfenster zu erzeugen. Der Videobildkompositor kann eine Korrektur der Linsenverzerrung an Weitwinkelkamera(s) 1270, Surround-Kamera(s) 1274 und/oder an Sensoren von Überwachungskameras in der Kabine durchführen. Der Sensor der Überwachungskamera in der Kabine wird vorzugsweise durch ein neuronales Netz überwacht, das auf einer anderen Instanz des hochentwickelten SoC läuft und so ausgestaltet ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein System in der Kabine kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Telefonanruf zu tätigen, E-Mails zu diktieren, den Zielort des Fahrzeugs zu ändern, das Infotainmentsystem des Fahrzeugs und Einstellungen davon zu aktivieren bzw. zu ändern oder sprachaktiviertes Websurfen zu ermöglichen. Bestimmte Funktionen stehen dem Fahrer nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind andernfalls deaktiviert.
Der Videobildkompositor kann eine verbesserte zeitliche Rauschunterdrückung sowohl für die räumliche als auch für die zeitliche Rauschunterdrückung aufweisen. Wenn z.B. in einem Video eine Bewegung auftritt, gewichtet die Rauschunterdrückung die räumliche Information angemessen und verringert das Gewicht der von benachbarten Einzelbildern gelieferten Informationen. Wenn ein Bild oder ein Teil eines Bildes keine Bewegung aufweist, kann die von dem Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
Der Videobildkompositor kann auch so ausgestaltet sein, dass er eine Stereokorrektur auf Eingabebilder von Stereolinsen durchführt. Der Videobildkompositor kann auch für die Gestaltung von Benutzeroberflächen verwendet werden, wenn die Benutzeroberfläche des Betriebssystems verwendet wird und die GPU(s) 1208 nicht erforderlich ist/sind, um kontinuierlich neue Oberflächen zu rendern. Selbst wenn die GPU(s) 1208 eingeschaltet und für das 3D-Rendering aktiv ist/sind, kann der Videobildkompositor zur Entlastung der GPU(s) 1208 verwendet werden, um die Leistung und Reaktionsfähigkeit zu verbessern.
Das/die SoC(s) 1204 kann/können darüber hinaus eine serielle MIPI-Schnittstelle (Mobile Industry Processor Interface) für Kameras zum Empfang von Videos und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock aufweisen, der für Kamera- und zugehörige Pixeleingabefunktionen verwendet werden kann. Das/die SoC(s) 1204 kann/können ferner eine/mehrere Ein-/Ausgabe-Steuerung(en) aufweisen, die durch Software gesteuert werden kann/können und für den Empfang von E/A-Signalen verwendet werden kann/können, die nicht für eine bestimmte Rolle vorgesehen sind.
Das/die SoC(s) 1204 kann/können ferner eine breite Palette von Peripherieschnittstellen aufweisen, um die Kommunikation mit Peripheriegeräten, Audiocodecs, Energieverwaltung und/oder anderen Geräten zu ermöglichen. Das/die SoC(s) 1204 kann/können zur Verarbeitung von Daten von Kameras (z.B. über Gigabit Multimedia Serial Link und Ethernet verbunden), Sensoren (z.B. LIDAR-Sensor(en) 1264, RADAR-Sensor(en) 1260, usw., die über Ethernet verbunden sein können), Daten von einem Bus 1202 (z.B. Fahrzeuggeschwindigkeit 1200, Lenkradposition, usw.), Daten von (einem) GNSS-Sensor(en) 1258 (z.B. über Ethernet oder CAN-Bus verbunden) verwendet werden. Das (die) SoC(s) 1204 kann (können) ferner bestimmte Hochleistungs-Massenspeicher-Steuerungen aufweisen, die ihre eigenen DMA-Maschinen aufweisen können und die verwendet werden können, um die CPU(s) 1206 von Routineaufgaben der Datenverwaltung zu entlasten.
Das (die) SoC(s) 1204 kann (können) eine End-to-End-Plattform mit einer flexiblen Architektur sein, die die Automatisierungsstufen 3-5 umfasst und dadurch eine umfassende Architektur der funktionalen Sicherheit bietet, die die Computer-Bilderkennungs- und ADAS-Techniken für Diversität und Redundanz nutzt und effizient einsetzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Werkzeugen zum Tiefenlernen bereitstellt. Das/die SoC(s) 1204 sind möglicherweise schneller, zuverlässiger und sogar energie- und platzsparender als konventionelle Systeme. Beispielsweise können der/die Beschleuniger 1214 in Kombination mit der/den CPU(s) 1206, der/den GPU(s) 1208 und dem/den Datenspeicher(n) 1216 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Stufe 3-5 bilden.
Die Technologie bietet somit Fähigkeiten und Funktionen, die von konventionellen Systemen nicht erreicht werden können. Beispielsweise können Bildverarbeitungsalgorithmen auf CPUs ausgeführt werden, die mit Hilfe einer höheren Programmiersprache, z.B. der Programmiersprache C, so konfiguriert werden können, dass sie eine Vielzahl von Verarbeitungsalgorithmen für eine Vielzahl von visuellen Daten ausführen können. CPUs sind jedoch oft nicht in der Lage, die Leistungsanforderungen vieler Computer-Bilderkennungs-Anwendungen zu erfüllen, z.B. in Bezug auf Ausführungszeit und Stromverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, was eine Anforderung für ADAS-Anwendungen im Fahrzeug und eine Anforderung für praktische autonome Fahrzeuge der Stufe 3-5 ist.
Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungs-Clusters die gleichzeitige und/oder sequentielle Ausführung mehrerer neuronaler Netze sowie die Kombination der Ergebnisse, um eine autonome Fahrfunktionalität der Stufe 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder der GPU (z.B. der/den GPU(s) 1220) ausgeführt wird, eine Text- und Worterkennung aufweisen, die es dem Supercomputer ermöglicht, Verkehrszeichen zu lesen und zu verstehen, einschließlich von Zeichen, für die das neuronale Netz nicht speziell trainiert wurde. Der DLA kann ferner ein neuronales Netz aufweisen, das in der Lage ist, das Zeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis des Zeichens zu liefern und dieses semantische Verständnis an die auf dem CPU-Komplex laufenden Wegplanungsmodule weiterzugeben.
Als weiteres Beispiel können mehrere neuronale Netze gleichzeitig ausgeführt werden, wie es für das Fahren auf Stufe 3, 4 oder 5 erforderlich ist. Beispielsweise kann ein Warnschild mit der Aufschrift „Achtung: Blinklicht zeigt Vereisung an“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzen unabhängig oder kollektiv interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netz (z.B. einem trainierten neuronalen Netz) als Verkehrszeichen erkannt werden, der Text „Blinklicht zeigt Vereisungszustand an“ kann von einem zweiten eingesetzten neuronalen Netz interpretiert werden, das die Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass bei Erkennung von Blinklicht Vereisungszustände vorliegen. Das Blinklicht kann identifiziert werden, indem ein drittes eingesetztes neuronales Netz mit mehreren Einzelbildern arbeitet, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. Alle drei neuronalen Netze können gleichzeitig laufen, z.B. innerhalb des DLA und/oder auf der/den GPU(s) 1208.
Bei einigen Beispielen kann ein CNN zur Gesichtserkennung und Identifizierung des Fahrzeugbesitzers Daten von Kamerasensoren verwenden, um die Anwesenheit eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 1200 zu identifizieren. Die stets eingeschaltete Sensorverarbeitungsmaschine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn sich der Besitzer der Fahrertür nähert, und um die Lichter einzuschalten, und um im Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgt/en das/die SoC(s) 1204 für Sicherheit gegen Diebstahl und/oder Autodiebstahl.
Bei einem anderen Beispiel kann ein CNN für die Erkennung und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 1296 zur Erkennung und Identifizierung von Sirenen eines Einsatzfahrzeugs verwenden. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Erkennung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, verwendet/n das/die SoC(s) 1204 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung von visuellen Daten. Bei einer bevorzugten Ausführungsform wird das CNN, das auf dem DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu identifizieren (z.B. durch Nutzung des Doppler-Effekts). Das CNN kann auch darauf trainiert werden, Einsatzfahrzeuge zu identifizieren, die spezifisch für den lokalen Bereich sind, in dem das Fahrzeug eingesetzt wird, z.B. durch (einen) GNSS-Sensor(en) 1258. So wird das CNN z.B. bei Einsätzen in Europa versuchen, europäische Sirenen zu erkennen, während das CNN in den Vereinigten Staaten nur nordamerikanische Sirenen zu identifizieren versucht. Sobald ein Einsatzfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um mit Hilfe der Ultraschallsensoren 1262 eine Einsatzfahrzeug-Sicherheitsroutine auszuführen, indem das Fahrzeug verlangsamt, am Straßenrand angehalten, geparkt und/oder im Leerlauf gefahren wird, bis das (die) Einsatzfahrzeug(e) vorbeifährt (fahren).
Das Fahrzeug kann eine oder mehrere CPU(s) 1218 (z.B. separate CPU(s) oder dCPU(s)) aufweisen, die über eine Hochgeschwindigkeitsverbindung (z.B. PCle) mit der/den SoC(s) 1204 gekoppelt werden kann/können. Die CPU(s) 1218 kann/können z.B. einen X86-Prozessor aufweisen. Die CPU(s) 1218 kann/können zur Ausführung einer Vielzahl von Funktionen verwendet werden, einschließlich der Begutachtung potentiell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und der/den SoC(s) 1204 und/oder der Überwachung von Status und Zustand der Steuerung(en) 1236 und/oder des Infotainment-SoC 1230, zum Beispiel.
Das Fahrzeug 1200 kann (eine) GPU(s) 1220 aufweisen (z.B. diskrete GPU(s) oder dGPU(s)), die über eine Hochgeschwindigkeitsverbindung (z.B. NVIDIAs NVLINK) mit dem/den SoC(s) 1204 gekoppelt werden kann/können. Die GPU(s) 1220 kann/können zusätzliche Funktionen der künstlichen Intelligenz bereitstellen, z.B. durch Ausführung redundanter und/oder unterschiedlicher neuronaler Netze, und kann/können zum Trainieren und/oder Aktualisieren neuronaler Netze verwendet werden, die zumindest teilweise auf Eingaben (z.B. Sensordaten) von Sensoren des Fahrzeugs 1200 basieren.
Das Fahrzeug 1200 kann ferner die Netzwerkschnittstelle 1224 aufweisen, die eine oder mehrere Funkantennen 1226 (z.B. eine oder mehrere Funkantennen für verschiedene Kommunikationsprotokolle, wie z.B. eine Mobilfunkantenne, eine Bluetooth-Antenne usw.) aufweisen kann. Die Netzwerkschnittstelle 1224 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z.B. mit dem/den Server(n) 1278 und/oder anderen Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Computergeräten (z.B. Client-Geräte von Insassen) zu ermöglichen. Zur Kommunikation mit anderen Fahrzeugen kann eine direkte Verbindung zwischen den beiden Fahrzeugen und/oder eine indirekte Verbindung hergestellt werden (z.B. über Netzwerke und über das Internet). Direkte Verbindungen können über eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 1200 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 1200 liefern (z.B. Fahrzeuge vor, seitlich und/oder hinter dem Fahrzeug 1200). Diese Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 1200 sein.
Die Netzschnittstelle 1224 kann ein SoC aufweisen, das Modulations- und Demodulationsfunktionalität aufweist und es der (den) Steuerung(en) 1236 ermöglicht, über Funknetze zu kommunizieren. Die Netzwerkschnittstelle 1224 kann ein Hochfrequenz-Front-End für die Aufwärtskonvertierung vom Basisband auf Hochfrequenz und die Abwärtskonvertierung von der Hochfrequenz auf das Basisband aufweisen. Die Frequenzkonvertierungen können mit bekannten Verfahren und/oder mit Super-Heterodyne-Verfahren durchgeführt werden. Bei einigen Beispielen kann die Hochfrequenz-Front-End-Funktionalität durch einen separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann eine drahtlose Funktionalität für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle aufweisen.
Das Fahrzeug 1200 kann darüber hinaus einen oder mehrere Datenspeicher 1228 aufweisen, die auch Off-Chip-Speicher (z.B. außerhalb des SoC(s) 1204) enthalten können. Der (die) Datenspeicher 1228 kann (können) ein oder mehrere Speicherelemente aufweisen, einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte, die mindestens ein Datenbit speichern können.
Das Fahrzeug 1200 kann ferner einen oder mehrere GNSS-Sensor(en) 1258 aufweisen. Der/die GNSS-Sensor(en) 1258 (z.B. GPS und/oder assistierte GPS-Sensoren) dienen zur Unterstützung von Kartierungs-, Wahrnehmungs-, Belegungsgittergenerierungs- und/oder Wegplanungsfunktionen. Eine beliebige Anzahl von GNSS-Sensor(en) 1258 kann verwendet werden, einschließlich z.B. und ohne Einschränkung ein GPS, das einen USB-Anschluss mit einer Ethernet-zu-Seriell (RS-232)-Brücke aufweist.
Das Fahrzeug 1200 kann außerdem RADAR-Sensor(en) 1260 aufweisen. Der (die) RADAR-Sensor(en) 1260 kann (können) von dem Fahrzeug 1200 für die Fahrzeugerfassung mit großer Reichweite, auch bei Dunkelheit und/oder schlechten Wetterbedingungen, verwendet werden. Die funktionalen Sicherheitsstufen des RADAR-Systems können ASIL B sein. Der/die RADAR-Sensor(en) 1260 kann/können den CAN und/oder den Bus 1202 (z.B. zur Übertragung von Daten, die von dem/den RADAR-Sensor(en) 1260 erzeugt wurden) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, mit Zugriff auf das Ethernet, um in einigen Beispielen auf Rohdaten zuzugreifen. Es kann eine Vielzahl von RADAR-Sensortypen verwendet werden. Der/die RADAR-Sensor(en) 1260 kann/können z. B. und ohne Beschränkung für die RADAR-Nutzung an der Vorderseite, Rückseite und Seite angebracht sein. Bei einigen Beispielen werden Puls-Doppler-RADAR-Sensor(en) verwendet.
Der (die) RADAR-Sensor(en) 1260 kann (können) verschiedene Konfigurationen aufweisen, wie z.B. eine große Reichweite mit engem Sichtfeld, eine kurze Reichweite mit weitem Sichtfeld, eine seitliche Abdeckung mit kurzer Reichweite usw.
Bei einigen Beispielen kann das RADAR mit großer Reichweite für die adaptive Geschwindigkeitsregelungsfunktionalität verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein breites Sichtfeld bieten, das durch zwei oder mehr unabhängige Abtastungen, z.B. innerhalb einer Reichweite von 250 m, realisiert wird. Der/die RADAR-Sensor(en) 1260 kann/können bei der Unterscheidung zwischen statischen und sich bewegenden Objekten helfen und kann/können von ADAS-Systemen für Notbremsassistenten und zur Vorwärtskollisionswarnung verwendet werden. RADAR-Sensoren mit großer Reichweite können ein monostatisches multimodales RADAR mit mehreren (z.B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle aufweisen. Bei einem Beispiel mit sechs Antennen können die zentralen vier Antennen ein fokussiertes Strahlungsdiagramm erzeugen, das so ausgelegt ist, dass es die Umgebung des Fahrzeugs 1200 bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf benachbarten Fahrspuren aufzeichnet. Die beiden anderen Antennen können das Sichtfeld erweitern, so dass Fahrzeuge, die in die Spur des Fahrzeugs 1200 ein- oder aus dieser ausfahren, schnell erfasst werden können.
Mittelstrecken-RADAR-Systeme können beispielsweise eine Reichweite von bis zu 1260 m (vorn) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorn) oder 1250 Grad (hinten) aufweisen. Kurzstrecken-RADAR-Systeme können unter anderem RADAR-Sensoren aufweisen, die an beiden Enden des hinteren Stoßfängers installiert werden. Wenn ein solches RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers installiert ist, kann es zwei Strahlen erzeugen, die den toten Winkel hinter und neben dem Fahrzeug ständig überwachen.
Kurzstrecken-RADAR-Systeme können in einem ADAS-System zur Erkennung des toten Winkels und/oder zur Unterstützung des Spurwechsels verwendet werden.
Das Fahrzeug 1200 kann ferner Ultraschallsensor(en) 1262 aufweisen. Der (die) Ultraschallsensor(en) 1262, der (die) vorn, hinten und/oder an den Seiten des Fahrzeugs 1200 angebracht werden kann (können), kann (können) für eine Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsrasters verwendet werden. Eine große Vielfalt von Ultraschallsensor(en) 1262 kann verwendet werden, und verschiedene Ultraschallsensor(en) 1262 können für unterschiedliche Erfassungsbereiche (z.B. 2,5 m, 4 m) verwendet werden. Der (die) Ultraschallsensor(en) 1262 kann (können) mit einem funktionalen Sicherheitsniveau von ASIL B arbeiten.
Das Fahrzeug 1200 kann (einen) LIDAR-Sensor(en) 1264 aufweisen. Der (die) LIDAR-Sensor(en) 1264 kann (können) zur Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder für andere Funktionen verwendet werden. Der (die) LIDAR-Sensor(en) 1264 kann (können) der funktionalen Sicherheitsstufe ASIL B entsprechen. Bei einigen Beispielen kann das Fahrzeug 1200 mehrere LIDAR-Sensoren 1264 aufweisen (z.B. zwei, vier, sechs usw.), die Ethernet verwenden können (z.B. zur Bereitstellung von Daten für einen Gigabit-Ethernet-Switch).
Bei einigen Beispielen könnte(n) der/die LIDAR-Sensor(en) 1264 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld bereitzustellen. Kommerziell erhältliche(r) LIDAR-Sensor(en) 1264 kann/können laut Angabe eine Reichweite von ca. 1200 m mit einer Genauigkeit von 2 cm - 3 cm und mit einer Unterstützung z.B. für eine 1200 Mbps Ethernet-Verbindung aufweisen. Bei einigen Beispielen können ein oder mehrere nicht hervorstehende LIDAR-Sensoren 1264 verwendet werden. Bei solchen Beispielen kann/können der/die LIDAR-Sensor(en) 1264 als ein kleines Gerät implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 1200 eingebettet sein kann. Der (die) LIDAR-Sensor(en) 1264 kann (können) bei solchen Beispielen ein horizontales Sichtfeld von bis zu 1220 Grad und ein vertikales Sichtfeld von bis zu 35 Grad bereitstellen, mit einer Reichweite von 200 m selbst für Objekte mit geringen Reflektionseigenschaften. Ein frontmontierter LIDAR-Sensor 1264 kann für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad ausgestaltet sein.
Bei einigen Beispielen können auch LIDAR-Technologien, wie z.B. ein 3D-Blitz-LIDAR, verwendet werden. Ein 3D-Blitz-LIDAR verwendet einen Laserblitz als Übertragungsquelle, um die Fahrzeugumgebung bis zu einer Entfernung von ca. 200 m auszuleuchten. Eine Blitz-LIDAR-Einheit weist einen Empfänger auf, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum der Reichweite von dem Fahrzeug bis zu den Objekten entspricht. Mit einem Blitz-LIDAR können mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung erzeugt werden. Bei einigen Beispielen können vier Blitz-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 1200. Verfügbare 3D-Blitz-LIDAR-Systeme weisen eine Festkörper-3D-Blitz-LIDAR-Kamera auf, die außer einem Lüfter keine beweglichen Teile aufweist (z.B. ein nicht scannendes LIDAR-Gerät). Das Blitz-LIDAR-Gerät kann einen 5-Nanosekunden-Laserpuls der Klasse I (augensicher) pro Bild verwenden und das reflektierte Laserlicht in Form von 3D-Entfernungspunktwolken und ko-registrierten Intensitätsdaten erfassen. Durch die Verwendung von einem Blitz-LIDAR und weil es sich bei einem Blitz-LIDAR um ein Festkörpergerät ohne bewegliche Teile handelt, sind der/die LIDAR-Sensor(en) 1264 möglicherweise weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße.
Das Fahrzeug kann ferner einen oder mehrere IMU-Sensor(en) 1266 aufweisen. Der (die) IMU-Sensor(en) 1266 kann (können) sich bei einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 1200 befinden. Der/die IMU-Sensor(en) 1266 kann/können zum Beispiel und ohne Einschränkung einen/mehrere Beschleunigungsmesser, einen/mehrere Magnetometer, ein/mehrere Gyroskop(e), einen/mehrere Magnetkompass(e) und/oder andere Sensortypen aufweisen. Bei einigen Beispielen, wie z.B. bei sechsachsigen Anwendungen, kann/können der (die) IMU-Sensor(en) 1266 Beschleunigungsmesser und Gyroskope aufweisen, während bei neunachsigen Anwendungen der (die) IMU-Sensor(en) 1266 Beschleunigungsmesser, Gyroskope und Magnetometer aufweisen kann (können).
Bei einigen Ausführungsformen kann/können der/die IMU-Sensor(en) 1266 als ein GPS/INS (GPS/INS = GPS-Aided Inertial Navigation System) in Miniaturausführung implementiert sein, das Trägheitssensoren von mikro-elektro-mechanischen Systemen (MEMS = micro-electro-mechanical systems), einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen zur Schätzung von Position, Geschwindigkeit und Lage kombiniert. So kann bei einigen Beispielen der/die IMU-Sensor(en) 1266 das Fahrzeug 1200 in die Lage versetzen, den Kurs abzuschätzen, ohne dass eine Eingabe von einem magnetischen Sensor erforderlich ist, indem die Geschwindigkeitsänderungen von dem GPS zu dem/den IMU-Sensor(en) 1266 direkt beobachtet und korreliert werden. Bei einigen Beispielen können der (die) IMU-Sensor(en) 1266 und der (die) GNSS-Sensor(en) 1258 in einer einzigen integrierten Einheit kombiniert sein.
Das Fahrzeug kann Mikrophon(e) 1296 aufweisen, die in dem und/oder um das Fahrzeug 1200 herum platziert sind. Das (die) Mikrofon(e) 1296 kann (können) unter anderem für die Erkennung und Identifizierung von Einsatzfahrzeugen verwendet werden.
Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen aufweisen, einschließlich Stereokamera(s) 1268, Weitwinkelkamera(s) 1270, Infrarotkamera(s) 1272, Surround-Kamera(s) 1274, Fern- und/oder Mittelbereichskamera(s) 1298 und/oder andere Kameratypen. Die Kameras können zur Erfassung von Bilddaten um den gesamten Umfang des Fahrzeugs 1200 herum eingesetzt werden. Welche Arten von Kameras verwendet werden, hängt von den Ausführungsformen und Anforderungen für das Fahrzeug 1200 ab, und jede Kombination von Kameratypen kann verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 1200 herum zu gewährleisten. Darüber hinaus kann die Anzahl der Kameras je nach Ausführungsform unterschiedlich sein. So kann das Fahrzeug beispielsweise sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras aufweisen. Die Kameras können zum Beispiel und ohne Einschränkung Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras wird hier mit Bezug zu 12A und 12B ausführlicher beschrieben.
Das Fahrzeug 1200 kann außerdem (einen) Vibrationssensor(en) 1242 aufweisen. Der (die) Vibrationssensor(en) 1242 kann (können) Schwingungen von Komponenten des Fahrzeugs, wie z.B. der Achse(n), messen. Änderungen der Vibrationen können zum Beispiel auf eine Veränderung der Straßenoberfläche hinweisen. Bei einem anderen Beispiel, wenn zwei oder mehr Vibrationssensoren 1242 verwendet werden, können die Unterschiede zwischen den Schwingungen zur Bestimmung der Reibung oder des Schlupfes der Fahrbahnoberfläche verwendet werden (z.B. wenn der Schwingungsunterschied zwischen einer angetriebenen Achse und einer frei rotierenden Achse besteht).
Das Fahrzeug 1200 kann ein ADAS-System 1238 aufweisen. Das ADAS-System 1238 kann bei einigen Beispielen ein SoC aufweisen. Das ADAS-System 1238 kann einen autonomen/adaptiven/automatischen Tempomat (ACC), einen kooperativen adaptiven Tempomat (CACC), eine Warnung vor einem Aufprall vorn (FCW), ein automatisches Notbremsen (AEB), Spurhalteassistenten (LKA), eine Warnung vor dem toten Winkel (BSW), eine Warnung vor rückwärtigem Querverkehr (RCTW), Kollisionswarnsysteme (CWS), eine Spurzentrierung (LC) und/oder andere Merkmale und Funktionen aufweisen.
Die ACC-Systeme können RADAR-Sensor(en) 1260, LIDAR-Sensor(en) 1264 und/oder eine Kamera(s) verwenden. Die ACC-Systeme können einen Längs-ACC und/oder einen Quer-ACC aufweisen. Ein ACC in Längsrichtung überwacht und steuert den Abstand zum Fahrzeug unmittelbar vor dem Fahrzeug 1200 und passt die Fahrzeuggeschwindigkeit automatisch an, um einen Sicherheitsabstand zu vorausfahrenden Fahrzeugen einzuhalten. Der seitliche ACC sorgt für die Einhaltung des Abstands und weist das Fahrzeug 1200 an, bei Bedarf die Spur zu wechseln. Der seitliche ACC steht im Zusammenhang mit anderen ADAS-Anwendungen wie LCA und CWS.
Ein CACC nutzt Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 1224 und/oder die drahtlose(n) Antenne(n) 1226 von anderen Fahrzeugen über eine drahtlose Verbindung oder indirekt über eine Netzwerkverbindung (z.B. über das Internet) empfangen werden können. Direkte Verbindungen können über 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 vorausfahrenden Fahrzeuge (z.B. Fahrzeuge unmittelbar vor und auf derselben Fahrspur wie das Fahrzeug 1200), während das 12V-Kommunikationskonzept Informationen über den Verkehr weiter vorn liefert. CACC-Systeme können eine oder beide 12V- und V2V-Informationsquellen aufweisen. Angesichts der Informationen der vorausfahrenden Fahrzeuge vor dem Fahrzeug 1200 kann ein CACC zuverlässiger sein und hat das Potenzial, den Verkehrsfluss zu verbessern und Staus auf der Straße zu verringern.
FCW-Systeme sind so konzipiert, dass sie den Fahrer auf eine Gefahr aufmerksam machen, so dass der Fahrer korrigierend eingreifen kann. FCW-Systeme verwenden eine nach vorn gerichtete Kamera und/oder RADAR-Sensor(en) 1260, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch für eine Fahrer-Rückkopplung gekoppelt ist, wie z.B. eine Anzeige, ein Lautsprecher und/oder eine Vibrationskomponente. FCW-Systeme können eine Warnung bereitstellen, z.B. in Form eines Tons, einer visuellen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
AEB-Systeme erkennen eine bevorstehende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines bestimmten Zeit- oder Abstandsparameters korrigierend eingreift. AEB-Systeme können nach vorn gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1260 verwenden, die an einen bestimmten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr erkennt, warnt es in der Regel zuerst den Fahrer, damit dieser korrigierende Maßnahmen zur Vermeidung des Zusammenstoßes ergreift, und wenn der Fahrer keine korrigierenden Maßnahmen ergreift, kann das AEB-System automatisch die Bremsen betätigen, um die Auswirkungen des vorausgesagten Zusammenstoßes zu verhindern oder zumindest abzuschwächen. AEB-Systeme können Techniken wie die dynamische Bremsunterstützung und/oder das Abbremsen bei drohendem Zusammenstoß aufweisen.
LDW-Systeme stellen visuelle, akustische und/oder taktile Warnungen, wie Lenkrad- oder Sitzvibrationen, bereit, um den Fahrer zu warnen, wenn das Fahrzeug 1200 die Fahrbahnmarkierungen überfährt. Ein LDW-System wird nicht aktiviert, wenn der Fahrer durch Aktivierung eines Blinkers ein absichtliches Verlassen der Fahrspur anzeigt. LDW-Systeme können nach vorn gerichtete Kameras verwenden, die mit einem bestimmten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch an die Rückkopplung zu dem Fahrers gekoppelt ist, wie z.B. eine Anzeige, einen Lautsprecher und/oder eine Vibrationskomponente.
LKA-Systeme sind eine Variante der LDW-Systeme. LKA-Systeme liefern Lenkeingaben oder Bremsen, um das Fahrzeug 1200 zu korrigieren, wenn das Fahrzeug 1200 beginnt, die Fahrspur zu verlassen.
BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen, die sich in einem toten Winkel eines Fahrzeugs befinden. BSW-Systeme können einen optischen, akustischen und/oder taktilen Alarm ausgeben, um anzuzeigen, dass das Einfahren auf eine Spur oder ein Spurwechsel unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker benutzt. BSW-Systeme können nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1260 verwenden, die an einen dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch an die Rückkopplung zu dem Fahrer, wie z.B. eine Anzeige, einen Lautsprecher und/oder eine Vibrationskomponente, gekoppelt ist.
RCTW-Systeme können eine visuelle, akustische und/oder taktile Benachrichtigung liefern, wenn beim Rückwärtsfahren des Fahrzeugs 1200 ein Objekt außerhalb des Rückfahrkamera-Bereichs erkannt wird. Einige RCTW-Systeme weisen AEB auf, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Aufprall zu vermeiden. RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensor(en) 1260 verwenden, der/die mit einem bestimmten Prozessor, DSP, FPGA und/oder ASIC gekoppelt ist/sind, der/die elektrisch mit der Rückkopplung zu dem Fahrer gekoppelt ist/sind, wie z. B. eine Anzeige, ein Lautsprecher und/oder eine Vibrationskomponente.
Herkömmliche ADAS-Systeme können anfällig für falsch-positive Ergebnisse sein, die für einen Fahrer störend und ablenkend sein können, in der Regel aber nicht katastrophal sind, da die ADAS-Systeme den Fahrer warnen und ihm die Möglichkeit geben, zu entscheiden, ob ein Sicherheitszustand wirklich vorliegt, und entsprechend zu handeln. Bei einem autonomen Fahrzeug 1200 muss jedoch das Fahrzeug 1200 selbst bei widersprüchlichen Ergebnissen entscheiden, ob das Ergebnis von einem primären oder einem sekundären Rechner (z.B. einem ersten Steuergerät 1236 oder einem zweiten Steuergerät 1236) berücksichtigt werden soll. Bei einigen Ausführungsformen kann das ADAS-System 1238 beispielsweise ein Backup- und/oder Sekundärcomputer sein, der Wahrnehmungsinformationen an ein Rationalitätsmodul eines Backup-Computers liefert. Das Rationalitätsmodul des Backup-Computers kann eine redundante, andere Software auf Hardwarekomponenten ausführen, um Wahrnehmungsfehler und dynamische Fahraufgaben zu erkennen. Die Ausgaben des ADAS-Systems 1238 können einer übergeordneten MCU zur Verfügung gestellt werden. Wenn die Ausgaben des Primärrechners und des Sekundärrechners in Konflikt stehen, muss die übergeordnete MCU bestimmen, wie der Konflikt ausgeglichen werden kann, um einen sicheren Betrieb zu gewährleisten.
Bei einigen Beispielen kann der Primärcomputer so konfiguriert sein, dass er der übergeordneten MCU einen Vertrauenswert liefert, der das Vertrauen des Primärcomputers in das gewählte Ergebnis anzeigt. Wenn der Vertrauenswert einen Schwellenwert überschreitet, kann die übergeordnete MCU dem Vorschlag des primären Computers folgen, unabhängig davon, ob der sekundäre Computer ein widersprüchliches oder inkonsistentes Ergebnis liefert. Wenn der Vertrauenswert den Schwellenwert nicht erreicht und wenn der primäre und der sekundäre Computer unterschiedliche Ergebnisse anzeigen (z.B. den Konflikt), kann die übergeordnete MCU zwischen den Computern vermitteln, um das geeignete Ergebnis zu bestimmen.
Die übergeordnete MCU kann so ausgestaltet sein, dass sie ein neuronales Netz bzw. neuronale Netzwe betreibt bzw. betreiben kann, das bzw. die so trainiert und konfiguriert ist bzw. sind, dass es bzw. sie zumindest teilweise auf der Grundlage der Ausgaben des primären Computers und des sekundären Computers die Bedingungen bestimmt, unter denen der sekundäre Computer Fehlalarme ausgibt.
So kann (können) das (die) neuronale(n) Netz (e) in der übergeordneten MCU lernen, wann die Ausgabe des sekundären Computers vertrauenswürdig ist und wann nicht. Wenn es sich bei dem sekundären Computer beispielsweise um ein RADAR-basiertes FCW-System handelt, kann (können) ein neuronales Netz (neuronale Netze) in der übergeordneten MCU lernen, wenn das FCW-System metallische Objekte identifiziert, die in Wirklichkeit keine Gefahren darstellen, wie z.B. ein Entwässerungsgitter oder eine Schachtabdeckung, die einen Alarm auslösen. Wenn der sekundäre Computer ein kamerabasiertes LDW-System ist, kann ein neuronales Netz in der übergeordneten MCU lernen, die LDW außer Kraft zu setzen, wenn Radfahrer oder Fußgänger anwesend sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. Bei Ausführungsformen, die ein neuronales Netz bzw. neuronale Netze aufweisen, die auf der übergeordneten MCU laufen, kann die übergeordnete MCU mindestens eine DLA- oder GPU-Einheit aufweisen, die für den Betrieb des neuronalen Netzes bzw. der neuronalen Netze mit zugehörigem Speicher geeignet ist. Bei bevorzugten Ausführungsformen kann die übergeordnete MCU das (die) SoC(s) 1204 umfassen und/oder als ein Bestandteil des (der) SoC(s) 1204 vorhanden sein.
Bei anderen Beispielen kann das ADAS-System 1238 einen sekundären Computer aufweisen, der die ADAS-Funktionalität unter Verwendung traditioneller Regeln des Computersehens ausführt. Als solcher kann der sekundäre Computer die klassischen Regeln des Computersehens verwenden (wenn-dann), und das Vorhandensein eines oder mehrerer neuronaler Netze in der übergeordneten MCU kann die Zuverlässigkeit, Sicherheit und Leistung verbessern. Zum Beispiel macht die unterschiedliche Implementierung und absichtliche Nicht-Gleichheit das Gesamtsystem fehlertoleranter, insbesondere gegenüber Fehlern, die durch die Funktionalität der Software (oder der Software-Hardware-Schnittstelle) verursacht werden. Wenn beispielsweise ein Softwarefehler oder ein Fehler in der auf dem primären Computer laufenden Software vorliegt und der nicht identische Softwarecode, der auf dem sekundären Computer läuft, dasselbe Gesamtergebnis liefert, kann die übergeordnete MCU größere Zuversicht haben, dass das Gesamtergebnis korrekt ist und der Fehler in der Software oder Hardware auf dem primären Computer keinen wesentlichen Fehler verursacht.
Bei einigen Beispielen kann die Ausgabe des ADAS-Systems 1238 in den Wahrnehmungsblock des primären Computers und/oder in den Block der dynamischen Fahraufgabe des primären Computers eingespeist werden. Wenn das ADAS-System 1238 zum Beispiel eine Vorwärts-Aufprall-Warnung aufgrund eines unmittelbar vorausfahrenden Objekts anzeigt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. Bei anderen Beispielen kann der sekundäre Computer über ein eigenes neuronales Netz verfügen, das trainiert wird und somit das Risiko von falsch-positiven Entscheidungen reduziert, wie es hier beschrieben ist.
Das Fahrzeug 1200 kann ferner das Infotainment-SoC 1230 aufweisen (z.B. ein bordeigenes Infotainment-System (IVI)). Obwohl das Infotainment-System als SoC dargestellt und beschrieben ist, ist es möglicherweise kein SoC und kann zwei oder mehr diskrete Komponenten aufweisen. Das Infotainment-SoC 1230 kann eine Kombination aus Hard- und Software aufweisen, die für die Bereitstellung von Audio (z.B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z.B. Fernsehen, Filme, Streaming usw.), Telefon (z.B. Freisprecheinrichtung), Netzwerkanbindung (z.B. LTE, WiFi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Einparkhilfe hinten, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremskraftstoffstand, Ölstand, Tür öffnen/schließen, Luftfilterinformationen usw.) zum Fahrzeug 1200, eingesetzt wird. Das Infotainment-System SoC 1230 kann z.B. Radios, Plattenspieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, WiFi, Lenkrad-Audiobedienelemente, Freisprech-Sprachsteuerung, ein Head-up-Display (HUD), ein HMI-Display 1234, ein Telematikgerät, ein Bedienfeld (z.B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten umfassen. Das Infotainment-SoC 1230 kann darüber hinaus verwendet werden, um Informationen (z.B. visuelle und/oder akustische) für einen oder mehrere Benutzer des Fahrzeugs bereitzustellen, wie z.B. Informationen von dem ADAS-System 1238, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Informationen zur Umgebung (z.B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
Das Infotainment-SoC 1230 kann eine GPU-Funktionalität aufweisen. Das Infotainment-SoC 1230 kann über den Bus 1202 (z. B. CAN-Bus, Ethernet usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 1200 kommunizieren. Bei einigen Beispielen kann das Infotainment-SoC 1230 an eine übergeordnete MCU gekoppelt sein, so dass die GPU des Infotainmentsystems einige Selbststeuerungsfunktionen ausführen kann, falls die primäre(n) Steuerung(en) 1236 (z. B. der primäre- und/oder Backup-Computer des Fahrzeugs 1200) ausfallen. Bei einem solchen Beispiel kann das Infotainment-SoC 1230 das Fahrzeug 1200 in einen Modus versetzen, welcher es von dem Chauffeur-Modus zu einem sicheren Halt bringt, wie es hier beschrieben ist.
Das Fahrzeug 1200 kann darüber hinaus ein Kombiinstrument 1232 aufweisen (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.). Das Kombiinstrument 1232 kann ein Steuergerät und/oder einen Supercomputer aufweisen (z.B. ein diskretes Steuergerät oder einen Supercomputer). Das Kombiinstrument 1232 kann eine Reihe von Instrumenten aufweisen, z.B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltpositionsanzeige, Gurtwarnleuchte(n), Feststellbremswarnleuchte(n), Motorstörungsleuchte(n), Airbag (SRS)-Systeminformationen, Beleuchtungssteuerungen, Sicherheitssystemkontrollen, Navigationsinformationen usw. Bei einigen Beispielen können Informationen zwischen dem Infotainment-SoC 1230 und dem Kombiinstrument 1232 angezeigt und/oder gemeinsam genutzt werden. Mit anderen Worten: Das Kombiinstrument 1232 kann als Teil des Infotainmentsystems SoC 1230 oder umgekehrt vorhanden sein.
12D ist gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Systemschema für die Kommunikation zwischen Cloud-basierten Server(n) und dem autonomen Beispielfahrzeug 1200 aus 12A. Das System 1276 kann den/die Server 1278, das/die Netzwerk(e) 1290 und Fahrzeuge, einschließlich des Fahrzeugs 1200, aufweisen. Der/die Server 1278 kann/können eine Vielzahl von GPUs 1284(A)-1284(H) (hierin gemeinsam als GPUs 1284 bezeichnet), PCIe-Switches 1282(A)-1282(H) (hierin gemeinsam als PCIe-Switches 1282 bezeichnet) und/oder CPUs 1280(A)-1280(B) (hierin gemeinsam als CPUs 1280 bezeichnet) aufweisen. Die GPUs 1284, die CPUs 1280 und die PCIe-Switches können mit Hochgeschwindigkeitsverbindungen verbunden sein, wie z.B. und ohne Einschränkung die von NVIDIA entwickelten NVLink-Schnittstellen 1288 und/oder PCIe-Verbindungen 1286. Bei einigen Beispielen sind die GPUs 1284 über NVLink und/oder NVSwitch SoC und die GPUs 1284 und die PCIe-Switches 1282 über PCIe-Verbindungen miteinander verbunden. Obwohl acht GPUs 1284, zwei CPUs 1280 und zwei PCIe-Switches dargestellt sind, ist dies nicht als Einschränkung gedacht. Je nach Ausführungsform kann jeder der Server 1278 eine beliebige Anzahl von GPUs 1284, CPUs 1280 und/oder PCIe-Switches aufweisen. Der/die Server 1278 kann/können beispielsweise jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1284 aufweisen.
Der/die Server 1278 können über das/die Netzwerk(e) 1290 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder geänderte Straßenbedingungen zeigen, wie z. B. kürzlich begonnene Straßenarbeiten. Der (die) Server 1278 kann (können) über das (die) Netzwerk(e) 1290 und an die Fahrzeuge neuronale Netze 1292, aktualisierte neuronale Netze 1292 und/oder Karteninformationen 1294, einschließlich Informationen über Verkehrs- und Straßenbedingungen, übertragen. Die Aktualisierungen der Karteninformationen 1294 können Aktualisierungen für die HD-Karte 1222 aufweisen, z.B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. Bei einigen Beispielen können die neuronalen Netze 1292, die aktualisierten neuronalen Netze 1292 und/oder die Karteninformationen 1294 das Ergebnis eines neuen Trainings und/oder von Erfahrungswerten sein, die in Daten repräsentiert sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder zumindest teilweise auf einem Training beruhen, das in einem Datenzentrum durchgeführt wurde (z.B. unter Verwendung des/der Server(s) 1278 und/oder anderer Server).
Der/die Server 1278 kann/können verwendet werden, um Modelle des maschinellen Lernens (z.B. neuronale Netze) zu trainieren, was zumindest teilweise auf Trainingsdaten basiert. Die Trainingsdaten können von den Fahrzeugen und/oder in einer Simulation (z.B. unter Verwendung einer Spielmaschine) erzeugt werden. Bei einigen Beispielen werden die Trainingsdaten mit Tags versehen (z.B. wenn das neuronale Netz von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während bei anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z.B. wenn das neuronale Netz kein überwachtes Lernen erfordert). Sobald die Modelle zum maschinellen Lernen trainiert sind, können die Fahrzeuge die Modelle zum maschinellen Lernen verwenden (z.B. indem sie über das (die) Netzwerk(e) 1290 an die Fahrzeuge übertragen werden), und/oder die Modelle zum maschinellen Lernen können von dem (den) Server(n) 1278 zur Fernüberwachung der Fahrzeuge verwendet werden.
Bei einigen Beispielen kann/können der/die Server 1278 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Netze in Echtzeit für intelligente Echtzeit-Inferenzierung anwenden. Der/die Server 1278 kann/können tief lernende Supercomputer und/oder dedizierte Kl-Computer aufweisen, die von GPU(s) 1284 betrieben werden, wie z. B. von NVIDIA entwickelte DGX- und DGX-Station-Maschinen. Bei einigen Beispielen kann/können der/die Server 1278 jedoch eine Infrastruktur für tiefes Lernen aufweisen, die nur CPU-betriebene Rechenzentren verwendet.
Die Infrastruktur für tiefes Lernen des/der Server(s) 1278 ist möglicherweise in der Lage, schnelle Echtzeit-Abfragen durchzuführen, und kann diese Fähigkeit nutzen, um den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware im Fahrzeug 1200 zu bewerten und zu überprüfen. Zum Beispiel kann die Infrastruktur für das tiefe Lernen periodische Aktualisierungen von dem Fahrzeug 1200 erhalten, wie z.B. eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 1200 in dieser Bildsequenz lokalisiert hat (z.B. durch Computer-Sehen und/oder andere Klassifizierungstechniken für Objekte des maschinellen Lernens). Die Infrastruktur für das maschinelle Lernen kann ihr eigenes neuronales Netz betreiben, um die Objekte zu identifizieren und sie mit den von dem Fahrzeug 1200 identifizierten Objekten zu vergleichen. Wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 1200 fehlerhaft ist, können der/die Server 1278 ein Signal an das Fahrzeug 1200 senden und einen ausfallsicheren Computer des Fahrzeugs 1200 anweisen, die Kontrolle zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
Für die Inferenzierung können der/die Server 1278 die GPU(s) 1284 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT 3 von NVIDIA) aufweisen. Die Kombination aus GPU-betriebenen Servern und Inferenzbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. Bei anderen Beispielen, z. B. wenn die Leistung weniger kritisch ist, können Server, die mit CPUs, FPGAs und anderen Prozessoren arbeiten, für Inferenzzwecke eingesetzt werden.
13 ist ein Blockdiagramm eines Beispiel-Rechengeräts 1300, das sich zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung eignet. Die Computereinrichtung bzw. das Rechengerät 1300 kann einen Bus 1302 aufweisen, der direkt oder indirekt die folgenden Geräte koppelt: einen Speicher 1304, eine oder mehrere Zentraleinheiten (CPUs) 1306, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1308, eine Kommunikationsschnittstelle 1310, Ein-/Ausgabeanschlüsse 1312, Ein-/Ausgabekomponenten 1314, ein Netzteil 1316 und eine oder mehrere Darstellungskomponenten 1318 (z.B. Anzeige(n)).
Obwohl die verschiedenen Blöcke von 13 so dargestellt sind, als wären sie über den Bus 1302 mit Leitungen verbunden, ist dies nicht als Einschränkung gedacht und dient nur der Übersichtlichkeit. Zum Beispiel kann bei einigen Ausführungsformen eine Darstellungskomponente 1318, wie z.B. ein Anzeigegerät, als E/A-Komponente 1314 betrachtet werden (z.B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 1306 und/oder GPUs 1308 einen Speicher aufweisen (z.B. kann der Speicher 1304 zusätzlich zu dem Speicher der GPUs 1308, der CPUs 1306 und/oder anderer Komponenten eine Speichereinrichtung darstellen). Mit anderen Worten dient das Rechengerät von 13 lediglich der Veranschaulichung. Es wird nicht zwischen Kategorien wie „Arbeitsstation“, „Server“, „Laptop“, „Desktop“, „Tablett“, „Client-Gerät“, „mobiles Gerät“, „Handgerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, welche alle als das Rechengerät von 13 angesehen werden können.
Der Bus 1302 kann einen oder mehrere Busse darstellen, wie z.B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Der Bus 1302 kann einen oder mehrere Bustypen aufweisen, wie z.B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder einen anderen Bustyp.
Der Speicher 1304 kann eine Vielzahl von computerlesbaren Medien aufweisen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Rechengerät 1300 zugreifen kann. Zu den computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie herausnehmbare und nicht herausnehmbare Medien gehören. Als Beispiel, und nicht als Einschränkung, können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
Zu den computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien und/oder austauschbare und nicht austauschbare Medien gehören, die in einer beliebigen Methode oder Technologie zur Speicherung von Informationen wie computerlesbaren Befehlen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Zum Beispiel kann der Speicher 1304 computerlesbare Anweisungen speichern (z.B. die ein Programm (Programme) und/oder ein Programmelement (Programmelemente), wie ein Betriebssystem, darstellen). Computer-Speichermedien können unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetband, Magnetplattenspeicher oder andere magnetische Speichergeräte oder jedes andere Medium aufweisen, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das das Computergerät 1300 zugreifen kann. In der hier verwendeten Form umfassen Computerspeichermedien keine Signale an sich.
Die Kommunikationsmedien können computerlesbare Ausführungsformen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal, wie z.B. einer Trägerwelle oder einem anderen Transportmechanismus, aufweisen und umfassen alle Informationslieferungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder geändert wurden, dass Informationen in dem Signal kodiert werden. Als Beispiel und ohne Einschränkung können die Kommunikationsmedien drahtgebundene Medien wie ein drahtgebundenes Netzwerk oder eine direkt verdrahtete Verbindung sowie drahtlose Medien wie akustische, HF-, Infrarot- und andere drahtlose Medien aufweisen. Kombinationen aus einem der oben genannten Medien sollten auch in dem Umfang der computerlesbaren Medien enthalten sein.
Die CPU(s) 1306 kann (können) so ausgestaltet sein, dass sie die computerlesbaren Befehle zur Steuerung einer oder mehrerer Komponenten des Rechengeräts 1300 ausführt (ausführen), um eine oder mehrere der hier beschriebenen Verfahren und/oder Prozesse auszuführen. Die CPU(s) 1306 kann/können jeweils einen oder mehrere Kerne aufweisen (z.B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.), die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 1306 können jeden Prozessortyp aufweisen und je nach Art des implementierten Rechengeräts 1300 verschiedene Typen von Prozessoren enthalten (z.B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Zum Beispiel kann der Prozessor je nach Typ des Rechengeräts 1300 ein ARM-Prozessor, der mit RISC (Reduced Instruction Set Computing) implementiert ist, oder ein x86-Prozessor, der mit CISC (Complex Instruction Set Computing) implementiert ist, sein. Das Rechengerät 1300 kann eine oder mehrere CPUs 1306 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Koprozessoren, wie z.B. mathematische Koprozessoren, aufweisen.
Die GPU(s) 1308 kann/können von dem Rechengerät 1300 zum Rendern von Grafiken (z.B. 3D-Grafiken) verwendet werden. Die GPU(s) 1308 kann/können Hunderte oder Tausende von Kernen aufweisen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 1308 kann/können Pixeldaten für Ausgabebilder als Reaktion auf Rendering-Befehle erzeugen (z.B. Rendering-Befehle von der/den CPU(s) 1306, die über eine Host-Schnittstelle empfangen werden). Die GPU(s) 1308 kann/können Grafikspeicher, wie z. B. Bildschirmspeicher, zur Speicherung von Pixeldaten aufweisen. Der Anzeigespeicher kann als Teil des Speichers 1304 enthalten sein. Die GPU(s) 1308 kann/können zwei oder mehr parallel (z. B. über eine Verbindung) arbeitende GPUs aufweisen. Wenn sie miteinander kombiniert sind, kann jede GPU 1308 Pixeldaten für verschiedene Teile eines Ausgabebildes oder für verschiedene Ausgabebilder erzeugen (z.B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher aufweisen oder Speicher mit anderen GPUs gemeinsam nutzen.
Bei Beispielen, in denen das Rechengerät 1300 die GPU(s) 1308 nicht aufweist, kann/können die CPU(s) 1306 zum Rendern von Grafiken verwendet werden.
Die Kommunikationsschnittstelle 1310 kann einen oder mehrere Empfänger, Sender und/oder Transceiver aufweisen, die es dem Rechengerät 1300 ermöglichen, mit anderen Recheneinheiten bzw. Rechengeräten über ein elektronisches Kommunikationsnetz, einschließlich drahtgebundener und/oder drahtloser Kommunikation, zu kommunizieren. Die Kommunikationsschnittstelle 1310 kann Komponenten und Funktionen aufweisen, die eine Kommunikation über eine Reihe verschiedener Netzwerke 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), Weitverkehrsnetzwerke mit geringem Stromverbrauch (z.B. LoRaWAN, SigFox usw.) und/oder das Internet.
Die E/A-Anschlüsse 1312 können es ermöglichen, das Rechengerät 1300 logisch mit anderen Geräten zu koppeln, einschließlich der E/A-Komponenten 1314, der Darstellungskomponente(n) 1318 und/oder anderer Komponenten, von denen einige in das Rechengerät 1300 eingebaut (z.B. integriert) sein können. Die dargestellten E/A-Komponenten 1314 weisen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. auf. Die E/A-Komponenten 1314 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Gesten, eine Stimme oder andere physiologische Eingaben verarbeitet, die von einem Benutzer erzeugt werden. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzelement übertragen werden. Eine NUI kann eine beliebige Kombination von Spracherkennung, Taststifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Gesten, Kopf- und Augenverfolgung und Berührungserkennung (wie sie im Folgenden näher beschrieben werden) in Verbindung mit einer Anzeige des Rechengeräts 1300 implementieren. Das Rechengerät 1300 kann Tiefenkameras aufweisen, wie z.B. stereoskopische Kamerasysteme, Infrarot-Kamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, für die Gestenerfassung und -erkennung. Zusätzlich kann das Rechengerät 1300 Beschleunigungsmesser oder Gyroskope (z.B. als Teil einer Trägheitsmesseinheit (IMU)) aufweisen, die die Erkennung von Bewegungen ermöglichen. Bei einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von dem Rechengerät 1300 verwendet werden, um immersive Augmented Reality oder virtuelle Realität darzustellen.
Das Netzteil 1316 kann ein fest verdrahtetes Netzteil, ein Batterie-Netzteil oder eine Kombination daraus aufweisen. Das Netzteil 1316 kann das Rechengerät 1300 mit Strom versorgen, um den Betrieb der Komponenten des Rechnegeräts 1300 zu ermöglichen.
Die Präsentationskomponente(n) 1318 kann/können eine Anzeige (z.B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Head-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten aufweisen. Die Präsentationskomponente(n) 1318 kann/können Daten von anderen Komponenten empfangen (z.B. der/den GPU(s)1308, der/den CPU(s) 1306 usw.) und die Daten ausgeben (z.B. als Bild, Video, Ton usw.).
Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinenverwendbaren Befehlen, einschließlich computerausführbaren Befehlen wie Programmmodulen, beschrieben werden, die von einem Computer oder einer anderen Maschine, wie z.B. einem Assistenten für persönliche Daten oder einem anderen Handgerät, ausgeführt werden. Im Allgemeinen weisen Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf Code hin, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen ausgeführt sein, einschließlich Handgeräten, Unterhaltungselektronik, Allzweckcomputern, spezielleren Computergeräten usw. Die Offenbarung kann auch in verteilten Computerumgebungen ausgeführt sein, in denen die Tasks von abgesetzt arbeitenden Geräten ausgeführt werden, die durch ein Kommunikationsnetz miteinander verbunden sind.
Wie es hier verwendet wird, sollte eine Rezitation von „und/oder“ in Bezug auf zwei oder mehr Elemente so interpretiert werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C aufweisen. Darüber hinaus kann „mindestens eines von Element A oder Element B“ zumindest Element A, zumindest Element B oder zumindest Element A und Element B aufweisen. Ferner kann „mindestens eines von Element A und Element B“ zumindest Element A, zumindest Element B oder zumindest Element A und Element B aufweisen.
Der Gegenstand der vorliegenden Offenbarung wird hier in einer bestimmten Ausprägung beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung selbst ist jedoch nicht dazu gedacht, den Umfang dieser Offenbarung einzuschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise ausgeführt werden kann, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien aufzuweisen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente der angewandten Verfahren zu bezeichnen, sollten darüber hinaus die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbarten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte ist ausdrücklich beschrieben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 16/1011232 [0183]

Claims

Verfahren umfassend: Erhalten von Sensordaten von mindestens einem Sensor eines Fahrzeugs, welche für ein Gesichtsfeld des mindestens einen Sensors in einer Umgebung repräsentativ sind; Bestimmen von Parametern eines Objekts, welches sich in der Umgebung befindet, basierend zumindest teilweise auf den Sensordaten; Modellieren von Trajektorien des Objekts zu jeweils einer von mehreren Zielpositionen basierend zumindest teilweise auf den Parametern des Objekts; Berechnen ausgehend von den Trajektorien von sicheren Zeitintervallen, während welchen das Fahrzeug die mehreren Zielpositionen einnimmt, ohne dass es zu einer Kollision mit dem Objekt kommt; und Ausführen, basierend zumindest teilweise auf den sicheren Zeitintervallen und einer Position des Fahrzeugs in der Umgebung, von zumindest einem von Erzeugen einer Trajektorie für das Fahrzeug oder Analysieren einer vorgeschlagenen Trajektorie oder eines vorgeschlagenen Weges für das Fahrzeug.
Verfahren nach Anspruch 1, wobei die Parameter einen oder mehrere aufweisen von: einem Ort des Objekts, einer Pose des Objekts, einer Geschwindigkeit des Objekts, einer Abmessung des Objekts, einer Beschleunigung des Objekts; oder einer Masse des Objekts.
Verfahren nach Anspruch 1, wobei das Bestimmen der Parameter des Objekts ein Bestimmen einer Klassifikation des Objekts basierend zumindest teilweise auf den Sensordaten aufweist, und wobei zumindest einer der Parameter zumindest teilweise auf der Klassifikation basiert.
Verfahren nach Anspruch 1, wobei das Modellieren der Trajektorien des Objekts ein Bestimmen eines Bewegungsprofils umfasst, welches Änderungen bezüglich einer Geschwindigkeit des Objekts während jedes der sicheren Zeitintervalle definiert.
Verfahren nach Anspruch 1, wobei das Modellieren der Trajektorien des Objekts zumindest teilweise auf einer Reaktionszeit basiert, nach welcher das Objekt abzubremsen beginnt.
Verfahren nach Anspruch 1, wobei das Modellieren der Trajektorien des Objekts zumindest teilweise auf einer Geschwindigkeit des Objekts zu einer Startzeit der Trajektorien basiert.
Verfahren nach Anspruch 1, wobei die Trajektorien jeweils einen direkten Weg zu einer Zielposition der mehreren Zielpositionen umfassen.
Verfahren nach Anspruch 1, wobei das Berechnen der sicheren Zeitintervalle für jede Zielposition der mehreren Zielpositionen ein Bestimmen einer Zeit aufweist, während welcher das Objekt bei der Zielposition bei einer entsprechenden Trajektorie der Trajektorien anhält.
Verfahren nach Anspruch 1, wobei das Analysieren der vorgeschlagenen Trajektorie oder des vorgeschlagenen Weges aufweist: Bestimmen, ob vorgeschlagene Ankunftszeiten des Fahrzeugs an Punkten auf der Trajektorie jeweils innerhalb der sicheren Zeitintervalle für entsprechende Zielpositionen der Zielpositionen liegen; und Übertragen eines Hinweises zu einer Steuerkomponente des Fahrzeugs, ob die vorgeschlagenen Ankunftszeiten des Fahrzeugs an den Punkten auf der Trajektorie jeweils innerhalb der sicheren Zeitintervalle für die entsprechenden Zielpositionen der Zielpositionen liegen.
Verfahren umfassend: Bestimmen von Parametern eines Objekts, welches sich in einer Umgebung befindet, basierend zumindest teilweise auf Sensordaten, welche von zumindest einem Sensor in der Umgebung erzeugt werden; Berechnen, basierend zumindest teilweise auf den Parametern des Objekts, von sicheren Zeitintervallen für Zielpositionen in der Umgebung, während welchen ein Fahrzeug die Zielpositionen einnimmt, ohne dass es zu einer Kollision mit dem Objekt kommt; Erzeugen eines Bildes mit entsprechenden Datenwerten, welche zumindest Teile der sicheren Zeitintervalle repräsentieren; und Durchführen, basierend zumindest teilweise auf dem Bild und einer Position des Fahrzeugs in der Umgebung, von zumindest einem von Erzeugen einer Trajektorie für das Fahrzeug oder Analysieren einer vorgeschlagenen Trajektorie oder eines vorgeschlagenen Weges für das Fahrzeug.
Verfahren nach Anspruch 10, wobei sich die Datenwerte jeweils auf eine gemeinsame Startzeit der sicheren Zeitintervalle beziehen.
Verfahren nach Anspruch 10, wobei die Datenwerte eine Kontur ausbilden, welcher für eine Gruppe der Zielpositionen und eine vorgegebene sichere Ankunftszeit in einer entsprechenden Gruppe der sicheren Ankunftszeiten repräsentativ ist.
Verfahren nach Anspruch 10, wobei die sicheren Zeitintervalle erste sichere Zeitintervalle sind, und wobei das Verfahren darüber hinaus umfasst: Berechnen von zweiten sicheren Zeitintervallen für die Zielpositionen in der Umgebung, während welchen das Fahrzeug die Zielpositionen einnimmt, ohne dass es zu einer Kollision mit einem zweiten Objekt kommt; und Bestimmen für eine Gruppe der Zielpositionen, welche den Datenwerten entsprechen, dass die ersten sicheren Zeitintervalle vor den zweiten sicheren Zeitintervallen enden; wobei die Datenwerte für die ersten sicheren Zeitintervalle basierend zumindest teilweise auf dem Bestimmen, dass die ersten sicheren Zeitintervalle vor den zweiten sicheren Zeitintervallen enden, repräsentativ sind.
Verfahren nach Anspruch 10, darüber hinaus ein Darstellen einer Visualisierung umfassend, welche dem Bild auf einer oder auf mehreren Mensch-Maschinen-Schnittstellen-Anzeigen oder einem Armaturenbrett des Fahrzeugs entspricht.
Verfahren nach Anspruch 10, wobei die Sensordaten von mindestens einem Sensor des Fahrzeugs stammen, und wobei die Sensordaten für ein Gesichtsfeld des mindestens einen Sensors in der Umgebung repräsentativ sind.
Verfahren umfassend: Bestimmen von Parametern eines Objekts, welches sich in einer Umgebung befindet, basierend zumindest teilweise auf Sensordaten, welche durch einen Sensor in der Umgebung erzeugt werden; Bestimmen, zumindest teilweise basierend auf den Parametern des Objekts, von sicheren Ankunftszeiten, zu welchen ein Fahrzeug Zielpositionen in der Umgebung einnimmt, ohne dass es zu einer Kollision mit dem Objekt kommt; Erzeugen einer Kontur, welche eine Gruppe der Zielpositionen repräsentiert und einer entsprechenden Gruppe der sicheren Ankunftszeiten entspricht; und Durchführen, basierend zumindest teilweise auf der Kontur und einer Position des Fahrzeugs in der Umgebung, von zumindest einem von Erzeugen einer Trajektorie für das Fahrzeug oder Analysieren einer vorgeschlagenen Trajektorie oder eines vorgeschlagenen Weges für das Fahrzeug.
Verfahren nach Anspruch 16, wobei das Erzeugen der Kontur aufweist: Auswählen der Gruppe der Zielpositionen basierend zumindest teilweise auf einem Bestimmen einer selben sicheren Ankunftszeit der sicheren Ankunftszeiten für jede Zielposition der Gruppe; und Ausbilden der Kontur basierend zumindest teilweise auf dem Auswählen der Gruppe der Zielpositionen.
Verfahren nach Anspruch 16, wobei das Erzeugen der Kontur aufweist ein Erzeugen eines Bildes mit Datenwerten, welche für die sicheren Ankunftszeiten repräsentativ sind, und wobei das Durchführen von zumindest einem von dem Erzeugen der Trajektorie für das Fahrzeug oder dem Analysieren der vorgeschlagenen Trajektorie oder des vorgeschlagenen Weges für das Fahrzeug ein Analysieren des Bildes aufweist.
Verfahren nach Anspruch 16, darüber hinaus ein Darstellen einer Visualisierung umfassend, welche der Kontur entspricht, auf einer oder auf mehreren Mensch-Maschine-Schnittstelle-Anzeigen oder einem Armaturenbrett des Fahrzeugs.
Verfahren nach Anspruch 16, wobei die Sensordaten von zumindest einem Sensor des Fahrzeugs stammen, und wobei die Sensordaten für ein Gesichtsfeld des mindestens einen Sensors in der Umgebung repräsentativ sind.