DE112021001994T5 - Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen - Google Patents

Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen Download PDF

Info

Publication number
DE112021001994T5
DE112021001994T5 DE112021001994.5T DE112021001994T DE112021001994T5 DE 112021001994 T5 DE112021001994 T5 DE 112021001994T5 DE 112021001994 T DE112021001994 T DE 112021001994T DE 112021001994 T5 DE112021001994 T5 DE 112021001994T5
Authority
DE
Germany
Prior art keywords
vehicle
data
mlm
actors
dnn
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112021001994.5T
Other languages
English (en)
Inventor
Nikolai Smolyanskiy
Alexeyi Kamenev
Lirui WANG
David Nister
Ollin Boer Bohan
Ishwar Kulkarni
Fangkai Yang
Julia Ng
Alperen Degirmenci
Ruchi Bhargava
Rotem Aviv
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE112021001994T5 publication Critical patent/DE112021001994T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G06N3/084—Backpropagation, e.g. using gradient descent
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/08—Learning methods
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/0088—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots characterized by the autonomous decision making process, e.g. artificial intelligence, predefined behaviours
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/042—Knowledge-based neural networks; Logical representations of neural networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/044—Recurrent networks, e.g. Hopfield networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/02—Neural networks
    • G06N3/04—Architecture, e.g. interconnection topology
    • G06N3/045—Combinations of networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N3/00—Computing arrangements based on biological models
    • G06N3/004—Artificial life, i.e. computing arrangements simulating life
    • G06N3/006—Artificial life, i.e. computing arrangements simulating life based on simulated virtual individual or collective life forms, e.g. social simulations or particle swarm optimisation [PSO]

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Molecular Biology (AREA)
  • Biophysics (AREA)
  • General Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Mathematical Physics (AREA)
  • Data Mining & Analysis (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Game Theory and Decision Science (AREA)
  • Medical Informatics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Automation & Control Theory (AREA)
  • Traffic Control Systems (AREA)
  • Control Of Driving Devices And Active Controlling Of Vehicle (AREA)

Abstract

In verschiedenen Beispielen wird bestärkendes Lernen (Reinforcement Learning) verwendet, um zumindest ein Machine-Learning-Modell (MLM) zur Steuerung eines Fahrzeugs zu trainieren, indem ein Deep-Neural-Network (DNN), das auf realen Daten trainiert wurde, verwendet wird, um die Bewegungen eines oder mehrerer Akteure vorherzusagen und ein Weltmodell zu definieren. Das DNN kann anhand von realen Daten trainiert werden, um Attribute von Akteuren, wie z. B. Orte und/oder Bewegungen, aus Eingabeattributen vorherzusagen. Die Vorhersagen können Zustände der Umgebung in einem Simulator definieren, und ein oder mehrere Attribute eines oder mehrerer Akteure, die in das DNN eingegeben werden, können durch den Simulator verändert oder gesteuert werden, um Bedingungen zu simulieren, die andernfalls nicht realisierbar wären. Das/die MLM kann/können die Vorhersagen des DNN nutzen, um eine oder mehrere Aktionen für das Fahrzeug vorherzusagen.

Description

  • HINTERGRUND DER ERFINDUNG
  • Techniken für maschinelles Lernen wie das bestärkende Lernen (Reinforcement Learning, RL), die Verfahren nach dem Prinzip „Versuch und Irrtum“ anwenden, können verwendet werden, um optimale Strategien für die Planung und Steuerung von Operationen in Robotik-Applikationen zu trainieren. Das Verwenden von bestärkendem Lernen, um Fahrstrategien für autonome und teilautonome Fahrzeuge zu trainieren, kann jedoch eine Herausforderung darstellen. In der Robotik zum Beispiel können Strategien in einem Simulator oder in sehr begrenztem Umfang in realen Robotersystemen trainiert werden. Die Übertragung von im Simulator trainierten Strategien auf Fahrzeuge ist jedoch aufgrund von Domänenunterschieden und Modellierungsunterschieden schwierig. Um genaue Ergebnisse zu erzielen, muss ein Simulator, der zum Trainieren von Fahrstrategien unter Verwendung von bestärkendem Lernen verwendet wird, gemäß konventionellen Ansätzen möglicherweise alle Fahrbedingungen simulieren, was nicht praktikabel wäre. Darüber hinaus kann die direkte Anwendung von Techniken des bestärkenden Lernens auf reale Robotersysteme gegen Sicherheitsanforderungen verstoßen, da sie es erforderlich machen können, einen Fahrer, Maschinenbediener, das autonome System selbst oder Objekte oder Akteure in der lokalen Umgebung in gefährliche Situationen zu bringen. Diese Probleme haben dazu beigetragen, dass sich die Algorithmen des bestärkenden Lernens für die Planung und Steuerung von autonomen Fahrzeugen nicht durchsetzen konnten.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Ausführungsbeispiele der vorliegenden Offenbarung beziehen sich auf modellbasiertes bestärkendes Lernen zur Verhaltensvorhersage. Es werden Systeme und Verfahren offenbart, die verwendet werden können, um Modelle unter Verwendung von bestärkendem Lernen (Reinforcement Learning, RL) zu trainieren, indem eine auf realen Daten aufgebaute Simulation genutzt wird.
  • Im Gegensatz zu konventionellen Systemen, wie den beschriebenen, können die offenbarten Ansätze bestärkendes Lernen verwenden, um zumindest ein Modell für maschinelles Lernen (engl. machine learning model, MLM) zu trainieren, das sich ergänzend oder alternativ auf ein maschinell erlerntes Modell oder ein ML-basiertes Modell beziehen kann, das zur Steuerung eines Fahrzeugs (z.B. zur Implementierung einer Fahrpolitik) verwendet wird, indem ein Deep-Neural-Network („DNN“) verwendet wird, das auf realen Daten trainiert wurde, um die Bewegungen eines oder mehrerer Akteure vorherzusagen und ein Weltmodell (engl. world model, dt. auch Umgebungsmodell) zu definieren. Das DNN kann beispielsweise anhand von realen Daten trainiert werden, um Attribute von Akteuren, wie Orte und/oder Bewegungen, aus Eingabeattributen vorherzusagen. Die Vorhersagen können Zustände der Umgebung in einem Simulator definieren, und ein oder mehrere Attribute eines oder mehrerer Akteure, die in das DNN eingegeben werden, können vom Simulator geändert oder gesteuert werden (z.B. unter Verwendung von Heuristiken), um Bedingungen zu simulieren, die andernfalls nicht durchführbar wären (z.B. ein Akteur, der sich auf das Fahrzeug zubewegt). Das/die MLM(e) kann/können die vom DNN gemachten Vorhersagen nutzen, um eine oder mehrere Aktionen für das Fahrzeug vorherzusagen. Diese Vorhersagen können unter Verwendung eines klassischen Vorhersagemodells nach dem DNN extrapoliert werden. Die Zustände der Umgebung können verwendet werden, um den vom MLM gemachten Vorhersagen unter Verwendung einer Wertfunktion, die auf einem oder mehreren Zielen des MLM basieren kann, eine Bewertung zuzuweisen. In einem oder mehreren Ausführungsbeispielen kann die Wertfunktion von einem oder mehreren MLMs gelernt werden. Das/die trainierte(n) MLM kann/können dann in einem autonomen Fahrzeug zur Verwendung bei der Vorhersage und/oder Steuerung von Akteuren im Verkehr (und anderen realen Situationen) eingesetzt werden, was die Vorhersage der Bewegungen des Ego-Fahrzeugs und/oder anderer Akteure beinhalten kann.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren für modellbasiertes bestärkendes Lernen zur Verhaltensvorhersage werden im Folgenden detailliert unter Bezugnahme auf die beigefügten Figuren beschrieben, wobei Folgendes gezeigt wird:
    • 1A ist ein Diagramm, das ein Beispiel für ein Modelltrainingssystem zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 1B ist ein Diagramm, das ein Beispiel für eine Vorhersage zeigt, die bei der Planung und Steuerung eines autonomen Fahrzeugs verwendet wird, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 2 ist ein Diagramm, das eine Visualisierung von Beispieleingaben und - ausgaben eines maschinellen Vorhersage-Lernmodells zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 3 ist ein Diagramm, das die Kodierung und Dekodierung eines latenten Raums eines neuronalen Vorhersagenetzwerks darstellt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 4 zeigt ein beispielhaftes Datenflussdiagramm für einen Prozess zur Vorhersage von Trajektorien von einem oder mehreren Akteuren in einer Umgebung, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 5 zeigt eine Beispielarchitektur eines Deep-Neural-Network (DNN), die sich zur Implementierung des Verfahrens von 4 eignet, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 6 zeigt eine visuelle Repräsentation von beispielhaften Trajektorien von Akteuren, die auf einer Karte überlagert sind, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 7 zeigt ein Beispiel für die Verlängerung eines vorhergesagten Pfades unter Verwendung eines klassischen mechanischen Bewegungsalgorithmus, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 8 ist ein Flussdiagramm, das ein Verfahren zum Trainieren eines Modells für maschinelles Lernen zeigt, um Vorhersagen unter Verwendung von Orten von Akteuren zu treffen, die mit einem DNN vorhergesagt wurden, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 9 ist ein Flussdiagramm, das ein Verfahren zum Trainieren eines maschinellen Lernmodells zeigt, um Vorhersagen unter Verwendung eines DNN als Weltmodell zu treffen, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 10 ist ein Flussdiagramm, das ein Verfahren zur Steuerung eines autonomen Fahrzeugs basierend auf Vorhersagen zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 11A ist eine Darstellung eines autonomen Fahrzeugs, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 11B ist ein Beispiel für Kamerastandorte und Sichtfelder für das autonome Fahrzeug von 11A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 11C ist ein Blockdiagramm einer Beispielsystemarchitektur für das autonome Fahrzeug von 11A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 11D ist ein Systemdiagramm für die Kommunikation zwischen einem/mehreren Cloud-basierten Server(n) und dem autonomen Beispielfahrzeug von 11A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung;
    • 12 ist ein Blockdiagramm eines beispielhaften Rechengeräts, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist; und
    • 13 ist ein Blockdiagramm eines beispielhaften Datenzentrums, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Es werden Systeme und Verfahren offenbart, die sich auf modellbasiertes bestärkendes (dt. auch verstärkendes) Lernen zur Verhaltensvorhersage beziehen. Obwohl die vorliegende Offenbarung in Bezug auf ein Beispiel für ein autonomes Fahrzeug 1100 (hier auch als „Fahrzeug 1100“ oder „Ego-Fahrzeug 1100“ bezeichnet) beschrieben werden kann, von dem ein Beispiel in Bezug auf 11A-11D beschrieben ist), ist dies nicht als Einschränkung zu verstehen. Beispielsweise können die hierin beschriebenen Systeme und Verfahren ohne Einschränkung von nicht-autonomen Fahrzeugen, halbautonomen Fahrzeugen (z.B. in einem oder mehreren adaptiven Fahrerassistenzsystemen (ADAS)), gelenkten und ungelenkten Robotern oder Roboterplattformen, Lagerfahrzeugen, Geländefahrzeugen, Fahrzeugen, die an einen oder mehrere Anhänger gekoppelt sind, fliegenden Schiffen, Booten, Shuttles, Notfalleinsatzfahrzeugen, Motorrädern, elektrischen oder motorisierten Fahrrädern, Flugzeugen, Baufahrzeugen, Unterwasserfahrzeugen, Drohnen und/oder anderen Fahrzeugtypen verwendet werden. Obwohl die vorliegende Offenbarung in Bezug auf die Verhaltensvorhersage für autonome Fahrzeuge beschrieben wird, soll dies nicht einschränkend sein, und die hierin beschriebenen Systeme und Verfahren können in den Bereichen Augmented Reality, Virtual Reality, Mixed Reality, Robotik, Sicherheit und Überwachung, autonome oder halbautonome Maschinenapplikationen und/oder jedem anderen Technologiebereich verwendet werden, in dem Vorhersagen verwendet werden können.
  • Vor der Verwendung zum Trainieren mindestens eines MLM (das hier auch als Richtlinien-Netzwerk, oder Policy-Netzwerk, bezeichnet werden kann) zur Vorhersage einer oder mehrerer Aktionen für ein Fahrzeug kann ein DNN oder ein anderes MLM (das hier auch als Vorhersagenetzwerk bezeichnet werden kann) trainiert werden, um ein oder mehrere Ausgabeattribute eines oder mehrerer Akteure (die das Ego-Fahrzeug und/oder einen oder mehrere andere Akteure in der Nähe des Ego-Fahrzeugs umfassen können) aus einem oder mehreren Eingabeattributen vorherzusagen.
  • In einem oder mehreren Ausführungsbeispielen kann ein Satz von Trainingsdaten, die zum Trainieren des DNN verwendet werden, unter Verwendung eines oder mehrerer realer Fahrzeugsensoren generiert werden, die die Bewegungen des einen oder der mehreren Akteure in der Umgebung während eines Zeitraums anzeigen. Der Trainingsdatensatz kann unter Verwendung einer beliebigen Kombination verschiedener Arten von Fahrzeugsensoren (wie Kameras, LiDAR-Sensoren, Radarsensoren usw.) von verschiedenen Fahrzeugen in zahlreichen verschiedenen realen Situationen generiert werden. Da sich der Verkehr nur schwer modellieren lässt, können Sensordaten aus der realen Welt verwendet werden, um das DNN zu trainieren, damit es lernt, wie sich die Akteure verändern werden. Beispielsweise können Trajektorien für den/die Akteur(e) aus den realen Daten extrahiert und verwendet werden, um Eingaben für das DNN zu definieren, ebenso wie Grundwahrheitsdaten. In einem oder mehreren Ausführungsbeispielen kann der Satz von Trainingsdaten Daten zu den Bewegungen des Ego-Fahrzeugs enthalten oder anderweitig damit assoziiert sein. Dies liegt daran, dass die Bewegungen des Ego-Fahrzeugs die Bewegungen anderer Akteure in der Umgebung des Ego-Fahrzeugs beeinflussen können und dass die Bewegungen des Ego-Fahrzeugs auch wie hier beschrieben vorhergesagt werden können.
  • Nach dem Training (z.B. zur Vorhersage von Bewegungen von Akteuren im Verkehr) kann das DNN verwendet werden, um ein Weltmodell in einer Simulation zu definieren und das Richtlinien-Netzwerk durch Reinforcement Learning (RL) zu trainieren. Beispielsweise können die vom DNN gemachten Vorhersagen Zustände der in der Simulation repräsentierten Umgebung definieren. In einem oder mehreren Ausführungsbeispielen kann das trainierte DNN als Verkehrsmodell in der Simulation verwendet werden. Das Richtlinien-Netzwerk kann auch trainiert werden, um basierend auf den Vorhersagen des DNN eine oder mehrere Aktionen für das Fahrzeug vorherzusagen (z.B. eine oder mehrere Trajektorien für das Fahrzeug). Beispielsweise kann das Richtlinien-Netzwerk durch Training in der Simulation lernen, wie man Vorhersagen für eine oder mehrere Trajektorien eines oder mehrerer Akteure trifft. In einem oder mehreren Ausführungsbeispielen kann die Simulation ein oder mehrere Attribute eines oder mehrerer Akteure in den Zuständen des Weltmodells, die in das DNN eingegeben werden, ändern oder steuern, um Aktionen dieser Akteure zu simulieren (z.B. ein Fahrzeug, das sich auf das Fahrzeug zubewegt, das Fahrzeug, das am Straßenrand fährt, unsichere Fahrbedingungen, usw.). Auf diese Weise kann das Richtlinien-Netzwerk aus simulierten Situationen lernen, für die in der realen Welt keine oder nur dünn besetzte Trainingsdaten zur Verfügung stehen.
  • RL-Techniken können mit dieser Simulation verwendet werden, um das Netzwerk gemäß einer oder mehrerer Richtlinien (engl. policies, auch Strategien) zu trainieren. Ein Richtlinien-Netzwerk kann z.B. lernen, wie die beste(n) Aktion(en) für das Fahrzeug zu planen ist/sind, wenn ein Ziel (z.B. als Eingabe oder implizit im Training) und Verkehrsinformationen durch das DNN kodiert werden. Beispiele für Ziele können das Erreichen eines bestimmten Ziels, das Verfolgen eines anderen Fahrzeugs usw. sein. Wenn ein Bewegungsplaner, der die vom Richtlinien-Netzwerk gemachten Vorhersagen nutzt, eine oder mehrere Aktionen auswählt, kann er mit dem Verkehrsmodell und den vorhergesagten zukünftigen Trajektorien (z.B. zukünftige Verkehrsbewegungen für andere Akteure) interagieren und die Aktionen entsprechend ändern oder aktualisieren. Auf diese Weise können die Möglichkeiten im Simulator für alle möglichen Zukünfte, die von den Aktionen des Planers abhängen, erneut durchgespielt werden, und das Richtlinien-Netzwerk kann trainiert werden, um optimale Zustände zu erreichen (und/oder schlechte Zustände zu vermeiden), wenn das Ziel gegeben ist.
  • In einem oder mehreren Ausführungsbeispielen kann das Planer/Richtlinien-Netzwerk bzw. können die Planer/Richtlinien-Netzwerke trainiert werden, indem ein interner latenter Zustand des DNN als Repräsentation des Weltzustands verwendet wird, wodurch das Training vereinfacht werden kann. Der Simulator kann schrittweise durch die Umgebung iterieren, indem er das DNN verwendet, um Vorhersagen in einem latenten Raum zu generieren, dann die Vorhersagen in den metrischen Raum der realen Welt dekodiert, einen oder mehrere Akteure gemäß den Vorhersagen und einem oder mehreren physikalischen Modellen bewegt und dann die veränderte Welt erneut in den latenten Raum kodiert, um im nächsten Schritt erneut Vorhersagen zu treffen. Auf diese Weise kann das Planer-/Richtlinien-Netzwerk lernen, die beste(n) Aktion(en) (z.B. Trajektorie) für ein Fahrzeug zu inferenzieren, wenn sein aktuelles Ziel (z.B. ein zu erreichendes Ziel auf einer Karte) und eine aktuelle Verkehrssituation (und in einigen Ausführungsbeispielen seine Vergangenheit) als latenter Raumvektor des DNN kodiert sind.
  • In einem oder mehreren Ausführungsbeispielen kann bestärkendes Lernen, das zum Trainieren eines Richtlinien-Netzwerks verwendet wird, eine Wertfunktion anwenden, die zumindest basierend auf einem oder mehreren der vom DNN vorhergesagten Zustände der Umgebung bewertet werden kann, um den vom MLM gemachten Vorhersagen eine oder mehrere Punkte zuzuweisen. Beispielsweise können Belohnungen mit einem oder mehreren Zielen des Richtlinien-Netzwerks assoziiert sein und Strafen können mit Kollisionen oder anderen vorhergesagten oder inferenzierten Zuständen des Netzwerks assoziiert sein. In einem oder mehreren Ausführungsbeispielen kann die Wertfunktion eine oder mehrere Zustandswertfunktionen und/oder q-Funktionen enthalten, und die Zustände der Wertfunktion können Zeiten und Orten im latenten Raum des DNN entsprechen. In einem oder mehreren Ausführungsbeispielen kann das bestärkende Lernen zumindest teilweise unter Verwendung eines Algorithmus zur Bewertung von Akteuren implementiert werden. Zum Beispiel kann das Richtlinien-Netzwerk als Akteur und ein Wertfunktionsnetzwerk, das zur Vorhersage der Werte der Wertfunktion trainiert wurde, als Bewerter agieren.
  • Sobald das Richtlinien-Netzwerk und/oder eine Wertfunktion ausreichend trainiert ist, kann das Richtlinien-Netzwerk und/oder die Wertfunktion zur Planung und/oder Steuerung eines autonomen Fahrzeugs in realen Situationen verwendet werden. Beispielsweise kann das Netzwerk bzw. können die Netzwerke verwendet werden, um Vorhersagen zu treffen (z.B. Einzelbild für Einzelbild), die von einem Bewegungsplaner zur Steuerung des Fahrzeugs verwendet werden können. Beispielsweise kann ein Richtlinien-Netzwerk eine oder mehrere Trajektorien für einen oder mehrere Akteure (z.B. ein Objekt und/oder das autonome Fahrzeug) basierend auf einem Zustand der Umgebung vorhersagen, der in das DNN eingegeben wird. Der Bewegungsplaner kann die entsprechende(n) vorhergesagte(n) Trajektorie(n) als eine Trajektorie für das Fahrzeug verwenden und/oder eine oder mehrere Trajektorien für das Fahrzeug bestimmen und/oder bewerten. Zusätzlich oder alternativ kann, wenn ein Wertfunktionsnetzwerk vorgesehen ist, das Wertfunktionsnetzwerk verwendet werden, um eine oder mehrere Trajektorien für das Fahrzeug zu bestimmen und/oder zu bewerten. In einem oder mehreren Ausführungsbeispielen, in denen Trajektorien vorhergesagt werden, kann die Trajektorie unter Verwendung eines klassischen mechanischen Bewegungsalgorithmus erweitert werden, um eine erweiterte Trajektorie zu generieren (z.B. während des Trainings und/oder des Einsatzes). In einem oder mehreren Ausführungsbeispielen kann der klassische mechanische Bewegungsalgorithmus die Trajektorie in einer Bewegungsrichtung des Akteurs basierend auf der Geschwindigkeit, der Beschleunigung und/oder anderen Ausgaben, die von dem/den MLM vorhergesagt wurden, erweitern. Der klassische Teil kann weniger rechenintensiv sein als der/die MLM-vorgesagte(n) Teil(e) der Trajektorie und/oder kann kürzere MLM-basierte Vorhersagen ermöglichen, da die Genauigkeit dieser Vorhersagen mit der Zeit abnehmen kann. Weiter kann die erweiterte Trajektorie leichter von einem klassischen Planer und/oder Steuergerät des Fahrzeugs verwendet werden.
  • In mindestens einem Ausführungsbeispiel kann das DNN zumindest teilweise unter Verwendung einer oder mehrerer überwachter Lerntechniken trainiert werden, zu denen (beispielsweise und ohne Einschränkung) das Imitationslernen gehören kann. Ein möglicher Nachteil des traditionellen Nachahmungslernens ist, dass konventionelle Implementierungen oft Schwierigkeiten haben, seltene und/oder unsichere Ereignisse zu behandeln. Diese seltenen und/oder unsicheren Ereignisse werden in den Trainingsdaten möglicherweise nicht richtig erfasst, so dass das Modell nur unzureichend auf die seltenen und/oder unsicheren Ereignisse vorbereitet ist. Beispiele für solche seltenen und/oder unsicheren Ereignisse sind z. B. das Auffahren auf ein Fahrzeug oder starkes Bremsen, das zu Kollisionen führen kann. Um diese Probleme anzugehen, verwenden eine oder mehrere Ausführungsbeispiele der Offenbarung ein modellbasiertes Framework für bestärkendes Lernen und formulieren das Fahrproblem als Markov Decision Process (MDP) mit dem DNN als Übergangsmodell. Ausführungsbeispiele der vorliegenden Offenbarung können ein zusätzliches Richtlinien-Netzwerk trainieren, um Ego-Aktionen zu produzieren.
  • Ausführungsbeispiele der vorliegenden Offenbarung können so besser darauf vorbereitet sein, diese seltenen und/oder unsicheren Ereignisse (z. B. durch scharfes Bremsen veranlasste Auffahrunfälle und Kollisionen) zu bewältigen, die für herkömmliche Lösungen der adaptiven Geschwindigkeitsregelung (ACC) schwierig waren. Eine Iteration kann beispielsweise eine Vielzahl von Fahrzeugen umfassen, darunter ein Führungsfahrzeug, ein Nachbarfahrzeug und das Ego-Fahrzeug. Für die Simulation kann ein zufälliger initialer Zustand verwendet werden. Das Nicht-Ego-Fahrzeug kann durch ein Vorhersagenetzwerk gesteuert werden, während das Ego-Fahrzeug durch das Richtlinien-Netzwerk des bestärkenden Lernens gesteuert werden kann. In einem Beispiel für ein seltenes und/oder unsicheres Ereignis kann das Nachbarfahrzeug eine Einfädelungsbewegung ausführen, wenn es eine Lücke zwischen dem führenden Fahrzeug und dem Ego-Fahrzeug feststellt. In einem anderen Beispiel für ein seltenes und/oder unsicheres Ereignis führt das führende Fahrzeug eine zufällige Vollbremsung aus.
  • Ausführungsbeispiele der vorliegenden Offenbarung können eine Strategie erlernen, die den Zustand zu einem bestimmten Zeitpunkt einer bestimmten Aktion zuordnet, z. B. einer Beschleunigung des Ego-Fahrzeugs. Eine Aufgabenbelohnung kann durch eine Summe von manuell entworfenen Belohnungsausdrücken wie Abstand zum führenden Fahrzeug, Beschleunigungsänderungen usw. sowie durch einen dünnbesetzten Strafausdruck definiert werden, der die seltenen Ereignisse wie Zusammenstöße und Kollisionen berücksichtigt. Die trainierte RL-Politik kann so über Iterationen lernen, so zu planen, dass der Abstand verringert und Zusammenstöße vermieden werden, und eine langsamere Geschwindigkeit beizubehalten und künftige harte Bremsungen zu vermeiden.
  • In einigen Ausführungsbeispielen der vorliegenden Offenbarung kann das DNN einen Soft-Actor-Critic-Algorithmus (SAC) verwenden, um die Richtlinien- und Critic-Netzwerke zu trainieren, wobei die Stammgewichte konstant gehalten werden. Ein latenter Vektor kann in drei voll gefaltete Schichten eingespeist werden, um Merkmale zu extrahieren, wobei jedes der Richtlinien- und Bewertungs-Netzwerke ein dreischichtiges Multilayer Perceptron (MLP) sein kann. Als Beispiel kann ein MDP-Diskontierungsfaktor verwendet werden, z. B. (ohne Einschränkung) 0,95. Die ACC-Belohnungsfunktion kann die Änderungen der Beschleunigung und der Geschwindigkeit sowie den Abstand zum führenden Fahrzeug bezeichnen und kann so eingestellt werden, dass in realen Szenarien ein gleichmäßiges Folgen erreicht wird. Verschiedene Iterationen können mit randomisierten initialen Bedingungen beginnen. Eine Iteration kann enden, wenn eine Kollision oder ein Einschneiden mit einer aufgabenspezifischen Strafe erfolgt oder die maximale Anzahl von Iterationsschritten (z. B. achtundvierzig) oder ein anderes Kriterium erreicht wird.
  • 1A ist ein Beispiel für ein Modelltrainingssystem 100, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Es ist zu verstehen, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu den gezeigten oder anstelle von diesen verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsbeispielen können die hierin beschriebenen Systeme, Verfahren und Prozesse unter Verwendung ähnlicher Komponenten, Merkmale und/oder Funktionen wie die des Beispiels eines autonomen Fahrzeugs 1100 der 11A-11D, dem Beispiel-Rechengerät 1200 von 12 und/oder dem Beispiel-Datenzentrum 1300 von 13.
  • 1A zeigt das Modelltrainingssystem 100, das verwendet werden kann, um ein Richtlinien-MLM 106 unter Verwendung eines trainierten Vorhersage-MLM 104 zu trainieren, um ein Weltmodell zu definieren. Als Ausführungsbeispiel kann das Modelltrainingssystem 100 einen iterativen Ansatz zum Trainieren des Richtlinien-MLM 106 implementieren; in einer oder mehreren Ausführungsbeispielen kann ein iterativer Ansatz auch zum Trainieren einer Wertfunktion MLM 108 verwendet werden. Eine Iteration kann beinhalten, dass die Trainings-Engine 112 Simulationsdaten 102, die unter Verwendung eines Simulators 116 generiert wurden, auf das Vorhersage-MLM 104 anwendet, um Ausgabedaten zu generieren. Das Richtlinien-MLM 106 kann Daten verwenden, die der Ausgabe des Vorhersage-MLM 104 entsprechen, um eine oder mehrere Vorhersagen zu generieren, die einer oder mehreren Aktionen für ein Fahrzeug, wie das Fahrzeug 1100, entsprechen. Das Wertfunktions-MLM 108 kann auch Daten verwenden, die der Ausgabe des Vorhersage-MLM 104 entsprechen, um eine oder mehrere Vorhersagen zu generieren, die einer oder mehreren Bewertungen für die eine oder mehrere Aktionen entsprechen, die unter Verwendung des Richtlinien-MLM 106 vorhergesagt wurden. Ein Weltzustandsdekodierer 110 kann auch Daten verwenden, die der Ausgabe des Vorhersage-MLM 104 entsprechen, um Eingaben an die Trainings-Engine 112 zu liefern. Zum Beispiel kann der Dekodierer 110 einen latenten Raum des Vorhersage-MLMs 104 in den metrischen realen Raum dekodieren. Die Trainings-Engine 112 kann die dekodierten Daten verwenden, um die Leistung des Richtlinien-MLM 106 und/oder der Wertfunktion MLM 108 zu bewerten und einen oder mehrere Parameter davon zu aktualisieren. Die Trainings-Engine 112 kann zusätzlich oder alternativ die dekodierten Daten verwenden, um einen Weltzustand 118 zu definieren, der verwendet wird, um die Simulationsdaten 102 für eine nachfolgende Iteration zu generieren.
  • In einem oder mehreren Ausführungsbeispielen kann die Trainings-Engine 112 die Leistung des Richtlinien-MLM 106 (das in mindestens einem Ausführungsbeispiel auf den von der Trainings-Engine 112 bereitgestellten Zieldaten 114 basieren kann) und/oder des Wertfunktions-ML 108 zumindest basierend auf den von einem oder mehreren dieser MLMs generierten Ausgabedaten bewerten. Basierend auf der Bewertung (Scoring) kann das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 aktualisiert oder überarbeitet werden (z.B. unter Verwendung von Backpropagation und/oder anderen geeigneten MLM-Trainingstechniken).
  • In einem oder mehreren Ausführungsbeispielen kann die Trainings-Engine 112 aktualisierte Simulationsdaten 102 und/oder aktualisierte Zieldaten 114 für eine nachfolgende Iteration des Trainings bereitstellen. Die aktualisierten Simulationsdaten 102 und/oder die aktualisierten Zieldaten 114 können direkt oder indirekt vom Simulator 116 bereitgestellt werden und können den Weltzustand 118 widerspiegeln. Der Simulator 116 kann eine Applikation enthalten, die den Weltzustand 118 zumindest basierend auf Ausgaben des Vorhersage-MLM 104 speichert und modelliert, was der Simulator 116 nutzen kann, um eine genaue Simulation der realen Bedingungen zu liefern. Beispielsweise kann der Weltzustand 118 Orte, Attribute und/oder andere Vorhersagen für einen oder mehrere Akteure aufzeichnen, die von der Vorhersage-MLM 104 zumindest basierend auf einem früheren Weltzustand 118 gemacht wurden, der durch die Simulationsdaten 102 kodiert wurde. In einem oder mehreren Ausführungsbeispielen kann die Trainings-Engine 112 ein oder mehrere physikalische Modelle und/oder Heuristiken verwenden, um einen oder mehrere der Akteure zu steuern und die Orte, Attribute und/oder andere Informationen über den Zustand der Akteure anzupassen, die im Weltzustand 118 aufgezeichnet und/oder durch die Simulationsdaten 102 indiziert werden. Zum Beispiel kann zumindest ein Akteur zumindest teilweise unter Verwendung des Simulators 116 gesteuert werden, wobei das Vorhersage-MLM 104 verwendet wird, um durch den/die Akteur(e) veranlasste Änderungen des Weltzustands vorherzusagen (z.B. Vorhersage von Trajektorien eines oder mehrerer anderer Akteure basierend auf dem gesteuerten oder beeinflussten Akteur).
  • In einem oder mehreren Ausführungsbeispielen kann die Trainings-Engine 112 eine Kosten- oder Wertmetrik über eine beliebige Anzahl von Iterationen des Vorhersage-MLM 104 berechnen, das verwendet wird, um zumindest einen Teil des Weltzustands und/oder des Simulators 116, der den Akteur kontrolliert oder beeinflusst, vorherzusagen. Diese Kosten- oder Wertmetrik kann verwendet werden, um das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 zu aktualisieren. Beispielsweise kann die Wertmetrik verwendet werden, um das Richtlinien-MLM 106 zu trainieren, um zu versuchen, die Wertmetrik zu maximieren, und kann verwendet werden, um das Wertfunktions-MLM 108 zu trainieren, um die Wertmetrik vorherzusagen. Auf diese Weise kann der Simulator 116 verwendet werden, um gefährliche oder unpraktische Szenarien zu simulieren oder um das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 anderweitig zu trainieren, ohne dass reale Daten benötigt werden.
  • In einem oder mehreren Ausführungsbeispielen kann der Simulator 116 und/oder die Trainings-Engine 112 zumindest teilweise unter Verwendung von Software, z. B. eines Toolkits, implementiert werden, das eine Umgebung und ein Framework für die Simulation der Umgebung über eine Vielzahl von Zeitschritten bereitstellt, wobei z. B. eine Physik-Engine und/oder von der Vorhersage-MLM 104 gemachte Vorhersagen verwendet werden. In einem oder mehreren Ausführungsbeispielen umfasst der Simulator 116 ein RL-Fitnessstudio. Ein nicht einschränkendes Beispiel für eine solche Software ist OpenAI Gym. In einem oder mehreren Ausführungsbeispielen kann jeder Zeitschritt einer oder mehreren Iterationen des Trainings des Richtlinien-MLM 106 und/oder des Wertfunktions-MLM 108 entsprechen. In einem oder mehreren Ausführungsbeispielen kann jeder Zeitschritt einem oder mehreren Punkten auf einer oder mehreren Trajektorien entsprechen, die unter Verwendung des Vorhersage-MLM 104 für einen oder mehrere Akteure vorhergesagt wurden. In einem oder mehreren Ausführungsbeispielen kann jeder Zeitschritt einem Zustand entsprechen, der von der Trainings-Engine 112 unter Verwendung der Wertmetrik bewertet werden kann.
  • In einem oder mehreren Ausführungsbeispielen kann das Vorhersage-MLM 104 als Eingabe einen oder mehrere Orte und/oder andere Attribute (z.B. Geschwindigkeit, Beschleunigung, Trajektorie usw.) für einen oder mehrere Akteure erhalten, die in den Simulationsdaten 102 kodiert sind. In verschiedenen Beispielen kann es sich bei dem einen oder mehreren Akteuren um das Ego-Fahrzeug und/oder ein oder mehrere andere Fahrzeuge oder Objekte handeln (z.B. ein mobiles Objekt und/oder einen Akteur wie einen Fußgänger, einen Radfahrer, ein Tier usw.). Das Vorhersage-MLM 104 kann die Eingaben verwenden, um eine oder mehrere Vorhersagen in Bezug auf den einen oder die mehreren Orte und/oder andere Attribute (z.B. Geschwindigkeit, Beschleunigung, Trajektorie usw.) für den einen oder die mehreren Akteure zu treffen. Nicht einschränkende Beispiele für solche Vorhersagen können einen oder mehrere zukünftige Werte eines dieser Attribute für einen oder mehrere zukünftige Zeitschritte beinhalten. Als Ausführungsbeispiel und ohne Einschränkung können in einer oder mehreren Ausführungsformen das Vorhersage-MLM 104, das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 als DNN 416 implementiert werden oder ein solches weiter enthalten, wie in 4 beschrieben.
  • 2 ist ein Diagramm, das gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung eine Visualisierung 200 von Beispieleingaben und -ausgaben des Vorhersage-MLM 104 zeigt. Die Visualisierung 200 zeigt, wie eine Reihe von Eingaben 202 dem Vorhersage-MLM 104 zugeführt werden kann, um eine Reihe von Ausgaben 204 zu erzeugen. Die Eingaben 202 sind in 2 unter Verwendung eines Top-Down-Bildes der Umgebung beispielhaft und ohne Einschränkung angegeben. In einem oder mehreren Ausführungsbeispielen können die Eingaben in einem Koordinatenraum angegeben werden, der sich auf die Draufsicht oder eine andere Ansicht bezieht. Die Orte von Objekten können durch Quadrate angezeigt werden (z.B. jedes entspricht einem Zeitschritt), von denen eines oder mehrere mit einem bestimmten Akteur assoziiert und/oder ihm zugeordnet sein können. So werden beispielsweise die Orte von Objekten in schwarzer Farbe dargestellt, während die entsprechenden Orte in der Vergangenheit in grauer Farbe angezeigt werden (wobei weiter zurückliegende Orte in hellerem Grau dargestellt werden). Stationäre Objekte können in Schwarz ohne entsprechende Graustufen dargestellt werden. Mit diesem Satz von Eingaben 202 kann das Vorhersage-MLM 104 die aktuellen und vergangenen Orte eines oder mehrerer Akteure (zu denen auch ein Ego-Fahrzeug gehören kann) berücksichtigen. Geschwindigkeiten und Beschleunigungen können durch Abstände zwischen Zeitschritten indiziert und/oder in einen oder mehrere Zeitschritte kodiert werden.
  • Das Vorhersage-MLM 104 kann den Satz von Eingaben 202 verwenden, um eine Trajektorie für jeden Akteur zu inferenzieren, die durch den Satz von Ausgaben 204 angegeben wird. Als Beispiel zeigt 2 eine visuelle Repräsentation von Beispieltrajektorien in der Top-Down-Ansicht, gemäß einiger Ausführungsbeispiele der vorliegenden Offenbarung. Der Satz von Ausgaben 204 kann Ortskoordinaten und/oder andere assoziierte vorhergesagte Attribute (z.B. die gleichen oder andere als die Eingabeattribute) für eine beliebige Anzahl von Zeitschritten enthalten. Zum Beispiel kann in 2 ein zusammenhängender Pfad von Ort-Punkten einer vorhergesagten Trajektorie für einen Akteur entsprechen, wobei jeder Punkt einem entsprechenden Zeitschritt entspricht. Ein dunklerer Gradient, der für den Satz von Ausgaben 204 angezeigt wird, kann auf eine geringere Unsicherheit in den Vorhersagen hinweisen, während ein heller Gradient eine größere Unsicherheit anzeigen kann. Die Trainings-Engine 112 und/oder der Simulator 116 können jede dieser verschiedenen Informationen mit Karteninformationen assoziieren (z.B. nachdem die Dekodierung unter Verwendung des Weltzustandsdekodierers 110 durchgeführt wurde), wie z.B. Fahrspurinformationen, die durch die Fahrspurlinien und Trajektorien für verschiedene Akteure zugeordnet werden.
  • In einem oder mehreren Ausführungsbeispielen können Ausgabedaten des Vorhersage-MLM 104 verwendet werden, um ein oder mehrere andere MLMs zu trainieren, wie das Richtlinien-MLM 106 und das Wertfunktions-MLM 108. In mindestens einem Ausführungsbeispiel können ein oder mehrere Teile des Richtlinien-MLM 106 und/oder des Wertfunktions-MLM 108 eine Komponente des Vorhersage-MLM 104 sein. Beispielsweise kann das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 zumindest teilweise einen oder mehrere Köpfe oder Dekodierer des Vorhersage-MLM 104 enthalten, wie in 3 weiter beschrieben.
  • 3 ist ein Diagramm, das die Kodierung und Dekodierung eines latenten Raums 302 des Prädiktions-MLM 104 gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung darstellt. 3 zeigt, dass das Prädiktions-MLM 104 (z.B. ein neuronales Netzwerk) einen Kodierer 304 zum Kodieren der Simulationsdaten 102 in den latenten Raum 302 enthalten kann. 3 zeigt auch, dass das Vorhersage-MLM 104 einen oder mehrere Dekodierer enthalten kann, wie z. B. einen Dekodierer 306A und/oder einen Dekodierer 306B zum Dekodieren des latenten Raums 302, um eine oder mehrere verschiedene Ausgaben zu erzeugen. Zum Beispiel können der Dekodierer 306A und der Dekodierer 306B zumindest einem Teil des Richtlinien-MLM 106 entsprechen. Wie gezeigt, kann der Dekodierer 306A ein oder mehrere Attribute eines oder mehrerer anderer Objekte oder Akteure vorhersagen, und der Dekodierer 306B kann ein oder mehrere Attribute eines Ego-Akteurs, wie des Fahrzeugs 1100, vorhersagen. Zusätzlich oder alternativ kann die Wertfunktions-MLM 108 ebenfalls zumindest teilweise unter Verwendung eines Dekodierers des latenten Raums 302 implementiert werden.
  • Das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 müssen jedoch keine Komponente des Vorhersage-MLM 104 sein und können von dem Vorhersage-MLM 104 getrennt sein. Beispielsweise kann in einem oder mehreren Ausführungsbeispielen der Weltzustandsdekodierer 110 und/oder eine andere Nachverarbeitungseinheit verwendet werden, um Eingaben für das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 zu generieren. Somit kann in mindestens einem Ausführungsbeispiel das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 basierend auf dem latenten Raum 302 des Vorhersage-MLM 104 arbeiten, ohne zumindest einen Teil des latenten Raums zu empfangen und/oder zu dekodieren.
  • In einem oder mehreren Ausführungsbeispielen kann das Richtlinien-MLM 106 trainiert werden, um eine zielbasierte Vorhersage zumindest basierend auf den Ausführungsdaten des Vorhersage-MLM 104 zu treffen. Zum Beispiel können die Zieldaten 114 von der Trainings-Engine 112 verwendet werden, um ein oder mehrere Ziele für das Richtlinien-MLM 106 zu kodieren. Das Richtlinien-MLM 106 kann dann von der Trainings-Engine 112 trainiert werden, um Vorhersagen zu treffen, um ein oder mehrere entsprechende Ziele zu erreichen. Zum Beispiel können die Zieldaten 114 dem Richtlinien-MLM 106 und/oder dem Wertfunktions-MLM 108 zur Verwendung bei der Erstellung von Schlussfolgerungen zur Verfügung gestellt werden. In mindestens einem Ausführungsbeispiel müssen die Zieldaten 114 jedoch nicht verwendet werden, um das Richtlinien-MLM 106 und/oder das Wertfunktions-MLM 108 zu trainieren, um zielbasierte Vorhersagen zu treffen. Vielmehr können die ein oder mehreren Ziele durch die Wertfunktion erfasst werden, die verwendet wird, um das Richtlinien-MLM 106 und/oder die Wertfunktions-MLM 108 zu trainieren.
  • Wie hierin beschrieben, kann das Richtlinien-MLM 106 trainiert werden, um eine oder mehrere Vorhersagen zu treffen, die einer oder mehreren Aktionen entsprechen, die von einem oder mehreren Akteuren durchgeführt werden sollen. Zum Beispiel kann das Richtlinien-MLM 106 eine Trajektorie und/oder einen Ort vorhersagen, den ein Akteur, wie das Fahrzeug 1100, durchfahren soll. Dabei kann das Richtlinien-MLM 106 das eine oder die mehreren Ziele berücksichtigen. Beispiele für Ziele, die optional in den Zieldaten 114 kodiert werden können, umfassen die Fähigkeit, einen gegebenen Pfad, eine Spur, eine Position oder ein anderes Akteursattribut und/oder Aspekte eines Weltzustands (z.B. Geschwindigkeit, Beschleunigung, Orientierung, Pose usw.) erfolgreich zu erreichen oder zu erreichen, die Fähigkeit, eine Kollision erfolgreich zu vermeiden, und/oder die Fähigkeit, ein Attribut oder einen Zustand relativ zum Attribut oder Zustand eines anderen Akteurs erfolgreich zu erreichen (z.B. vor dem anderen Akteur zu fahren). Das Richtlinien-MLM 106 kann also trainiert werden, um Vorhersagen zu treffen, die darauf abzielen, ein oder mehrere Attribute und/oder Weltzustände zu erreichen, so dass das/die Ziel(e) erfüllt werden können.
  • Wie hierin beschrieben, kann die Trainings-Engine 112 die Leistung des Richtlinien-MLM 106 und/oder der Wertfunktions-MLM 108 bewerten und eines oder mehrere dieser Netzwerke unter Verwendung von bestärkendem Lernen entsprechend aktualisieren. Zum Beispiel kann die Trainings-Engine 112 die Wertfunktion verwenden, um einen oder mehrere Werte zu bestimmen, die die Leistung des Richtlinien-MLM 106 und/oder der Wertfunktions-MLM 108 über einen oder mehrere Zeitschritte und/oder Iterationen einer Inkrementierung des Weltzustands 118 unter Verwendung des Vorhersage-MLM 104 und/oder des Simulators 116 anzeigen. Dies kann beinhalten, dass die Trainings-Engine 112 eine oder mehrere Punktzahlen (engl. scores, dt. auch Bewertungen) für eine oder mehrere von der Richtlinien-MLM 106 und/oder der Wertfunktions-MLM 108 gemachte Vorhersagen berechnet oder zuweist. Basierend auf der (den) Punktzahl(en) kann die Trainings-Engine 112 bestimmen, ob ein oder mehrere Parameter der Richtlinien-MLM 106 und/oder der Wertfunktions-MLM 108 aktualisiert oder überarbeitet werden sollten. Die Trainings-Engine 112 kann dann den einen oder die mehreren zu aktualisierenden oder zu überarbeitenden Parameter anweisen, ändern oder auf andere Weise eine Indikation liefern. Der eine oder die mehreren Parameter des zumindest einen MLM können dann zumindest basierend auf der einen oder den mehreren Bewertungen aktualisiert werden.
  • Wie hierin beschrieben, kann die Wertfunktion zumindest basierend auf der Trainings-Engine 112 berechnet werden, die den Weltzustand 118 und/oder die von dem Vorhersage-MLM 104 bezüglich des Weltzustands 118 gemachten Vorhersagen auswertet, um ein oder mehrere Ereignisse unter Verwendung der Ausgabe(n) des Vorhersage-MLM 104 zu bestimmen oder zu identifizieren. Zum Beispiel kann die Trainings-Engine 112 aus einem oder mehreren nachfolgenden Zuständen der Umgebung eine Kollision des Ego-Fahrzeugs (und/oder anderer Akteure) in der Umgebung bestimmen. Die eine oder mehreren Bewertungen der von der Trainings-Engine 112 berechneten Wertfunktion können auf dem einen oder den mehreren Ereignissen basieren, z.B. zumindest basierend auf dem Bestimmen der Kollision (z.B. kann die Richtlinien-MLM 106 basierend auf dem Bestimmen, dass eine Kollision auftreten würde oder wahrscheinlicher ist, bestraft werden). In einem oder mehreren Ausführungsbeispielen kann ein Ereignis einem von dem Richtlinien-MLM 106 zu erreichenden Ziel entsprechen oder dieses repräsentieren, wie hierin beschrieben (z.B. einen Ort erreichen, einen Weltzustand oder ein Attribut erreichen usw.). In einem oder mehreren Ausführungsbeispielen kann die Wertfunktion zumindest basierend auf einer Nähe zu dem Ereignis berechnet werden (z.B. eine Entfernung zu einem gegebenen Ort, eine Entfernung zu einem Zielattributwert usw.). In einem oder mehreren Ausführungsbeispielen kann die Wertfunktion eine oder mehrere Zustandswertfunktionen und/oder q-Funktionen enthalten, und die Zustände der Wertfunktion können Zeiten und Orten im latenten Raum des DNN (z.B. den Zeitschritten) entsprechen. In einem oder mehreren Ausführungsbeispielen kann das bestärkende Lernen zumindest teilweise unter Verwendung eines akteursbewertenden Algorithmus implementiert werden. Zum Beispiel kann das Richtlinien-MLM 106 als Akteur und das Wertfunktions-MLM 108, das zur Vorhersage der Werte der Wertfunktion trainiert wurde, zur Bewertung dienen.
  • Wie hierin beschrieben, kann die Trainings-Engine 112 den Simulator 116 bei der Bewertung der Leistung des Vorhersage-MLM 104 und/oder des Wertfunktions-MLM 108 verwenden. Zum Beispiel kann die Trainings-Engine 112 den Simulator 116 verwenden, um Ereignisse und/oder Attribute im Weltzustand 118 zu detektieren. In einem oder mehreren Ausführungsbeispielen kann der Simulator 116 eine physikbasierte Engine (Physik-Engine) verwenden, um eines oder mehrere der Ereignisse und/oder Attribute zu bestimmen und/oder zu detektieren, die zum Berechnen der Wertfunktion für einen oder mehrere Zustände oder Zeitschritte verwendet werden. Dies kann die Vorwärtsprojektion eines oder mehrerer Aspekte des Weltzustands 118 (z.B. über eine beliebige Anzahl von Iterationen oder Zeitschritten) unter Verwendung zumindest eines Teils der einen oder mehreren Aktionen umfassen, die unter Verwendung des Richtlinien-MLM 106 vorhergesagt wurden. Zusätzlich oder alternativ kann der Simulator 116 das Vorhersage-MLM 104 verwenden, um einen oder mehrere Aspekte des Weltzustands 118 (z.B. über eine beliebige Anzahl von Iterationen oder Zeitschritten) vorwärts zu projizieren, wobei zumindest ein Teil der einen oder mehreren Aktionen verwendet wird, die unter Verwendung des Richtlinien-MLM 106 vorhergesagt wurden. In einem oder mehreren Ausführungsbeispielen kann das Vorhersage-MLM 104 vom Simulator 116 verwendet werden, um den Verkehr schrittweise zu steuern und die Akteure im Weltzustand 118 gemäß den Vorhersagen für jede Iteration zu bewegen. Der Simulator 116 kann die Welt gemäß dem aktualisierten Weltzustand 118 neu zeichnen, Kollisionsprüfungen durchführen und die Dynamik der Akteure zur Verwendung in der Wertfunktion bewerten. In mindestens einem Ausführungsbeispiel kann der Simulator 116 zwischen einem oder mehreren der Schritte interpolieren, um Auswertungen mit höherer Frequenz bereitzustellen. In einem oder mehreren Ausführungsbeispielen kann der Simulator 116 bei der Durchführung der Vorwärtsprojektion einen oder mehrere Akteure unter Verwendung der Physik-Engine und/oder Heuristiken steuern.
  • In einem oder mehreren Ausführungsbeispielen kann ein Zyklus oder eine Iteration die Bereitstellung der Simulationsdaten 102, die Erstellung einer oder mehrerer Vorhersagen unter Verwendung des Vorhersage-MLM 104, des Richtlinien-MLM 106 und des Wertfunktions-MLM 108, die Auswertung der vom Richtlinien-MLM 106 und/oder der Wertfunktions-MLM 108 gemachten Vorhersagen und/oder die Aktualisierung eines oder mehrerer Parameter des Richtlinien-MLM 106 und/oder der Wertfunktions-MLM 108 basierend auf der Auswertung umfassen. Bei oder während jeder Iteration kann der Simulator 116 den Weltzustand 118 inkrementell vorwärts bewegen (z.B. um einen oder mehrere Zeitschritte) und einen aktualisierten Satz der Simulationsdaten 102 und/oder der Zieldaten 114 für eine weitere Iteration des Trainings bereitstellen, bis das Richtlinien-MLM 106 und/oder die Wertfunktions-MLM 108 konvergieren.
  • 1B ist ein Diagramm, das ein Beispiel für eine Vorhersage zeigt, die bei der Planung und Steuerung des autonomen Fahrzeugs 1100 verwendet wird, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Wie dargestellt, kann das Fahrzeug 1100 einen Routenplaner 150, einen Fahrspurplaner 152, den Planungsverwalter 154 und einen Controller 156 verwenden, um eine oder mehrere Operationen zur Planung und Steuerung durchzuführen. Eine oder mehrere dieser Komponenten können zumindest teilweise in einem hierin erörterten Drive-Stack 428 enthalten sein.
  • 1B zeigt ein Aktions-MLM(s) 180, das sich auf eine beliebige Kombination des Richtlinien-MLM 106, des Wertfunktions-MLM 108 oder des Vorhersage-MLM 104 beziehen kann. Zum Beispiel kann die vorhergesagte Information über den Akteur 182 für einen Ego-Akteur einer vorhergesagten Aktion (z.B. Trajektorie) entsprechen, die durch das Richtlinien-MLM 106 und/oder eine vorhergesagte Wertfunktions-MLM 108 bestimmt wurde. Andere vorhergesagte Akteursinformationen 184 können für einen oder mehrere andere Akteure einer entsprechenden vorhergesagten Aktion (z.B. Trajektorie) und/oder einem Attribut entsprechen, das durch das Vorhersage-MLM 104 und/oder das Richtlinien-MLM 106 (z.B. den Dekodierer 306A) bestimmt wurde. Wenn es in dem autonomen Fahrzeug 1100 implementiert ist, kann das Aktions-MLM 180 verwendet werden, um die vorhergesagten Akteursinformationen 182 und/oder die anderen vorhergesagten Akteursinformationen 184 vorherzusagen, um einen Planungsverwalter 154 des Fahrzeugs 1100 zu informieren.
  • Der Routenplaner 150 kann einen geplanten Pfad für das Fahrzeug 1100 generieren, der auf verschiedenen realen oder simulierten Eingaben basiert. Der geplante Pfad kann Wegpunkte (z.B. GPS-Wegpunkte), Ziele, Koordinaten (z.B. kartesische, polare oder andere Weltkoordinaten) oder andere Referenzpunkte enthalten. Die Bezugspunkte können Koordinaten relativ zu einem Ursprungspunkt des Fahrzeugs 1100 usw. angeben. Die Bezugspunkte können eine bestimmte Entfernung in der Zukunft für das Fahrzeug 1100 repräsentieren, wie z.B. eine Anzahl von Häuserblocks, eine Anzahl von Kilometern, eine Anzahl von Fuß, eine Anzahl von Zoll, eine Anzahl von Meilen, usw., die als Ziel für den Fahrspurplaner 152 verwendet werden können.
  • Der Fahrspurplaner 152 kann einen Fahrspurgraphen, die Posen von Objekten innerhalb des Fahrspurgraphen und/oder einen Zielpunkt und eine Zielrichtung in der Entfernung in der Zukunft vom Routenplaner als Eingaben verwenden. Der Zielpunkt und die Zielrichtung können dem am besten passenden fahrbaren Punkt und der besten fahrbaren Richtung im Fahrspurgraphen zugeordnet werden (z.B. basierend auf GNSS und/oder Kompassrichtung). Ein Graphensuchalgorithmus kann dann auf dem Fahrspurgraphen von einer aktuellen Kante im Fahrspurgraphen aus ausgeführt werden, um den kürzesten Pfad zum Zielpunkt zu finden.
  • Der Planungsverwalter 154 kann das Aktions-MLM 180 verwenden, um Bewegungen für das Ego-Fahrzeug und/oder andere Akteure in der Nähe des Ego-Fahrzeugs und/oder eine Wertmetrik für eine oder mehrere Aktionen des Ego-Fahrzeugs vorherzusagen. Der Planungsverwalter 154 kann einen Geschwindigkeitsprofilgenerator 158, einen Generator für eine Auswahl (engl. fan, dt. auch Fächer) von möglichen Querpfaden 160, einen Vorbegrenzer 162, einen Trajektorien-Bewerter 164 und einen Optimierer 166 umfassen. Der Geschwindigkeitsprofilgenerator 158 kann Geschwindigkeiten basierend auf dem seitlichen Abstand zwischen zwei oder mehr aufeinanderfolgenden Orten für den Akteur, geteilt durch ein Zeitintervall zwischen den aufeinanderfolgenden Orten, generieren. Die Geschwindigkeitsprofile können zumindest teilweise verwendet werden, um die zukünftigen Aktionen der assoziierten Akteure unter Verwendung des Aktions-MLM 180 vorherzusagen. Der Generator für eine Auswahl von Querpfaden 160 kann eine Auswahl von Querpfaden für ein Ego-Fahrzeug basierend auf den Vorhersagen des Aktions-MLM 180 generieren. Die Auswahl von Querpfaden können eine Indikation für wahrscheinliche seitliche (laterale) Bewegungen sein, die das Ego-Fahrzeug fortsetzen kann. Der Vorbegrenzer 162 kann die weniger wahrscheinlichen Ausgaben reduzieren, so dass unwahrscheinliche Pfade (z.B. drastische Geschwindigkeits- und/oder Richtungsänderungen) verworfen werden können, um den gesamte Rechenaufwand zu reduzieren. Trajektorien und/oder vorhergesagte andere Aktionen können in den Trajektorien-Bewerter 164 eingespeist werden. Der Trajektorie-Bewerter kann eine oder mehrere der Aktionen bewerten und ihnen Punktwerte zuweisen. Der Optimierer 166 kann zumindest basierend auf den Bewertungen, die unter Verwendung des Trajektorien-Bewerters 164 vorgenommen wurden, eine oder mehrere Operationen zur Steuerung des Fahrzeugs 1100 auswählen und/oder optimieren (z.B. eine Trajektorie basierend auf einem entsprechenden Punktwert auswählen und die Trajektorie zur Optimierung der einen oder mehreren Operationen zur Steuerung verwenden).
  • Das Steuergerät 156 kann die Steuerung des Fahrzeugs 1100 gemäß einem ausgewählten und/oder optimierten Pfad vom Optimierer 166 veranlassen. In einigen Ausführungsbeispielen kann das Steuergerät 156 die Aktionen des Fahrzeugs 1100, wie Beschleunigen, Bremsen, Wenden usw., direkt zu leiten. Zum Beispiel kann das Steuergerät 156 einen Bremsaktuator 1148, ein Antriebssystem 1150 und/oder eine Drosselklappe 1152, ein Lenksystem 1154 und/oder einen Lenkaktuator 1156 und/oder andere Komponenten des Fahrzeugs 1100 steuern (wie in 11A dargestellt). In anderen Ausführungsbeispielen kann das Steuergerät 156 die Aktionen des Fahrzeugs 1100 indirekt steuern, z.B. indem es eine Nachricht oder Anweisung an ein anderes System des Fahrzeugs 1100 sendet.
  • So kann der Planungsverwalter 154 die bekannten vergangenen Orte und die vorhergesagten zukünftigen Orte von Akteuren zusammensetzen und Trajektorien generieren und/oder bewerten, indem er das Aktions-MLM 180 verwendet, das von einem Drive-Stack 1128 des Fahrzeugs 1100 verwendet werden kann. In einer oder mehreren Ausführungsbeispielen kann eine Trajektorie, die unter Verwendung der Aktions-MLM(s) 180 vorhergesagt, generiert und/oder ausgewählt wurde, unter Verwendung eines klassischen mechanischen Bewegungsalgorithmus erweitert werden, wovon Beispiele unter Verwendung von 7 hierin beschrieben werden. Zum Beispiel kann der Planungsverwalter 154 zu Planungszwecken einen maximalen Zeitrahmen für eine Vorhersage verlängern, um von verschiedenen Komponenten des Fahrzeugs 1100 besser verwendet zu werden.
  • 4 zeigt ein beispielhaftes Datenflussdiagramm für einen Prozess 400 zur Vorhersage von Trajektorien eines oder mehrerer Akteure in einer Umgebung, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Es sollte verstanden werden, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der in 4 dargestellten verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Das Verfahren 400 umfasst das DNN 416, das dem Vorhersage-MLM 104, dem Richtlinien-MLM 106 und/oder dem Wertfunktions-MLM 108 von 1A entsprechen kann. Der Prozess 400 kann das Generieren und/oder Empfangen von Sensordaten 402 von einem oder mehreren Sensoren des Fahrzeugs 1100 umfassen. Die Sensordaten 402 können von dem Fahrzeug 1100 und innerhalb des Prozesses 400 verwendet werden, um zukünftige Trajektorien von einem oder mehreren Objekten oder Akteuren - wie anderen Fahrzeugen, Fußgängern, Radfahrern usw. - in der Umgebung. Die Sensordaten 402 können ohne Einschränkung Sensordaten 402 von jedem der Sensoren des Fahrzeugs 1100 (und/oder anderer Fahrzeuge oder Objekte, wie Robotergeräte, VR-Systeme, AR-Systeme usw., in einigen Beispielen) umfassen. Zum Beispiel, und mit Bezug auf 11A-11C können die Sensordaten 402 beispielsweise die Daten umfassen, die von einem oder mehreren GNSS-Sensoren (Global Navigation Satellite Systems) 1158 (z.B. Global Positioning System-Sensor(en)), RADAR-Sensor(en) 1160, Ultraschallsensor(en) 1162, LIDAR-Sensor(en) 1164, Inertial Measurement Unit (IMU)-Sensor(en) 1166 (z.B., Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 1196, Stereokamera(s) 1168, Weitwinkelkamera(s) 1170 (z.B. Fischaugenkameras), Infrarotkamera(s) 1172, Surround-Kamera(s) 1174 (z.B., 360-Grad-Kameras), Fern- und/oder Mitteldistanzkamera(s) 1198, Geschwindigkeitssensor(en) 1144 (z.B. zur Messung der Geschwindigkeit des Fahrzeugs 1100 und/oder der zurückgelegten Strecke) und/oder andere Sensortypen.
  • In einigen Beispielen können die Sensordaten 402 die Sensordaten umfassen, die von einem oder mehreren nach vorne gerichteten Sensoren, Seitensicht-Sensoren und/oder Rücksichts-Sensoren generiert werden. Diese Sensordaten 402 können zum Identifizieren, Detektieren, Klassifizieren und/oder Verfolgen der Bewegung von Objekten um das Fahrzeug 1100 herum in der Umgebung nützlich sein. In Ausführungsbeispielen kann eine beliebige Anzahl von Sensoren verwendet werden, um mehrere Sichtfelder (z.B. die Sichtfelder der Fernkameras 1198, der nach vorne gerichteten Stereokamera 1168 und/oder der nach vorne gerichteten Weitwinkelkamera 1170 von 11B) und/oder Sensorfelder (z.B. eines LIDAR-Sensors 1164, eines RADAR-Sensors 1160, usw.) einzubeziehen.
  • Die Sensordaten 402 können Bilddaten enthalten, die ein oder mehrere Bilder repräsentieren, Bilddaten, die ein Video repräsentieren (z.B. Schnappschüsse von Videos), und/oder Sensordaten, die Repräsentationen von Sensorfeldern von Sensoren repräsentieren (z.B. Tiefenkarten für LIDAR-Sensoren, ein Wertediagramm für Ultraschallsensoren, usw.). Wenn die Sensordaten 402 Bilddaten enthalten, kann jede Art von Bilddatenformat verwendet werden, wie zum Beispiel und ohne Einschränkung komprimierte Bilder wie in den Formaten Joint Photographic Experts Group (JPEG) oder Luminanz/Chrominanz (YUV), komprimierte Bilder als Frames, die aus einem komprimierten Videoformat wie H.264 /Advanced Video Coding (AVC) oder H.265/High Efficiency Video Coding (HEVC), Rohbilder, die beispielsweise von einem Red Clear Blue (RCCB), Red Clear (RCCC) oder einer anderen Art von Bildsensor stammen, und/oder andere Formate. Darüber hinaus können in einigen Beispielen die Sensordaten 402 innerhalb des Prozesses 400 ohne jegliche Vorverarbeitung verwendet werden (z.B. in einem rohen oder erfassten Format), während in anderen Beispielen die Sensordaten 402 einer Vorverarbeitung unterzogen werden können (z.B. Rauschausgleich, Entfernung des Mosaikeffekts, Skalierung, Zuschneiden, Vergrößerung, Weißabgleich, Tonkurvenanpassung usw., z.B. unter Verwendung eines Sensordaten-Vorprozessors (nicht gezeigt)). Wie hier verwendet, können sich die Sensordaten 402 auf unverarbeitete Sensordaten, vorverarbeitete Sensordaten oder eine Kombination davon beziehen.
  • Darüber hinaus kann der Prozess 400 das Generieren und/oder Empfangen von Kartendaten von einer Karte - wie einer HD-Karte 404 (die der HD-Karte 1122 von 11C ähnlich sein kann) - umfassen, auf die das Fahrzeug 1100 zugreifen kann und/oder die im Fahrzeug gespeichert ist. Die HD-Karte 404 kann in einigen Ausführungsbeispielen eine zentimetergenaue oder feinere Genauigkeit aufweisen, so dass sich das Fahrzeug 1100 bei präzisen Anweisungen, der Planung und der Lokalisierung auf die HD-Karte 404 verlassen kann. Die HD-Karte 404 kann Fahrspuren, Straßenbegrenzungen, Straßenform, Höhe, Neigung und/oder Kontur, Richtungsinformationen, Wartebedingungen, statische Objektorte und/oder andere Informationen repräsentieren. Als solches kann der Prozess 400 die Informationen aus der HD-Karte 404 - wie Orte und Formen von Fahrspuren - verwenden, um Eingaben 408 für DNN 416 zu generieren.
  • Zusätzlich zu oder alternativ zu den Sensordaten 402 und/oder der HD-Karte 404 kann der Prozess 400 das Generieren und/oder Empfangen (z.B. unter Verwendung der Sensordaten 402 und/oder der HD-Karte 404, in Ausführungsbeispielen) einer oder mehrerer Ausgaben von einem autonomen oder teilautonomen (z.B. ADAS) Fahrsoftware-Stack und/oder einer der verschiedenen in 1B gezeigten Komponenten umfassen. Beispielsweise können im Rahmen des Prozesses 400 zum Generieren der Eingaben 408 Informationen verwendet werden, die von einer Wahmehmungsschicht, einer Schicht zur Verwaltung des Weltmodells, einer Steuerungsschicht, einer Akteurschicht, einer Schicht zur Hindernisvermeidung und/oder anderen Schichten eines Software-Stacks generiert werden. Diese Informationen können Orte mit Freiraumgrenzen, Wartebedingungen, die Erkennung der Struktur von Kreuzungen, die Identifizierung des Fahrspurtyps, Informationen zur Straßenform, Informationen zur Objekterkennung und/oder -klassifizierung und/oder Ähnliches umfassen. Als solche können die Sensordaten 402, die HD-Karte 404 und/oder andere vom Fahrzeug 1100 zugewiesene Informationen verwendet werden, um die Eingaben 408 für das DNN 416 zu generieren.
  • In einigen nicht einschränkenden Ausführungsbeispielen können die Sensordaten 402, die Informationen aus der HD-Karte 404 und/oder andere Informationen (z.B. aus einem Drive-Stack) auf einen Perspektivenverschieber 406 angewendet werden, bevor sie als Eingabe 408 für das DNN 416 verwendet werden. Der Perspektivenverschieber 406 kann die Daten in Bezug auf einen der Akteure in der Umgebung, in Bezug auf einen Ort auf einer Straßenoberfläche und/oder in Bezug auf ein anderes durch die Daten repräsentiertes Merkmal ausrichten. In einigen Ausführungsbeispielen kann der Perspektivenverschieber 406 beispielsweise die Perspektive der Daten in Bezug auf einen Ort und/oder eine Ausrichtung des Fahrzeugs 1100 (z.B. eines Ego-Fahrzeugs oder eines Ego-Akteurs) verschieben. So können Orte von Akteuren oder Objekten, der Teil der HD-Karte 404 und/oder andere Informationen, die als Eingabe 408 verwendet werden sollen, relativ zum Fahrzeug 1100 verschoben werden (z.B. mit dem Ego-Fahrzeug 1100 in der Mitte, bei (x, y)-Koordinaten von (0, 0), wobei y eine Längsdimension ist, die sich von der Vorderseite bis zur Rückseite des Fahrzeugs erstreckt, und x eine seitliche Dimension ist, die senkrecht zu y steht und sich von links nach rechts des Fahrzeugs erstreckt.
  • In einigen Ausführungsbeispielen kann der Perspektivenverschieber 406 zusätzlich oder alternativ zur Verschiebung der Perspektive in Bezug auf ein Merkmal der Umgebung die Perspektive auf ein und dasselbe Sichtfeld verschieben. Wenn beispielsweise die HD-Karte 404 Daten aus einer Top-Down-Perspektive der Umgebung zuordnet, können die Sensoren, die die Sensordaten 402 generieren, dies aus verschiedenen Perspektiven tun - z. B. von vorne, von der Seite, von schräg unten, von schräg oben, usw. Um Eingaben 408 zu generieren, die gemeinsam genutzt werden, kann der Perspektivenverschieber 406 jede der Eingaben 408 auf dieselbe Perspektive einstellen. In einigen nicht einschränkenden Ausführungsbeispielen können die Sensordaten 402, die HD-Karte 404 und/oder andere Informationen einer Top-Down-Perspektive zugewiesen werden, z.B. einer perspektivischen Top-Down-Ansicht und/oder einer orthogonalen Top-Down-Ansicht. Darüber hinaus kann der Perspektivenverschieber 406 dabei helfen, die Eingaben 408 so zu generieren, dass für jede Instanz der Eingaben 408 ein gleicher oder im Wesentlichen ähnlicher (z.B. innerhalb von Zentimetern, Metern, etc.) Teil der Umgebung aus der Perspektive repräsentiert wird. Zum Beispiel kann eine erste Eingabe (z.B. ein gerastertes Bild), die vergangene Orte 410 von Akteuren in der Umgebung repräsentiert, durch eine Top-Down-Perspektive eines Teils der Umgebung repräsentiert werden, und eine zweite Eingabe (z.B. ein gerastertes Bild), die Karteninformationen 412 der Umgebung zuordnet, kann durch eine Top-Down-Perspektive des Teils der Umgebung repräsentiert werden. Infolgedessen kann das DNN 416 Ausgaben 418 generieren, indem es eine beliebige Anzahl von Eingaben 408 verwendet, die einem gleichen allgemeinen Teil der Umgebung entsprechen und somit einen ähnlichen Maßstab haben. Dies ist jedoch nicht als Einschränkung zu verstehen, und in einigen Ausführungsbeispielen können sich die Perspektiven, Ausrichtungen, Größen, Orte und der Maßstab der Eingaben 408 für verschiedene Eingabearten und/oder Instanzen unterscheiden. In einigen Ausführungsbeispielen kann das DNN 416 die Live- Wahrnehmung von Fahrspuren anstelle oder zusätzlich zu einer HD-Karte verwenden, die z. B. als Top-Down-Ansicht gerastert ist. Die live wahrgenommenen Fahrspuren (z.B. ihre Grenzen und/oder mittleren Fahrspuren) können zusätzlich oder alternativ von anderen Wahrnehmungs-DNNs oder MLMs abgeleitet werden.
  • Die Eingaben 408 können vergangene(n) Ort(e) 410 (z.B. von Akteuren in der Umgebung, wie Fahrzeugen, Fußgängern, Radfahrern, Robotern, Drohnen, Wasserfahrzeugen usw., je nach Implementierung), Zustandsinformationen 432 (z.B. Geschwindigkeits- und/oder Beschleunigungsdaten entsprechend den Akteuren), Karteninformationen 412 (z.B., wie unter Verwendung der HD-Karte 404 generiert), Wartebedingungen 414 (z.B. generiert unter Verwendung der Sensordaten 402, der HD-Karte 404 und/oder anderer Informationen) und/oder andere Eingaben 408 (z.B. Freirauminformationen, statische Objektinformationen usw., wie unter Verwendung der Sensordaten 402, der HD-Karte 404, eines Drive-Stacks 428 des Fahrzeugs 1100 und/oder anderer Informationen bestimmt). Der/die frühere(n) Ort(e) 410 kann/können frühere Vorgaben detektierter Orte von Fahrzeugen, Fußgängern, Radfahrern und/oder anderen Akteurstypen in der Umgebung umfassen. In einigen Ausführungsbeispielen kann/können der/die frühere(n) Ort(e) 410 in Bezug auf das Ego-Fahrzeug 1100 bestimmt werden, so dass während der Perspektivverschiebung die Änderung der Orientierung und des Ortes in Bezug auf die Akteure effizienter durchgeführt werden kann. Der (die) vergangene(n) Ort(e) 410 und/oder die Zustandsinformationen 432 können durch ein Bild (z.B. ein gerastertes Bild) repräsentiert werden, das die Orte der Akteure darstellt. In einigen Ausführungsbeispielen kann jede Instanz der vergangenen Orte 410 ein einzelnes Bild enthalten und einem einzelnen Zeitabschnitt entsprechen - z.B. kann eine Instanz jeden der verfolgten und/oder detektierten Akteure und ihren aktuellen Ort (z.B. relativ zum Fahrzeug 1100) in dem Zeitabschnitt erfassen. In einigen Ausführungsbeispielen kann jede Instanz der Zustandsinformationen 432 ein einzelnes Bild enthalten und einem einzelnen Zeitabschnitt entsprechen. In anderen Ausführungsbeispielen können die Zustandsinformationen 432 in den Instanzen der Bilder zusammen mit den vergangenen Orten 410 enthalten sein. Das DNN 416 kann eine oder mehrere Instanzen der vergangenen Orte 410 und/oder der Zustandsinformationen 432 als Eingabe nehmen, so dass das DNN 416 die Ausgaben 418 unter Verwendung einer oder mehrerer Instanzen der vergangenen Orte 410 und/oder der Zustandsinformationen 432 berechnen kann, die Orten von Akteuren während eines oder mehrerer Zeitabschnitte (z.B. während eines Zeitraums) entsprechen.
  • Beispielsweise können verschiedene Eingaben 408, die einem Zeitabschnitt (der hier auch als Zeitschritt bezeichnet werden kann) zu einem Zeitpunkt T1 entsprechen, vergangene Orte enthalten (und/oder die dazugehörigen Zustandsinformationen 432). Als solches kann jedes der Quadrate in 2 einem Ort und/oder einer Zustandsinformation eines Akteurs in der Umgebung entsprechen - in Ausführungsbeispielen einschließlich des Ego-Fahrzeugs 1100. In ähnlicher Weise können für einen Zeitabschnitt zu einer Zeit T2 Akteure an Orten innerhalb der Umgebung detektiert werden. Als nicht einschränkendes Beispiel können die Orte jedes Akteurs in Bezug auf einen Ego-Akteur ausgerichtet sein - der der zentral gelegene Akteur sein kann -, so dass das DNN 416 auf den Ego-Akteur konditioniert werden kann.
  • Die Karteninformationen 412 können Orte von Fahrspuren (z.B. Fahrspurmittellinien oder -schienen, Fahrbahnränder oder -teiler, Straßenbegrenzungen, Pannenstreifen usw.), Orte von statischen Objekten, Orte von Kreuzungen, Straßenforminformationen und/oder Ähnliches enthalten. In einigen Ausführungsbeispielen können die Karteninformationen 412 in Bezug auf das Ego-Fahrzeug 1100 so bestimmt werden, dass während der Perspektivverschiebung die Änderung der Ausrichtung und des Ortes in Bezug auf die Karteninformationen effizienter durchgeführt wird. Die Karteninformationen 412 können durch ein Bild (z.B. ein gerastertes Bild) repräsentiert werden, das die Orte der Fahrspuren, statischen Objekte usw. darstellt. In einigen Ausführungsbeispielen kann jede Instanz der Karteninformation 412 ein einzelnes Bild enthalten und einem einzelnen Zeitabschnitt entsprechen - z.B. kann eine Instanz die Struktur der Fahrbahn (z.B. relativ zum Fahrzeug 1100) in diesem Zeitabschnitt erfassen. Das DNN 416 kann eine oder mehrere Instanzen der Karteninformationen 412 als Eingabe nehmen, so dass das DNN 416 die Ausgaben 418 unter Verwendung einer oder mehrerer Instanzen der Karteninformationen 412 berechnen kann, die den Straßenstrukturinformationen über verschiedene Zeitabschnitte (z.B. während eines Zeitraums) entsprechen. In einigen nicht einschränkenden Ausführungsbeispielen kann für jeden Zeitabschnitt innerhalb eines Zeitraums dieselbe Karteninformation 412 verwendet werden (z.B. kann dieselbe Instanz der Karteninformation 412 für alle zwei Zeitabschnitte, alle drei Zeitabschnitte usw. verwendet werden und dann in einem gleichen Intervall aktualisiert werden). In anderen Ausführungsbeispielen können die Karteninformationen 412 in jedem Zeitabschnitt aktualisiert werden.
  • Beispielsweise können verschiedene Eingaben 408, die einem Zeitabschnitt zu einem bestimmten Zeitpunkt T1 entsprechen, Karteninformationen 412 enthalten. Als solche können die Karteninformationen 412 Fahrspurlinien, Linientypen, Straßenform und/oder - struktur und/oder andere Merkmale enthalten. In ähnlicher Weise kann für einen Zeitabschnitt zu einem Zeitpunkt T2 die Struktur der Straße repräsentiert werden. Als nicht einschränkendes Beispiel kann die Karteninformation 412 in Bezug auf einen Ego-Akteur - der der zentral gelegene Akteur sein kann - ausgerichtet sein, so dass das DNN 416 auf den Ego-Akteur konditioniert werden kann.
  • Die Wartebedingungen 414 können Orte von Wartebedingungselementen enthalten, wie z. B. Ampeln, Vorfahrtsschilder, Stoppschilder, Baustellen, Zebrastreifen und/oder andere Wartebedingungen sowie Orte von Kreuzungen, die unter Verwendung eines der oben aufgeführten Wartebedingungselemente definiert oder anderweitig durchgeführt werden. In einigen Ausführungsbeispielen können die Wartebedingungen 414 den Karteninformationen 412 zugeordnet werden, während in anderen Ausführungsbeispielen die Wartebedingungen 414 einen separaten Eingabekanal für das DNN 416 repräsentieren können. In einigen Ausführungsbeispielen können die Wartebedingungen 414, ähnlich wie der vergangene Ort 410 und/oder die Karteninformationen 412, in Bezug auf das Ego-Fahrzeug 1100 so bestimmt werden, dass während der Perspektivenverschiebung die Änderung der Orientierung und des Ortes in Bezug auf die Wartebedingungen 414 effizienter durchgeführt wird. Die Wartebedingungen 414 können durch ein Bild (z.B. ein gerastertes Bild) repräsentiert werden, das die Orte und/oder Arten von Wartebedingungen in der Umgebung darstellt. In einigen Ausführungsbeispielen kann jede Instanz der Wartebedingungen 414 ein einzelnes Bild enthalten und einem einzelnen Zeitabschnitt entsprechen - z.B. kann eine Instanz die Wartebedingungen (z.B. relativ zum Fahrzeug 1100) in diesem Zeitabschnitt erfassen. Das DNN 416 kann eine oder mehrere Instanzen der Wartebedingungen 414 als Eingabe nehmen, so dass das DNN 416 die Ausgaben 418 unter Verwendung einer oder mehrerer Instanzen der Wartebedingungen berechnen kann, die den Wartebedingungsorten und/oder -typen über verschiedene Zeitabschnitte (z.B. während eines Zeitraums) entsprechen. In einigen nicht einschränkenden Ausführungsbeispielen kann für jeden Zeitabschnitt innerhalb eines Zeitraums dieselbe Wartebedingung 414 verwendet werden (z.B. kann dieselbe Instanz der Wartebedingung 414 für alle zwei Zeitabschnitte, alle drei Zeitabschnitte usw. verwendet werden und dann in einem gleichen Intervall aktualisiert werden). In anderen Ausführungsbeispielen können die Wartebedingungen 414 in jedem Zeitabschnitt aktualisiert werden. Beispielsweise können verschiedene Eingaben 408, die einem Zeitabschnitt zu einem Zeitpunkt T1 entsprechen, Wartebedingungen 414 enthalten. Als solche können die Wartebedingungen 414 Stoppschilder, Stopplichter, Vorfahrtsschilder, Orte für die Einfahrt von Rettungsfahrzeugen und/oder andere Arten von Wartebedingungen umfassen. Während des Trainings des Richtlinien-MLM 106 und/oder des Wertfunktions-MLM 108, wie in 1A, können die Simulationsdaten 102 eine beliebige Kombination der Eingabe(n) 408 repräsentieren (z.B. wie im Weltzustand 118 kodiert oder unter Verwendung desselben).
  • Die Eingaben 408 können - z.B. nach perspektivischer Verschiebung und/oder Rasterung - dem DNN 416 als Eingabetensoren zugeführt werden. Zum Beispiel kann jede Eingabe - z.B. die Karteninformationen 412, die vergangenen Orte 410, die Wartebedingungen 414, andere Eingabetypen usw. - jeweils als separater Eingabe-Tensor auf einen oder mehrere Kanäle des DNN 416 angewendet werden. Wie hier beschrieben, kann in einigen Ausführungsbeispielen jeder Eingabetyp mit einem individuellen Eingabetensor und/oder Eingabekanal assoziiert sein. In anderen Ausführungsbeispielen können zwei oder mehr der Eingabearten (z.B. die Wartebedingungen 414 und die Karteninformationen 412) kombiniert werden, um einen einzigen Eingabetensor für einen einzigen Eingabekanal des DNN 416 zu bilden.
  • In einigen Ausführungsbeispielen kann das DNN 416 ein zeitliches und/oder räumliches DNN enthalten, so dass das DNN 416 in jeder Instanz Informationen analysiert, die mehr als einem zeitlichen Zeitabschnitt (z.B. einem Zeitraum) entsprechen, und/oder in jeder Instanz Informationen analysiert, die mehr als einem räumlichen Ort von Akteuren entsprechen. So kann das DNN 416 lernen, zukünftige Trajektorien - oder Informationen, die diese repräsentieren - vorherzusagen, indem es vergangene Orte von Akteuren, Straßenstrukturen, Wartebedingungen und/oder andere Informationen über eine Vielzahl von Zeitabschnitten überwacht und einbezieht. In einigen Ausführungsbeispielen kann das DNN 416 ein rekurrentes neuronales Netzwerk (RNN) enthalten. Als nicht einschränkendes Beispiel und wie unten in Bezug auf 5 detaillierter beschrieben, kann das DNN 416 einen Dekodierer enthalten.
  • Obwohl hier Beispiele für die Verwendung von neuronalen Netzwerken, insbesondere von RNNs, als DNN 416 beschrieben werden, ist dies nicht als Einschränkung zu verstehen. Beispielsweise und ohne Einschränkung kann das hier beschriebene DNN 416 jede Art von maschinellem Lernmodell umfassen, wie z. B. ein maschinelles Lernmodell, das lineare Regression, logistische Regression, Entscheidungsbäume, Support Vector Machines (SVM), Naive Bayes, k-nearest neighbor (Knn), K-Means-Clustering, Random Forest, Dimensionalitätsreduktionsalgorithmen, Gradient-Boosting-Algorithmen, neuronale Netzwerke und/oder andere Arten von maschinellen Lernmodellen verwendet. Beispiele für neuronale Netzwerke sind Auto-Encoder, Convolutional Neural Networks, Recurrent Neural Networks, Perceptrons, Long/Short Term Memory (LSTM), Hopfield, Boltzmann, Deep Belief, Deconvolutional Neural Networks, Generative Adversarial Networks, Liquid State Machines, Graphical Neural Networks (GNNs), wie z.B. ein GNN mit einer oder mehreren Eingaben, die eine Karte und eine oder mehrere Trajektorien aus der Vergangenheit umfassen), Convolutional Neural Networks (z.B. wenn vergangene Zeitabschnitte durch verschiedene Tensorkanäle repräsentiert werden können), usw.
  • 5 zeigt ein Beispiel für eine Deep-Neural-Network (DNN)-Architektur, die sich zur Implementierung in mindestens einem Ausführungsbeispiel des Verfahrens von 4 eignet, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das DNN 416 umfasst eine Vielzahl von Kodierer-Dekodierer-Stapeln, die jeweils einen 2D-FaltungsKodierer 504 (z.B. 504A-504B), einen 2D-Faltungs-Dekodierer 506 (z.B. 506A-506D) und/oder einen 2D-Faltungs-RNN 502 (z.B. 502A-502D) umfassen können. In einem oder mehreren Ausführungsbeispielen kann der 2D-Faltungskodierer 504 dem Kodierer 304 in 3 entsprechen. In ähnlicher Weise kann der 2D-Faltungsdekodierer 506 dem Dekodierer 306A und/oder 306B in 3 entsprechen.
  • Das DNN 415 kann je nach Ausführungsbeispiel so konfiguriert sein, dass es eine beliebige Anzahl von Zeitabschnitten vergangener Informationen empfängt und eine beliebige Anzahl von Zeitabschnitten zukünftiger Informationen vorhersagt. Beispielsweise kann das DNN 415 eine Trajektorie generieren, die Informationen aus den vergangenen zwei Sekunden und zwei Sekunden in die Zukunft enthält - z.B. wenn ein Trajektorienpunkt jede Sekunde, jede halbe Sekunde, viermal pro Sekunde, achtmal pro Sekunde usw. ausgegeben wird. Die Eingaben 408 können beispielsweise einen oder mehrere Tensoren umfassen, die vergangenen und/oder vorhergesagten zukünftigen Orten von Akteuren entsprechen, einen oder mehrere Tensoren, die Wartebedingungen 414 entsprechen, einen oder mehrere Tensoren, die Karteninformationen 412 zuordnen, usw. Die Ausgaben 418 können einen oder mehrere Tensoren umfassen, die einem Konfidenzfeld entsprechen (z.B. angezeigt durch die für die Ausgaben 204 in 2 dargestellten Gradienten), einen oder mehrere Tensoren, die einem oder mehreren Vektorfeldern entsprechen, usw. Da die Eingaben 408 im Closed-Loop-Modus auf tatsächlichen oder simulierten (z.B. Grundwahrheiten) Orten von einem oder mehreren Akteuren in der Umgebung basieren können, können die Ausgaben 418 im Closed-Loop-Modus in einigen Ausführungsbeispielen präziser sein - z.B. können sie einen kleineren Bereich potenzieller Orte für die Akteure enthalten, der näher an einer 1:1-Entsprechung zwischen der Eingabe 408 und der Ausgabe 418 liegen kann. Da die Eingaben 408 im Open-Loop-Modus auf zukünftigen Vorhersagen oder Simulationen von Orten eines oder mehrerer Akteure basieren können, können die Ausgaben 418 im Open-Loop-Modus außerdem weniger präzise sein - z.B. können sie einen größeren Bereich potenzieller Orte für die Akteure umfassen.
  • Das DNN 416 kann einen Closed-Loop-Modus für Vergangenheit und einen Open-Loop-Modus für Zukunft umfassen. In einigen Ausführungsbeispielen kann der Closed-Loop-Modus für Vergangenheit als Eingaben 408 tatsächliche reale oder simulierte vergangene Orte 110 von Akteuren in der Umgebung (zusätzlich zu anderen Eingaben 408, wie z.B. den Karteninformationen 412, den Wartebedingungen 414 usw.) verwenden, um die Ausgaben 418 zu generieren - z.B. wie durch quadratische Kästchen an den Eingaben 408A und 408B zugewiesen.
  • Wie in 4 dargestellt, können die Ausgaben 418 des DNN 416 Konfidenzfeld(er) 420, Vektorfeld(er) 422 und/oder andere Ausgabetypen umfassen. Die Kombination des/der Konfidenzfeldes/Konfidenzfelder 420 und des/der Vektorfeldes/Vektorfelder 422 kann von einem Postprozessor 424 - der hier detaillierter beschrieben wird - verwendet werden, um eine vollständige Trajektorie eines oder mehrerer Akteure in der Umgebung zu bestimmen, die einen oder mehrere vergangene Trajektorienpunkte oder Orte und/oder einen oder mehrere zukünftige Trajektorienpunkte oder Orte umfassen kann. In einigen nicht einschränkenden Ausführungsbeispielen können das/die Konfidenzfeld(er) 420 und das/die Vektorfeld(er) 422 für einen Zeitabschnitt derselben Region der Umgebung (z.B. demselben Gebiet) entsprechen und somit dieselbe räumliche Dimension aufweisen.
  • Das/die Konfidenzfeld(er) 420 kann/können für jeden Zeitabschnitt (z.B. Vergangenheit, Gegenwart und/oder Zukunft) ein Konfidenzfeld oder eine Karte enthalten, die die Konfidenz der Orte repräsentiert, an denen sich die Akteure befinden. Das Konfidenzfeld 420 kann durch eine H x W-Matrix repräsentiert werden, in der jedes Element (z.B. Pixel oder Punkt) einen Konfidenzwert darstellt. Zum Beispiel kann jedem Pixel oder Punkt im Konfidenzfeld 420 oder der Karte eine assoziierte Wahrscheinlichkeit zugeordnet werden, dass ein Akteur vorhanden ist. Als solches, und insbesondere für zukünftige Vorhersagen, kann das/die Konfidenzfeld/er 420 der Darstellung von 2 ähnlicher erscheinen. Zum Beispiel kann die Visualisierung 200 von 2 für die Ausgaben 204 eine Vielzahl von Konfidenzfeldern repräsentieren, die einer Vielzahl von übereinander liegenden Zeitabschnitten entsprechen.
  • Das (die) Vektorfeld(er) 422 kann (können) für jeden Zeitabschnitt (z.B. Vergangenheit, Gegenwart und/oder Zukunft) ein Vektorfeld 422 oder eine Karte enthalten, das (die) Vektoren (z.B. Verschiebungsvektoren) repräsentiert, die Vorhersagen darüber entsprechen, wo sich ein Akteur am Ort des Vektors im vorherigen Zeitabschnitt befand. Das Vektorfeld 422 kann eine H x W-Matrix enthalten, in der jedes Element (z.B. Pixel oder Punkt) einen 2D- (oder 3D-, in Ausführungsbeispielen) Vektor repräsentiert, der einer Verschiebung von einem aktuellen Ort des Vektors zu einem Punkt (z.B. einem Mittelpunkt) desselben Objekts oder Akteurs in einem früheren Zeitabschnitt (oder Zeitschritt) entspricht. Jeder Vektor kann in einigen nicht einschränkenden Ausführungsbeispielen durch eine Richtung und einen Betrag, einen Abstand (z.B. einen Pixelabstand) entlang des 2D- oder 3D-Raums und/oder eine andere Repräsentation repräsentiert werden. Zum Beispiel kann jedes Pixel oder jeder Punkt in dem Vektorfeld 422 oder der Karte für einen Zeitpunkt Tn einen assoziierten Vektor haben, der repräsentiert, wo ein Akteur - wenn ein Akteur an dem Pixel oder Punkt anwesend ist - zu einem vorherigen Zeitpunkt Tn-1 vorhergesagt wird (obwohl in Ausführungsbeispielen das DNN 416 trainiert werden kann, um die Vektorfelder 422 zu berechnen, die zum Beispiel einem zukünftigen Zeitpunkt Tn+1 entsprechen).
  • Der Postprozessor 424 kann das/die Konfidenzfeld(er) 420 und das/die Vektorfeld(er) 422 verwenden, um Trajektorien für jeden der verschiedenen Akteure in der Umgebung zu bestimmen. Beispielsweise kann das Konfidenzfeld 420, das einem letzten zukünftigen Zeitabschnitt (z.B. Tn) der Ausgaben 418 entspricht, vom Postprozessor 424 analysiert werden, um Orte von Akteuren zu bestimmen, und die entsprechenden Vektoren aus dem Vektorfeld 422 in demselben Zeitabschnitt können genutzt werden, um vorhergesagte Orte der Akteure in einem Konfidenzfeld 420 aus einem vorhergehenden Zeitabschnitt (z.B. Tn-1) zu bestimmen. Das Konfidenzfeld 420 aus dem vorhergehenden Zeitabschnitt kann dann verwendet werden, um die Orte der Akteure in diesem Zeitabschnitt (z.B. Tn-1) zu bestimmen, und dann kann das Vektorfeld 422 aus diesem Zeitabschnitt verwendet werden, um vorhergesagte Orte der Akteure in einem Konfidenzfeld 420 aus einem vorhergehenden Zeitabschnitt (z.B. Tn-2) zu bestimmen, und so weiter, bis ein aktueller Zeitpunkt erreicht ist. Ein Trajektoriengenerator 426 kann dann diese zukünftigen Vorhersagen an die vergangene Trajektorie der Akteure anhängen, die aus den tatsächlichen Detektierungen der Akteure bestimmt wurde, um eine finale Trajektorie zu generieren. In einigen Ausführungsbeispielen kann die vergangene Trajektorie auch unter Verwendung eines ähnlichen Prozesses wie für die zukünftigen Trajektorien generiert werden, wobei die Konfidenzfelder 420 verwendet werden, um Orte in einem Zeitabschnitt zu bestimmen, und die Vektorfelder 422 verwendet werden, um Orte in früheren Zeitabschnitten zu bestimmen.
  • Für ein Konfidenzfeld 420, das einem Zeitabschnitt entspricht (z.B. wie durch einen Zeitstempel angegeben), kann der Ort der Akteure unter Verwendung einer beliebigen Anzahl verschiedener Verfahren bestimmt werden, wie z.B. Verfahren, die Clustering einschließen (z.B. Unterdrückung von Nicht-Maxima, dichtebasiertes räumliches Clustering von Applikationen mit Rauschen (DBSCAN) usw.) und/oder Verfahren ohne Clustering. Wird beispielsweise Clustering verwendet, kann ein Konfidenz-Schwellenwert angewendet werden, um verrauschte Punkte zu entfernen. In solchen Beispielen kann der Schwellenwert ohne Einschränkung 0,7, 0,8, 0,85, 0,9 usw. betragen. Sobald die verrauschten Punkte herausgefiltert sind, kann auf die verbleibenden Punkte ein Clustering-Algorithmus angewendet werden, so dass Punkte, die innerhalb eines Schwellenwerts voneinander entfernt sind, als mit einem einzigen Akteur assoziiert bestimmt werden können. In einigen Ausführungsbeispielen können, sobald die Cluster bestimmt sind, ein oder mehrere der Vektoren aus dem Vektorfeld 422 desselben Zeitabschnitts, die denselben Punkten entsprechen, verwendet werden, um den Ort eines entsprechenden Akteurs (oder eines diesen repräsentierenden Clusters) in einem vorhergehenden Zeitabschnitt zu finden. In anderen Ausführungsbeispielen kann, sobald die Cluster bestimmt sind, ein Schwerpunkt jedes Clusters bestimmt werden, und eine Begrenzungsform vorbestimmter Größe (z.B. gleiche Größe für alle Cluster, unterschiedliche Größe für Cluster, die verschiedenen Akteurstypen entsprechen - z.B. Begrenzungsform erster Größe für Autos, Begrenzungsform zweiter Größe für Fußgänger usw.) kann auf den Schwerpunkt zentriert werden (z.B. ein Schwerpunkt einer Begrenzungsform, die auf den Schwerpunkt des Clusters zentriert ist). Die Begrenzungsform kann dann als Maske für das Vektorfeld 422 desselben Zeitabschnitts verwendet werden, um zu bestimmen, welche Vektoren für die Suche nach dem Ort eines entsprechenden Akteurs (oder eines Clusters oder einer dafür repräsentativen Begrenzungsform) in einem vorhergehenden Zeitabschnitt zu verwenden sind. Diese Prozesse können für jeden Zeitabschnitt abgeschlossen werden, bis eine vollständige Trajektorie durch jeden Zeitabschnitt bestimmt ist. In Fällen, in denen ein anderer Akteur (oder ein Cluster oder eine Begrenzungsform, die diesen repräsentiert) im vorherigen Zeitabschnitt unter Verwendung des Vektorfeldes 422 nicht lokalisiert werden kann, kann die Trajektorie verkürzt werden, kann verworfen werden (z.B. kann es sich um Rauschen, einen Fehler usw. handeln) und/oder kann basierend auf vergangenen zeitlichen Informationen abgeschätzt werden.
  • Ein weiteres Beispiel: Wird kein Clustering verwendet, kann ein anderer Algorithmus oder ein anderes Verfahren zur Bestimmung der Orte der Akteure implementiert werden. Beispielsweise kann ein gewichteter Mittelwertansatz verwendet werden, bei dem das/die Konfidenzfeld(er) 420 und das/die Vektorfeld(er) 422 für jeden Akteur in einem einzigen Durchgang verarbeitet werden können - mit dem inhärenten Rechenvorteil schneller Verarbeitungszeiten unabhängig von der Anzahl der Akteure. In einem solchen Algorithmus kann für jeden Akteur α die wahrscheinlichste nächste Position der Durchschnitt aller Positionen sein, deren Vorgängervektor auf α zeigt, gewichtet mit den Werten der Konfidenzfelder 420 an diesen Positionen. Die gewichteten Mittelwerte können für alle Akteure auf einmal berechnet werden, indem ein Hilfsspeicher für Zähler (numerator) und Nenner (denominator) verwendet wird, die beide auf Null initialisiert sind. Für jede Position, pos, in der Ausgabe des DNN 416 werden der Vorgänger, pred = predecessor[pos] und die Belegung, o = occupancy[pos] berechnet. Dann addiert man o*pos zum numerator[pred], und o zum denominator[pred]. Die nächste Position für jeden Akteur, a, kann durch numerator[a.position]/denominator[a.position] bestimmt werden. Der Zähler speichert die gewichtete Summe aller Positionen, deren Vorgängervektor auf α zeigt, und der Nenner speichert die Summe ihrer Gewichte, so dass das Ergebnis ein gewichteter Durchschnitt ist. Da die für jede Position anzuwendende Operation weitgehend unabhängig ist, können diese Schritte parallel durchgeführt werden (z.B. unter Verwendung einer Grafikverarbeitungseinheit (GPU) über mehrere parallele Threads).
  • Als weiteres Beispiel kann für jeden Akteur a das Konfidenzfeld 420 für einen gegebenen Zeitabschnitt gefiltert werden, um Pixel oder Punkte einzuschließen, deren Vorgängervektor auf den Akteur a zeigt. Die (weiche) argmax-Funktion kann auf die verbleibenden Punkte angewandt werden, um einen „Schwerpunkt“ der Punkte zu bestimmen. Insbesondere kann das Ergebnis die belegungsgewichtete Summe aller Positionen sein, deren Vorgänger (predecessor) auf a zeigt. Dies kann als die wahrscheinlichste zukünftige Position für a bestimmt werden. Dieses Verfahren kann für jeden anderen Akteur wiederholt werden. In einigen Ausführungsbeispielen kann für jeden Akteur ein separater Durchlauf über dasselbe Konfidenzfeld 420 durchgeführt werden, und dies kann in jedem Zeitabschnitt wiederholt werden. Dies kann dazu führen, dass die Gesamtlaufzeit des Systems länger ist als für einen Echtzeit- oder echtzeitnahen Einsatz gewünscht. Um dies zu vermeiden und die Operationen pro Akteur für alle Akteure gemeinsam durchzuführen, können zwei partielle Summen gespeichert werden. Eine erste Summe von Gewichten für eine Form H x W, gemäß Gleichung (1), unten: s u m _ w e i g h t s [ y , x ] = ∑ i , j ∈ H , W { o c c u p a n c y [ i , j ] w e n n   p r e d e c e s s o r [ i , j ] = ( y , x ) 0 s o n s t  
    Figure DE112021001994T5_0001
    und eine zweite Summe von Gewichten für eine Form H x W x 2 gemäß der nachstehenden Gleichung (2): s u m _ w e i g h t s [ y , x ] = ∑ i , j ∈ H , W { ( i , j ⋅ o c c u p a n c y [ i , j ] w e n n   p r e d e c e s s o r [ i , j ] = ( y , x ) 0 s o n s t  
    Figure DE112021001994T5_0002
  • Um dann den wahrscheinlichsten Nachfolger für den Akteur a zu finden, kann Gleichung (3) verwendet werden: s u m _ w e i g h t e d _ c o o r d s [ a . b b o x . s u m ( ) / s u m _ w e i g h t [ a . b b o x ] . s u m ( )
    Figure DE112021001994T5_0003
    die einen belegungsgewichteten Durchschnitt aller Positionen des nächsten Bildes repräsentieren kann, deren Vorgänger auf den Akteur a (oder ein entsprechendes Begrenzungsfeld) zeigt.
  • Da es sich bei den Belegungswerten (z.B. aus den Konfidenzfeldern 420) nicht um Wahrscheinlichkeiten handelt, kann in einigen Beispielen eine Schärfungsoperation durchgeführt werden, um eine Überstreuung der Trajektorien zu vermeiden. Beispielsweise kann eine Schärfungsoperation auf die Konfidenzfelder 420 angewandt werden, um Punkten mit höherer Konfidenz höhere Gewichte zuzuweisen, bevor das gewichtete Mittel berechnet wird. In einem nicht einschränkenden Ausführungsbeispiel kann die Schärfung mit einer Schärfungsstärke von 40 fest kodiert werden, wie in Gleichung (4) unten repräsentiert: s h a r p e n ( x ) = e 40 ⋅ x − 40
    Figure DE112021001994T5_0004
  • In einigen Ausführungsbeispielen kann die Schärfungsfunktion jedoch auch erlernt oder trainiert werden.
  • Als weiteres Beispiel und in Bezug auf 6 zeigt 6 eine visuelle Repräsentation von Akteuren, assoziierten Trajektorien, Wartebedingungen und einer Straßenstruktur, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Die Visualisierung 600 kann Informationen repräsentieren, die an den Drive-Stack 428 des Fahrzeugs 1100 übergeben werden, nachdem der Prozess 400 ausgeführt wurde. Beispielsweise kann die Visualisierung 600 eine abstrahierte Repräsentation einer Kombination von Eingaben und Ausgaben des DNN 416 (z.B. nach der Nachbearbeitung) enthalten. Beispielsweise können Straßenstruktur- oder Karteninformationen aus der HD-Karte 404 verwendet werden, um Straßengrenzen 418 zu bestimmen, die Wartebedingungen 414 können verwendet werden, um zu bestimmen, ob Stoppschilder 606A-606D vorhanden sind und deren Orte, und Trajektorien 604A-604F für jeden der Akteure 602A-602F können basierend auf den Ausgaben des Postprozessors 424 bestimmt werden. Darüber hinaus kann die Repräsentation, wie hier beschrieben, ego-zentriert sein, so dass die Visualisierung 600 aus der Perspektive eines Ego-Fahrzeugs (z.B. des Akteurs 612C) zentriert ist. Die gestrichelten Linien der Trajektorien 604 können in der Vergangenheit bekannte oder verfolgte Orte der Akteure 602 repräsentieren und die durchgezogenen Linien können vorausgesagte zukünftige Orte der Akteure 602 repräsentieren. Die Orte der Akteure 602 in der Repräsentation können die Orte der Akteure zum aktuellen Zeitpunkt repräsentieren.
  • Wie in 4 dargestellt, können die Ausgaben des Trajektorien-Generators 426 an den Drive-Stack 428 des Fahrzeugs 1100 übertragen oder angewendet werden. Sobald die Trajektorien beispielsweise berechnet wurden - und in Ausführungsbeispielen von 2D-Bildraumkoordinaten in 3D-Weltraumkoordinaten umgewandelt wurden - können die Trajektorien vom autonomen Fahrzeug 1100 bei der Durchführung einer oder mehrerer Operationen (z.B. Hindernisvermeidung, Spurhaltung, Spurwechsel, Pfadplanung, Kartierung usw.) verwendet werden. Insbesondere können die Trajektorien vom Drive-Stack 428 des autonomen Fahrzeugs 1100 verwendet werden, wie z.B. einem autonomen Maschinen-Software-Stack, der auf einer oder mehreren Komponenten des Fahrzeugs 1100 ausgeführt wird (z.B. dem/den SoC(s) 1104, der/den CPU(s) 1118, der/den GPU(s) 1120, usw.). Zum Beispiel kann das Fahrzeug 1100 diese Informationen (z.B. zukünftige Orte eines oder mehrerer Akteure in der Umgebung) verwenden, um zu navigieren, zu planen oder anderweitig eine oder mehrere Operationen (z.B. Hindernisvermeidung, Spurhaltung, Spurwechsel, Pfadplanung, Zusammenführen, Aufteilen usw.) innerhalb der Umgebung durchzuführen.
  • In einigen Ausführungsbeispielen können die Trajektorien von einer oder mehreren Schichten eines Software-Stacks 428 für autonome Maschinen (hier alternativ als „Drive-Stack 428“ bezeichnet) verwendet werden. Der Drive-Stack 428 kann einen Sensorverwalter (nicht gezeigt), Wahrnehmungskomponente(n) (z.B. entsprechend einer Wahrnehmungsschicht des Drive-Stacks 428), einen Weltmodellverwalter, Planungskomponente(n) (z.B. entsprechend einer Planungsschicht des Drive-Stacks 428 und/oder dem Planungsverwalter 154), Steuerungskomponente(n) (z.B., (z.B. entsprechend einer Steuerungsschicht des Drive-Stacks 428 und/oder dem Controller 156), Hindernisvermeidungskomponente(n) (z.B. entsprechend einer Hindernis- oder Kollisionsvermeidungsschicht des Drive-Stacks 428), Aktuator-Komponente(n) (z.B. entsprechend einer Aktuator-Schicht des Drive-Stacks 428) und/oder andere Komponenten, die zusätzlichen und/oder alternativen Schichten des Drive-Stacks 428 entsprechen. Der Prozess 400 kann in einigen Beispielen von der/den Wahrnehmungskomponente(n) ausgeführt werden, die Ausgaben von einer oder mehreren Schichten des Drive-Stacks 428 an den Weltmodellverwalter weiterleiten können, wie hierin detaillierter beschrieben.
  • Der Sensorverwalter kann die Sensordaten 402 von den Sensoren des Fahrzeugs 1100 verwalten und/oder abstrahieren. Beispielsweise können die Sensordaten 402 (z.B. ständig, in Intervallen, basierend auf bestimmten Bedingungen) von RADAR-Sensor(en) 1160 generiert werden, wie in 11C gezeigt wird. Der Verwalter kann die Sensordaten 402 von den Sensoren in unterschiedlichen Formaten empfangen (z.B. können Sensoren desselben Typs Sensordaten in unterschiedlichen Formaten ausgeben) und kann so konfiguriert sein, dass er die unterschiedlichen Formate in ein einheitliches Format umwandelt (z.B. für jeden Sensor desselben Typs). Infolgedessen können andere Komponenten, Merkmale und/oder Funktionen des autonomen Fahrzeugs 1100 das einheitliche Format verwenden, wodurch die Verarbeitung der Sensordaten 402 vereinfacht wird. In einigen Beispielen kann der Verwalter der Sensoren ein einheitliches Format verwenden, um einen Steuerparameter oder eine Anweisung auf die Sensoren des Fahrzeugs 1100 anzuwenden, z. B. um Bildraten einzustellen oder eine Verstärkungsregelung durchzuführen. Der Sensorverwalter kann auch Sensorpakete oder Kommunikationen, die den Sensordaten entsprechen, mit Zeitstempeln aktualisieren, um die Verarbeitung der Sensordaten durch verschiedene Komponenten, Merkmale und Funktionen eines autonomen Fahrzeugsteuerungssystems zu unterstützen.
  • Ein Weltmodellverwalter kann verwendet werden, um ein Weltmodell zu generieren, zu aktualisieren und/oder zu definieren. Der Weltmodellverwalter kann Informationen verwenden, die von der/den Wahrnehmungskomponente(n) des Drive-Stacks 428 generiert und empfangen werden (z.B. die vergangenen und vorhergesagten Orte der detektierten Akteure). Während des Trainings kann der Simulator 116 als Weltmodellverwalter fungieren.
  • Die Wahrnehmungskomponente(n) kann/können eine Hinderniswahrnehmung, eine Pfadwahrnehmung, eine Wartewahrnehmung, eine Kartenwahrnehmung und/oder eine andere Wahrnehmungskomponente(n) umfassen. Zum Beispiel kann das Weltmodell (z.B. entsprechend dem Weltzustand 118) zumindest teilweise basierend auf Erschwinglichkeiten für Hindernisse, Pfade und Wartebedingungen definiert werden, die in Echtzeit oder nahezu in Echtzeit von dem Hinderniswahrnehmer, dem Pfadwahrnehmer, dem Wartewahrnehmer und/oder dem Kartenwahrnehmer wahrgenommen werden können. Der Weltmodellverwalter kann das Modell basierend auf neu generierten und/oder empfangenen Eingaben (z.B. Daten) des Hinderniswahrnehmers, des Pfadwahrnehmers, des Wartewahrnehmers, des Kartenwahrnehmers und/oder anderer Komponenten des autonomen Fahrzeugsteuerungssystems kontinuierlich aktualisieren.
  • Das Weltmodell kann verwendet werden, um die Planungskomponente(n), die Steuerungskomponente(n), die Hindernisvermeidungskomponente(n) und/oder die Aktuator-Komponente(n) des Drive-Stacks 428 zu informieren. Der Hinderniswahrnehmer kann eine Hinderniswahrnehmung durchführen, die darauf basieren kann, wo das Fahrzeug 1100 fahren darf oder fahren kann (z.B. basierend auf dem Ort der fahrbaren Pfade, die durch das Vermeiden von detektierten Hindernissen definiert sind), und wie schnell das Fahrzeug 1100 fahren kann, ohne mit einem Hindernis zu kollidieren (z.B. einem Objekt, wie einer Struktur, einer Entität, einem Fahrzeug, usw.), das von den Sensoren des Fahrzeugs 1100 gemessen wird.
  • Der Pfadwahrnehmer kann eine Pfadwahrnehmung durchführen, z.B. indem er nominelle Pfade wahrnimmt, die in einer bestimmten Situation verfügbar sind. In einigen Beispielen kann der Pfadwahrnehmer bei der Pfadwahrnehmung weiter Fahrspurwechsel berücksichtigen (z.B. berücksichtigen). Ein Fahrspurgraph (z.B. generiert zumindest teilweise unter Verwendung der HD-Karte 404) kann den Pfad oder die Pfade repräsentieren, die dem Fahrzeug 1100 zur Verfügung stehen, und kann so einfach sein wie ein einzelner Pfad auf einer Autobahnauffahrt. In einigen Beispielen kann der Fahrspurgraph Pfade zu einer gewünschten Spur enthalten und/oder verfügbare Wechsel auf der Autobahn (oder einem anderen Straßentyp) anzeigen, oder er kann nahegelegene Fahrspuren, Fahrspurwechsel, Gabelungen, Abbiegungen, Kleeblattkreuzungen, Zusammenführungen und/oder andere Informationen enthalten.
  • Der Wartewahrnehmer kann für das Bestimmen von Einschränkungen für das Fahrzeug 1100 verantwortlich sein, die sich aus Regeln, Konventionen und/oder praktischen Erwägungen ergeben. Die Regeln, Konventionen und/oder praktischen Erwägungen können sich zum Beispiel auf Ampeln, mehrspurige Haltepunkte, Abbiegevorgänge, Zusammenführungen, Mautstellen, Schranken, Polizei oder anderes Notfallpersonal, Straßenarbeiter, angehaltene Busse oder andere Fahrzeuge, Arbitrierung von Einbahnstraßenbrücken, Fähreneinfahrten usw. beziehen. Auf diese Weise kann der Wartewahrnehmer genutzt werden, um potenzielle Hindernisse zu erkennen und eine oder mehrere Kontrollen zu implementieren (z.B. Abbremsen, Anhalten usw.), die allein mit der Hinderniswahrnehmung nicht möglich gewesen wären.
  • Der Kartenwahrnehmer kann einen Mechanismus enthalten, mit dem Verhaltensweisen erkannt werden, und in einigen Beispielen spezifische Beispiele dafür bestimmen, welche Konventionen an einem bestimmten Ort angewendet werden. Beispielsweise kann der Kartenwahrnehmer anhand von Daten, die frühere Fahrten repräsentieren, feststellen, dass an einer bestimmten Kreuzung zwischen bestimmten Uhrzeiten nicht gewendet werden darf, dass ein elektronisches Schild, das die Richtungsänderung der Fahrspur abhängig von der Tageszeit anzeigt, dass zwei Ampeln in unmittelbarer Nähe (z.B. kaum versetzt zueinander) verschiedenen Straßen zugeordnet sind, dass in Rhode Island das erste Auto, das an einer Ampel auf das Linksabbiegen wartet, gegen das Gesetz verstößt, indem es vor dem entgegenkommenden Verkehr abbiegt, wenn die Ampel grün wird, und/oder andere Informationen. Der Kartenwahrnehmer kann das Fahrzeug 1100 über statische oder stationäre Infrastrukturobjekte und Hindernisse informieren. Der Kartenwahrnehmer kann auch Informationen für den Wartewahrnehmer und/oder den Pfadwahrnehmer generieren, z.B. um zu bestimmen, welche Ampel an einer Kreuzung grün sein muss, damit das Fahrzeug 1100 einen bestimmten Pfad einschlagen kann.
  • In einigen Beispielen können Informationen von dem Kartenwahrnehmer an einen oder mehrere Server (z.B. an einen Kartenverwalter des Servers/der Server 1178 von 11D) gesendet, übertragen und/oder bereitgestellt werden, und Informationen von dem/den Server(n) können an den Kartenwahrnehmer und/oder einen Lokalisierungsverwalter des Fahrzeugs 1100 gesendet, übertragen und/oder bereitgestellt werden. Der Kartenverwalter kann eine Cloud-Mapping-Applikation umfassen, die vom Fahrzeug 1100 entfernt angeordnet ist und auf die das Fahrzeug 1100 über ein oder mehrere Netzwerk(e) zugreifen kann. Beispielsweise kann der Kartenverwalter und/oder der Verwalter für die Lokalisierung des Fahrzeugs 1100 mit dem Kartenverwalter und/oder einer oder mehreren anderen Komponenten oder Funktionen des Servers/der Server kommunizieren, um den Kartenverwalter und/oder den Verwalter für die Lokalisierung über vergangene und gegenwärtige Fahrten oder Fahrten des Fahrzeugs 1100 sowie über vergangene und gegenwärtige Fahrten oder Fahrten anderer Fahrzeuge zu informieren. Der Kartenverwalter kann Kartenausgaben (z.B. Kartendaten) bereitstellen, die vom Lokalisierungsverwalter basierend auf einem bestimmten Ort des Fahrzeugs 1100 zugeordnet werden können, und die lokalisierten Kartenausgaben können vom Weltmodellverwalter verwendet werden, um das Weltmodell zu generieren und/oder zu aktualisieren.
  • Die Planungskomponente(n) kann/können den Routenplaner 150, den Fahrspurplaner 152, einen Verhaltensplaner und einen Verhaltenswähler neben anderen Komponenten, Merkmalen und/oder Funktionen umfassen. Der Verhaltensplaner kann die Durchführbarkeit grundlegender Verhaltensweisen des Fahrzeugs 1100 bestimmen, wie z.B. auf der Spur zu bleiben oder die Spur nach links oder rechts zu wechseln, so dass die durchführbaren Verhaltensweisen mit den am meisten gewünschten Verhaltensweisen, die vom Fahrspurplaner ausgegeben werden, abgeglichen werden können. Wenn beispielsweise festgestellt wird, dass das gewünschte Verhalten nicht sicher und/oder nicht verfügbar ist, kann stattdessen ein Standardverhalten gewählt werden (z.B. kann das Standardverhalten sein, in der Spur zu bleiben, wenn das gewünschte Verhalten oder der Spurwechsel nicht sicher ist).
  • Die Steuerungskomponente(n) kann/können einer Trajektorie oder einem Pfad (seitlich und in Längsrichtung) folgen, die/der vom Verhaltenswähler der Planungskomponente(n) so genau wie möglich und im Rahmen der Möglichkeiten des Fahrzeugs 1100 empfangen wurde. Die Steuerungskomponente(n) kann/können eine enge Rückkopplung verwenden, um ungeplante Ereignisse oder Verhaltensweisen zu behandeln, die nicht modelliert sind und/oder alles, was Abweichungen vom Ideal veranlasst (z.B. unerwartete Verzögerung). In einigen Beispielen können die Steuerungskomponente(n) ein Vorwärtsprognosemodell verwenden, das die Steuerung als Eingabevariable verwendet und Vorhersagen erzeugt, die mit dem gewünschten Zustand verglichen werden können (z.B. mit dem gewünschten lateralen und longitudinalen Pfad, der von der/den Planungskomponente(n) verlangt wird). Auf diese Weise kann diejenige(n) Steuerung(en) bestimmt werden, die die Diskrepanz minimieren.
  • Die Hindernisvermeidungskomponente(n) kann/können das autonome Fahrzeug 1100 dabei unterstützen, Kollisionen mit Objekten (z.B. sich bewegenden oder stationären Objekten) zu vermeiden. Die Hindernisvermeidungskomponente(n) kann/können einen Rechenmechanismus auf einer „Primärebene“ der Hindernisvermeidung umfassen und kann/können als ein „Überlebensgehirn“ oder „Reptiliengehirn“ für das Fahrzeug 1100 fungieren. In einigen Beispielen kann die Hindernisvermeidungskomponente(n) unabhängig von Komponenten, Merkmalen und/oder Funktionen des Fahrzeugs 1100 verwendet werden, die erforderlich sind, um Verkehrsregeln zu befolgen und rücksichtsvoll zu fahren. In solchen Beispielen kann (können) die Komponente(n) zur Hindernisvermeidung Verkehrsgesetze, Straßenverkehrsregeln und Normen für rücksichtsvolles Fahren ignorieren, um sicherzustellen, dass es nicht zu Kollisionen zwischen dem Fahrzeug 1100 und irgendwelchen Objekten kommt. Die Schicht zur Hindernisvermeidung kann also eine von der Schicht mit den Verkehrsregeln getrennte Schicht sein, und die Schicht zur Hindernisvermeidung kann sicherstellen, dass das Fahrzeug 1100 nur sichere Aktionen unter dem Gesichtspunkt der Hindernisvermeidung durchführt. Die Schicht der Verkehrsregeln kann andererseits sicherstellen, dass das Fahrzeug die Verkehrsgesetze und -konventionen einhält und die gesetzliche und konventionelle Vorfahrt beachtet (wie hier beschrieben).
  • In einigen Beispielen können die befahrbaren Pfade und/oder Objektdetektionen von der/den Hindernisvermeidungskomponente(n) zum Bestimmen von Steuerungen oder zu ergreifenden Maßnahmen verwendet werden. Zum Beispiel können die befahrbaren Pfade eine Indikation für die Hindernisvermeidungskomponente(n) liefern, wo das Fahrzeug 1100 manövrieren kann, ohne auf irgendwelche Objekte, Strukturen und/oder dergleichen zu stoßen, oder zumindest, wo keine statischen Strukturen existieren können.
  • In nicht einschränkenden Ausführungsbeispielen kann die Hindernisvermeidungskomponente(n) als ein separates, eigenständiges Merkmal des Fahrzeugs 1100 implementiert werden. Beispielsweise kann (können) die Hindernisvermeidungskomponente(n) separat (z.B. parallel zu, vor und/oder nach) der Planungsschicht, der Steuerungsschicht, der Akteurschicht und/oder anderen Schichten des Drive-Stacks 428 operieren.
  • Als solches kann das Fahrzeug 1100 diese Informationen (z.B. als die Kanten oder Schienen der Pfade) verwenden, um zu navigieren, zu planen oder anderweitig eine oder mehrere Operationen (z.B. Spurhaltung, Spurwechsel, Pfadplanung, Zusammenführen, Aufteilen usw.) innerhalb der Umgebung durchzuführen.
  • 7 zeigt ein Beispiel für die Verlängerung eines vorhergesagten Pfades unter Verwendung eines kinetischen Bewegungsalgorithmus (auch bekannt als klassischer mechanischer Bewegungsalgorithmus), gemäß einiger Ausführungsbeispiele der vorliegenden Offenbarung. Wie hierin erörtert, können Orte (z.B. Trajektorien) für den einen oder die mehreren Akteure vorhergesagt und/oder bestimmt werden. In mindestens einem Ausführungsbeispiel kann zumindest ein erster Ort für einen oder mehrere Akteure einer Vorhersage entsprechen, die unter Verwendung eines oder mehrerer der hierin beschriebenen Vorhersage-MLM 104, Richtlinien-MLM 106 und/oder Wertfunktions-MLM 108 getroffen wurde. In einigen Ausführungsbeispielen kann der erste Ort zumindest bis zu einem zweiten Ort ausgedehnt werden, indem der kinetische Bewegungsalgorithmus verwendet wird, der beispielsweise eine stetige Trajektorie zum zweiten Ort annehmen kann, um eine erweiterte Trajektorie zu generieren. In mindestens einem Ausführungsbeispiel kann die hier beschriebene Wertfunktion auf der erweiterten Trajektorie für einen oder mehrere Akteure basieren.
  • Wie in 7 gezeigt, kann ein Fahrzeug 702 (mit den durch 702A-D angegebenen Orten) eine Trajektorie 704 durchfahren. Bei der Vorhersage von Trajektorien, die befolgt werden, um schließlich zu der Trajektorie 704 zu führen, kann ein klassischer mechanischer Bewegungsalgorithmus verwendet werden, um eine entsprechende Halte- oder erweiterte Trajektorie 706A-D für jede vorhergesagte Trajektorie zu berechnen. Zum Beispiel enthält das Fahrzeug 702 bei 702A eine vorhergesagte Trajektorie, die sich entlang einer Haltebahn 706A fortsetzt. Die Haltetrajektorie 706A kann zumindest teilweise basierend auf Akteursattributen des Fahrzeugs 702 am oder in der Nähe des Endes der vorhergesagten Trajektorie (z.B. Geschwindigkeit, Beschleunigung, Pose, etc.) berechnet werden. Die gehaltene Trajektorie 706A kann somit die vorhergesagte Trajektorie (z.B. entsprechend der Ausgabe 204 von 2) auf ein weiteres Zeitintervall verlängern, das von verschiedenen hierin beschriebenen Planungs- und Steuerungskomponenten verwendet werden kann. Während der klassische mechanische Bewegungsalgorithmus eine Richtung und/oder Geschwindigkeit des Fahrzeugs 702 beibehalten kann, wenn er den erweiterten Teil einer Trajektorie berechnet, können einige Beispiele die Variation der Richtung und/oder Geschwindigkeit oder die Beibehaltung einer oder mehrerer anderer Eigenschaften der vorhergesagten Trajektorie und/oder der Akteursattribute oder des Zustands (z.B. kann ein Krümmungswinkel beibehalten werden) beinhalten.
  • Unter Bezugnahme auf 8-10, umfasst jeder Block der hier beschriebenen Verfahren 800, 900 und 100 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Die Verfahren können auch als vom Rechner verwendbare Anweisungen, die auf Computerspeichermedien gespeichert sind, verkörpert werden. Die Verfahren können durch eine eigenständige Applikation, 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. Darüber hinaus werden die Verfahren 800, 900 und 1000 beispielhaft in Bezug auf das Modelltrainingssystem 100 von 1A beschrieben. Diese Verfahren können jedoch 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 Systeme. Beispielsweise können die Verfahren von einem System ausgeführt werden, das eine oder mehrere Verarbeitungseinheiten und eine oder mehrere Speichereinheiten umfasst, die Befehle speichern, die, wenn sie von der einen oder den mehreren Verarbeitungseinheiten ausgeführt werden, die eine oder die mehreren Verarbeitungseinheiten veranlassen, Operationen auszuführen.
  • 8 ist ein Flussdiagramm, das ein Verfahren 800 zum Trainieren eines maschinellen Lernmodells zur Vorhersage von Akteurbewegungen unter Verwendung von Akteurpositionen, die unter Verwendung eines DNN vorhergesagt werden, zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das Verfahren 800 umfasst in Block B802 das Bestimmen einer Akteursposition unter Verwendung eines Simulators. In einem oder mehreren Ausführungsbeispielen kann eine Position eines Akteurs ohne Einschränkung einen oder mehrere Orte, eine Pose, eine Orientierung, eine Größe, eine Höhe, ein Gieren, ein Nicken oder ein Rollen usw. des Akteurs umfassen. Beispielsweise kann die Trainings-Engine 112 unter Verwendung einer Simulation, die dem Weltzustand 118 entspricht, eine erste, zumindest eine Position eines oder mehrerer Akteure basierend zumindest auf einem ersten Zustand einer Umgebung bestimmen. Der eine oder die mehreren Akteure können das Fahrzeug und/oder zumindest ein anderes Fahrzeug umfassen.
  • Das Verfahren 800 umfasst in Block B804 die Anwendung der Position des Akteurs auf ein DNN, das trainiert wird, um eine zukünftige Position des Akteurs vorherzusagen. Beispielsweise kann die Trainings-Engine 112 die Simulationsdaten 102 auf das Vorhersage-MLM 104 anwenden, das trainiert wurde, um aus der ersten zumindest einen Position des einen oder der mehreren Akteure Vorhersagen einer zweiten zumindest einen Position des einen oder der mehreren Akteure zu generieren. In Ausführungsbeispielen wurde das Vorhersage-MLM 104 unter Verwendung von Nachahmungslernen basierend auf Daten aus der realen Welt trainiert.
  • Das Verfahren 800 umfasst in Block B806 die Anwendung von Daten, die einer Vorhersage des DNN entsprechen, auf ein MLM, um eine zukünftige Aktion für ein Fahrzeug vorherzusagen. Zum Beispiel kann die Trainings-Engine 1112 zweite Daten, die den Vorhersagen entsprechen (dt. auch die mit den Vorhersagen übereinstimmen), auf das Richtlinien-MLM 106 anwenden, um unter Verwendung des zumindest einen MLM eine Vorhersage zu generieren, die einer oder mehreren Aktionen für ein Fahrzeug entspricht.
  • Das Verfahren 800 umfasst in Block B808 die Zuweisung eines Punktewertes zu der Vorhersage. Zum Beispiel kann die Trainings-Engine 112 der Vorhersage einen oder mehrere Punktwerte zuweisen, indem sie eine Wertfunktion verwendet, die zumindest auf einem zweiten Zustand der Umgebung basiert, der den Vorhersagen entspricht.
  • Das Verfahren 800 umfasst in Block B810 die Aktualisierung eines Parameters des MLM basierend auf dem Punktwert. Beispielsweise kann die Trainings-Engine 112 einen oder mehrere Parameter des Richtlinien-MLM 106 zumindest basierend auf dem einen oder mehreren Punktwerten aktualisieren (z.B. der Dekodierer 306A und/oder 306B).
  • Das Verfahren 800 kann ferner das Vorhersagen einer oder mehrerer Positionen des einen oder der mehreren Akteure unter Verwendung des DNN enthalten, wobei das Bestimmen der ersten mindestens einen Position eines oder mehrerer Akteure das Anpassen mindestens einer der einen oder mehreren Positionen basierend auf dem Modellieren des Verhaltens eines Akteurs umfasst, um die erste mindestens eine Position zu generieren. Die zweite zumindest eine Position des einen oder der mehreren Akteure kann einer Trajektorie eines Akteurs entsprechen und das Verfahren umfasst das Erweitern der Trajektorie unter Verwendung eines klassischen mechanischen Bewegungsalgorithmus, um eine erweiterte Trajektorie zu generieren, wobei der eine oder die mehreren Punktwerte der erweiterten Trajektorie entsprechen. Das Verfahren 800 kann ferner das Bestimmen einer Kollision des Fahrzeugs in der Umgebung anhand des zweiten Zustands der Umgebung und das Berechnen des einen oder der mehreren Punktwerte basierend zumindest auf der Bestimmung der Kollision enthalten.
  • 9 ist ein Flussdiagramm, das ein Verfahren 900 zum Trainieren eines maschinellen Lernmodells zur Erstellung von Vorhersagen unter Verwendung eines DNN als Weltmodell zeigt, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das Verfahren 900 umfasst in Block B902 die Verwendung eines DNN als Weltmodell für eine Simulation. Zum Beispiel kann die Trainings-Engine 112 die Vorhersage MLM 104 als Weltmodell für eine Simulation verwenden.
  • Das Verfahren 900 umfasst in Block B904 das Trainieren eines MLM, um Vorhersagen unter Verwendung der Simulation zu treffen. Zum Beispiel kann die Trainings-Engine 112 bestärkendes Lernen anwenden, um zumindest ein MLM zu trainieren, um eine Vorhersage einer oder mehrerer Aktionen für eine Maschine zu generieren, die die Simulation verwendet. Ein latenter Raum des DNN kann in ein Weltzustandsmodell für die Simulation dekodiert werden, um das bestärkende Lernen anzuwenden, um das zumindest eine MLM unter Verwendung der Simulation zu trainieren. Das DNN kann unter Verwendung des Nachahmungslernens von realen Daten trainiert worden sein und kann verwendet werden, um das zumindest eine MLM zu trainieren, um eine Vorhersage einer Trajektorie für ein Fahrzeug zu generieren. Ein oder mehrere neuronale Netzwerke mit Wertfunktionen können trainiert werden, um eine Vorhersage von einem oder mehreren Punktwerten einer Wertfunktion des RL zu generieren.
  • 10 ist ein Flussdiagramm, das ein Verfahren 1000 zur Steuerung eines autonomen Fahrzeugs gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung auf der Grundlage von Vorhersagen zeigt, die unter Verwendung eines MLM simuliert wurden. Das Verfahren 1000, in Block B 1002, umfasst den Empfang von Sensordaten. Dies kann den Empfang von Sensordaten umfassen, die von einem oder mehreren Sensoren eines Fahrzeugs in einer Umgebung generiert werden.
  • Das Verfahren 1000, in Block B1004, umfasst das Bestimmen einer Position des Akteurs basierend auf den Sensordaten. Dies kann das Bestimmen, zumindest teilweise basierend auf den Sensordaten, einer ersten, zumindest einen Position eines oder mehrerer Akteure beinhalten.
  • Das Verfahren 1000 umfasst in Block B1006 die Anwendung von Daten auf ein MLM, um zukünftige Positionen von Akteuren vorherzusagen. Dies kann die Anwendung erster Daten auf ein Deep-Neural-Network (DNN) umfassen, das trainiert wurde, um aus der ersten zumindest einen Position des einen oder der mehreren Akteure Vorhersagen einer zweiten zumindest einen Position des einen oder der mehreren Akteure zu generieren.
  • Das Verfahren 1000 umfasst in Block B1008 die Anwendung von Daten auf ein neuronales Netzwerk zur Vorhersage von Werten einer Fahrrichtlinie (engl. driving policy, Fahrstrategie). Dies kann das Anwenden von zweiten Daten, die den Vorhersagen entsprechen, auf ein neuronales Netzwerk (z.B. die Wertfunktions-MLM 108) beinhalten, um unter Verwendung des neuronalen Netzwerks Vorhersagen von einem oder mehreren Werten einer Wertfunktion zu generieren, wobei der eine oder die mehreren Werte einer oder mehreren Fahrrichtlinien entsprechen. Die Wertfunktion kann eine Zustandswertfunktion umfassen. Die Zustände der Wertfunktion können Zeiten und Orten der zweiten, zumindest einen Position in einem latenten Raum des MLM entsprechen. In Ausführungsbeispielen kodieren die zweiten Daten ein oder mehrere Ziele für die eine oder mehrere Fahrrichtlinien, und der eine oder die mehreren Punktwerte entsprechen dem einen oder den mehreren Zielen. In Ausführungsbeispielen dekodiert das neuronale Netzwerk zumindest einen Teil des latenten Raums des DNN, um die Vorhersagen des einen oder der mehreren Punktwerte zu generieren.
  • Das Verfahren 1000 umfasst in Block B1010 das Bestimmen einer Fahrrichtlinie, die dem einen oder den mehreren Punktwerten entspricht. Das Verfahren 100 in Block B1012 umfasst die Durchführung einer Fahrzeugaktion basierend auf der Fahrrichtlinie. Dies kann die Übertragung von Daten beinhalten, die ein Fahrzeug veranlassen, eine oder mehrere Aktionen basierend auf der einen oder den mehreren Fahrrichtlinien durchzuführen.
  • BEISPIELHAFTES AUTONOMES FAHRZEUG
  • 11A ist eine Darstellung eines Beispiels eines autonomen Fahrzeugs 1100, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das autonome Fahrzeug 1100 (hier alternativ als „Fahrzeug 1100“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug umfassen, wie z.B. ein Auto, einen Lastwagen, einen Bus, ein Ersthilfe-Fahrzeug, ein Transportfahrzeug, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, einen Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne, ein an einen Anhänger gekoppeltes Fahrzeug und/oder eine andere Art von Fahrzeug (z.B., das unbemannt ist und/oder einen oder mehrere Passagiere aufnimmt). Autonome Fahrzeuge werden im Allgemeinen in Form von Automatisierungsstufen beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (Standard Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert werden. Das Fahrzeug 1100 kann gemäß einem oder mehreren der Level 3 - Level 5 der autonomen Fahrstufen funktionsfähig sein. Das Fahrzeug 1100 kann gemäß einem oder mehreren der Level 1 - Level 5 der autonomen Fahrstufen funktionsfähig sein. Zum Beispiel kann das Fahrzeug 1100 je nach Ausführungsbeispiel Fahrerassistenz (Stufe 1), partielle Automatisierung (Stufe 2), bedingte Automatisierung (Stufe 3), hohe Automatisierung (Stufe 4) und/oder vollständige Automatisierung (Stufe 5) bieten. Der Begriff „autonom“, wie er hier verwendet wird, kann jede und/oder alle Arten von Autonomie für das Fahrzeug 1100 oder eine andere Maschine umfassen, wie z.B. vollständig autonom, hochgradig autonom, bedingt autonom, partiell autonom, unterstützende Autonomie, teilautonom, primär autonom oder andere Bezeichnungen.
  • Das Fahrzeug 1100 kann Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z.B. 2, 4, 6, 8, 18, etc.), Reifen, Achsen und andere Komponenten eines Fahrzeugs enthalten. Das Fahrzeug 1100 kann ein Antriebssystem 1150 enthalten, wie z.B. einen Verbrennungsmotor, ein Hybrid-Elektrokraftwerk, einen reinen Elektromotor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 1150 kann mit einem Antriebsstrang des Fahrzeugs 1100 verbunden sein, der ein Getriebe umfassen kann, um den Antrieb des Fahrzeugs 1100 zu ermöglichen. Das Antriebssystem 1150 kann als Reaktion darauf gesteuert werden, dass es Signale von der Drosselklappe/Beschleunigungsvorrichtung 1152 empfängt.
  • Ein Lenksystem 1154, das ein Lenkrad enthalten kann, kann verwendet werden, um das Fahrzeug 1100 zu lenken (z.B. entlang eines gewünschten Pfades oder einer Route), wenn das Antriebssystem 1150 in Betrieb ist (z.B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 1154 kann Signale von einem Lenkaktuator 1156 empfangen. Das Lenkrad kann optional für die Vollautomatisierung (Stufe 5) eingesetzt werden.
  • Das Bremssensorsystem 1146 kann verwendet werden, um die Fahrzeugbremsen als Reaktion darauf zu betätigen, dass Signale von den Bremsaktuatoren 1148 und/oder den Bremssensoren empfangen werden.
  • Der/die Controller 1136, der/die ein oder mehrere System-on-Chips (SoCs) 1104 (11C) und/oder GPU(s) enthalten kann/können, kann/können Signale (z.B. repräsentativ für Befehle) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 1100 liefern. Zum Beispiel kann (können) das (die) Steuergerät(e) Signale senden, um die Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 1148 zu betätigen, um das Lenksystem 1154 über einen oder mehrere Lenkaktuatoren 1156 zu betätigen, um das Antriebssystem 1150 über einen oder mehrere Drossel-/Beschleunigungsaktuatoren 1152 zu betreiben. Das (die) Steuergerät(e) 1136 kann (können) ein oder mehrere eingebaute (z.B. integrierte) Rechengeräte (z.B. Supercomputer) umfassen, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z.B. Signale, die Befehle repräsentieren), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Fahren des Fahrzeugs 1100 zu unterstützen. Das/die Steuergerät(e) 1136 kann/können ein erstes Steuergerät 1136 für autonome Fahrfunktionen, ein zweites Steuergerät 1136 für funktionale Sicherheitsfunktionen, ein drittes Steuergerät 1136 für Funktionen der künstlichen Intelligenz (z.B. Computervision), ein viertes Steuergerät 1136 für Infotainmentfunktionen, ein fünftes Steuergerät 1136 für Redundanz in Notfällen und/oder andere Steuergeräte umfassen. In einigen Beispielen kann ein einziges Steuergerät 1136 zwei oder mehr der oben genannten Funktionen übernehmen, zwei oder mehr Steuergeräte 1136 können eine einzige Funktion übernehmen und/oder eine beliebige Kombination davon.
  • Das/die Steuergerät(e) 1136 kann/können die Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 1100 als Reaktion darauf bereitstellen, dass Sensordaten von einem oder mehreren Sensoren (z.B. Sensoreingaben) empfangen werden. Die Sensordaten können beispielsweise und ohne Einschränkung von (einem) Sensor(en) des globalen Navigationssatellitensystems 1158 (z.B. Global Positioning System-Sensor(en)), (einem) RADAR-Sensor(en) 1160, (einem) Ultraschallsensor(en) 1162, (einem) LIDAR-Sensor(en) 1164, (einem) Sensor(en) der Trägheitsmesseinheit (Inertialmesseinheit, IMU) 1166 (z.B., Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 1196, Stereokamera(s) 1168, Weitwinkelkamera(s) 1170 (z.B., Fischaugenkameras), Infrarotkamera(n) 1172, Surroundkamera(n) 1174 (z.B. 360-Grad-Kameras), Fern- und/oder Mitteldistanzkamera(n) 1198, Geschwindigkeitssensor(en) 1144 (z.B. zur Messung der Geschwindigkeit des Fahrzeugs 1100), Vibrationssensor(en) 1142, Lenksensor(en) 1140, Bremssensor(en) (z.B. als Teil des Bremssensorsystems 1146), und/oder andere Sensortypen.
  • Eines oder mehrere der Steuergeräte 1136 können Eingaben (z.B. repräsentiert durch Eingabedaten) von einem Kombiinstrument 1132 des Fahrzeugs 1100 empfangen und Ausgaben (z.B. repräsentiert durch Ausgabedaten, Anzeigedaten usw.) über eine Anzeige 1134 der Mensch-Maschine-Schnittstelle (HMI), einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 1100 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Geschwindigkeit, Zeit, Kartendaten (z.B. die HD-Karte 1122 von 11C), Ortsdaten (z.B. der Ort des Fahrzeugs 1100, wie auf einer Karte), Richtung, Ort anderer Fahrzeuge (z.B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie sie von dem/den Controllern) 1136 wahrgenommen werden, usw. umfassen. Beispielsweise kann die HMI-Anzeige 1134 Informationen über das Vorhandensein eines oder mehrerer Objekte (z.B. ein Straßenschild, ein Warnschild, eine sich ändernde Ampel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z.B. jetzt die Spur wechseln, in zwei Meilen die Ausfahrt 34B nehmen, usw.).
  • Das Fahrzeug 1100 enthält weiterhin eine Netzwerkschnittstelle 1124, die eine oder mehrere drahtlose Antenne(n) 1126 und/oder Modem(e) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann die Netzwerkschnittstelle 1124 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. zu kommunizieren. Die drahtlose(n) Antenne(n) 1126 kann/können 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 Weitverkehrsnetze mit geringer Leistung (LPWANs) wie LoRaWAN, SigFox usw. verwendet werden.
  • 11B ist ein Beispiel für Kamerastandorte und Sichtfelder für das autonome Fahrzeug 1100 von 11A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Die Kameras und die jeweiligen Sichtfelder stellen ein Ausführungsbeispiel dar und sind nicht als einschränkend zu betrachten. Beispielsweise können zusätzliche und/oder alternative Kameras enthalten sein und/oder die Kameras können an verschiedenen Orten des Fahrzeugs 1100 angeordnet sein.
  • Die Kameratypen für die Kameras können unter anderem Digitalkameras umfassen, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 1100 ausgebildet sein können. Die Kamera(s) kann/können auf der Sicherheitsstufe (ASIL) B und/oder auf einer anderen ASIL betrieben werden. Die Kameratypen können je nach Ausführungsbeispiel eine beliebige Bildaufnahmerate haben, z. B. 60 Bilder pro Sekunde (fps), 120 fps, 240 fps usw. Die Kameras können Rolling Shutter, Global Shutter, einen anderen Verschlusstyp oder eine Kombination davon verwenden. In einigen Beispielen kann das Farbfilter-Array ein Rot-Klar-Klar-Klar-Farbfilter-Array (RCCC), ein Rot-Klar-Klar-Blau-Farbfilter-Array (RCCB), ein Rot-Blau-Grün-Klar-Farbfilter-Array (RBGC), ein Foveon X3 Farbfilter-Array, ein Bayer-Sensor-Farbfilter-Array (RGGB), ein Monochrom-Sensor-Farbfilter-Array und/oder eine andere Art von Farbfilter-Array umfassen. In einigen Ausführungsbeispielen können zur Erhöhung der Lichtempfindlichkeit Clear-Pixel-Kameras, wie z. B. Kameras mit einem RCCC-, einem RCCB- und/oder einem RBGC-Farbfilter-Array, verwendet werden.
  • In einigen Beispielen können eine oder mehrere der Kameras verwendet werden, um erweiterte Funktionen von Fahrerassistenzsystemen (ADAS) auszuführen (z.B. als Teil eines redundanten oder ausfallsicheren Designs). So kann beispielsweise eine Multi-Funktions-Monokamera installiert werden, um Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitzustellen. Eine oder mehrere der Kameras (z.B. alle Kameras) können gleichzeitig Bilddaten (z.B. Video) aufzeichnen und liefern.
  • Eine oder mehrere der Kameras können in einer Montagevorrichtung, wie z.B. einer kundenspezifischen (3-D-gedruckten) Vorrichtung, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z.B. Reflexionen vom Armaturenbrett, die sich in den Außenspiegeln der Windschutzscheibe spiegeln) auszuschalten, die die Bilddatenerfassung der Kamera beeinträchtigen könnten. Bei der Montage von Außenspiegeln können die Außenspiegel kundenspezifisch dreidimensional gedruckt werden, so dass die Kameramontageplatte der Form des Außenspiegels entspricht. In einigen Beispielen können die Kameras in den Außenspiegel integriert werden. Bei Seitenkameras können die Kameras auch in die vier Säulen an jeder Ecke der Kabine integriert werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 1100 einschließt (z.B. nach vorne gerichtete Kameras), können für die Surround-Sicht verwendet werden, um nach vorne gerichtete Pfade und Hindernisse zu identifizieren und um mit Hilfe eines oder mehrerer Steuergeräte 1136 und/oder Steuer-SoCs Informationen bereitzustellen, die für das Generieren eines Belegungsrasters und/oder das Bestimmen der bevorzugten Pfade des Fahrzeugs entscheidend sind. Nach vorne gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorne gerichtete Kameras können auch für ADAS-Funktionen und -Systeme verwendet werden, z. B. für Spurverlassenswarnungen (Lane Departure Warnings, LDW), autonome Geschwindigkeitsregelung (Autonomous Cruise Control, ACC) und/oder andere Funktionen wie die Erkennung von Verkehrszeichen.
  • In einer nach vorne gerichteten Konfiguration kann eine Vielzahl von Kameras verwendet werden, z. B. eine monokulare Kameraplattform mit einem CMOS-Farbbildsensor (Complementary Metal Oxide Semiconductor). Ein weiteres Beispiel sind eine oder mehrere Weitwinkelkameras 1170, die dazu verwendet werden können, Objekte zu erkennen, die von der Peripherie her ins Blickfeld geraten (z.B. Fußgänger, kreuzenden Verkehr oder Fahrräder). Obwohl in 11B nur eine Weitwinkelkamera dargestellt ist, kann sich eine beliebige Anzahl von Weitwinkelkameras 1170 am Fahrzeug 1100 befinden. Darüber hinaus kann/können die Weitwinkelkamera(s) 1198 (z.B. ein Weitwinkel-Stereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netzwerk noch nicht trainiert wurde. Die Langstreckenkamera(s) 1198 kann/können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
  • Eine oder mehrere Stereokameras 1168 können auch in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 1168 kann/können eine integrierte Steuereinheit enthalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (FPGA) und einen Multi-Core-Mikroprozessor mit integrierter CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Eine solche Einheit kann verwendet werden, um eine 3D-Karte der Fahrzeugumgebung zu generieren, einschließlich einer Abschätzung der Entfernung für alle Punkte im Bild. Eine alternative Stereokamera(s) 1168 kann einen kompakten Stereo Vision Sensor(s) umfassen, der zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip enthält, der den Abstand zwischen dem Fahrzeug und dem Zielobjekt messen und die generierten Informationen (z.B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurhaltewarnfunktionen verwenden kann. Zusätzlich oder alternativ zu den hier beschriebenen Stereokameras können auch andere Typen von Stereokameras (1168) verwendet werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 1100 einschließt (z.B. Seitenkameras), können für die Surround-Sicht verwendet werden und Informationen liefern, die zum Erstellen und Aktualisieren des Belegungsgitters sowie zum Generieren von Seitenaufprallwarnungen verwendet werden. Beispielsweise können die Surround-Kamera(s) 1174 (z.B. vier Surround-Kameras 1174, wie in 11B dargestellt) auf dem Fahrzeug 1100 positioniert werden. Die Surround-Kamera(s) 1174 kann/können Weitwinkelkamera(s) 1170, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches umfassen. Vier Beispiele: Vier Fischaugenkameras können an der Vorderseite, am Heck und an den Seiten des Fahrzeugs positioniert werden. In einer alternativen Anordnung kann das Fahrzeug drei Surround-Kamera(s) 1174 (z.B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z.B. eine nach vorne gerichtete Kamera) als vierte Surround-View-Kamera einsetzen.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 1100 einschließt (z.B. Rückfahrkameras), können für die Einparkhilfe, die Surround-Ansicht, die Heckkollisionswarnungen und die Erstellung und Aktualisierung des Belegungsrasters verwendet werden. Es kann eine Vielzahl von Kameras verwendet werden, einschließlich, aber nicht beschränkt auf Kameras, die auch als nach vorne gerichtete Kamera(s) geeignet sind (z.B. Fern- und/oder Mitteldistanzkamera(s) 1198, Stereokamera(s) 1168), Infrarotkamera(s) 1172 usw.), wie hier beschrieben.
  • 11C ist ein Blockdiagramm einer Beispielsystemarchitektur für das autonome Fahrzeug 1100 von 11A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Es sollte verstanden werden, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der dargestellten verwendet werden, und einige Elemente können ganz weggelassen werden. Weiter sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Zum Beispiel können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Alle Komponenten, Merkmale und Systeme des Fahrzeugs 1100 in 11C sind so dargestellt, dass sie über den Bus 1102 verbunden sind. Der Bus 1102 kann eine Controller Area Network (CAN)-Datenschnittstelle (hier alternativ als „CAN-Bus“ bezeichnet) enthalten. Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 1100 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 1100 verwendet wird, wie z.B. Betätigung der Bremsen, Beschleunigung, Bremsen, Lenkung, Scheibenwischer, usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten besitzt, von denen jeder seine eigene eindeutige Kennung (z.B. eine CAN-ID) hat. Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, die Fahrgeschwindigkeit, die Drehzahl des Motors (RPM), die Positionen der Tasten und/oder andere Indikationen für den Fahrzeugstatus zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
  • Obwohl der Bus 1102 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. So können beispielsweise zusätzlich oder alternativ zum CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Auch wenn eine einzelne Leitung verwendet wird, um den Bus 1102 zu repräsentieren, ist dies nicht als Einschränkung zu verstehen. Beispielsweise kann es eine beliebige Anzahl von Bussen 1102 geben, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Arten von Bussen, die ein anderes Protokoll verwenden, umfassen können. In einigen Beispielen können zwei oder mehr Busse 1102 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder sie können zur Redundanz verwendet werden. Beispielsweise kann ein erster Bus 1102 für die Kollisionsvermeidungsfunktionalität und ein zweiter Bus 1102 für die Aktuatorsteuerung verwendet werden. In jedem Beispiel kann jeder Bus 1102 mit jeder Komponente des Fahrzeugs 1100 kommunizieren, und zwei oder mehr Busse 1102 können mit denselben Komponenten kommunizieren. In einigen Beispielen kann jeder SoC 1104, jedes Steuergerät 1136 und/oder jeder Rechner innerhalb des Fahrzeugs Zugang zu denselben Eingabedaten (z.B. Eingaben von Sensoren des Fahrzeugs 1100) haben und mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
  • Das Fahrzeug 1100 kann ein oder mehrere Steuergerät(e) 1136 enthalten, wie sie hier mit Bezug auf 11A beschrieben sind. Das/die Steuergerät(e) 1136 kann/können für eine Vielzahl von Funktionen verwendet werden. Das (die) Steuergerät(e) 1136 kann (können) mit den verschiedenen anderen Komponenten und Systemen des Fahrzeugs 1100 gekoppelt werden und kann (können) für die Steuerung des Fahrzeugs 1100, die künstliche Intelligenz des Fahrzeugs 1100, das Infotainment für das Fahrzeug 1100 und/oder ähnliches verwendet werden.
  • Das Fahrzeug 1100 kann ein oder mehrere System(e) auf einem Chip (SoC) 1104 enthalten. Der SoC 1104 kann CPU(s) 1106, GPU(s) 1108, Prozessor(en) 1110, Cache(s) 1112, Beschleuniger 1114, Datenspeicher 1116 und/oder andere nicht dargestellte Komponenten und Merkmale umfassen. Der/die SoC(s) 1104 kann/können zur Steuerung des Fahrzeugs 1100 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise kann der/die SoC(s) 1104 in einem System (z.B. dem System des Fahrzeugs 1100) mit einer HD-Karte 1122 kombiniert werden, die über eine Netzwerkschnittstelle 1124 von einem oder mehreren Servern (z.B. dem/den Server(n) 1178 der 11D) Kartenauffrischungen und/oder Aktualisierungen erhalten kann.
  • Die CPU(s) 1106 kann/können einen CPU-Cluster oder CPU-Komplex (hier auch als „CCPLEX“ bezeichnet) umfassen. Die CPU(s) 1106 kann/können mehrere Kerne und/oder L2-Caches enthalten. In einigen Ausführungsbeispielen können die CPU(s) 1106 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In einigen Ausführungsbeispielen kann (können) die CPU(s) 1106 vier Dual-Core-Cluster umfassen, wobei jeder Cluster über einen dedizierten L2-Cache (z.B. einen 2 MB L2-Cache) verfügt. Die CPU(s) 1106 (z.B. der CCPLEX) kann/können so konfiguriert werden, dass sie die gleichzeitige Operation von Clustern unterstützt/unterstützen, so dass eine beliebige Kombination von Clustern der CPU(s) 1106 zu jedem gegebenen Zeitpunkt aktiv sein kann.
  • Die CPU(s) 1106 kann/können Energieverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Merkmale umfassen: individuelle Hardwareblöcke können im Leerlauf automatisch getaktet werden, um dynamische Energie zu sparen; jeder Kerntakt kann getaktet werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig stromversorgt werden; jeder Kern-Cluster kann unabhängig getaktet werden, wenn alle Kerne taktversorgt oder stromversorgt sind; und/oder jeder Kern-Cluster kann unabhängig stromversorgt werden, wenn alle Kerne stromversorgt sind. Die CPU(s) 1106 kann/können weiter einen verbesserten Algorithmus zur Verwaltung von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufwachzeiten angegeben werden und die Hardware/der Mikrocode den besten Energiezustand für den Kern, den Cluster und CCPLEX bestimmt. Die Verarbeitungskerne können vereinfachte Sequenzen für die Eingabe des Energiezustands in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
  • Der/die Grafikprozessor(en) 1108 kann/können einen integrierten Grafikprozessor (hier auch als „iGPU“ bezeichnet) umfassen. Die GPU(s) 1108 kann/können programmierbar und für parallele Arbeitslasten effizient sein. Die GPU(s) 1108 kann/können in einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Der (die) GPU(s) 1108 kann (können) einen oder mehrere Strom-Mikroprozessoren enthalten, wobei jeder Strom-Mikroprozessor einen L1-Cache (z.B. einen L1-Cache mit zumindest 96 KB Speicherkapazität) enthalten kann, und zwei oder mehr der Strom-Mikroprozessoren können sich einen L2-Cache (z.B. einen L2-Cache mit 512 KB Speicherkapazität) teilen. In einigen Ausführungsbeispielen können die GPU(s) 1108 zumindest acht Strom-Mikroprozessoren umfassen. Der/die Grafikprozessor(en) 1108 kann/können Programmierschnittstelle(n) (API(s)) zum Berechnen von Anwendungen verwenden. Darüber hinaus kann/können der/die Grafikprozessor(en) 1108 eine oder mehrere Plattformen für paralleles Rechnen und/oder Programmiermodelle (z.B. CUDA von NVIDIA) verwenden.
  • Der/die Grafikprozessor(en) 1108 kann/können für die beste Leistung in automobilen und eingebetteten Anwendungsfällen optimiert werden. Beispielsweise können die GPU(s) 1108 auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Dies ist jedoch nicht als Einschränkung zu verstehen, und die GPU(s) 1108 können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Strom-Mikroprozessor kann eine Anzahl von Verarbeitungskernen mit gemischter Genauigkeit enthalten, die in mehrere Blöcke unterteilt sind. So können beispielsweise 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungskerne unterteilt werden, ohne darauf beschränkt zu sein. In einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32 Kerne, 8 FP64 Kerne, 16 INT32 Kerne, zwei NVIDIA TENSOR COREs mit gemischter Genauigkeit zur Deep-Learning-Matrixarithmetik, ein L0-Befehlscache, ein Warp-Planer, eine Sendeeinheit und/oder eine 64 KB große Registerdatei zugewiesen werden. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkomma-Datenpfade enthalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnen und Adressieren zu ermöglichen. Die Strom-Mikroprozessoren können eine unabhängige Thread-Planungsfunktion enthalten, um eine feinkörnigere Synchronisation und Zusammenarbeit zwischen parallelen Threads zu ermöglichen. Die Strom-Mikroprozessoren können einen kombinierten L1-Datencache und eine gemeinsam genutzte Speichereinheit enthalten, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
  • Der/die Grafikprozessor(en) 1108 kann/können einen Speicher mit hoher Bandbreite (HBM) und/oder ein 16-GB-HBM2-Speicher-Subsystem umfassen, um in einigen Beispielen eine Spitzen-Speicherbandbreite von etwa 900 GB/Sekunde zu erreichen. In einigen Beispielen kann zusätzlich zu oder alternativ zu dem HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) verwendet werden, z. B. ein synchroner Grafik-Doppeldatenraten-Direktzugriffsspeicher vom Typ 5 (GDDR5).
  • Die GPU(s) 1108 kann/können eine einheitliche Speichertechnologie mit Zugriffszählern enthalten, um eine genauere Migration von Speicherseiten zu dem Prozessor zu ermöglichen, der am häufigsten auf sie zugreift, wodurch die Effizienz für gemeinsam genutzte Speicherbereiche zwischen Prozessoren verbessert wird. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, damit die GPU(s) 1108 direkt auf die Seitentabellen der CPU(s) 1106 zugreifen kann. In solchen Beispielen kann, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 1108 einen Fehler feststellt, eine Adressübersetzungsanforderung an die CPU(s) 1106 übermittelt werden. Als Reaktion darauf kann die CPU(s) 1106 in ihren Seitentabellen nach der virtuell-physikalischen Zuordnung für die Adresse suchen und die Übersetzung an die GPU(s) 1108 zurückübertragen. Die Unified-Memory-Technologie ermöglicht einen einzigen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 1106 als auch der GPU(s) 1108 und vereinfacht so die Programmierung der GPU(s) 1108 und die Portierung von Applikationen auf die GPU(s) 1108.
  • Darüber hinaus kann die GPU(s) 1108 einen Zugriffszähler enthalten, der die Häufigkeit des Zugriffs der GPU(s) 1108 auf den Speicher anderer Prozessoren verfolgen kann. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
  • Der/die SoC(s) 1104 kann/können eine beliebige Anzahl von Cache(s) 1112 enthalten, einschließlich der hier beschriebenen. Der/die Cache(s) 1112 kann/können beispielsweise einen L3-Cache enthalten, der sowohl der/den CPU(s) 1106 als auch der/den GPU(s) 1108 zur Verfügung steht (z.B. der sowohl mit der/den CPU(s) 1106 als auch mit der/den GPU(s) 1108 verbunden ist). Der/die Cache(s) 1112 kann/können einen Write-Back-Cache enthalten, der die Zustände der Zeilen verfolgen kann, z.B. durch Verwenden eines Cache-Kohärenzprotokolls (z.B. MEI, MESI, MSI, etc.). Der L3-Cache kann je nach Ausführungsbeispiel 4 MB oder mehr umfassen, obwohl auch kleinere Cache-Größen verwendet werden können.
  • Der/die SoC(s) 1104 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) enthalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der vielen Aufgaben oder Operationen des Fahrzeugs 1100 - wie z. B. der Verarbeitung von DNNs - eingesetzt werden kann. Darüber hinaus kann der SoC 1104 eine oder mehrere Gleitkommaeinheiten (FPU(s)) - oder andere mathematische Koprozessoren oder numerische Koprozessoren - zur Durchführung mathematischer Operationen innerhalb des Systems enthalten. Beispielsweise können die SoC(s) 104 eine oder mehrere FPUs enthalten, die als Ausführungseinheiten in einer oder mehreren CPU(s) 1106 und/oder GPU(s) 1108 integriert sind.
  • Der/die SoC(s) 1104 kann/können einen oder mehrere Beschleuniger 1114 (z.B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon) enthalten. Beispielsweise können die SoC(s) 1104 einen Hardware-Beschleunigungscluster enthalten, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher umfassen kann. Der große On-Chip-Speicher (z.B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster in die Lage versetzen, neuronale Netzwerke und andere Berechnungen zu beschleunigen. Der Hardware-Beschleunigungscluster kann zur Ergänzung der GPU(s) 1108 und zur Entlastung einiger Aufgaben der GPU(s) 1108 verwendet werden (z.B. um mehr Zyklen der GPU(s) 1108 für die Durchführung anderer Aufgaben freizugeben). Der/die Beschleuniger 1114 kann/können beispielsweise für gezielte Arbeitslasten (z.B. Wahrnehmung, Convolutional Neural Networks (CNNs) usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der hier verwendete Begriff „CNN“ kann alle Arten von CNNs umfassen, einschließlich regionenbasierter oder regionaler Convolutional Neural Networks (RCNNs) und Fast RCNNs (z.B. für die Objekterkennung verwendet).
  • Der/die Beschleuniger 1114 (z.B. der Hardware-Beschleunigungscluster) kann/können einen Deep-Learning-Beschleuniger (DLA) enthalten. Der/die DLA(s) kann/können eine oder mehrere Tensor Processing Units (TPUs) umfassen, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Leaming-Anwendungen und Inferenzieren bereitstellen. Bei den TPUs kann es sich um Beschleuniger handeln, die für die Ausführung von Bildverarbeitungsfunktionen (z.B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Der/die DLA(s) kann/können weiter für eine bestimmte Gruppe von Typen neuronaler Netzwerke und Gleitkommaoperationen sowie Inferenzieren optimiert werden. Das Design der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Allzweck-GPU und übertrifft die Leistung einer CPU bei weitem. Die TPU(s) kann/können mehrere Funktionen ausführen, darunter eine Faltungsfunktion mit einer Instanz, die beispielsweise INT8-, INT16- und FP16-Datentypen sowohl für Merkmale als auch für Gewichte unterstützt, sowie Postprozessorfunktionen.
  • Der (die) DLA(s) kann (können) schnell und effizient neuronale Netzwerke, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, darunter beispielsweise und ohne Einschränkung: ein CNN für die Identifizierung und Detektierung von Objekten unter Verwendung von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Erkennung und Identifizierung von Einsatzfahrzeugen und die Erkennung unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und die Identifizierung von Fahrzeugbesitzern unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsrelevante Ereignisse.
  • Der/die DLA(s) kann/können jede Funktion des/der GPU(s) 1108 ausführen, und durch Verwenden eines Inferenzbeschleunigers kann ein Entwickler beispielsweise entweder den/die DLA(s) oder den/die GPU(s) 1108 für eine beliebige Funktion einsetzen. So kann der Entwickler beispielsweise die Verarbeitung von CNNs und Gleitkommaoperationen auf den/die DLA(s) konzentrieren und andere Funktionen dem/den GPU(s) 1108 und/oder anderen Beschleunigern 1114 überlassen.
  • Der/die Beschleuniger 1114 (z.B. der Hardware-Beschleunigungscluster) kann/können einen programmierbaren Visionsbeschleuniger (engl. programmable vision accelerator, PVA) enthalten, der hier auch als Computervision-Beschleuniger bezeichnet werden kann. Der PVA kann so konzipiert und konfiguriert sein, dass er Computervision-Algorithmen für fortschrittliche Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented Reality (AR) und/oder Virtual Reality (VR) Applikationen beschleunigt. Der (die) PVA kann (können) ein Gleichgewicht zwischen Leistung und Flexibilität bieten. So kann jede PVA beispielsweise und ohne Einschränkung eine beliebige Anzahl von Rechenkernen mit reduziertem Befehlssatz (RISC), direkten Speicherzugriff (DMA) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
  • Die RISC-Kerne können mit Bildsensoren (z.B. den Bildsensoren einer der hier beschriebenen Kameras), Bildsignalprozessoren und/oder dergleichen zusammenwirken. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher enthalten. Die RISC-Kerne können je nach Ausführungsbeispiel eine beliebige Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. Die RISC-Kerne können unter Verwendung eines oder mehrerer integrierter Geräte, anwendungsspezifischer integrierter Schaltungen (ASICs) und/oder Speichergeräte implementiert werden. Die RISC-Kerne können beispielsweise einen Befehls-Cache und/oder ein eng gekoppeltes RAM enthalten.
  • Der DMA kann es Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 1106 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Funktionen unterstützen, die zur Optimierung der PVA verwendet werden, einschließlich, aber nicht beschränkt auf die Unterstützung von multidimensionaler Adressierung und/oder zirkulärer Adressierung. In einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die Blockbreite, Blockhöhe, Blocktiefe, horizontale Blockabstufung, vertikale Blockabstufung und/oder Tiefenabstufung umfassen können.
  • Bei den Vektorprozessoren kann es sich um programmierbare Prozessoren handeln, die so konzipiert sein können, dass sie die Programmierung von Algorithmen für die Computervision effizient und flexibel ausführen und Signalverarbeitungsfunktionen bereitstellen. In einigen Beispielen kann die PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen umfassen. Der PVA-Kem kann ein Prozessor-Subsystem, DMA-Engine(s) (z.B. zwei DMA-Engines) und/oder andere Peripheriegeräte umfassen. Das Vektorverarbeitungs-Subsystem kann als primäre Engine der PVA arbeiten und eine Vektorverarbeitungseinheit (VPU), einen Befehlscache und/oder einen Vektorspeicher (z.B. VMEM) umfassen. Ein VPU-Kern kann einen digitalen Signalprozessor wie z. B. einen SIMD-Digitalprozessor (Single Instruction, Multiple Data) mit sehr langen Befehlsworten (VLIW) enthalten. Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
  • Jeder der Vektorprozessoren kann einen Befehls-Cache enthalten und mit einem dedizierten Speicher gekoppelt sein. Daher kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren arbeitet. In anderen Beispielen können die Vektorprozessoren, die in einer bestimmten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität verwenden. In einigen Ausführungsbeispielen kann die Vielzahl von Vektorprozessoren, die in einer einzigen PVA enthalten sind, denselben Computervision-Algorithmus ausführen, jedoch für unterschiedliche Bereiche eines Bildes. In anderen Beispielen können die in einer bestimmten PVA enthaltenen Vektorprozessoren gleichzeitig verschiedene Algorithmen der Computervision für dasselbe Bild oder sogar verschiedene Algorithmen für aufeinander folgende Bilder oder Teile eines Bildes ausführen. Unter anderem kann eine beliebige Anzahl von PVAs im Hardware-Beschleunigungscluster enthalten sein und eine beliebige Anzahl von Vektorprozessoren in jeder der PVAs. Der/die PVA kann/können außerdem einen zusätzlichen ECC-Speicher (Error Correcting Code) enthalten, um die Sicherheit des Gesamtsystems zu erhöhen.
  • Der (die) Rechner 1114 (z.B. der Hardware-Beschleunigungscluster) kann (können) ein Computervisions-Netzwerk auf dem Chip und SRAM enthalten, um ein SRAM mit hoher Bandbreite und geringer Latenz für den (die) Rechner 1114 bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher zumindest 4 MB SRAM umfassen, der beispielsweise und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl die PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine APB-Schnittstelle (Advanced Peripheral Bus), Konfigurationsschaltungen, einen Controller und einen Multiplexer umfassen. Es kann jeder beliebige Speichertyp verwendet werden. Der PVA und der DLA können über einen Backbone auf den Speicher zugreifen, der dem PVA und dem DLA einen Hochgeschwindigkeitszugriff auf den Speicher ermöglicht. Das Backbone kann ein Computervisions-Netzwerk auf dem Chip umfassen, das die PVA und den DLA mit dem Speicher verbindet (z.B. unter Verwendung des APB).
  • Das Computervisions-Netzwerk auf dem Chip kann eine Schnittstelle enthalten, die vor der Übertragung von Steuersignalen/Adressen/Daten bestimmt, dass sowohl die PVA als auch der DLA einsatzbereite und gültige Signale liefern. Eine solche Schnittstelle kann getrennte Phasen und getrennte Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-Kommunikation für die kontinuierliche Datenübertragung vorsehen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, es können aber auch andere Normen und Protokolle verwendet werden.
  • In einigen Beispielen können die SoC(s) 1104 einen Echtzeit-Raytracing-Hardwarebeschleuniger enthalten, wie er in der am 10. August 2018 eingereichten US-Patentanmeldung Nr. 16/101,232 beschrieben ist. Der Echtzeit-Raytracing-Hardwarebeschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z.B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeit-Visualisierungssimulationen zu generieren, für die RADAR-Signalinterpretation, für die Schallausbreitungssynthese und/oder -analyse, für die Simulation von SONAR-Systemen, für die allgemeine Wellenausbreitungssimulation, für den Vergleich mit LIDAR-Daten zum Zweck der Lokalisierung und/oder für andere Funktionen und/oder für andere Zwecke. In einigen Ausführungsbeispielen können eine oder mehrere Tree Traversal Units (TTUs) verwendet werden, um eine oder mehrere Operationen im Zusammenhang mit der Strahlenverfolgung auszuführen.
  • Der/die Beschleuniger 1114 (z.B. der Hardware-Beschleuniger-Cluster) haben ein breites Array an Verwendungen für das autonome Fahren. Der PVA kann ein programmierbarer Visionsbeschleuniger sein, der für wichtige Verarbeitungsschritte in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten der PVA eignen sich gut für algorithmische Bereiche, in denen eine vorhersehbare Verarbeitung bei geringem Stromverbrauch und geringer Latenzzeit erforderlich ist. Mit anderen Worten: Der PVA eignet sich gut für halbdichtes oder dichtes regelmäßiges Rechnen, selbst bei kleinen Datensätzen, die vorhersehbare Laufzeiten mit geringer Latenz und geringem Stromverbrauch erfordern. Im Zusammenhang mit Plattformen für autonome Fahrzeuge sind die PVAs daher für die Ausführung klassischer Algorithmen der Computervision ausgelegt, da diese effizient bei der Objekterkennung sind und mit ganzzahligen Berechnungen arbeiten.
  • Der PVA wird beispielsweise gemäß einem Ausführungsbeispiel der Technologie zur Durchführung von Computervision verwendet. In einigen Beispielen kann ein auf semiglobalem Abgleich basierender Algorithmus verwendet werden, wobei dies nicht als Einschränkung zu verstehen ist. Viele Applikationen für das autonome Fahren der Stufen 3-5 erfordern eine Bewegungsabschätzung/Stereoabgleich während der Fahrt (z.B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Der PVA kann eine Computer-Stereovision-Funktion auf Eingaben von zwei monokularen Kameras ausführen.
  • In einigen Beispielen kann der PVA zur Durchführung eines dichten optischen Flusses verwendet werden. Gemäß der Verarbeitung von RADAR-Rohdaten (z.B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um verarbeitete RADAR-Daten bereitzustellen. In anderen Beispielen wird die PVA zur Verarbeitung der Flugzeittiefe verwendet, indem sie z. B. Flugzeit-Rohdaten verarbeitet, um verarbeitete Flugzeitdaten zu liefern.
  • Der DLA kann verwendet werden, um jede Art von Netzwerk zu betreiben, um die Kontrolle und die Fahrsicherheit zu verbessern, z. B. ein neuronales Netzwerk, das ein Konfidenzmaß für jede Objekterkennung ausgibt. Ein solcher Konfidenz-Wert kann als Wahrscheinlichkeit oder als relative „Gewichtung“ jeder Erkennung im Vergleich zu anderen Erkennungen interpretiert werden. Dieser Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als echte positive Erkennungen und welche als falsche positive Erkennungen zu betrachten sind. So kann das System beispielsweise einen Schwellenwert für die Konfidenz festlegen und nur die Erkennungen, die diesen Schwellenwert überschreiten, als echte positive Erkennungen betrachten. In einem automatischen Notbremssystem (AEB) würden falsch positive Erkennungen das Fahrzeug veranlassen, automatisch eine Notbremsung durchzuführen, was natürlich unerwünscht ist. Daher sollten nur die Erkennungen mit der höchsten Konfidenz als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netzwerk zur Regression des Konfidenzwertes einsetzen. Das neuronale Netzwerk kann als Eingabe zumindest eine Teilmenge von Parametern verwenden, wie z.B. die Abmessungen des Begrenzungsrahmens, die (z.B. von einem anderen Teilsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des IMU-Sensors 1166, die mit der Ausrichtung des Fahrzeugs 1100 korreliert, die Entfernung, die 3D-Schätzungen des Ortes des Objekts, die vom neuronalen Netzwerk und/oder anderen Sensoren (z.B. LIDAR-Sensor(en) 1164 oder RADAR-Sensor(en) 1160) erhalten werden, und andere.
  • Der/die SoC(s) 1104 kann/können Datenspeicher 1116 (z.B. einen Speicher) enthalten. Bei dem/den Datenspeicher(n) 1116 kann es sich um einen On-Chip-Speicher des/der SoC(s) 1104 handeln, der neuronale Netzwerke speichern kann, die auf der GPU und/oder dem DLA ausgeführt werden sollen. In einigen Beispielen kann die Kapazität des/der Datenspeicher(s) 1116 groß genug sein, um mehrere Instanzen von neuronalen Netzwerken aus Gründen der Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 1112 kann/können L2 oder L3 Cache(s) 1112 umfassen. Der Verweis auf den/die Datenspeicher 1116 kann einen Verweis auf den mit der PVA, DLA und/oder anderen Beschleunigern 1114 assoziierten Speicher beinhalten, wie hier beschrieben.
  • Der/die SoC(s) 1104 kann/können einen oder mehrere Prozessor(en) 1110 (z.B. eingebettete Prozessoren) enthalten. Der (die) Prozessor(en) 1110 kann (können) einen Boot- und Leistungsverwaltungsprozessor enthalten, der ein dedizierter Prozessor und ein Subsystem sein kann, um Boot-Energie- und Verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Leistungsverwaltungsprozessor kann Teil der Bootsequenz des/der SoC(s) 1104 sein und Dienste zur Verwaltung der Laufzeitleistung bereitstellen. Der Boot- und Leistungsverwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Übergängen in einen Zustand mit geringer Leistung, Verwaltung von SoC(s) 1104-Temperaturen und Temperatursensoren und/oder Verwaltung der SoC(s) 1104-Leistungszustände bieten. Jeder Temperatursensor kann als Ringoszillator implementiert werden, dessen Ausgabefrequenz proportional zur Temperatur ist, und der/die SoC(s) 1104 kann/können die Ringoszillatoren verwenden, um die Temperaturen der CPU(s) 1106, der GPU(s) 1108 und/oder des/der Beschleuniger(s) 1114 zu ermitteln. Wird festgestellt, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Leistungsverwaltungsprozessor in eine Temperaturfehlerroutine eintreten und den/die SoC(s) 1104 in einen niedrigeren Leistungszustand versetzen und/oder das Fahrzeug 1100 in einen Fahrmodus zum sicheren Anhalten versetzen (z.B. das Fahrzeug 1100 zu einem sicheren Halt bringen).
  • Der (die) Prozessor(en) 1110 kann (können) weiter einen Satz eingebetteter Prozessoren enthalten, die als Audioverarbeitungs-Engine dienen können. Bei der Audioverarbeitungs-Engine kann es sich um ein Audio-Subsystem handeln, das eine vollständige Hardware-Unterstützung für Multi-Channel-Audio über mehrere Schnittstellen und eine breite und flexible Palette von Audio-E/A-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
  • Der (die) Prozessor(en) 1110 kann (können) weiterhin eine ständig eingeschaltete Engine enthalten, die die erforderlichen Hardwarefunktionen zur Unterstützung der Verwaltung von Sensoren mit geringem Stromverbrauch und des Aufwachens von Anwendungen bereitstellt. Die „always on“-Prozessor-Engine kann einen Prozessorkern, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z.B. Timer und Interrupt-Controller), verschiedene E/A-Controller-Peripheriegeräte und Routing-Logik umfassen.
  • Der/die Prozessor(en) 1110 kann/können weiter eine Safety-Cluster-Engine enthalten, die ein dediziertes Prozessor-Subsystem für die Verwaltung der Sicherheit von Automobilanwendungen umfasst. Die Safety-Cluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten Arbeitsspeicher, unterstützende Peripheriegeräte (z.B. Timer, einen Interrupt-Controller usw.) und/oder Routing-Logik umfassen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Lockstep-Modus arbeiten und als ein einziger Kern mit einer Vergleichslogik funktionieren, um Unterschiede zwischen ihren Operationen zu detektieren.
  • Der (die) Prozessor(en) 1110 kann (können) weiter eine Echtzeit-Kamera-Engine enthalten, die ein dediziertes Prozessor-Subsystem für die Verwaltung der Echtzeit-Kamera enthalten kann.
  • Der (die) Prozessor(en) 1110 kann (können) weiter einen Signalprozessor mit hohem Dynamikbereich enthalten, der einen Bildsignalprozessor enthalten kann, der eine Hardware-Engine ist, die Teil der Pipeline zum Verarbeiten der Kamera ist.
  • Der/die Prozessor(en) 1110 kann/können einen Videobildkompositor enthalten, der ein Verarbeitungsblock sein kann (z.B. auf einem Mikroprozessor implementiert), der Videonachverarbeitungsfunktionen implementiert, die von einer Videowiedergabe-Applikation benötigt werden, um das finale Bild für das Player-Fenster zu erzeugen. Der Videobildkompositor kann eine Linsenverzerrungskorrektur an der (den) Weitwinkelkamera(s) 1170, der (den) Surround-Kamera(s) 1174 und/oder an den Sensoren der Überwachungskamera in der Kabine vornehmen. Der kabineninterne Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netzwerk überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein System in der Kabine kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, das Fahrtziel zu ändern, das Infotainmentsystem und die Einstellungen des Fahrzeugs zu aktivieren oder zu ändern oder sprachgesteuertes Surfen im Internet zu ermöglichen. Bestimmte Funktionen stehen dem Fahrer nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
  • Der Videobildkompositor kann eine verbesserte zeitliche Rauschunterdrückung sowohl für die räumliche als auch für die zeitliche Rauschunterdrückung enthalten. Wenn beispielsweise Bewegungen in einem Video auftreten, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend und verringert das Gewicht der Informationen, die von benachbarten Bildern geliefert werden. Wenn ein Bild oder ein Teil eines Bildes keine Bewegung enthält, kann die vom Videobild-Kompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
  • Der Videobildzusammensetzer kann auch so konfiguriert sein, dass er eine Stereorektifizierung der eingegebenen Stereobildrahmen durchführt. Der Videobild-Kompositor kann weiter für die Gestaltung der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 1108 nicht ständig neue Oberflächen rendern muss. Auch wenn der/die Grafikprozessor(en) 1108 eingeschaltet ist/sind und aktiv 3D-Rendering betreibt/betreiben, kann der Videobildkompositor verwendet werden, um den/die Grafikprozessor(en) 1108 zu entlasten und so die Leistung und Reaktionsfähigkeit zu verbessern.
  • Der/die SoC(s) 1104 kann/können weiterhin eine serielle MIPI-Kameraschnittstelle zum Empfang von Video und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock enthalten, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Der/die SoC(s) 1104 kann/können weiterhin einen Eingabe/Ausgabe-Controller enthalten, der durch Software gesteuert werden kann und für den Empfang von E/A-Signalen verwendet werden kann, die keiner bestimmten Funktion zugeordnet sind.
  • Der/die SoC(s) 1104 kann/können weiterhin eine breite Palette von Peripherieschnittstellen enthalten, um die Kommunikation mit Peripheriegeräten, Audiocodecs, der Verwaltung der Stromversorgung und/oder anderen Geräten zu ermöglichen. Der/die SoC(s) 1104 kann/können zum Verarbeiten von Daten von Kameras (z.B. über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z.B. LIDAR-Sensor(en) 1164, RADAR-Sensor(en) 1160 usw., die über Ethernet angeschlossen werden können), Daten vom Bus 1102 (z.B. Geschwindigkeit des Fahrzeugs 1100, Lenkradposition usw.), Daten von GNSS-Sensor(en) 1158 (z.B. über Ethernet oder CAN-Bus angeschlossen) verwendet werden. Der/die SoC(s) 1104 kann/können weiterhin dedizierte Hochleistungs-Massenspeicher-Controller enthalten, die ihre eigenen DMA-Engines besitzen und verwendet werden können, um die CPU(s) 1106 von Routineaufgaben der Datenverwaltung zu entlasten.
  • Der/die SoC(s) 1104 kann/können eine End-to-End-Plattform mit einer flexiblen Architektur sein, die sich über die Automatisierungsstufen 3-5 erstreckt und dadurch eine umfassende funktionale Sicherheitsarchitektur bereitstellt, die Computervision und ADAS-Techniken für Diversität und Redundanz nutzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Deep-Learning-Tools bereitstellt. Die SoC(s) 1104 können schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Zum Beispiel kann der/die Beschleuniger 1114 in Kombination mit der/den CPU(s) 1106, der/den GPU(s) 1108 und dem/den Datenspeicher(n) 1116 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Stufe 3-5 bilden.
  • Die Technologie bietet somit Fähigkeiten und Funktionen, die mit herkömmlichen Systemen nicht erreicht werden können. Beispielsweise können Algorithmen für Computervision auf CPUs ausgeführt werden, die unter Verwendung einer höheren Programmiersprache, wie z. B. der Programmiersprache C, so konfiguriert werden können, dass sie eine Vielzahl von Verarbeitungsalgorithmen für eine Vielzahl visueller Daten ausführen. Allerdings sind CPUs oft nicht in der Lage, die Leistungsanforderungen vieler Computervision Applikationen zu erfüllen, wie z.B. in Bezug auf die Ausführungszeit und den Stromverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Algorithmen zur Objekterkennung in Echtzeit auszuführen, was eine Voraussetzung für fahrzeuginterne ADAS-Applikationen und eine Voraussetzung für praktische autonome Fahrzeuge der Stufe 3-5 ist.
  • Im Gegensatz zu konventionellen 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 Netzwerke und die Kombination der Ergebnisse, um autonome Fahrfunktionen der Stufe 3-5 zu ermöglichen. Beispielsweise kann ein CNN, das auf dem DLA oder der dGPU (z.B. die GPU(s) 1120) ausgeführt wird, eine Text- und Worterkennung umfassen, die es dem Supercomputer ermöglicht, Verkehrsschilder zu lesen und zu verstehen, einschließlich Schildern, für die das neuronale Netzwerk nicht speziell trainiert wurde. Der DLA kann weiter ein neuronales Netzwerk enthalten, das in der Lage ist, das Zeichen zu identifizieren, zu interpretieren und semantisch zu verstehen und dieses semantische Verständnis an die auf dem CPU-Komplex laufenden Pfadplanungsmodule weiterzuleiten.
  • Ein weiteres Beispiel ist die gleichzeitige Ausführung mehrerer neuronaler Netzwerke, wie sie für das Fahren der Stufen 3, 4 oder 5 erforderlich ist. Ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter deuten auf Glatteis hin“ kann zusammen mit einem elektrischen Licht von mehreren neuronalen Netzwerken unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netzwerk (z.B. einem trainierten neuronalen Netzwerk) als Verkehrsschild identifiziert werden, der Text „Blinkende Lichter deuten auf Glatteis hin“ kann von einem zweiten eingesetzten neuronalen Netzwerk interpretiert werden, das der Pfadplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) mitteilt, dass, wenn blinkende Lichter erkannt werden, Glatteis vorliegt. Das Blinklicht kann durch die Operation eines dritten neuronalen Netzwerks über mehrere Frames identifiziert werden, das die Pfadplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. Alle drei neuronalen Netzwerke können gleichzeitig laufen, z. B. innerhalb des DLA und/oder auf der/den GPU(s) 1108.
  • In 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 1100 zu identifizieren. Die Engine zum Verarbeiten der ständig eingeschalteten Sensoren kann verwendet werden, um das Fahrzeug zu entriegeln, wenn sich der Besitzer der Fahrertür nähert und die Beleuchtung einschaltet, und um im Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgen die SoC(s) 1104 für Sicherheit gegen Diebstahl und/oder Carjacking.
  • In einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 1196 verwenden, um Sirenen von Einsatzfahrzeugen zu detektieren und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifizierer verwenden, um Sirenen zu detektieren und manuell Merkmale zu extrahieren, verwenden die SoC(s) 1104 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung visueller Daten. In einem bevorzugten Ausführungsbeispiel wird der auf dem DLA laufende CNN darauf trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu erkennen (z.B. unter Verwendung des Dopplereffekts). Das CNN kann auch so trainiert werden, dass es Einsatzfahrzeuge identifiziert, die für den lokalen Bereich, in dem das Fahrzeug operiert, spezifisch sind, wie von GNSS-Sensor(en) 1158 ermittelt. So wird das CNN beispielsweise bei einer Operation in Europa versuchen, europäische Sirenen zu detektieren, und bei einer Operation in den Vereinigten Staaten wird das CNN versuchen, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Einsatzfahrzeug detektiert wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge auszuführen, das Fahrzeug zu verlangsamen, an den Straßenrand zu fahren, das Fahrzeug zu parken und/oder das Fahrzeug im Leerlauf laufen zu lassen, und zwar mit Hilfe von Ultraschallsensoren 1162, bis das/die Einsatzfahrzeug(e) vorbeigefahren sind.
  • Das Fahrzeug kann eine oder mehrere CPU(s) 1118 (z.B. diskrete CPU(s) oder dCPU(s)) enthalten, die über eine Hochgeschwindigkeitsverbindung (z.B. PCIe) mit dem/den SoC(s) 1104 gekoppelt sein können. Die CPU(s) 1118 kann/können zum Beispiel einen X86-Prozessor enthalten. Die CPU(s) 1118 kann/können verwendet werden, um eine Vielzahl von Funktionen auszuführen, einschließlich der Arbitrierung potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und dem/den SoC(s) 1104 und/oder der Überwachung des Status und des Zustands des/der Controller(s) 1136 und/oder des Infotainment-SoC 1130, zum Beispiel.
  • Das Fahrzeug 1100 kann eine GPU(s) 1120 (z.B. diskrete GPU(s) oder dGPU(s)) enthalten, die mit dem/den SoC(s) 1104 über eine Hochgeschwindigkeitsverbindung (z.B. NVIDIAs NVLINK) gekoppelt sein kann. Der/die Grafikprozessor(en) 1120 kann/können zusätzliche Funktionen der künstlichen Intelligenz bereitstellen, z.B. durch Ausführung redundanter und/oder unterschiedlicher neuronaler Netzwerke, und kann/können verwendet werden, um neuronale Netzwerke basierend auf Eingaben (z.B. Sensordaten) von Sensoren des Fahrzeugs 1100 zu trainieren und/oder zu aktualisieren.
  • Das Fahrzeug 1100 kann weiter die Netzwerkschnittstelle 1124 enthalten, die eine oder mehrere drahtlose Antennen 1126 enthalten kann (z.B. eine oder mehrere drahtlose Antennen für verschiedene Kommunikationsprotokolle, wie eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzwerkschnittstelle 1124 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z.B. mit dem/den Server(n) 1178 und/oder anderen Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Rechengeräten (z.B. Client-Geräten von Fahrgästen) zu ermöglichen. Um mit anderen Fahrzeugen zu kommunizieren, kann eine direkte Verbindung zwischen den beiden Fahrzeugen und/oder eine indirekte Verbindung hergestellt werden (z.B. über Netzwerke und das Internet). Direkte Verbindungen können zu leiten sein, indem eine Kommunikationsverbindung von Fahrzeug zu Fahrzeug verwendet wird. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 1100 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 1100 liefern (z.B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 1100). Diese Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 1100 sein.
  • Die Netzwerkschnittstelle 1124 kann einen SoC enthalten, der Modulations- und Demodulationsfunktionen bereitstellt und es dem/den Controllern) 1136 ermöglicht, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 1124 kann ein Funkfrequenz-Frontend für die Aufwärtskonvertierung von Basisband auf Funkfrequenz und die Abwärtskonvertierung von Funkfrequenz auf Basisband enthalten. Die Frequenzumwandlungen können durch bekannte Verfahren und/oder unter Verwendung von Superheterodyn-Verfahren durchgeführt werden. In einigen Beispielen kann die Funkfrequenz-Front-End-Funktionalität durch einen separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann drahtlose Funktionen für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle enthalten.
  • Das Fahrzeug 1100 kann weiterhin Datenspeicher 1128 enthalten, die außerhalb des Chips (z.B. außerhalb der SoC(s) 1104) gespeichert werden können. Der/die Datenspeicher 1128 kann/können ein oder mehrere Speicherelemente umfassen, einschließlich RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte, die zumindest ein Datenbit speichern können.
  • Das Fahrzeug 1100 kann weiterhin GNSS-Sensor(en) 1158 enthalten. Der/die GNSS-Sensor(en) 1158 (z.B. GPS, unterstützte GPS-Sensoren, Differential-GPS (DGPS)-Sensoren, usw.), um bei der Zuweisung, Wahrnehmung, Generierung von Belegungsrastern und/oder Pfad-Planungsfunktionen zu helfen. Es kann eine beliebige Anzahl von GNSS-Sensoren 1158 verwendet werden, einschließlich, zum Beispiel und ohne Einschränkung, ein GPS, das einen USB-Anschluss mit einer Ethernet-zu-Seriell (RS-232)-Brücke verwendet.
  • Das Fahrzeug 1100 kann weiterhin RADAR-Sensor(en) 1160 enthalten. Der/die RADAR-Sensor(en) 1160 kann/können vom Fahrzeug 1100 zur Fahrzeugdetektierung über große Entfernungen verwendet werden, auch bei Dunkelheit und/oder schlechten Wetterbedingungen. Der/die RADAR-Sensor(en) 1160 kann/können den CAN-Bus und/oder den Bus 1102 (z.B. zur Übertragung von Daten, die von dem/den RADAR-Sensor(en) 1160 generiert wurden) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugriff auf Rohdaten über Ethernet erfolgt. Es kann eine Vielzahl von RADAR-Sensortypen verwendet werden. Beispielsweise und ohne Einschränkung können der/die RADAR-Sensor(en) 1160 für Front-, Heck- und Seiten-RADAR-Verwendung geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensoren verwendet.
  • Der/die RADAR-Sensor(en) 1160 kann/können verschiedene Konfigurationen umfassen, wie z. B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit breitem Sichtfeld, seitliche Abdeckung kurzer Reichweite usw. In einigen Beispielen kann RADAR mit großer Reichweite für die Funktion des adaptiven Tempomats 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) 1160 kann/können helfen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und kann/können von ADAS-Systemen für Notbremsassistenten und Vorwärtskollisionswarnungen verwendet werden. Langstrecken-RADAR-Sensoren können monostatische multimodale RADAR mit mehreren (z.B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle umfassen. In einem Beispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu dient, die Umgebung des Fahrzeugs bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den angrenzenden Fahrspuren zu erfassen. Die beiden anderen Antennen können das Sichtfeld erweitern, so dass Fahrzeuge, die in die 1100-Fahrspur einfahren oder diese verlassen, schnell detektiert werden können.
  • RADAR-Systeme mit mittlerer Reichweite können beispielsweise eine Reichweite von bis zu 1160 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 1150 Grad (hinten) haben. Zu den RADAR-Systemen mit geringer Reichweite können unter anderem RADAR-Sensoren gehören, die an beiden Enden des hinteren Stoßfängers installiert werden. Wenn sie an beiden Enden des hinteren Stoßfängers installiert sind, können solche RADAR-Sensorsysteme zwei Strahlen erzeugen, die den toten Winkel im hinteren Bereich und neben dem Fahrzeug ständig überwachen.
  • RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder zur Unterstützung beim Spurwechsel verwendet werden.
  • Das Fahrzeug 1100 kann weiterhin Ultraschallsensor(en) 1162 enthalten. Der/die Ultraschallsensor(en) 1162, der/die vorne, hinten und/oder an den Seiten des Fahrzeugs 1100 positioniert sein kann/können, kann/können zur Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsrasters verwendet werden. Es kann eine Vielzahl von Ultraschallsensoren 1162 verwendet werden, und unterschiedliche Ultraschallsensoren 1162 können für unterschiedliche Detektionsbereiche (z.B. 2,5 m, 4 m) verwendet werden. Der/die Ultraschallsensor(en) 1162 kann/können bei funktionalen Sicherheitsstufen von ASIL B operieren.
  • Das Fahrzeug 1100 kann LIDAR-Sensor(en) 1164 enthalten. Der/die LIDAR-Sensor(en) 1164 kann/können zur Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder anderen Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 1164 kann/können der funktionalen Sicherheitsstufe ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 1100 mehrere LIDAR-Sensoren 1164 (z.B. zwei, vier, sechs usw.) enthalten, die Ethernet verwenden können (z.B. um Daten an einen Gigabit-Ethernet Switch zu liefern).
  • In einigen Beispielen kann/können der/die LIDAR-Sensor(en) 1164 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld zu liefern. Kommerziell erhältliche LIDAR-Sensoren 1164 können eine Reichweite von ca. 1100m haben, mit einer Genauigkeit von 2cm-3cm, und mit Unterstützung für eine 1100Mbps Ethernet-Verbindung, zum Beispiel. In einigen Beispielen können ein oder mehrere nicht vorspringende LIDAR-Sensoren 1164 verwendet werden. In solchen Beispielen kann/können der/die LIDAR-Sensor(en) 1164 als kleines Gerät implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 1100 eingebettet werden kann. Der/die LIDAR-Sensor(en) 1164 kann/können in solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von 35 Grad bieten, mit einer Reichweite von 200 m selbst für Objekte mit geringer Reflektivität. Der/die frontseitig montierte(n) LIDAR-Sensor(en) 1164 kann/können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert werden.
  • In einigen Beispielen können auch LIDAR-Technologien, wie 3D Flash LIDAR, verwendet werden. 3D Flash LIDAR verwendet einen Laserblitz als Sendequelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von ca. 200 m zu beleuchten. Eine Flash-LIDAR-Einheit umfasst einen Empfänger, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum der Entfernung zwischen dem Fahrzeug und den Objekten entspricht. Mit Flash-LIDAR lassen sich mit jedem Laserblitz hochpräzise und verzerrungsfreie Bilder der Umgebung generieren. In einigen Beispielen können vier Flash-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 1100. Zu den verfügbaren 3D-Blitz-LIDAR-Systemen gehört eine 3D-LIDAR-Kamera mit starrem Array, die außer einem Gebläse keine beweglichen Teile aufweist (z.B. ein nicht scannendes LIDAR-Gerät). Das Flash-LIDAR-Gerät kann einen 5-Nanosekunden-Laserimpuls der Klasse I (augensicher) pro Bild verwenden und das reflektierte Laserlicht in Form von 3D-Entfernungspunktwolken und koregistrierten Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR und weil Flash-LIDAR ein festes Gerät ohne bewegliche Teile ist, kann der/die LIDAR-Sensor(en) 1164 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße sein.
  • Das Fahrzeug kann weiterhin IMU-Sensor(en) 1166 enthalten. Der/die IMU-Sensor(en) 1166 kann/können in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 1100 angeordnet sein. Der (die) IMU-Sensor(en) 1166 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 umfassen. In einigen Beispielen, wie z. B. in sechsachsigen Applikationen, kann der/die IMU-Sensor(en) 1166 Beschleunigungsmesser und Gyroskope enthalten, während in neunachsigen Applikationen der/die IMU-Sensor(en) 1166 Beschleunigungsmesser, Gyroskope und Magnetometer enthalten kann/können.
  • In einigen Ausführungsbeispielen kann der/die IMU-Sensor(en) 1166 als ein miniaturisiertes, hochleistungsfähiges GPS-gestütztes Trägheitsnavigationssystem (GPS/INS) implementiert werden, das MEMS-Trägheitssensoren, einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen kombiniert, um Abschätzungen von Position, Geschwindigkeit und Lage zu liefern. In einigen Beispielen kann das Fahrzeug 1100 durch den/die IMU-Sensor(en) 1166 in die Lage versetzt werden, den Kurs abzuschätzen, ohne dass eine Eingabe von einem Magnetsensor erforderlich ist, indem die Geschwindigkeitsänderungen von GPS direkt beobachtet und mit dem/den IMU-Sensor(en) 1166 korreliert werden. In einigen Beispielen können der/die IMU-Sensor(en) 1166 und der/die GNSS-Sensor(en) 1158 in einer einzigen integrierten Einheit kombiniert werden.
  • Das Fahrzeug kann Mikrofon(e) 1196 enthalten, die im und/oder um das Fahrzeug 1100 herum angebracht sind. Das (die) Mikrofon(e) 1196 kann (können) unter anderem zum Detektieren und Identifizieren von Einsatzfahrzeugen verwendet werden.
  • Das Fahrzeug kann weiterhin eine beliebige Anzahl von Kameratypen enthalten, einschließlich Stereokamera(s) 1168, Weitwinkelkamera(s) 1170, Infrarotkamera(s) 1172, Surround-Kamera(s) 1174, Langstrecken- und/oder Mitteldistanzkamera(s) 1198 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten rund um den gesamten Umfang des Fahrzeugs 1100 zu erfassen. Welche Kameratypen verwendet werden, hängt von den Ausführungsbeispielen und Anforderungen an das Fahrzeug 1100 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 1100 herum zu gewährleisten. Darüber hinaus kann die Anzahl der Kameras je nach Ausführungsbeispiel unterschiedlich sein. So kann das Fahrzeug beispielsweise sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras umfassen. 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 hierin mit Bezug auf 11A und 11B detaillierter beschrieben.
  • Das Fahrzeug 1100 kann weiterhin einen oder mehrere Vibrationssensoren 1142 enthalten. Der/die Schwingungssensor(en) 1142 kann/können Schwingungen von Komponenten des Fahrzeugs, wie z. B. der Achse(n), messen. Zum Beispiel können Änderungen der Vibrationen eine Änderung der Straßenoberfläche anzeigen. In einem anderen Beispiel, wenn zwei oder mehr Schwingungssensoren 1142 verwendet werden, können die Unterschiede zwischen den Schwingungen verwendet werden, um die Reibung oder den Schlupf der Straßenoberfläche zu bestimmen (z.B. wenn der Unterschied in der Schwingung zwischen einer angetriebenen Achse und einer frei drehenden Achse besteht).
  • Das Fahrzeug 1100 kann ein ADAS-System 1138 enthalten. Das ADAS-System 1138 kann in einigen Beispielen einen SoC enthalten. Das ADAS-System 1138 kann einen autonomen/adaptiven/automatischen Geschwindigkeitsregler (ACC), einen kooperativen adaptiven Geschwindigkeitsregler (CACC), eine Auffahrwarnung (FCW), eine automatische Notbremsung (AEB), eine Spurverlassenswarnung (LDW), einen Spurhalteassistenten (LKA), einen Toter-Winkel-Warner (BSW), einen Querverkehrswarner (RCTW), Kollisionswarnsysteme (CWS), eine Spurenzentrierung (LC) und/oder andere Merkmale und Funktionen umfassen.
  • Die ACC-Systeme können RADAR-Sensor(en) 1160, LIDAR-Sensor(en) 1164 und/oder eine Kamera(en) verwenden. Die ACC-Systeme können Längs-ACC und/oder Quer-ACC umfassen. Der ACC in Längsrichtung überwacht und steuert den Abstand zu dem unmittelbar vor dem Fahrzeug 1100 befindlichen Fahrzeug und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Der seitliche ACC hält den Abstand zum vorausfahrenden Fahrzeug und rät dem Fahrzeug 1100, die Spur zu wechseln, wenn dies erforderlich ist. Lateral ACC ist mit anderen ADAS-Applikationen wie LCA und CWS verwandt.
  • CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 1124 und/oder die Funkantenne(n) 1126 von anderen Fahrzeugen über eine drahtlose Verbindung oder indirekt über eine Netzwerkverbindung (z.B. über das Internet) empfangen werden können. Direkte Verbindungen können durch eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung (V2V) bereitgestellt werden, während indirekte Verbindungen eine Infrastruktur-zu-Fahrzeug-Kommunikationsverbindung (I2V) sein können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Informationen über die unmittelbar vorausfahrenden Fahrzeuge (z.B. Fahrzeuge, die sich unmittelbar vor dem Fahrzeug 1100 und auf derselben Fahrspur wie dieses befinden), während das I2V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr liefert. CACC-Systeme können eine oder beide I2V- und V2V-Informationsquellen enthalten. Angesichts der Informationen über die vor dem Fahrzeug 1100 fahrenden Fahrzeuge kann CACC zuverlässiger sein und hat das Potenzial, den Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
  • FCW-Systeme sind so konzipiert, dass sie den Fahrer vor einer Gefahr warnen, so dass der Fahrer korrigierend eingreifen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 1160, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung ausgeben, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
  • AEB-Systeme detektieren einen drohenden Zusammenstoß 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 Entfernungsparameters korrigierend eingreift. AEB-Systeme können nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1160 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr detektiert, warnt es in der Regel zunächst den Fahrer, damit er korrigierende Maßnahmen ergreift, um die Kollision zu vermeiden. Wenn der Fahrer keine korrigierenden Maßnahmen ergreift, kann das AEB-System automatisch die Bremsen betätigen, um die Auswirkungen der vorhergesagten Kollision zu verhindern oder zumindest abzumildern. AEB-Systeme können Techniken wie die dynamische Bremsunterstützung und/oder die Crash-Imminent-Bremsung umfassen.
  • LDW-Systeme warnen den Fahrer durch optische, akustische und/oder taktile Signale, wie z. B. Vibrationen am Lenkrad oder am Sitz, wenn das Fahrzeug 1100 die Fahrbahnmarkierungen überschreitet. Ein Spurhaltewarnsystem wird nicht aktiviert, wenn der Fahrer durch Betätigen des Blinkers ein absichtliches Verlassen der Fahrspur anzeigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • LKA-Systeme sind eine Variation von LDW-Systemen. LKA-Systeme geben Eingaben in die Lenkung oder bremsen, um das Fahrzeug 1100 zu korrigieren, wenn das Fahrzeug 1100 beginnt, die Fahrspur zu verlassen.
  • BSW-Systeme detektieren und warnen den Fahrer vor Fahrzeugen, die sich im toten Winkel des Fahrzeugs befinden. BSW-Systeme können ein optisches, akustisches und/oder taktiles Warnsignal ausgeben, um anzuzeigen, dass das Zusammenführen oder Wechseln der Fahrspur unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker verwendet. BSW-Systeme können nach hinten gerichtete Kamera(s) und/oder RADAR-Sensoren 1160 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • RCTW-Systeme können eine visuelle, akustische und/oder taktile Benachrichtigung liefern, wenn ein Objekt außerhalb des Bereichs der Rückfahrkamera detektiert wird, wenn das Fahrzeug 1100 rückwärts fährt. Einige RCTW-Systeme umfassen AEB, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. RCTW-Systeme können einen oder mehrere nach hinten gerichtete(n) RADAR-Sensor(en) 1160 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit der Rückmeldung an den Fahrer gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • Herkömmliche ADAS-Systeme können für falsch positive Ergebnisse anfällig sein, die für einen Fahrer ärgerlich und ablenkend sein können, aber typischerweise nicht katastrophal sind, weil die ADAS-Systeme den Fahrer warnen und es dem Fahrer ermöglichen, zu entscheiden, ob eine Sicherheitsbedingung wirklich vorliegt und entsprechend zu handeln. In einem autonomen Fahrzeug 1100 muss das Fahrzeug 1100 jedoch im Falle widersprüchlicher Ergebnisse selbst entscheiden, ob es das Ergebnis eines primären Rechners oder eines sekundären Rechners (z.B. eines ersten Steuergeräts 1136 oder eines zweiten Steuergeräts 1136) beachtet. In einigen Ausführungsbeispielen kann das ADAS-System 1138 beispielsweise ein Backup- und/oder Sekundärrechner sein, der einem Rationalitätsmodul des Backup-Rechners Wahrnehmungsinformationen liefert. Der Rationalitätsmonitor des Backup-Rechners kann eine redundante diverse Software auf Hardwarekomponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahraufgaben zu detektieren. Die Ausgaben des ADAS-Systems 1138 können an eine übergeordnete MCU weitergeleitet werden. Wenn die Ausgaben des primären Rechners und des sekundären Rechners in Konflikt geraten, muss die überwachende MCU bestimmen, wie der Konflikt zu lösen ist, um eine sichere Operation zu gewährleisten.
  • In einigen Beispielen kann der primäre Rechner so konfiguriert sein, dass er der übergeordneten MCU einen Punktwert für die Konfidenz liefert, der die Indikation für die Konfidenz des primären Rechners in Bezug auf das gewählte Ergebnis darstellt. Übersteigt der Konfidenzwert einen Schwellenwert, kann die überwachende MCU der Anweisung des primären Rechners folgen, unabhängig davon, ob der sekundäre Rechner ein widersprüchliches oder inkonsistentes Ergebnis liefert. Erreicht der Konfidenzwert nicht den Schwellenwert und zeigen der primäre und der sekundäre Rechner unterschiedliche Ergebnisse an (z.B. Konflikt), kann die überwachende MCU zwischen den Rechnern arbitrieren, um das geeignete Ergebnis zu bestimmen.
  • Die überwachende MCU kann so konfiguriert sein, dass sie ein neuronales Netzwerk bzw. neuronale Netzwerke ausführt, das bzw. die trainiert und so konfiguriert ist bzw. sind, dass es bzw. sie basierend auf den Ausgaben des primären Rechners und des sekundären Rechners die Bedingungen bestimmt bzw. bestimmen, unter denen der sekundäre Rechner Fehlalarme liefert. So kann das neuronale Netzwerk bzw. können die neuronalen Netzwerke in der Überwachungs-MCU lernen, wann den Ausgaben des sekundären Rechners vertraut werden kann und wann nicht. Handelt es sich bei dem sekundären Rechner beispielsweise um ein RADAR-basiertes FCW-System, kann ein neuronales Netzwerk in der übergeordneten MCU lernen, wann das FCW-System metallische Objekte identifiziert, bei denen es sich in Wirklichkeit nicht um Gefahren handelt, wie z. B. ein Entwässerungsgitter oder eine Schachtabdeckung, die einen Alarm auslöst. Wenn der sekundäre Rechner ein kamerabasiertes Spurhaltewarnsystem ist, kann ein neuronales Netzwerk in der übergeordneten MCU lernen, das Spurhaltewarnsystem außer Kraft zu setzen, wenn Radfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsbeispielen, die ein neuronales Netzwerk (bzw. neuronale Netzwerke) enthalten, das/die auf der überwachenden MCU läuft/laufen, kann die überwachende MCU zumindest einen DLA oder eine GPU enthalten, der/die für den Betrieb des/der neuronalen Netzwerke(s) mit assoziiertem Speicher geeignet ist. In bevorzugten Ausführungsbeispielen kann die Überwachungs-MCU eine Komponente des/der SoC(s) 1104 umfassen und/oder darin enthalten sein.
  • In anderen Beispielen kann das ADAS-System 1138 einen sekundären Rechner umfassen, der die ADAS-Funktionalität unter Verwendung herkömmlicher Regeln der Computervision ausführt. Als solcher kann der sekundäre Rechner klassische Regeln der Computervision (wenn-dann) verwenden, und das Vorhandensein eines neuronalen Netzwerks (von neuronalen Netzwerken) in der übergeordneten MCU kann die Zuverlässigkeit, Sicherheit und Leistung verbessern. Beispielsweise wird das Gesamtsystem durch die vielfältige Implementierung und die absichtliche Nichtidentität fehlertoleranter, insbesondere gegenüber Fehlern, die durch Softwarefunktionen (oder Software-Hardware-Schnittstellen) veranlasst werden. Wenn beispielsweise ein Softwarefehler in der auf dem primären Rechner laufenden Software auftritt und der nicht identische Softwarecode, der auf dem sekundären Rechner läuft, dasselbe Gesamtergebnis liefert, kann die überwachende MCU mit größerer Konfidenz davon ausgehen, dass das Gesamtergebnis korrekt ist und der Fehler in der Software oder Hardware des primären Rechners keinen wesentlichen Fehler veranlasst.
  • In einigen Beispielen kann die Ausgabe des ADAS-Systems 1138 in den Wahrnehmungsblock des primären Rechners und/oder in den Block für dynamische Fahraufgaben des primären Rechners eingespeist werden. Wenn das ADAS-System 1138 beispielsweise eine Vorwärtscrash-Warnung aufgrund eines unmittelbar vorausliegenden Objekts anzeigt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der sekundäre Rechner ein eigenes neuronales Netzwerk besitzen, das trainiert ist und so das Risiko von Fehlalarmen reduziert, wie hier beschrieben.
  • Das Fahrzeug 1100 kann weiterhin den Infotainment-SoC 1130 enthalten (z.B. ein bordeigenes Infotainment-System (IVI)). Obwohl als SoC dargestellt und beschrieben, ist das Infotainment-System möglicherweise kein SoC, sondern kann zwei oder mehr diskrete Komponenten umfassen. Das Infotainment-SoC 1130 kann eine Kombination aus Hardware und Software enthalten, die verwendet werden kann, um Audio (z.B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z.B. TV, Filme, Streaming usw.), Telefon (z.B. Freisprechen), Netzwerk-Konnektivität (z.B., LTE, Wi-Fi, etc.) und/oder Informationsdienste (z.B. Navigationssysteme, Einparkhilfe, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremskraftstoffstand, Ölstand, Tür öffnen/schließen, Luftfilterinformationen, etc.) an das Fahrzeug 1100. Der Infotainment-SoC 1130 kann z.B. Radios, Plattenspieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Audiobedienelemente am Lenkrad, Freisprecheinrichtung, ein Heads-up-Display (HUD), eine HMI-Anzeige 1134, ein Telematikgerät, ein Bedienfeld (z.B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten umfassen. Der Infotainment-SoC 1130 kann weiter dazu verwendet werden, einem oder mehreren Nutzern des Fahrzeugs Informationen (z.B. visuell und/oder akustisch) zur Verfügung zu stellen, wie z.B. Informationen vom ADAS-System 1138, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z.B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
  • Der Infotainment-SoC 1130 kann GPU-Funktionen enthalten. Der Infotainment-SoC 1130 kann über den Bus 1102 (z.B. CAN-Bus, Ethernet, etc.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 1100 kommunizieren. In einigen Beispielen kann der Infotainment-SoC 1130 mit einer Überwachungs-MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primäre(n) Steuereinheit(en) 1136 (z.B. die primären und/oder Backup-Rechner des Fahrzeugs 1100) ausfallen. In einem solchen Beispiel kann das Infotainment SoC 1130 das Fahrzeug 1100 in einen Fahrmodus zum sicheren Anhalten versetzen, wie hierin beschrieben.
  • Das Fahrzeug 1100 kann weiterhin ein Kombiinstrument 1132 enthalten (z.B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.). Das Kombiinstrument 1132 kann ein Steuergerät und/oder einen Supercomputer (z.B. ein diskretes Steuergerät oder einen Supercomputer) enthalten. Das Kombiinstrument 1132 kann eine Reihe von Instrumenten enthalten, wie z. B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltstellungsanzeige, Sicherheitsgurt-Warnleuchte(n), Feststellbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Informationen über das Airbag-System (SRS), Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen usw. In einigen Beispielen können die Informationen vom Infotainment SoC 1130 und dem Kombiinstrument 1132 angezeigt und/oder gemeinsam genutzt werden. Mit anderen Worten: Das Kombiinstrument 1132 kann Teil des Infotainment-SoC 1130 sein oder umgekehrt.
  • 11D ist ein Systemdiagramm für die Kommunikation zwischen dem/den Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug 1100 aus 11A, gemäß einigen Ausführungsbeispielen der vorliegenden Offenbarung. Das System 1176 kann Server 1178, Netzwerk(e) 1190 und Fahrzeuge, einschließlich des Fahrzeugs 1100, umfassen. Der/die Server 1178 kann/können eine Vielzahl von GPUs 1184(A)-1184(H) (hierin kollektiv als GPUs 1184 bezeichnet), PCIe-Switches 1182(A)-1182(H) (hierin kollektiv als PCIe-Switches 1182 bezeichnet) und/oder CPUs 1180(A)-1 180(B) (hierin kollektiv als CPUs 1180 bezeichnet) umfassen. Die GPUs 1184, die CPUs 1180 und die PCIe-Switches können mit Hochgeschwindigkeitsverbindungen, wie z. B. den von NVIDIA aufgebauten NVLink-Schnittstellen 1188 und/oder PCIe-Verbindungen 1186, miteinander verbunden sein. In einigen Beispielen sind die GPUs 1184 über NVLink und/oder NVSwitch SoC verbunden, und die GPUs 1184 und die PCIe-Switches 1182 sind über PCIe-Verbindungen verbunden. Obwohl acht GPUs 1184, zwei CPUs 1180 und zwei PCIe-Switches dargestellt sind, ist dies nicht als Einschränkung zu verstehen. Je nach Ausführungsbeispiel kann jeder der Server 1178 eine beliebige Anzahl von GPUs 1184, CPUs 1180 und/oder PCIe-Switches enthalten. Beispielsweise können die Server 1178 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1184 enthalten.
  • Der (die) Server 1178 kann (können) über das (die) Netzwerk(e) 1190 und von den Fahrzeugen Bilddaten empfangen, die Bilder repräsentieren, die unerwartete oder veränderte Straßenzustände zeigen, z. B. kürzlich begonnene Straßenarbeiten. Der (die) Server 1178 kann (können) über das (die) Netzwerk(e) 1190 und an die Fahrzeuge neuronale Netzwerke 1192, aktualisierte neuronale Netzwerke 1192 und/oder Karteninformationen 1194, einschließlich Informationen über den Verkehr und die Straßenbedingungen, übertragen. Die Aktualisierungen der Karteninformationen 1194 können Aktualisierungen für die HD-Karte 1122 enthalten, z. B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In einigen Beispielen können die neuronalen Netzwerke 1192, die aktualisierten neuronalen Netzwerke 1192 und/oder die Karteninformationen 1194 aus neuem Training und/oder Erfahrungen resultieren, die in Daten repräsentiert werden, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder basierend auf Training, das in einem Datenzentrum (z.B. unter Verwendung des/der Server(s) 1178 und/oder anderer Server) durchgeführt wurde.
  • Der/die Server 1178 kann/können verwendet werden, um Modelle des maschinellen Lernens (z.B. neuronale Netzwerke) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen generiert werden und/oder in einer Simulation (z.B. unter Verwendung einer Game-Engine). In einigen Beispielen werden die Trainingsdaten markiert (z.B. wenn das neuronale Netzwerk von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht markiert und/oder vorverarbeitet werden (z.B. wenn das neuronale Netzwerk kein überwachtes Lernen benötigt). Das Training kann gemäß einer oder mehrerer Klassen von Techniken des maschinellen Lernens durchgeführt werden, einschließlich, ohne Einschränkung, Klassen wie: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, selbstlernendes Lernen, bestärkendes Lernen, föderiertes Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multi-lineares Unterraumlemen, mannigfaltiges Lernen, Repräsentationslemen (einschließlich Lernen mit Ersatzwörterbüchern), regelbasiertes maschinelles Lernen, Anomalieerkennung und jegliche Varianten oder Kombinationen davon. Sobald die Modelle des maschinellen Lernens trainiert sind, können die Modelle des maschinellen Lernens von den Fahrzeugen verwendet werden (z.B. über das/die Netzwerk(e) 1190 an die Fahrzeuge übertragen werden, und/oder die Modelle des maschinellen Lernens können von dem/den Server(n) 1178 zur Fernüberwachung der Fahrzeuge verwendet werden.
  • In einigen Beispielen können der/die Server 1178 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Netzwerke für intelligentes Inferenzieren in Echtzeit anwenden. Der/die Server 1178 kann/können Deep-Learning-Supercomputer und/oder dedizierte KI-Rechner umfassen, die von GPU(s) 1184 angetrieben werden, wie die von NVIDIA aufgebauten DGX- und DGX-Station-Maschinen. In einigen Beispielen kann der/die Server 1178 jedoch eine Deep-Learning-Infrastruktur enthalten, die nur CPUbetriebene Rechenzentren verwendet.
  • Die Deep-Learning-Infrastruktur des/der Server(s) 1178 kann zu schnellem Inferenzieren in Echtzeit fähig sein und kann diese Fähigkeit verwenden, um den Zustand der Prozessoren, der Software und/oder der assoziierten Hardware im Fahrzeug 1100 zu bewerten und zu überprüfen. Beispielsweise kann die Deep-Learning-Infrastruktur periodische Aktualisierungen vom Fahrzeug 1100 erhalten, wie z.B. eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 1100 in dieser Bildsequenz lokalisiert hat (z.B. über Computervision und/oder andere maschinelle Objektklassifizierungsverfahren). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netzwerk laufen lassen, um die Objekte zu identifizieren und sie mit den vom Fahrzeug 1100 identifizierten Objekten zu vergleichen. Wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 1100 nicht richtig funktioniert, kann der/die Server 1178 ein Signal an das Fahrzeug 1100 senden, das einen ausfallsicheren Rechner des Fahrzeugs 1100 anweist, die Kontrolle zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver abzuschließen.
  • Zum Inferenzieren kann der/die Server 1178 die GPU(s) 1184 und einen oder mehrere programmierbare Inferenzbeschleuniger (z.B. TensorRT von NVIDIA) enthalten. Die Kombination aus GPU-betriebenen Servern und Inferenzbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, in denen die Leistung weniger kritisch ist, können Server mit CPUs, FPGAs und anderen Prozessoren zum Inferenzieren verwendet werden.
  • BEISPIELHAFTES RECHENGERÄT
  • 12 ist ein Blockdiagramm eines beispielhaften Rechengeräts 1200, das zur Verwendung bei der Implementierung einiger Ausführungsbeispiele der vorliegenden Offenbarung geeignet ist. Das Rechengerät 1200 kann ein Verbindungssystem 1202 enthalten, das die folgenden Geräte direkt oder indirekt koppelt: Speicher 1204, eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 1206, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1208, eine Kommunikationsschnittstelle 1210, E/A-Anschlüsse 1212, Eingabe-/Ausgabekomponenten 1214, eine Stromversorgung 1216, eine oder mehrere Präsentationskomponenten 1218 (z.B. Anzeige(n)) und eine oder mehrere Logikeinheiten 1220. In mindestens einem Ausführungsbeispiel kann das (die) Rechengerät(e) 1200 eine oder mehrere virtuelle Maschinen (VMs) umfassen und/oder jede der Komponenten davon kann virtuelle Komponenten (z.B. virtuelle Hardwarekomponenten) umfassen. Als nicht einschränkende Beispiele können eine oder mehrere der GPUs 1208 eine oder mehrere vGPUs umfassen, eine oder mehrere der CPUs 1206 können eine oder mehrere vCPUs umfassen, und/oder eine oder mehrere der Logikeinheiten 1220 können eine oder mehrere virtuelle Logikeinheiten umfassen. Als solche kann ein Rechengerät 1200 diskrete Komponenten (z.B. eine vollständige GPU, die dem Rechengerät 1200 gewidmet ist), virtuelle Komponenten (z.B. einen Teil einer GPU, die dem Rechengerät 1200 gewidmet ist) oder eine Kombination davon umfassen.
  • Obwohl die verschiedenen Blöcke in 12 als über das Verbindungssystem 1202 mit Linien verbunden dargestellt sind, ist dies nicht als Einschränkung gedacht und dient nur der Klarheit. In einigen Ausführungsbeispielen kann z.B. eine Präsentationskomponente 1218, wie ein Anzeigegerät, als E/A-Komponente 1214 betrachtet werden (z.B. wenn es sich bei der Anzeige um einen Touchscreen handelt). Als weiteres Beispiel können die CPUs 1206 und/oder GPUs 1208 Speicher enthalten (z.B. kann der Speicher 1204 zusätzlich zum Speicher der GPUs 1208, der CPUs 1206 und/oder anderer Komponenten ein Gerät repräsentieren). Mit anderen Worten: Das Rechengerät von 12 ist lediglich illustrativ dargestellt. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da alle im Rahmen des Rechengeräts von 12 in Betracht gezogen werden.
  • Das Verbindungssystem 1202 kann eine oder mehrere Verbindungen oder Busse repräsentieren, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 1202 kann einen oder mehrere Bus- oder Verbindungstypen umfassen, wie z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsbeispielen gibt es direkte Verbindungen zwischen den Komponenten. Zum Beispiel kann die CPU 1206 direkt mit dem Speicher 1204 verbunden sein. Weiter kann die CPU 1206 direkt mit der GPU 1208 verbunden sein. Bei direkten oder Punkt-zu-Punkt-Verbindungen zwischen Komponenten kann das Verbindungssystem 1202 einen PCIe-Link enthalten, um die Verbindung herzustellen. In diesen Beispielen muss das Rechengerät 1200 nicht unbedingt einen PCI-Bus enthalten.
  • Der Speicher 1204 kann aus einer Vielzahl von computerlesbaren Medien bestehen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Rechengerät 1200 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entfernbare und nicht entfernbare Medien umfassen. Als Beispiel und ohne Einschränkung können die computerlesbaren Medien Computer-Speichermedien und Kommunikationsmedien umfassen.
  • Die Computer-Speichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen wie computer-implementierten Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Beispielsweise kann der Speicher 1204 computerlesbare Anweisungen speichern (z.B., die ein oder mehrere Programme und/oder ein oder mehrere Programmelemente repräsentieren, wie z.B. ein Betriebssystem. Zu den Computerspeichermedien können unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichergeräte oder jedes andere Medium gehören, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das das Rechengerät 1200 zugreifen kann. Wie hierin verwendet, umfassen Rechner-Speichermedien nicht per se Signale.
  • Die Computer-Speichermedien können computerlesbare Befehle, Datenstrukturen, Programm-Module und/oder andere Datentypen in einem modulierten Datensignal, wie z.B. einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und umfassen beliebige Informationsliefermedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Charakteristiken so eingestellt oder verändert sind, dass Informationen in dem Signal kodiert werden. Die Speichermedien des Rechners können beispielsweise verdrahtete Medien wie ein verdrahtetes Netzwerk oder eine direkt verdrahtete Verbindung sowie drahtlose Medien wie akustische, RF-, Infrarot- und andere drahtlose Medien umfassen. Kombinationen der oben genannten Möglichkeiten sollten ebenfalls in den Anwendungsbereich der computerlesbaren Medien fallen.
  • Die CPU(s) 1206 kann/können so konfiguriert sein, dass sie zumindest einige der computerlesbaren Befehle ausführt/ausführen, um eine oder mehrere Komponenten des Rechengeräts 1200 zu steuern, um eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 1206 kann/können jeweils einen oder mehrere Kerne (z.B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig, usw.) umfassen, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 1206 kann/können jeden beliebigen Prozessortyp umfassen und je nach Art des implementierten Rechengeräts 1200 unterschiedliche Typen von Prozessoren umfassen (z.B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Je nach Art des Rechengeräts 1200 kann der Prozessor beispielsweise ein Advanced RISC Machines (ARM)-Prozessor sein, der mit Reduced Instruction Set Computing (RISC) implementiert ist, oder ein x86-Prozessor, der Complex Instruction Set Computing (CISC) verwendet. Das Rechengerät 1200 kann eine oder mehrere CPUs 1206 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Koprozessoren, wie z. B. mathematischen Koprozessoren, enthalten.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 1206 kann/können die GPU(s) 1208 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Rechengeräts 1200 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Verarbeiten durchzuführen. Eine oder mehrere der GPU(s) 1208 können eine integrierte GPU sein (z.B. mit einer oder mehreren der CPU(s) 1206 und/oder eine oder mehrere der GPU(s) 1208 können eine diskrete GPU sein. In Ausführungsbeispielen kann eine oder mehrere der GPU(s) 1208 ein Koprozessor einer oder mehrerer der CPU(s) 1206 sein. Der/die GPU(s) 1208 kann/können vom Rechengerät 1200 zum Rendern von Grafiken (z.B. 3D-Grafiken) oder zur Durchführung allgemeiner Berechnungen verwendet werden. Beispielsweise kann/können der/die GPU(s) 1208 für General-Purpose-Rechnen auf GPUs (GPGPU) verwendet werden. Die GPU(s) 1208 kann/können Hunderte oder Tausende von Kernen umfassen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Der/die Grafikprozessor(en) 1208 kann/können als Reaktion darauf Rendering-Befehle (z.B. Rendering-Befehle von der/den CPU(s) 1206, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für die Ausgabe von Bildern generieren. Die GPU(s) 1208 kann/können einen Grafikspeicher, wie z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, wie z. B. GPGPU-Daten, enthalten. Der Anzeigespeicher kann als Teil des Speichers 1204 enthalten sein. Die GPU(s) 1208 kann/können zwei oder mehr GPUs umfassen, die parallel (z.B. über eine Verbindung) operieren. Die Verbindung kann die GPUs direkt zu leiten (z.B. unter Verwendung von NVLINK) oder die GPUs über einen Switch zu verbinden (z.B. unter Verwendung von NVSwitch). In Kombination kann jede GPU 1208 Pixeldaten oder GPGPU-Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben generieren (z.B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann einen eigenen Speicher besitzen oder den Speicher gemeinsam mit anderen GPUs nutzen.
  • Zusätzlich zu oder alternativ zu der (den) CPU(s) 1206 und/oder der (den) GPU(s) 1208 kann (können) die Logikeinheit(en) 1220 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt (ausführen), um eine oder mehrere Komponenten des Rechengeräts 1200 so zu steuern, dass sie eines oder mehrere der hier beschriebenen Verfahren und/oder Verarbeitungen durchführen. In Ausführungsbeispielen können die CPU(s) 1206, die GPU(s) 1208 und/oder die Logikeinheit(en) 1220 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 1220 können Teil einer oder mehrerer der CPU(s) 1206 und/oder der GPU(s) 1208 sein und/oder eine oder mehrere der Logikeinheiten 1220 können diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 1206 und/oder der GPU(s) 1208 liegen. In Ausführungsbeispielen kann eine oder mehrere der Logikeinheiten 1220 ein Koprozessor einer oder mehrerer der CPU(s) 1206 und/oder einer oder mehrerer der GPU(s) 1208 sein.
  • Beispiele für die Logikeinheit(en) 1220 umfassen einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie z. B. Datenverarbeitungseinheiten (DPUs), Tensorkerne (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Grafikverarbeitungscluster (GPCs), Texturverarbeitungscluster (TPCs), Streaming-Multiprozessoren (SMs), Tree Traversal Units (TTUs), Artificial Intelligence Accelerators (AIAs), Deep Learning Accelerators (DLAs), Arithmetik-Logik-Einheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkomma-Einheiten (FPUs), Eingabe/Ausgabe (E/A)-Elemente, Peripheral Component Interconnect (PCI)- oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
  • Die Kommunikationsschnittstelle 1210 kann einen oder mehrere Empfänger, Sender und/oder Transceiver enthalten, die es dem Rechengerät 1200 ermöglichen, mit anderen Rechengeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 1210 kann Komponenten und Funktionen enthalten, um die Kommunikation über eine Reihe verschiedener Netzwerke zu ermöglichen, wie z.B. drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee, etc.), verdrahtete Netzwerke (z.B. Kommunikation über Ethernet oder InfiniBand), Low-Power-Weitverkehrsnetzwerke (z.B. LoRaWAN, SigFox, etc.) und/oder das Internet. In einem oder mehreren Ausführungsbeispielen kann (können) die Logikeinheit(en) 1220 und/oder die Kommunikationsschnittstelle 1210 eine oder mehrere Datenverarbeitungseinheiten (DPUs) enthalten, um über ein Netzwerk und/oder über das Verbindungssystem 1202 empfangene Daten direkt zu (z.B. einem Speicher von) einer oder mehreren GPU(s) 1208 zu leiten.
  • Über die E/A-Anschlüsse 1212 kann das Rechengerät 1200 logisch mit anderen Geräten gekoppelt werden, darunter die E/A-Komponenten 1214, die Präsentationskomponente(n) 1218 und/oder andere Komponenten, von denen einige in das Rechengerät 1200 eingebaut (z.B. integriert) sein können. Illustrative E/A-Komponenten 1214 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die E/A-Komponenten 1214 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die von einem Benutzer generierte Luftgesten, Spracheingaben oder andere physiologische Eingaben verarbeitet. In einigen Instanzen können die Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten detaillierter beschrieben) implementieren, die mit einer Anzeige des Rechengeräts 1200 assoziiert ist. Das Rechengerät 1200 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -detektierung enthalten. Darüber hinaus kann das Rechengerät 1200 Beschleunigungsmesser oder Gyroskope (z.B. als Teil einer Trägheitsmesseinheit (IMU)) enthalten, die das Erkennen von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von dem Rechengerät 1200 verwendet werden, um immersive Augmented Reality oder Virtual Reality zu rendern.
  • Die Stromversorgung 1216 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon umfassen. Die Stromversorgung 1216 kann das Rechengerät 1200 mit Strom versorgen, um den Betrieb der Komponenten des Rechengeräts 1200 zu ermöglichen.
  • Die Präsentationskomponente(n) 1218 kann/können eine Anzeige (z.B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 1218 kann/können Daten von anderen Komponenten (z.B. der/den GPU(s) 1208, der/den CPU(s) 1206, DPUs usw.) empfangen und die Daten ausgeben (z.B. als Bild, Video, Ton usw.).
  • BEISPIELHAFTES DATENZENTRUM
  • 13 zeigt ein Beispiel für ein Datenzentrum 1300, das zumindest in einem Ausführungsbeispiel der vorliegenden Offenbarung verwendet werden kann. Das Datenzentrum 1300 kann eine Datenzentrumsinfrastrukturschicht 1310, eine Framework-Schicht 1320, eine Softwareschicht 1330 und/oder eine Applikationsschicht 1340 umfassen.
  • Wie in 13 gezeigt, kann die Datenzentrum-Infrastrukturschicht 1310 einen Ressourcen-Orchestrator 1312, gruppierte Rechner-Ressourcen 1314 und Knoten-Rechner-Ressourcen („Knoten C.R.s“) 1316(1)-1316(N) umfassen, wobei „N“ eine beliebige ganze, positive Zahl repräsentiert. In mindestens einem Ausführungsbeispiel können die Knoten C.R.s 1316(1)-1316(N) eine beliebige Anzahl von zentralen Verarbeitungseinheiten (CPUs) oder anderen Prozessoren (einschließlich DPUs, Beschleunigern, feldprogrammierbaren Gate-Arrays (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Speichergeräten (z.B, dynamischer Festwertspeicher), Speichergeräte (z.B. Solid-State- oder Festplattenlaufwerke), Netzwerk-Eingabe/Ausgabe-Geräte (NW I/O), Netzwerk-Switches, virtuelle Maschinen (VMs), Stromversorgungsmodule und/oder Kühlmodule usw. In einigen Ausführungsbeispielen können ein oder mehrere Knoten-C.R.s unter den Knoten-C.R.s 1316(1)-1316(N) einem Server entsprechen, der über eine oder mehrere der oben erwähnten Rechenressourcen verfügt. Darüber hinaus können in einigen Ausführungsbeispielen die Knoten C.R.s 1316(1)-13161(N) eine oder mehrere virtuelle Komponenten enthalten, wie z.B. vGPUs, vCPUs und/oder dergleichen, und/oder einer oder mehrere der Knoten C.R.s 1316(1)-1316(N) können einer virtuellen Maschine (VM) entsprechen.
  • In mindestens einem Ausführungsbeispiel können die gruppierten Rechner-Ressourcen 1314 separate Gruppierungen von Knoten-C.R.s 1316 umfassen, die in einem oder mehreren Racks (nicht gezeigt) untergebracht sind, oder viele Racks, die in Datenzentren an verschiedenen geografischen Orten untergebracht sind (ebenfalls nicht gezeigt). Getrennte Gruppierungen von Knoten-C.R.s 1316 innerhalb der gruppierten Rechenressourcen 1314 können gruppierte Rechen-, Netzwerk-, Arbeitsspeicher- oder Speicherressourcen umfassen, die zur Unterstützung einer oder mehrerer Arbeitslasten konfiguriert oder zugewiesen werden können. In mindestens einem Ausführungsbeispiel können mehrere Knoten-C.R.s 1316 mit CPUs, GPUs, DPUs und/oder anderen Prozessoren in einem oder mehreren Racks gruppiert werden, um Rechenressourcen zur Unterstützung einer oder mehrerer Arbeitslasten bereitzustellen. Die ein oder mehreren Racks können auch eine beliebige Anzahl von Stromversorgungsmodulen, Kühlmodulen und/oder Netzwerk Switches in beliebiger Kombination enthalten.
  • Der Ressourcen-Orchestrator 1312 kann einen oder mehrere Knoten-C.R.s 1316(1)-1316(N) und/oder gruppierte Rechner-Ressourcen 1314 konfigurieren oder anderweitig steuern. In mindestens einem Ausführungsbeispiel kann der Ressourcen-Orchestrator 1312 eine Verwaltungseinheit für die Software-Design-Infrastruktur (SDI) des Datenzentrums 1300 umfassen. Der Ressourcen-Orchestrator 1312 kann Hardware, Software oder eine Kombination davon umfassen.
  • In mindestens einem Ausführungsbeispiel, wie in 13 gezeigt, kann die Framework-Schicht 1320 einen Planer für Aufgaben 1333, einen Konfigurationsmanager 1334, einen Verwalter für Ressourcen 1336 und/oder ein verteiltes Dateisystem 1338 enthalten. Die Framework-Schicht 1320 kann ein Framework zur Unterstützung von Software 1332 der Software-Schicht 1330 und/oder einer oder mehrerer Applikation(en) 1342 der Applikationsschicht 1340 enthalten. Die Software 1332 bzw. die Anwendung(en) 1342 kann/können auf webbasierten Diensten oder Anwendungen basieren, wie sie beispielsweise von Amazon Web Services, Google Cloud und Microsoft Azure angeboten werden. Bei der Applikationsschicht 1320 kann es sich um eine Art kostenloses und quelloffenes Software-Framework für Webanwendungen wie Apache SparkTM (im Folgenden „Spark“) handeln, das ein verteiltes Dateisystem 1338 zum Verarbeiten großer Datenmengen (z.B. „Big Data“) nutzen kann, ist aber nicht darauf beschränkt. In mindestens einem Ausführungsbeispiel kann der Planer für Aufgaben 1333 einen Spark-Treiber enthalten, um die Planung von Arbeitslasten zu erleichtern, die von verschiedenen Schichten des Datenzentrums 1300 unterstützt werden. Der Verwalter 1334 kann in der Lage sein, verschiedene Schichten wie die Softwareschicht 1330 und die Framework-Schicht 1320 einschließlich Spark und das verteilte Dateisystem 1338 zur Unterstützung der Verarbeitung großer Datenmengen zu konfigurieren. Der Ressourcenverwalter 1336 kann in der Lage sein, geclusterte oder gruppierte Rechenressourcen zu verwalten, die dem verteilten Dateisystem 1338 und dem Planer für Aufgaben 1333 zugeordnet sind. In mindestens einem Ausführungsbeispiel können geclusterte oder gruppierte Rechenressourcen die gruppierte Rechenressource 1314 in der Datenzentrum-Infrastrukturschicht 1310 umfassen. Der Verwalter 1336 kann sich mit dem Ressourcen-Orchestrator 1312 abstimmen, um diese zugeordneten oder zugewiesenen Rechenressourcen zu verwalten.
  • In mindestens einem Ausführungsbeispiel kann die in der Softwareschicht 1330 enthaltene Software 1332 Software enthalten, die zumindest von Teilen der Knoten C.R.s 1316(1)-1316(N), den gruppierten Rechenressourcen 1314 und/oder dem verteilten Dateisystem 1338 der Framework-Schicht 1320 verwendet wird. Eine oder mehrere Arten von Software können unter anderem Internet-Such-Software, E-Mail-Viren-Scan-Software, Datenbank-Software und Software für Strom-Videoinhalte umfassen.
  • In mindestens einem Ausführungsbeispiel kann (können) die in der Applikationsschicht 1340 enthaltene(n) Applikation(en) 1342 eine oder mehrere Arten von Anwendungen umfassen, die zumindest von Teilen der Knoten C.R.s 1316(1)-1316(N), der gruppierten Rechnerressourcen 1314 und/oder des verteilten Dateisystems 1338 der Framework-Schicht 1320 verwendet werden. Eine oder mehrere Arten von Applikationen können eine beliebige Anzahl von genomischen Applikationen, kognitiven Rechnern und maschinellen Lernapplikationen umfassen, sind aber nicht darauf beschränkt, einschließlich Trainings- oder Inferenzierungssoftware, Framework-Software für maschinelles Lernen (z.B. PyTorch, TensorFlow, Caffe, etc.) und/oder andere maschinelle Lernapplikationen, die in Verbindung mit einer oder mehreren Ausführungsbeispielen verwendet werden.
  • In mindestens einem Ausführungsbeispiel können der Konfigurationsverwalter 1334, der Ressourcenverwalter 1336 und der Ressourcen-Orchestrator 1312 eine beliebige Anzahl und Art von selbstmodifizierenden Aktionen implementieren, basierend auf einer beliebigen Menge und Art von Daten, die auf jede technisch machbare Weise erfasst wurden. Selbstmodifizierende Aktionen können den Betreiber eines Datenzentrums 1300 davon entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Teile eines Datenzentrums zu vermeiden.
  • Das Datenzentrum 1300 kann Werkzeuge, Dienste, Software oder andere Ressourcen enthalten, um ein oder mehrere Modelle des maschinellen Lernens zu trainieren oder Informationen vorherzusagen oder zu inferenzieren, indem ein oder mehrere Modelle des maschinellen Lernens gemäß einem oder mehreren hierin beschriebenen Ausführungsbeispielen verwendet werden. Beispielsweise kann ein maschinelles Lernmodell bzw. können maschinelle Lernmodelle trainiert werden, indem Gewichtsparameter gemäß einer Architektur eines neuronalen Netzwerks unter Verwendung von Software und/oder Rechenressourcen berechnet werden, die oben in Bezug auf das Datenzentrum 1300 beschrieben wurden. In mindestens einem Ausführungsbeispiel können trainierte oder eingesetzte Modelle für maschinelles Lernen, die einem oder mehreren neuronalen Netzwerken entsprechen, verwendet werden, um Informationen zu inferenzieren oder vorherzusagen, wobei die oben beschriebenen Ressourcen in Bezug auf das Datenzentrum 1300 verwendet werden, indem Gewichtsparameter verwendet werden, die durch eine oder mehrere Trainingstechniken berechnet werden, wie z. B., aber nicht beschränkt auf die hierin beschriebenen.
  • In mindestens einem Ausführungsbeispiel kann das Datenzentrum 1300 CPUs, anwendungsspezifische integrierte Schaltungen (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder Inferenzieren unter Verwendung der oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der oben beschriebenen Software- und/oder Hardwareressourcen als Dienst konfiguriert werden, um Benutzern das Trainieren oder Inferenzieren von Informationen zu ermöglichen, wie z. B. Bilderkennung, Spracherkennung oder andere Dienste der künstlichen Intelligenz.
  • Beispielhafte Netzwerkumgebungen
  • Netzwerkumgebungen, die sich zur Verwendung bei der Implementierung von Ausführungsbeispielen der Offenbarung eignen, können ein oder mehrere Client-Geräte, Server, Network Attached Storage (NAS), andere Backend-Geräte und/oder andere Gerätetypen umfassen. Die Client-Geräte, Server und/oder andere Gerätetypen (z.B. jedes Gerät) können auf einer oder mehreren Instanzen des/der Rechengerät(e) 1200 von 12 implementiert werden - z.B. kann jedes Gerät ähnliche Komponenten, Merkmale und/oder Funktionalität des/der Rechengerät(e) 1200 enthalten. Wenn Backend-Geräte (z.B. Server, NAS usw.) implementiert sind, können die Backend-Geräte außerdem Teil eines Datenzentrums 1300 sein, dessen Beispiel in 13 detaillierter beschrieben wird.
  • Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerke miteinander kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netzwerk kann aus mehreren Netzwerken oder einem Netzwerk von Netzwerken bestehen. So kann das Netzwerk beispielsweise 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 öffentliches Telefonnetz (PSTN) und/oder ein oder mehrere private Netzwerke umfassen. Wenn das Netzwerk ein drahtloses Telekommunikationsnetz umfasst, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) drahtlose Konnektivität bereitstellen.
  • Zu den kompatiblen Netzwerkumgebungen gehören eine oder mehrere Peer-to-Peer-Netzwerkumgebungen - in diesem Fall kann ein Server nicht in einer Netzwerkumgebung enthalten sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung enthalten sein. In Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Geräten implementiert werden.
  • In mindestens einem Ausführungsbeispiel kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine Umgebung für verteiltes Rechnen, eine Kombination davon usw. umfassen. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Planer für Aufgaben, einen Verwalter für Ressourcen und ein verteiltes Dateisystem umfassen, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kern-Netzwerkserver und/oder Edge-Server umfassen können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Software-Schicht und/oder einer oder mehrerer Applikation(en) einer Applikationsschicht umfassen. Die Software oder die Anwendung(en) können jeweils webbasierte Dienstsoftware oder Applikationen umfassen. In Ausführungsbeispielen können ein oder mehrere der Geräte die webbasierte Dienstsoftware oder Applikationen verwenden (z.B. durch Zugriff auf die Dienstsoftware und/oder Applikationen über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs)). Bei der Framework-Schicht kann es sich um eine Art von freiem und quelloffenem Software-Webapplikations-Framework handeln, das z.B. ein verteiltes Dateisystem zum Verarbeiten großer Datenmengen (z.B. „Big Data“) verwendet, ist aber nicht darauf beschränkt.
  • Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination der hierin beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführen. Jede dieser verschiedenen Funktionen kann von zentralen oder Kern-Servern (z.B. von einem oder mehreren Datenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) über mehrere Orte verteilt werden. Befindet sich eine Verbindung zu einem Benutzer (z.B. einem Client-Gerät) relativ nahe an einem Edge-Server, kann ein Kern-Server zumindest einen Teil der Funktionalität dem Edge-Server zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat (z.B. auf eine einzelne Organisation beschränkt), öffentlich (z.B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z.B. eine hybride Cloud-Umgebung) sein.
  • Das (die) Client-Gerät(e) kann (können) zumindest einige der Komponenten, Merkmale und Funktionen des (der) hierin in Bezug auf 12 beschriebenen Rechengeräts (Rechengeräte) 1200 enthalten. Als Ausführungsbeispiel und ohne Einschränkung kann ein Rechengerät ein Personal Computer (PC), ein Laptop-Computer, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smartwatch, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder ein Gerät, ein Videoplayer, eine Videokamera, ein Überwachungsgerät oder -system, ein Fahrzeug ein Boot, ein fliegendes Schiff, eine virtuelle Maschine, eine Drohne, ein Roboter, ein tragbares Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Rechnersystem für Fahrzeuge, eine eingebettete Systemsteuerung, eine Fernbedienung, ein Gerät, ein elektronisches Gerät für Verbraucher, eine Workstation, ein Edge-Gerät, eine beliebige Kombination dieser beschriebenen Geräte oder jedes andere geeignete Gerät.
  • Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Befehlen, einschließlich computerausführbarer Befehle, wie z. B. Programmmodule, beschrieben werden, die von einem Rechner oder einer anderen Maschine, wie z. B. einem persönlichen Datenassistenten oder einem anderen tragbaren Gerät, ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, allgemeinen Rechnern, spezielleren Rechengeräten, usw. Die Offenbarung kann auch in verteilten Rechenumgebungen angewandt werden, in denen Aufgaben von ferngesteuerten Geräten ausgeführt werden, die über ein Kommunikationsnetzwerk verbunden sind.
  • Wenn hier von „und/oder“ in Bezug auf zwei oder mehr Elemente die Rede ist, so ist damit nur ein Element oder eine Kombination von Elementen gemeint. So kann beispielsweise „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C umfassen. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B enthalten. Ferner kann „mindestens eines der Elemente A und B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B enthalten.
  • Der Gegenstand der vorliegenden Offenbarung wird hier mit einer gewissen Genauigkeit beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, 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 zu umfassen. Auch wenn die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbart dargestellten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 16101232 [0146]

Claims (20)

  1. Verfahren umfassend: Bestimmen mindestens einer ersten Position eines oder mehrerer Akteure basierend zumindest auf einem ersten Zustand einer Umgebung unter Verwendung zumindest teilweise simulierter Daten; Anwenden erster Daten auf ein Deep-Neural-Network (DNN), um unter Verwendung der mindestens einen ersten Position des einen oder der mehreren Akteure eine oder mehrere Vorhersagen für mindestens eine zweite Position des einen oder der mehreren Akteure zu generieren; Anwenden von zweiten Daten, die der einen oder den mehreren Vorhersagen entsprechen, auf mindestens ein maschinelles Lernmodell (MLM), um zumindest teilweise basierend auf der einen oder den mehreren Vorhersagen eine vorhergesagte Aktion zu generieren, die einer oder mehreren Aktionen für ein Ego-Fahrzeug entspricht; Zuweisen von einer oder mehreren Ausgaben zu der Vorhersage unter Verwendung einer Wertfunktion, die zumindest auf einem zweiten Zustand der Umgebung basiert; und Aktualisieren von einem oder mehreren Parametern des mindestens einen MI,M zumindest basierend auf der einen oder den mehreren Ausgaben.
  2. Verfahren nach Anspruch 1, wobei das mindestens eine MLM zumindest einen Teil eines latenten Raums des DNN dekodiert, um die vorhergesagte Aktion entsprechend der einen oder mehreren Aktionen zu generieren.
  3. Verfahren nach Anspruch 1, weiter umfassend Bestimmen einer oder mehrerer Positionen des einen oder der mehreren Akteure unter Verwendung des DNN, wobei das Bestimmen der mindestens einen ersten Position des einen oder der mehreren Akteure ein Anpassen mindestens einer der vorhergesagten einen oder mehreren Positionen basierend auf dem Modellieren des Verhaltens eines Akteurs umfasst, um die mindestens eine erste Position zu generieren.
  4. Verfahren nach Anspruch 1, wobei die zweiten Daten ein oder mehrere Ziele der einen oder mehreren Aktionen für das Ego-Fahrzeug kodieren.
  5. Verfahren nach Anspruch 1, wobei das DNN ein DNN umfasst, das unter Verwendung von Imitationslernen trainiert wurde.
  6. Verfahren nach Anspruch 1, wobei die Vorhersage der einen oder mehreren Aktionen unter Verwendung eines Akteursnetzwerks des mindestens einen MLM erfolgt und mindestens einer der einen oder mehreren Parameter von einem Bewertungsnetzwerk stammt, das dem mindestens einen MLM entspricht.
  7. Verfahren nach Anspruch 1, wobei die eine oder mehreren Aktionen eine oder mehrere Trajektorien für das Ego-Fahrzeug umfassen.
  8. Verfahren nach Anspruch 1, wobei die zumindest eine zweite Position des einen oder der mehreren Akteure einer Trajektorie eines Akteurs entspricht und das Verfahren das Erweitern der Trajektorie unter Verwendung eines mechanischen Bewegungsalgorithmus umfasst, um eine erweiterte Trajektorie zu generieren, wobei die eine oder die mehreren Ausgaben der erweiterten Trajektorie entsprechen.
  9. Verfahren nach Anspruch 1, wobei der eine oder die mehreren Akteure das Ego-Fahrzeug und zumindest ein anderes Fahrzeug umfassen.
  10. Verfahren nach Anspruch 1, umfassend: Bestimmen, unter Verwendung des zweiten Zustands der Umgebung, einer Wahrscheinlichkeit einer Kollision zwischen dem Ego-Fahrzeug und einem anderen Objekt in der Umgebung; und Berechnen der einen oder mehreren Ausgaben, basierend zumindest auf der Wahrscheinlichkeit der Kollision.
  11. Prozessor, der eine oder mehrere Schaltungen umfasst, um ein Deep-Neural-Network (DNN) als Weltmodell für eine Simulation zu verwenden und bestärkendes Lernen anzuwenden, um zumindest ein MI,M zu trainieren, um eine Vorhersage einer oder mehrerer Aktionen für eine Ego-Maschine zu generieren, die die Simulation verwendet.
  12. Prozessor nach Anspruch 11, wobei ein latenter Raum des DNN in einen Zustand des Weltmodells für die Simulation dekodiert wird, um bestärkendes Lernen anzuwenden, um das zumindest eine MI,M unter Verwendung der Simulation zu trainieren.
  13. Prozessor nach Anspruch 11, wobei das DNN ein DNN umfasst, das unter Verwendung von Imitationslernen trainiert wird.
  14. Prozessor nach Anspruch 11, wobei das zumindest eine MLM trainiert wird, um eine Vorhersage einer Trajektorie für ein Fahrzeug zu generieren.
  15. Prozessor nach Anspruch 11, wobei bestärkendes Lernen unter Verwendung einer Wertfunktion angewandt wird, und wobei ein oder mehrere neuronale Netzwerke mit Wertfunktion trainiert werden, um eine Vorhersage einer oder mehrerer Ausgaben der Wertfunktion zu generieren.
  16. System, umfassend: eine oder mehrere Verarbeitungseinheiten; eine oder mehrere Speichereinheiten, die Anweisungen speichern, die, wenn sie von der einen oder den mehreren Verarbeitungseinheiten ausgeführt werden, die eine oder die mehreren Verarbeitungseinheiten veranlassen, Operationen auszuführen, die Folgendes umfassen: Empfangen von Sensordaten, die von einem oder mehreren Sensoren eines Ego-Fahrzeugs in einer Umgebung erzeugt werden; zumindest teilweise basierend auf den Sensordaten, Bestimmen mindestens einer ersten Position eines oder mehrerer Akteure; Anwenden erster Daten, die die mindestens eine erste Position anzeigen, auf ein Deep-Neural-Network (DNN), um unter Verwendung der mindestens einen ersten Position des einen oder der mehreren Akteure eine oder mehrere Vorhersagen mindestens einer zweiten Position des einen oder der mehreren Akteure zu generieren; Anwenden zweiter Daten, die der einen oder den mehreren Vorhersagen entsprechen, auf ein neuronales Netzwerk, um eine oder mehrere Vorhersagen einer oder mehrerer Ausgaben einer Wertfunktion zu generieren; Bestimmen einer oder mehrerer Fahrrichtlinien, die der einen oder den mehreren Ausgaben entsprechen; und Übertragen von Daten, die das Ego-Fahrzeug veranlassen, eine oder mehrere Aktionen basierend auf der einen oder den mehreren Fahrrichtlinien durchzuführen.
  17. System nach Anspruch 16, wobei die Wertfunktion eine Zustandswertfunktion enthält und ein oder mehrere Zustände der Wertfunktionen einem oder mehreren Zeitpunkten und einer oder mehreren Positionen der zumindest einen zweiten Position in dem latenten Raum entsprechen.
  18. System nach Anspruch 16, wobei die zweiten Daten ein oder mehrere Ziele für die eine oder mehreren Fahrrichtlinien kodieren und die eine oder mehreren Ausgaben dem einen oder den mehreren Zielen entsprechen.
  19. System nach Anspruch 16, wobei das neuronale Netzwerk zumindest einen Teil eines latenten Raums des DNN dekodiert, um die eine oder mehreren Vorhersagen der einen oder mehreren Ausgaben zu generieren.
  20. System nach Anspruch 16, wobei das System zumindest eines der folgenden Systeme umfasst: ein Steuersystem für eine autonome oder halbautonome Maschine; ein Wahrnehmungssystem für eine autonome oder halbautonome Maschine; ein System zum Durchführen von Simulationsoperationen; ein System zum Durchführen von Deep-Learning-Operationen; ein System, das unter Verwendung eines Edge-Geräts implementiert ist; ein System, das unter Verwendung eines Roboters implementiert ist; ein System, das eine oder mehrere virtuelle Maschinen (VMs) enthält; ein System, das zumindest teilweise in einem Datenzentrum implementiert ist; oder ein System, das zumindest teilweise unter Verwendung von Cloud-Rechenressourcen implementiert ist.
DE112021001994.5T 2020-11-01 2021-11-01 Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen Pending DE112021001994T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202063108432P 2020-11-01 2020-11-01
US63/108,432 2020-11-01
US17/453,055 2021-11-01
PCT/US2021/072157 WO2022094624A1 (en) 2020-11-01 2021-11-01 Model-based reinforcement learning for behavior prediction in autonomous systems and applications
US17/453,055 US20220138568A1 (en) 2020-11-01 2021-11-01 Model-based reinforcement learning for behavior prediction

Publications (1)

Publication Number Publication Date
DE112021001994T5 true DE112021001994T5 (de) 2023-01-19

Family

ID=81380207

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021001994.5T Pending DE112021001994T5 (de) 2020-11-01 2021-11-01 Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen

Country Status (5)

Country Link
US (1) US20220138568A1 (de)
JP (1) JP2023548721A (de)
CN (1) CN115315709A (de)
DE (1) DE112021001994T5 (de)
WO (1) WO2022094624A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11810225B2 (en) * 2021-03-30 2023-11-07 Zoox, Inc. Top-down scene generation
US11858514B2 (en) 2021-03-30 2024-01-02 Zoox, Inc. Top-down scene discrimination
CN113095481B (zh) * 2021-04-03 2024-02-02 西北工业大学 一种基于并行自我博弈的空战机动方法
US11847598B2 (en) * 2021-08-13 2023-12-19 Edgeverve Systems Limited Method and system for analyzing process flows for a process performed by users
US20230131614A1 (en) * 2021-10-21 2023-04-27 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods for coordinated vehicle lane assignment
EP4300132A1 (de) * 2022-07-01 2024-01-03 Infineon Technologies AG Radarvorrichtung und verfahren zum betreiben einer radarvorrichtung
CN116048085B (zh) * 2023-02-03 2023-11-07 江南大学 一种移动机器人的故障估计和容错迭代学习控制方法
CN116229318B (zh) * 2023-02-24 2023-09-22 湖北联投咨询管理有限公司 基于分向数据的信息解析系统
CN116028663B (zh) * 2023-03-29 2023-06-20 深圳原世界科技有限公司 三维数据引擎平台
CN116321239A (zh) * 2023-05-09 2023-06-23 深圳大学 基于无人机辅助的低功耗广域网通信的链路状态优化方法
CN117319451B (zh) * 2023-11-28 2024-02-27 爱瑞克(大连)安全技术集团有限公司 基于多模态大数据的城市级消防物联网监管系统及其方法

Also Published As

Publication number Publication date
JP2023548721A (ja) 2023-11-21
US20220138568A1 (en) 2022-05-05
CN115315709A (zh) 2022-11-08
WO2022094624A1 (en) 2022-05-05

Similar Documents

Publication Publication Date Title
DE112021000135T5 (de) Sensorfusion für anwendungen autonomer maschinen durch maschinelles lernen
DE112019006484T5 (de) Detektion von abständen zu hindernissen in autonomen maschinenanwendungen
DE112020003043T5 (de) Erkennung und klassifizierung von kreuzungsregionen für autonome maschinenanwendungen
DE112020001897T5 (de) Trainieren neuronaler Netze unter Verwendung von Grundwahrheitsdaten, die mit Karteninformationen ergänzt wurden, für autonome Maschinenanwendungen
DE112020006410T5 (de) Dreidimensionale kreuzungsstrukturvorhersage für anwendungen zum autonomen fahren
DE112021000216T5 (de) Verhaltensplanung für autonome Fahrzeuge
DE112020002126T5 (de) Erkennung von kreuzungsposen in autonomen maschinenanwendungen
DE112021001994T5 (de) Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen
DE112020002166T5 (de) Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen
DE102020117792A1 (de) Wirksames einsetzen von hindernis- und spurerkennungen, um spurzuweisungen für objekte in einer umgebung zu bestimmen
DE112020006404T5 (de) Planung und steuerung von spurwechseln in autonomen maschinenapplikationen
DE102021126254A1 (de) Überwachen der Aufmerksamkeit und der kognitiven Belastung der Insassen für autonome und halbautonome Fahranwendungen
DE112019000048T5 (de) Bestimmung eines befahrbaren freiraums für autonome fahrzeuge
DE112020000413T5 (de) Detektion von orientierungspunkten unter verwendung von kurvenanpassung für anwendungen für autonomes fahren
DE102021123159A1 (de) Adaptiver objektverfolgungsalgorithmus für autonome maschinenanwendungen
DE112020001400T5 (de) Iterative erzeugung räumlicher graphen
DE102019113114A1 (de) Verhaltensgesteuerte wegplanung in autonomen maschinenanwendungen
DE102020100685A1 (de) Vorhersage zeitlicher informationen in autonomenmaschinenanwendungen
DE102022121121A1 (de) Objektverfolgung unter Verwendung von LiDAR-Daten für autonome Maschinenanwendungen
DE102022112748A1 (de) Verwendung von ankunftszeitpunkten und sicherheitsprozedurenin bewegungsplanungstrajektorien für autonome fahrzeuge
DE112021000104T5 (de) Projizieren von mit fischaugenobjektiven aufgenommenen bildern zur merkmalserkennung in autonomen maschinenanwendungen
DE112021000422T5 (de) Vorhersage künftiger Trajektorien in Umgebungen mit mehreren Aktoren für autonome Maschinenanwendungen
DE102022104026A1 (de) Erzeugung von ground-truth-daten für die wahrnehmung durch tiefe neuronale netze in anwendungen für autonomes fahren
DE102022126706A1 (de) 3D-Oberflächenrekonstruktion mit Punktwolkenverdichtung unter Verwendung tiefer neuronaler Netze für autonome Systeme und Anwendungen
DE102022128030A1 (de) 3d-flächenrekonstruktion mit punktwolkenverdichtung unter verwendung künstlicher intelligenz für autonome systeme und anwendungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed