DE102022118649A1 - Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen - Google Patents

Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen Download PDF

Info

Publication number
DE102022118649A1
DE102022118649A1 DE102022118649.0A DE102022118649A DE102022118649A1 DE 102022118649 A1 DE102022118649 A1 DE 102022118649A1 DE 102022118649 A DE102022118649 A DE 102022118649A DE 102022118649 A1 DE102022118649 A1 DE 102022118649A1
Authority
DE
Germany
Prior art keywords
lidar
image
data
flow
vehicle
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
DE102022118649.0A
Other languages
English (en)
Inventor
David Wehr
Ibrahim Eden
Joachim Pehserl
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 DE102022118649A1 publication Critical patent/DE102022118649A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/56—Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
    • G06V20/58—Recognition of moving objects or obstacles, e.g. vehicles or pedestrians; Recognition of traffic objects, e.g. traffic signs, traffic lights or roads
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01B—MEASURING LENGTH, THICKNESS OR SIMILAR LINEAR DIMENSIONS; MEASURING ANGLES; MEASURING AREAS; MEASURING IRREGULARITIES OF SURFACES OR CONTOURS
    • G01B11/00—Measuring arrangements characterised by the use of optical techniques
    • G01B11/22—Measuring arrangements characterised by the use of optical techniques for measuring depth
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S17/00—Systems using the reflection or reradiation of electromagnetic waves other than radio waves, e.g. lidar systems
    • G01S17/88—Lidar systems specially adapted for specific applications
    • G01S17/89—Lidar systems specially adapted for specific applications for mapping or imaging
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S17/00—Systems using the reflection or reradiation of electromagnetic waves other than radio waves, e.g. lidar systems
    • G01S17/88—Lidar systems specially adapted for specific applications
    • G01S17/93—Lidar systems specially adapted for specific applications for anti-collision purposes
    • G01S17/931—Lidar systems specially adapted for specific applications for anti-collision purposes of land vehicles
    • 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/02—Control of position or course in two dimensions
    • G05D1/021—Control of position or course in two dimensions specially adapted to land vehicles
    • G05D1/0231—Control of position or course in two dimensions specially adapted to land vehicles using optical position detecting means
    • 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/02—Control of position or course in two dimensions
    • G05D1/021—Control of position or course in two dimensions specially adapted to land vehicles
    • G05D1/0231—Control of position or course in two dimensions specially adapted to land vehicles using optical position detecting means
    • G05D1/0238—Control of position or course in two dimensions specially adapted to land vehicles using optical position detecting means using obstacle or wall sensors
    • G05D1/024—Control of position or course in two dimensions specially adapted to land vehicles using optical position detecting means using obstacle or wall sensors in combination with a laser
    • 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/02—Control of position or course in two dimensions
    • G05D1/021—Control of position or course in two dimensions specially adapted to land vehicles
    • G05D1/0231—Control of position or course in two dimensions specially adapted to land vehicles using optical position detecting means
    • G05D1/0246—Control of position or course in two dimensions specially adapted to land vehicles using optical position detecting means using a video camera in combination with image processing means
    • 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/20—Control system inputs
    • G05D1/24—Arrangements for determining position or orientation
    • G05D1/247—Arrangements for determining position or orientation using signals provided by artificial sources external to the vehicle, e.g. navigation beacons
    • G05D1/249—Arrangements for determining position or orientation using signals provided by artificial sources external to the vehicle, e.g. navigation beacons from positioning sensors located off-board the vehicle, e.g. from cameras
    • 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/0464—Convolutional networks [CNN, ConvNet]
    • 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
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N7/00—Computing arrangements based on specific mathematical models
    • G06N7/01—Probabilistic graphical models, e.g. probabilistic networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/20—Analysis of motion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/50—Depth or shape recovery
    • G06T7/55—Depth or shape recovery from multiple images
    • G06T7/579—Depth or shape recovery from multiple images from motion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/70—Determining position or orientation of objects or cameras
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/10—Image acquisition modality
    • G06T2207/10028—Range image; Depth image; 3D point clouds
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/20—Special algorithmic details
    • G06T2207/20081—Training; Learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/30—Subject of image; Context of image processing
    • G06T2207/30248—Vehicle exterior or interior
    • G06T2207/30252—Vehicle exterior; Vicinity of vehicle
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/30—Subject of image; Context of image processing
    • G06T2207/30248—Vehicle exterior or interior
    • G06T2207/30252—Vehicle exterior; Vicinity of vehicle
    • G06T2207/30261—Obstacle

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Remote Sensing (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Electromagnetism (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Automation & Control Theory (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Evolutionary Computation (AREA)
  • Mathematical Physics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Artificial Intelligence (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mathematical Analysis (AREA)
  • Algebra (AREA)
  • Mathematical Optimization (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Computational Mathematics (AREA)
  • Molecular Biology (AREA)
  • Health & Medical Sciences (AREA)
  • Biophysics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biomedical Technology (AREA)
  • Optics & Photonics (AREA)
  • Image Processing (AREA)
  • Image Analysis (AREA)

Abstract

In verschiedenen Beispielen werden Systeme und Verfahren beschrieben, die durch Vereinfachen der 3D-LiDAR-Daten zu einem optischen „2,5D“-Raum (z. B. x-, y- und Tiefenfluss) einen Szenenfluss im 3D-Raum generieren. Zum Beispiel können LiDAR-Abstandsbilder verwendet werden, um 2,5D-Darstellungen von Tiefenflussinformation zwischen LiDAR-Datenframes zu generieren, und zwei oder mehr Abstandsbilder können verglichen werden, um Tiefenflussinformation zu generieren, und Nachrichten können - z. B. durch einen Belief Propagation-Algorithmus - weitergegeben werden, um Pixelwerte in der 2,5D-Darstellung zu aktualisieren. Die resultierenden Bilder können dann verwendet werden, um 2,5D-Bewegungsvektoren zu generieren, und die 2,5D-Bewegungsvektoren können in den 3D-Raum rückkonvertiert werden, um eine 3D-Szenenflussdarstellung einer Umgebung einer autonomen Maschine zu generieren.

Description

  • HINTERGRUND
  • Für einen sicheren und effektiven Betrieb müssen autonome und teilautonome Fahrzeuge sich bewegende Hindernisse oder Objekte in unterschiedlichen Entfernungen erkennen, um rechtzeitig geeignete Maßnahmen ergreifen zu können. Eine geeignete Maßnahme kann zum Beispiel ein Wenden, einen Spurwechsel, ein Bremsen und/oder Beschleunigen beinhalten, um erkannten Hindernissen auszuweichen oder von diesen weg zu manövrieren. Die frühzeitige und genaue Bestimmung von Hindernissen und ihrer Bewegung lässt außerdem Zeit zur Bestimmung und Ausführung geeigneter Maßnahmen. Daher muss die Objekterkennung und -verfolgung in Echtzeit oder nahezu in Echtzeit erfolgen, selbst wenn das Fahrzeug mit hoher Geschwindigkeit auf der Autobahn fährt oder Querverkehr vorhanden ist.
  • Eine Darstellung statischer und/oder sich bewegender Objekte im dreidimensionalen (3D) Raum kann als Szenenfluss bezeichnet werden. Bestehende Szenenflusssysteme sind in der Regel stationär und/oder für begrenzte Sichtfelder ausgelegt. Aufgrund der Komplexität und der Rechenanforderungen der Durchführung des Szenenflusses im 3D-Raum können bestehende Szenenflusssysteme auch nicht in der Lage sein, in Echtzeit zu arbeiten, oder können nur mit beschränkter Auflösung und/oder Genauigkeit in Echtzeit arbeiten. Aufgrund dieser Einschränkungen sind bestehende autonome Fahrzeuge auf andere Verfahren und Datenquellen zur Hinderniserkennung wie z. B. kamerabasierte neuronale Netze, LiDAR-Punktwolken und/oder RADAR-Daten angewiesen. Auch wenn kamerabasierte neuronale Netze bei kurzen Entfernungen genau sind, sind sie bei größeren Entfernungen aufgrund der beschränkten Anzahl von Pixeln, die ein gegebenes Objekt oder Hindernis darstellen, nicht so genau. Darüber hinaus enthalten LiDAR- und RADAR-Sensoren allgemein fehlende Datenpunkte und können verrauscht sein. Diese bestehenden Verfahren stützen sich in der Regel auf die Analyse einzelner Datenframes, denen wichtiger Kontext fehlen kann, der nur durch Analyse mehrerer Datenframes über die Zeit gewonnen werden kann.
  • ZUSAMMENFASSUNG
  • Ausführungsformen der vorliegenden Erfindung betreffen die Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen. Es werden Systeme und Verfahren offenbart, die einen LiDAR-basierten Szenenfluss in Echtzeit bereitstellen, indem sie sich mindestens zum Teil auf die Bewegung über die Zeit konzentrieren, statt auf die Detektion von Einzelbildern. Im Gegensatz zu herkömmlichen Systemen, wie den oben beschriebenen, generiert das vorliegende System und Verfahren den Szenenfluss im 3D-Raum durch Vereinfachen der 3D-LiDAR-Daten zu einem erweiterten zweidimensionalen („2,5D“) Tiefenflussraum (z. B. x-, y- und Tiefenfluss - um eine Änderung in Tiefenwerten zwischen LiDAR-Abstandsbildern anzugeben), Weitergeben von Nachrichten zwischen Pixeln (z. B. zwischen Knoten einer Pixeldarstellung wie z. B. eine Matrix, ein Raster, eine Tabelle usw., die Pixeln entsprechen) - z. B. durch einen Belief Propagation-Algorithmus - und Berechnen von 3D-Bewegungsvektoren für Pixel durch Rückkonvertieren der 2,5D-Information in den 3D-Raum (z. B. auf der Basis bekannter Zuordnungen zwischen den 2,5D-Bildraumpositionen und 3D-Weltraumpositionen). Dadurch kann verrauschte oder fehlende Information aus den LiDAR-Daten durch Nachrichtenweitergabe (Message Passing) - z. B. im 2D- oder 2,5D-Raum - geschätzt werden, um eine dichtere Darstellung der Szene zu generieren, und die dichtere Darstellung kann dann zur Verwendung bei der Detektion, Identifizierung und/oder Verfolgung von dynamischen Objekten in der Umgebung in den 3D-Raum rückkonvertiert werden. Das vorliegende System kann dazu konfiguriert sein, auf einer mobilen Plattform wie z.B. einer autonomen Maschine (z. B. Fahrzeug, Roboter usw.) eingesetzt zu werden, und kann z. B. rotierende LiDAR-Sensoren oder andere Tiefensensoren umfassen, die ein größeres Sichtfeld (z. B. bis zu 360 Grad) als bestehende Systeme haben. Da ein wesentlicher Teil der Berechnungen in Bezug auf Projektionsbilder (z. B. LiDAR-Abstandsbilder) erfolgt, statt im 3D-Raum, ist das vorliegende System zudem auch in der Lage, in Echtzeit arbeiten, um sich bewegende Hindernisse zu identifizieren.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren zur Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen werden im Folgenden Bezug nehmend auf die beigefügten Zeichnungen im Detail beschrieben, wobei:
    • 1A ein Datenflussdiagramm ist, das ein System zur Schätzung eines Szenenflusses gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
    • 1B ein Zeitablaufdiagramm ist, das einen Prozess zum Generieren eines Szenenflusses gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
    • 2 ein Diagramm ist, das Labels auf einem beispielhaften Pixelvolumen zeigt, das gemäß Ausführungsformen der vorliegenden Erfindung die Bildverschiebung und den Tiefenfluss darstellt;
    • 3 ein Diagramm ist, das eine beispielhafte Kostenfunktion für die Nachrichtenweitergabe in Bezug auf den Tiefenfluss gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
    • 4 ein Diagramm ist, das die Nachrichtenweitergabe zwischen einem Pixelknoten und benachbarten Pixelknoten gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
    • 5 ein Diagramm ist, das zwei aufeinanderfolgende LiDAR-Abstandsbilder und ein resultierendes Tiefenflussbild gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
    • 6A und 6B Diagramme sind, die resultierende Szenenflüsse zeigen, die aus Tiefenflussbildern gemäß Ausführungsformen der vorliegenden Erfindung generiert wurden;
    • 7 ein Ablaufplan ist, der ein Verfahren zum Generieren eines Szenenflusses durch Belief Propagation gemäß Ausführungsformen der vorliegenden Erfindung darstellt;
    • 8A eine Darstellung eines beispielhaften autonomen Fahrzeugs gemäß Ausführungsformen der vorliegenden Erfindung ist;
    • 8B ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug von 8A gemäß Ausführungsformen der vorliegenden Erfindung ist;
    • 8C ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 8A gemäß Ausführungsformen der vorliegenden Erfindung ist;
    • 8D ein Systemdiagramm für die Kommunikation zwischen Cloud-basierten Servern und dem beispielhaften autonomen Fahrzeug von 8A gemäß Ausführungsformen der vorliegenden Erfindung ist;
    • 9 ein Blockdiagramm einer beispielhaften Computereinheit ist, die zur Implementierung von Ausführungsformen der vorliegenden Erfindung geeignet ist; und
    • 10 ein Blockdiagramm eines beispielhaften Datenzentrums ist, das zur Implementierung von Ausführungsformen der vorliegenden Erfindung geeignet ist.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Es werden Systeme und Verfahren offenbart, die die Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen betreffen. Auch wenn die vorliegende Erfindung in Bezug auf ein beispielhaftes autonomes Fahrzeug 800 (hier auch als „Fahrzeug 800“ oder „Ego-Fahrzeug 800“ bezeichnet) beschrieben werden kann, das auf 8A-8D Bezug nehmend als Beispiel beschrieben wird, ist dies nicht einschränkend zu verstehen. Die Systeme und Verfahren, die hier beschrieben werden, sind zum Beispiel, ohne darauf beschränkt zu sein, auch in nicht-autonomen Fahrzeugen, halbautonomen Fahrzeugen (z. B. in adaptiven Fahrerassistenzsystemen (ADAS)), gelenkten und ungelenkten Robotern oder Roboterplattformen, Lagerfahrzeugen, Geländefahrzeugen, fliegenden Wasserfahrzeugen, Booten, Shuttles, Noteinsatzfahrzeugen, Motorrädern, elektrischen oder motorisierten Zweirädern, Flugzeugen, Baufahrzeugen, Unterwasserfahrzeugen, Drohnen und/oder Fahrzeuge und autonome Maschinen anderen Typs anwendbar. Auch wenn die vorliegende Erfindung in Bezug auf das Generieren eines Szenenflusses für autonomes Fahren beschrieben werden kann, ist dies nicht einschränkend zu verstehen, und die Systeme und Verfahren, die hier beschrieben werden, können in Augmented Reality-, Virtual Reality-, Mixed Reality-, Robotik-, Sicherheits- und Überwachungs-, autonomen oder halbautonomen Maschinenanwendungen und/oder jeden anderen Technologiebereichen verwendet werden, in denen ein Szenenfluss verwendet werden kann.
  • Ausführungsformen der vorliegenden Erfindung betreffen die Bestimmung des Szenenflusses unter Verwendung von Tiefensensoren wie z. B. LiDAR-Sensoren, die in autonomen Fahrzeugen eingesetzt werden, durch Erzeugen und Analyse von Abstandsbildern, die aus LiDAR-Abstandsbildern (oder anderen Projektionsbildern) generiert werden. Zum Beispiel können die LiDAR-Sensoren 3D-LiDAR-Daten generieren, die für ihr Sicht- oder Sensorfeld repräsentativ sind - z. B. können LiDAR-Daten eine sphärische Standardprojektion oder einen anderen Projektionstyp darstellen. Die LiDAR-Sensoren können ständig LiDAR-Daten generieren, sodass zahlreiche LiDAR-Datensätze generiert werden, die jeweils eine einzelne Abtastung oder Umdrehung des LiDAR-Sensors darstellen. Die LiDAR-Datensätze können durch ein Zeitintervall getrennt sein - das dem Zeitintervall entspricht, das erforderlich ist, um zum Beispiel eine Umdrehung zu vollenden -, und Ausführungsformen der vorliegenden Erfindung können einen ersten (z. B. aktuellen) LiDAR-Datensatz verwenden und ihn mit einem zweiten, früheren (z. B. unmittelbar vorhergehenden) LiDAR-Datensatz vergleichen, um verschiedene Informationen aus den Daten zu bestimmen, wie hier erläutert. In Ausführungsformen können zwei aufeinanderfolgende LiDAR-Datensätze analysiert werden; dies ist jedoch nicht einschränkend zu verstehen, und die analysierten LiDAR-Datensätze können auch anderen Datenanordnungen als aufeinanderfolgenden Einzelbildern entsprechen.
  • Die komplexen 3D-LiDAR-Daten (die z. B. für eine 3D-Punktwolke repräsentativ sind) können zu einem 2D-LiDAR-Abstandsbild (oder einem Projektionsbild anderen Typs) vereinfacht und mit Zusatzinformation (z. B. Tiefenfluss) kodiert werden, um ein 2.5D-Tiefenflussbild (im Folgenden auch als „Tiefenflussbild“ bezeichnet) zu generieren, das eine schnellere Analyse ermöglicht. In Ausführungsformen kann die Auflösung des Tiefenflussbilds auch durch einen Pyramiden- oder Mehrskalenansatz reduziert werden, um insbesondere, wenn zwischen Einzelbildern größere Bewegungen auftreten, die Identifizierung von optischer Flussinformation zu beschleunigen. Das Tiefenflussbild kann eine Gruppe von Pixeln enthalten, die jeweils einen Satz zweidimensionaler (2D) Koordinaten und einen Tiefenflusswert (der Änderungen in der Tiefe oder im Abstand über Einzelbilder hinweg anzeigt) aufweisen. In Ausführungsformen kann der Tiefenfluss als ein Satz Label vereinfacht werden (z. B., wenn ein Label-basierter Algorithmus wie z. B. Belief Propagation verwendet wird), die eine Bewegung zum Sensor hin, eine Bewegung vom Sensor weg und/oder keine Bewegung zum Sensor hin oder vom Sensor weg (z. B. stationär) anzeigen. Diese Tiefenflusswerte können zum Beispiel als -1 (hin), +1 (weg) und 0 (stationär) dargestellt werden. In Ausführungsformen kann der Tiefenfluss körniger sein und eine schnelle Bewegung zum Sensor hin, eine langsame Bewegung zum Sensor hin, keine Bewegung zum Sensor hin, eine langsame Bewegung vom Sensor weg und/oder eine schnelle Bewegung vom Sensor weg darstellen. Diese vereinfachte Tiefenflussinformation kann die Analyse, die hier erläutert wird, ermöglichen.
  • Beim Vergleich von zwei - z. B. aufeinanderfolgenden - Abstandsbildern kann ein Abstandsbild (z. B. das vorherige Bild) in ein Koordinatensystem des nachfolgenden oder aktuellen Abstandsbilds (oder umgekehrt) umgewandelt oder rektifiziert werden, um die Ego-Bewegung zu kompensieren. Durch Kompensieren der Ego-Bewegung braucht bei der anschließenden Analyse nur die Bewegung von Objekten relativ zum Ego-Fahrzeug berücksichtigt zu werden, da die Bewegung des Ego-Fahrzeugs ausgeklammert wurde, was die Ausrichtung der zwei Abstandsbilder in einem gemeinsamen Koordinatensystem ermöglicht.
  • In Ausführungsformen werden zwei oder mehr Abstandsbilder verglichen, um die 3D-Bewegungsvektoren jedes darin enthaltenen Pixels zu bestimmen. Der 3D-Bewegungsvektor wird über einen Message Passing Belief Propagation-Algorithmus durch Analyse von zwei oder mehr Tiefenbildern generiert. Zum Beispiel können Pixeldaten durch den Belief Propagation-Algorithmus zu benachbarten Pixeln (z. B. Pixelknoten, die in einer Matrix, einer Tabelle, einem Raster usw. dargestellt sind) propagiert werden, und die an benachbarten Pixeln (z. B. benachbarten Knoten der Pixeldarstellung) empfangenen Daten werden analysiert und verwendet, um aktualisierte Werte für die Pixel zu bestimmen. Dann werden zusätzliche Iterationen durchgeführt, um die Ergebnisse zu verfeinern.
  • Allgemein ist die Belief Propagation ein Message-Passing-Algorithmus zum Inferieren von Information aus grafischen Modellen. Obwohl Belief Propagation in manchen Fällen genau sein kann, wird sie häufig für Näherungen verwendet. Der Belief Propagation-Algorithmus kann erfordern, dass zwei Nebenbedingungen definiert werden: Die erste ist die Bestimmung eines Datenterms; und die zweite ist die Bestimmung eines Glättungsterms. Der Datenterm kann verwendet werden, um in zwei Abstandsbildern ähnliche oder gleiche Pixel zu identifizieren, sodass die Bewegung des durch die Pixel dargestellten Objekts bestimmt werden kann. Der Glättungsterm kann verwendet werden, um die Werte benachbarter Pixel so anzupassen, dass identifizierte Objekte sich als Einheit bewegen, oder Grenzen zwischen Objekten oder Flächen als solche behandelt werden. Die Nachrichten können zwischen Pixeln (z. B. den Pixeln entsprechende Pixelknoten) desselben Tiefenflussbilds gesendet werden und enthalten Information sowohl bezüglich des Datenterms als auch des Glättungsterms. Die Nachrichten können insbesondere die Tiefenflussinformation (um eine allgemeine Richtung nach innen und außen zur Identifizierung der richtigen Pixel zwischen Einzelbildern zu ermitteln), 2D-Pixelflussinformation (Pixelbewegung zwischen Einzelbildern) und/oder die Kosten (um zu ermitteln, wie stark die Pixel ihre Nachbarn beeinflussen sollten) enthalten.
  • Der Datenterm kann angeben, welche Pixel in den zwei oder mehr Abstandsbildern demselben Objekt (oder einem Teil desselben Objekts) entsprechen. Der Datenterm kann in bestimmten Fällen nützlich sein, da das physische Objekt und/oder die Tiefensensoren sich zwischen den Bildern bewegen. Variablen wie Tiefenfluss, Reflektivität, Farbwerte, Intensität, Time of Flight (ToF), Textur, Rücklaufverhalten und/oder andere Information (wie z. B. solche, die durch LiDAR-Daten oder in LiDAR-Abstandsbildern dargestellt wird) können im Datenterm analysiert werden.
  • Zwischen Pixeln (z. B. Pixelknoten), die unterschiedlichen Objekten entsprechen, dürfen keine Nachrichten weitergegeben werden. Zum Beispiel werden benachbarte Pixel, für die berechnet wurde, dass sie nicht demselben physischen Objekt in der physischen Umgebung entsprechen (z. B., weil ein erkannter Unterschied in der Tiefe oder im Reflexionsvermögen zwischen beiden Pixeln einen bestimmten Schwellenwert übersteigt), keine Nachrichten miteinander austauschen. Diese Pixel dürfen ihre Nachbarpixel nicht beeinflussen, da sie unterschiedlichen physischen Objekten entsprechen. Dadurch werden Unterschiedlichkeiten diesen benachbarten Pixeln durch den Belief Propagation-Algorithmus nicht übermäßig beeinflusst.
  • Der Glättungsterm kann identifizieren, welcher Wert für den Tiefenfluss bei Pixeln, die demselben physischen Objekt entsprechen, annähernd korrekt ist. Ein sich im Raum bewegendes physisches Objekt bewegt sich in der Regel als eine Einheit. Daher können die unvollständigen und ungenauen Daten einiger Pixel durch benachbarte Pixel angepasst und beeinflusst werden, um diese Information zu berücksichtigen. Zum Beispiel werden jedem Pixel Kosten zugewiesen, die davon abhängig sind, wie zuverlässig die damit verbundenen Daten sind. Pixeln mit unvollständigen Daten (z. B. kein Rücklauf zum LiDAR-Sensor) können niedrige Kosten zugewiesen werden, sodass sie durch den Belief Propagation-Algorithmus mit größerer Wahrscheinlichkeit von ihren Nachbarpixeln beeinflusst werden. Dies kann trotz fehlender Daten aus der ursprünglichen LiDAR-Abtastung die Erzeugung eines dichten Bewegungsfelds ermöglichen.
  • Durch Weitergabe und Analyse dieser Nachrichten zwischen Pixeln desselben Tiefenflussbilds kann die Genauigkeit der verschiedenen Daten an jedem Pixel zu einem verfeinerten 2D (oder 2,5D)-Bewegungsvektor verbessert werden. Fehlende oder unvollständige Daten für andere Pixel können ebenfalls geschätzt und verfeinert werden.
  • Die 2D (oder 2,5D)-Vektoren können dann anhand der bekannten Entsprechung zwischen den 2D-Bildraum- und den 3D-Weltraum-Positionen in den 3D-Raum rückkonvertiert werden. Dadurch kann für Punkte in den LiDAR-Punktwolken ein 3D-Bewegungsvektor bestimmt werden, wobei die 3D-Bewegungsvektoren die Differenz (oder Bewegung) der Punkte - und somit der Objekte oder Hindernisse - über Einzelframes der LiDAR-Daten hinweg darstellen. Der Message Passing Belief Propagation-Algorithmus ermöglicht es, diese komplexe Analyse zu vereinfachen und vor der Rückkehr in den 3D-Raum abzuschließen - wodurch der Rechenaufwand und die Laufzeit des Systems reduziert werden, da die Analyse in einem 3D-Koordinatensystem vermieden wird. Schließlich zeigt der Szenenfluss die Bewegung der verschiedenen physischen Objekte rund um die Tiefensensoren und kann verwendet werden, um dynamische Objekte rund um eine autonome oder halbautonome Maschine zu erkennen und zu verfolgen, sodass die Maschine verschiedene geeignete Maßnahmen ergreifen kann, um die Objekte zu berücksichtigen.
  • Nun auf 1A Bezug nehmend, stellt 1A ein beispielhaftes SzenenflussGenerierungssystem 100 gemäß Ausführungsformen der vorliegenden Erfindung dar. Es versteht sich, dass diese und andere Anordnungen, die hier beschrieben werden, lediglich beispielhaft sind. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, Funktionsgruppen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können auch ganz entfallen. Ferner sind viele der Elemente, die hier beschrieben werden, 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 Funktionen, die hier als von Einheiten durchgeführt beschrieben werden, können durch Hardware, Firmware und/oder Software durchgeführt werden. Zum Beispiel können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In Ausführungsformen kann das System 100 ähnliche Komponenten, Merkmale und/oder Funktionalitäten wie die des Fahrzeugs 800, das hier auf 8A-8D Bezug nehmend beschrieben wird, der beispielhaften Recheneinheit 900 von 9 und/oder des beispielhaften Datenzentrums 1000 von 10 umfassen.
  • Wie in 1A gezeigt, kann das Szenenflusssystem 100 einen oder mehrere Tiefenperzeptionssensoren 102 (wie z. B. einen LiDAR-Sensor, einen RADAR-Sensor, einen Ultraschallsensor usw.) umfassen. Tiefenperzeptionssensoren 102 können allgemein einen Sender und einen Empfänger umfassen und ein beliebiges geeignetes Sichtfeld oder Sensorfeld haben - wie z. B. ein weites Sichtfeld (z. B. 180 Grad bis zu 360 Grad) - und können sich in Ausführungsformen bewegen (z. B. rotieren), um das Sichtfeld des Tiefenperzeptionssensors 102 zu erweitern. Die Signale - z. B. LiDAR-Signale - können von Objekten in der Nähe des Tiefenperzeptionssensors 102 reflektiert werden. Die Objekte können sich relativ zum Tiefenperzeptionssensor 102 bewegen, und der Tiefenperzeptionssensor 102 kann sich relativ zu einer darunter liegenden Fläche (wie z. B. einer Straße, auf der das autonome Fahrzeug fährt) bewegen. Der Empfänger kann (direkt oder indirekt) eine Indikation dieser verschiedenen reflektierten Signale empfangen, und die Indikation kann als Daten gespeichert und/oder zur späteren Analyse übertragen werden.
  • Der Tiefenperzeptionssensor 102 kann einen Sensor-Controller 104 aufweisen, der den Betrieb des Tiefenperzeptionssensors 102 steuert und die Ergebnisse interpretiert. Zum Beispiel kann der Sensor-Controller 104 oder ein anderer Prozessor die Sensordaten 106 empfangen und verarbeiten, analysieren oder andere Berechnungen bezüglich der Sensordaten 106 durchführen. In Ausführungsformen können der Tiefenperzeptionssensor 102 und/oder die Sensorsteuerung 104 dem LiDAR-Sensor 864 entsprechen, der auf 8A-8C Bezug nehmend beschrieben wird, oder kann ein Tiefenperzeptionssensor 102 anderen Typs sein.
  • Der Sensor-Controller 104 kann Sensordaten 106 an ein Computersystem 108 ausgeben, wie z.B. ein Computersystem, das im Fahrzeug 800 und/oder in der beispielhaften Recheneinheit 900 von 9 ausgeführt wird. Die Sensordaten 106 können in verschiedenen Formen vorliegen, wie z. B. als 3D-LiDAR-Punktwolke, ohne darauf beschränkt zu sein. Die Sensordaten 106 können analysiert werden, um verschiedene damit verbundene Funktionen durchzuführen, und sie können in Verbindung mit anderen Sensordaten 106 (wie z. B. den verschiedenen Sensoren, die in 8A-8C gezeigt und hier erläutert werden) verwendet werden. In Ausführungsformen, in denen ein LiDAR-Sensor verwendet wird, können die Sensordaten 106 als LiDAR-Daten bezeichnet werden; in anderen Ausführungsformen der vorliegenden Erfindung können die Sensordaten 106 jedoch auch Tiefendaten anderen Typs sein (z. B. RADAR-, Ultraschall usw.).
  • Das System 100 kann einen Koordinatenwandler 110 umfassen, der die Sensordaten 106 in verschiedene Formate, Bezugssysteme (z. B. von 3D zu 2D oder 2,5D usw.) und/oder Typen (z. B. von Punktwolken zu Projektionen oder Abstandsbildern) konvertieren kann. Als nicht einschränkendes Beispiel kann der Koordinatenwandler 110 LiDAR-Daten, die für eine 3D-Punktwolke repräsentativ sind, in ein 2D-Abstandsbild oder ein Projektionsbild anderen Typs konvertieren, und ein Tiefenflussgenerator kann Tiefeninformation zwischen Einzelbildern analysieren, um unter Verwendung des Tiefenflussbildgenerators 112 ein „2,5D“-Tiefenflussbild zu erzeugen. In Ausführungsformen kann der Koordinatenwandler 110 ein oder mehrere Abstandsbilder (auf der Basis der bekannten oder verfolgten Bewegung des Fahrzeugs 800 (z. B. Ego-Bewegung)) in dasselbe Koordinatensystem konvertieren und nach der optischen Flussanalyse, der Nachrichtenweitergabe usw. im 2,5D-Raum kann der Koordinatenwandler 110 das resultierende 2,5D-Tiefenflussbild in eine 3D-Szenenflussdarstellung konvertieren.
  • Das System 100 kann außerdem den Tiefenflussgenerator 116 umfassen, der unter Verwendung eines oder mehrerer Sätze von Sensordaten 106 ein oder mehrere Tiefenflussbild(er) erzeugen kann. Abstandsbilder, wie in 5 gezeigt, können mit einem oder mehreren LiDAR-Sensoren aus LiDAR-Daten erzeugt werden. 5 zeigt einen ersten LiDAR-Datensatz 502, der an einem Zeitpunkt T1 erfasst wurde, und einen zweiten LiDAR-Datensatz 504, der an einem Zeitpunkt T2 erfasst wurde. LiDAR-Datensätze können zum Beispiel eine sphärische Projektion oder eine Projektion anderen Typs darstellen, die sich vom Tiefenperzeptionssensor 102 aus erstreckt. Die LiDAR-Sensoren können ständig LiDAR-Daten generieren, sodass zahlreiche LiDAR-Datensätze generiert werden. Jeder dieser Sätze kann eine einzige Abtastung, Umdrehung oder andere Erfassung des LiDAR-Sensors anzeigen, und die LiDAR-Datensätze können durch ein Zeitintervall getrennt sein. Um optische Flussbilder oder Tiefenflussbilder zu erzeugen, kann der Tiefenflussbildgenerator 112 in Ausführungsformen einen zweiten (z. B. aktuellen oder jüngsten) LiDAR-Datensatz 504 verwenden und diesen mit einem vorherigen LiDAR-Datensatz 502 vergleichen, um verschiedene Informationen aus den Daten zu bestimmen, wie hier beschrieben. In Ausführungsformen können zwei aufeinanderfolgende LiDAR-Datensätze analysiert werden; dies ist jedoch nicht einschränkend zu verstehen, und die analysierten LiDAR-Datensätze können auch anderen Anordnungen als aufeinanderfolgenden Einzelbildern entsprechen.
  • In Ausführungsformen kann das optische Flussbild oder Tiefenflussbild eine vereinfachte „2,5D“-Wiedergabe von 3D-Information sein, in der Pixel (z. B. jedes Pixel) eine Koordinate (z. B. eine (x, y)-Koordinate, die z. B. jeweils einen Azimut und eine Elevation angibt) und eine oder mehrere zugehörige Variablen wie z. B. Tiefe und/oder Tiefenfluss aufweisen. Durch Reduzieren der 3D-Darstellung auf eine 2D- oder 2,5D-Darstellung kann die Rechen- und Laufzeit verkürzt werden.
  • In Ausführungsformen kann der Tiefenflussbildgenerator 112 mindestens zum Teil auf der Basis von ersten LiDAR-Daten, die an einem Zeitpunkt T1 mit einem oder mehreren LiDAR-Sensor(en) generiert wurden, ein erstes Abstandsbild generieren. Das erste Abstandsbild kann derart generiert werden, dass die Pixel des Bilds Tiefenflusswerte aufweisen, die z. B. die Änderung in Tiefenwerten über Einzelbilder hinweg anzeigen. Dementsprechend kann der Tiefenflussbildgenerator 112 mindestens zum Teil auf der Basis von zweiten LiDAR-Daten, die an einem Zeitpunkt T2 nach T1 mit dem oder den LiDAR-Sensor(en) generiert wurden, ein zweites Abstandsbild generieren. Das erste und das zweite Abstandsbild können dann gespeichert, analysiert und/oder miteinander (sowie mit dritten Tiefenflussbildern, vierten Tiefenflussbildern usw.) verglichen werden, wie hier beschrieben.
  • In Ausführungsformen der vorliegenden Erfindung können die Abstandsbilder aus LiDAR-Abstandsbildern generiert werden, die mit Daten generiert wurden, die für eine oder mehrere LiDAR-Punktwolke(n) repräsentativ sind. LiDAR-Punktwolken, wie hier beschrieben, können den von LiDAR-Sensoren (und/oder vom LiDAR-Controller) ausgegeben Rohdaten entsprechen. Die LiDAR-Daten können eine beliebige Kombination verschiedener Variablen darstellen, die in den gesendeten und empfangenen Signalen enthalten sind, wie z. B., ohne darauf beschränkt zu sein, Reflektivitätsinformation, Texturinformation, Time of Flight (ToF)-Information, Farbinformation und/oder Intensitätsinformation.
  • Die komplexen 3D-LiDAR-Daten (die z. B. für eine 3D-Punktwolke repräsentativ sind) können zu einem 2D-LiDAR-Abstandsbild (oder einem Projektionsbild anderen Typs) vereinfacht und mit Zusatzinformation (wie z. B. dem Tiefenfluss) kodiert werden, um ein 2,5D-Tiefenflussbild zu generieren, das eine schnelle Analyse ermöglicht. In Ausführungsformen kann die Auflösung des Tiefenflussbilds auch durch einen Pyramiden- oder Multiskalenansatz reduziert werden, um insbesondere, wenn zwischen Einzelbildern eine größere Bewegung auftritt (wie bei Tiefenperzeptionssensoren 102 in einem autonomen Fahrzeug, das mit hoher Geschwindigkeit auf der Autobahn fährt), die Identifizierung optischer Flussinformation zu beschleunigen. Das Tiefenflussbild kann einen Gruppe von Pixeln enthalten, die jeweils einen Satz von 2D-Koordinaten und einen Tiefenfluss aufweisen. Der Tiefenfluss kann in Ausführungsformen als Label am Pixel gespeichert werden.
  • Die vereinfachte Tiefenflussdarstellung kann anstelle der komplexeren 3D-LiDAR-Punktwolkendaten in der Verarbeitung für den Szenenfluss verwendet werden. Die vereinfachten Berechnungen können die Durchführung der hier beschriebenen Analyse in Echtzeit ermöglichen, und die Ergebnisse können in den 3D-Raum rückprojiziert werden, sodass mit weniger Rechen- und Verarbeitungszeit genaue 3D-Szenenflussinformation generiert wird.
  • Das System 100 kann einen Belief Propagator 114 umfassen, der eine oder mehrere Pixel-Eigenschaft(en) identifizieren oder zuweisen kann, wie in 2 dargestellt. Zum Beispiel kann der Belief Propagator 114, wie in 3 dargestellt, Nachrichten zwischen Pixeln (z. B. Pixelknoten einer Darstellung der Pixel wie z.B. eine Matrix, ein Graph, eine Tabelle usw.) des Tiefenflussbilds übergeben, um die darin enthaltene Information zu verfeinern und zu analysieren. In Ausführungsformen können Pixeln Kosten zugewiesen werden, wie in 4 gezeigt.
  • Ausführungsformen der vorliegenden Erfindung können einen Belief Propagation-Algorithmus verwenden, um zwischen benachbarten Pixeln (z. B. Pixelknoten) der Tiefenflussbilder Nachrichten weiterzugeben. Allgemein ist Belief Propagation ein Message Passing-Algorithmus zum Inferieren von Information aus grafischen Modellen. Obwohl Belief Propagation in manchen Fällen genau sein kann, wird sie häufig für Näherungen verwendet. Zum Beispiel wird die genaue Information der LiDAR-Daten zum Tiefenflussbild vereinfacht, die Nachrichtenweitergabe nähert die Werte benachbarter Pixel, und die genäherten Werte werden in den Koordinatenraum der generierten LiDAR-Daten zurückgegeben. Die Vereinfachung, Nachrichtenweitergabe und Rückgabe können schneller durchgeführt werden als eine komplette Analyse voll in 3D, während zugleich eine ausreichende Bestimmtheit in der Detektion, Identifizierung und/oder Verfolgung von Hindernissen gewährleistet wird.
  • Um den Belief Propagation-Algorithmus bei der Nachrichtenweitergabe zwischen benachbarten Pixeln (z. B. Pixelknoten einer Pixeldarstellung) zu unterstützen, können Pixeln Labels zugewiesen werden, die Information enthalten, die für benachbarte Pixel relevant ist. „Pixel“ kann sich hier auf jede Unterteilung des Tiefenflussbilds beziehen und kann Knoten entsprechen, die Pixel oder deren Unterteilung in einer Darstellung des Tiefenflussbilds (z. B. einer Matrix, Tabelle, Grafik usw.) darstellen. Die Auflösung der einzelnen Pixel kann reduziert werden, um eine schnellere Verarbeitung zu ermöglichen. Dementsprechend können Gruppen von Pixeln gruppiert werden - z. B. können Nachrichten zwischen Gruppen benachbarter Pixel übergeben werden, statt von Pixel zu Pixel.
  • Nun auf 2 Bezug nehmend, stellt 2 beispielhafte Labels dar, die Pixeln zugeordnet sein können. Zum Beispiel können Belief Propagation-Labels einem rechteckigen 2,5D-Block entsprechen. Die gezeigten Labels können die Bildverschiebung und den Tiefenfluss darstellen, wobei das Label-Volumen der Bewegung in einer Z-Richtung (z. B. zum Tiefenperzeptionssensor 102 hin und von diesem weg) entsprechen kann.
  • In Ausführungsformen kann der Tiefenfluss zu einem Satz Label vereinfacht werden, die eine Bewegung zum Sensor hin, eine Bewegung vom Sensor weg und keine Bewegung zum Sensor hin oder von diesem weg (z. B. stationär) angeben. Diese Tiefenflusswerte (Z in 2) können zum Beispiel jeweils als -1, +1 und 0 dargestellt werden. In nicht einschränkenden Ausführungsformen können diese vereinfachten Datenfluss-Label als ternäre Label bekannt sein, die eine ausgeglichene ternäre Logik verwenden. In Ausführungsformen kann der Tiefenfluss ein vereinfachter Satz Label sein, die eine schnelle Bewegung zum Sensor hin, eine langsame Bewegung zum Sensor hin, keine Bewegung relativ zum Sensor, eine langsame Bewegung vom Sensor weg und eine schnelle Bewegung vom Sensor weg angeben. Die Werte des Tiefenflusses können z. B. jeweils als -2, -1, 0, +1 und +2 dargestellt werden (nicht dargestellt). Diese Label sind jedoch nur beispielhaft, und in anderen Ausführungsformen können andere Label-Typen verwendet werden, um den Tiefenfluss - oder die Änderung in der Tiefe - zwischen Einzelbildern darzustellen.
  • Nun auf 3 Bezug nehmend, zeigt 3 einen anderen Label-Typ, der Pixeln geordnet sein kann. 3 zeigt zum Beispiel einen beispielhaften Graphen, der eine Berechnung einer Kostenfunktion für einen Tiefenflussdatenterm darstellt. Die x-Achse des Graphen in 3 entspricht der Differenz in der Tiefe, die für dieses Pixel erkannt wird, und die y-Achse des Graphen in 3 entspricht den zugehörigen Kosten. Als erstes Beispiel werden Kosten von 0 zugewiesen, wenn die Tiefendifferenz 0,0 und der Tiefenflusswert 0 ist, was bedeutet, dass die Kosten sehr niedrig sind, wenn ein entsprechendes physisches Objekt sich nicht bewegt und zwei benachbarte Pixel im gleichen Abstand sind. Als zweites Beispiel werden die niedrigsten Kosten dem Tiefenfluss-Label Z=1 zugeordnet, die zweitniedrigsten Kosten Z=0 und die höchsten Kosten Z=-1, wenn die Tiefendifferenz 0,125 beträgt (am ersten Skalenstrich in 3), Die Kosten werden als y-Wert bei dem geeigneten Tiefenflusswert für dieses Pixel und den entsprechenden Tiefenfluss für dieses Pixel ausgewählt. Es versteht sich, dass die im Graphen dargestellten y-Werte sowie die Steigungen der entsprechenden Kurven lediglich beispielshaft sind, und dass die tatsächlichen Kostenwerte und Tiefen-Labelfunktionen durch verschiedene Faktuatoren variieren können.
  • Sobald die Label zugewiesen sind, können die Pixel über den Belief Propagation-Algorithmus Nachrichten untereinander weitergeben, wie in 4 dargestellt - z. B. können Knoten, die Pixeln entsprechen, Nachrichten an benachbarte Knoten weitergeben, die angrenzenden oder benachbarten Pixeln entsprechen. Zum Beispiel kann der Belief Propagator 114 eine oder mehrere Nachrichten, die mindestens zum Teil die jeweiligen Tiefenflusswerte der Pixel und die jeweiligen Kosten der Pixel angeben, zwischen Pixeln der zweiten Gruppe von Pixeln weitergeben. In Ausführungsformen werden Nachrichten durch einen Belief Propagation-Algorithmus weitergegeben. Allgemein können Nachrichten, die mindestens zum Teil die hier erläuterten Label angeben, an benachbarte Pixel gesendet werden. Die empfangenen Nachrichten können dann analysiert werden, insbesondere können die Bildverschiebung und der Tiefenfluss mit den zugehörigen Kosten mit den entsprechenden Werten für dieses Pixel verglichen werden. Neue Nachrichten können dann mit verfeinerten Werten gesendet und analysiert werden, um die Werte der Label weiter zu verfeinern. Von einem bestimmten Schwellenwert an können die Iterationen der Meldungen und Analysen eingestellt werden. In einigen Beispielen kann der Schwellenwert eine bestimmte Anzahl von Iterationen, das Überschreiten eines bestimmten Zeitintervalls, das Erreichen eines bestimmten Schwellenwert-Konfidenzniveaus, ein mit der Prozessor- und/oder Speicherkapazität verbundener Schwellenwert und/oder ein anderer Schwellenwert sein.
  • Die Verwendung des Belief Propagation-Algorithmus kann verschiedene Nebenbedingungen erfüllen. Zum Beispiel kann der Belief Propagation-Algorithmus feststellen, welche benachbarten Pixel demselben physischen Objekt (z. B. Datenterm) entsprechen, und der Belief Propagation-Algorithmus kann benachbarte Werte so „glätten“, dass benachbarte Pixel, die demselben physischen Objekt entsprechen, zunächst einen ähnlichen Ergebniswert (z. B. Glättungsterm) haben. Demnach kann der Belief Propagation-Algorithmus durch den Datenterm bestimmen, welche benachbarten Pixel demselben physischen Objekt entsprechen, und durch den Glättungsterm Näherungswerte für die zu diesem physischen Objekt gehörigen Pixel bestimmen. Durch mehrere Iterationen der Nachrichtenweitergabe und Analyse über dasselbe optische Flussbild oder Tiefenflussbild hinweg kann die Bestimmung der physischen Objekte und eine Näherung ihrer Bewegung durchgeführt werden. Durch mehrere Iterationen über zahlreiche aufeinanderfolgende Tiefenflussbilder hinweg können neue physische Objekte (wie z. B. solche, die zuvor verdeckt waren oder in den Bereich des Tiefenperzeptionssensors 102 gelangt sind) identifiziert und Änderungen (z. B. eine Richtungs- oder Geschwindigkeitsänderung) bei zuvor identifizierten physischen Objekten bestimmt und verfolgt werden.
  • In Ausführungsformen können die Nachrichten zwischen Pixeln (z. B. Knoten, die Pixeln entsprechen) desselben Tiefenflussbilds gesendet werden und Information über den Datenterm und den Glättungsterm enthalten. In einigen Ausführungsformen kann der Datenterm während eines ersten Satzes von Iterationen bestimmt werden, und der Glättungsterm kann während der nachfolgenden Iterationen desselben Tiefenflussbilds bestimmt werden. In anderen Ausführungsformen können der Datenterm und der Glättungsterm gleichzeitig bestimmt werden. Insbesondere können die Nachrichten die Tiefenflussinformation (um eine allgemeine Richtung nach innen und außen zur Identifizierung der richtigen Pixel zwischen Bildern zu ermitteln) und/oder die Kosten enthalten (um zu ermitteln, wie stark die Pixel ihre Nachbarn beeinflussen sollten).
  • Eine beispielhafte Nachrichtenweitergabe wird in 4 gezeigt. Ein Beispiel eines Subjekt-Pixels „X“ ist in der Mitte von 4 dargestellt. Das Subjekt-Pixel grenzt in horizontalen und vertikalen Richtungen an benachbarte Pixel an. In Ausführungsformen kann das Subjekt-Pixel auch in horizontalen oder in anderen Richtungen (nicht dargestellt) an benachbarte Pixel angrenzen. In 4 sind die in vertikaler Richtung benachbarten Pixel mit v+ (vertikal über dem Subjekt-Pixel) und v- (vertikal unter dem Subjekt-Pixel) gekennzeichnet. Die in horizontaler Richtung benachbarten Pixel sind mit h+ (horizontal rechts vom Subjekt-Pixel) und h- (horizontal links vom Subjekt-Pixel) gekennzeichnet. Es versteht sich, dass jedes Pixel im Tiefenflussbild zusammen mit den entsprechenden benachbarten Pixeln als Subjekt-Pixel bezeichnet werden kann. Zum Beispiel kann das Pixel h+ in 4 als Subjekt-Pixel bestimmt werden, das horizontal benachbarte Pixel wie z.B. das Pixel „x“ sowie ein weiteres Pixel weiter rechts (in 4 nicht dargestellt) hat. Darüber hinaus kann die Nachrichtenweitergabe zwischen Knoten oder anderen Pixeldarstellungen in einem Graphen, einer Matrix, einer Tabelle oder einer anderen Darstellung der Bilder erfolgen, auch wenn diese als Pixel bezeichnet werden.
  • Zwischen den jeweiligen Pixeln können Nachrichten übergeben werden. Zum Beispiel kann das Subjekt-Pixel Nachrichten an seine Nachbarpixel senden, und die Nachrichten können jeweils mindestens ein Label - oder einen Teil davon - enthalten. Die Nachrichten können in Ausführungsformen einfachen Informationspaketen entsprechen, die ein oder mehrere zum jeweiligen Pixel gehörige Label betreffen. Durch gemeinsame Nutzung der Information mit benachbarten Pixeln können, wie hier beschrieben, verschiedene Aspekte der Daten bestimmt werden.
  • Ausgehende Nachrichten können wie in 4 mit einem klein geschriebenen Lambda und einer tiefgestellten Angabe des Pixels, von dem die ausgehende Nachricht stammt, gekennzeichnet sein, wobei der Empfänger der Nachricht in Klammern hinzugefügt wird (diese Konvention ist lediglich beispielhaft). Zum Beispiel kann eine ausgehende Nachricht vom Subjekt-Pixel x zu seinem vertikal oberen Nachbarn als λx(v+) bezeichnet werden. Das Subjekt-Pixel kann also vier ausgehende Nachrichten erstellen und senden: λx(v+), λx(v-), λx(h+) und λx(h-). Wie hier beschrieben, können in Ausführungsformen der vorliegenden Erfindung auch andere Nachrichten (wie z. B. solche an diagonal benachbarte Pixel) gesendet werden. Ausgehende Nachrichten können Information über aktuelle Labels enthalten, die dem Subjekt-Pixel zugeordnet sind. In einigen Beispielen können ausgehende Nachrichten von einem Subjekt-Pixel (z. B. dem Subjekt-Pixel entsprechenden Knoten) zu jedem benachbarten Pixel (z. B. benachbarten Pixeln entsprechenden Knoten) ähnlich oder gleich sein, weil das oder die zum Subjekt-Pixel gehörigen Label alle gleich sind. In anderen Ausführungsformen kann der Inhalt mindestens einer ausgehenden Nachricht auf der Basis einer oder mehrerer Eigenschaften des benachbarten Pixels gewählt werden.
  • Eingehende Nachrichten werden in 4 mit einem klein geschriebenen Pi und einer tiefgestellten Angabe des Pixels, an welches die eingehende Nachricht gerichtet ist, gekennzeichnet, wobei der Absender der Nachricht in Klammern hinzugefügt wird (diese Konvention ist lediglich beispielhaft). Zum Beispiel kann eine beim Subjekt-Pixel x eingehende Nachricht von einem horizontal rechten Nachbarpixel als πx(h+) bezeichnet werden. Das Subjekt-Pixel empfängt also vier eingehende Nachrichten: πx(h+), πx(h-), πx(v+) und πx(v-). Wie hier beschrieben, können in Ausführungsformen der vorliegenden Erfindung auch andere Nachrichten (wie z. B. solche von diagonal benachbarten Pixeln) empfangen werden. Eingehende Nachrichten stellen Information über aktuelle Label bereit, die benachbarten Pixeln zugeordnet sind. In Ausführungsformen ist der Inhalt der ausgehenden Nachricht(en) unterschiedlich, da die den benachbarten Pixeln zugeordneten Label unabhängig sind.
  • Es versteht sich auch, dass eine einzelne Nachricht je nach Perspektive der betroffenen Pixel unterschiedlich bezeichnet werden kann. Zum Beispiel ist die ausgehende Nachricht λx(v+) auch eine eingehende Nachricht aus der Perspektive des Pixels v+. Dementsprechend ist die eingehende Nachricht πx(h+) auch eine ausgehende Nachricht aus der Perspektive des Pixels h+. Die eingehende Nachricht πx(h+) kann auch ähnlich oder gleich wie die anderen Nachrichten sein, die vom Pixel h+ an seine Nachbarpixel gesendet wurden.
  • Wie hier beschrieben, identifiziert der Datenterm, welche benachbarten Pixel demselben physischen Objekt entsprechen, und der Glättungsterm passt benachbarte Werte so an, dass benachbarte Pixel, die demselben physischen Objekt entsprechen, zunächst einen ähnlichen Ergebniswert haben. In Ausführungsformen kann der Belief Propagator 114 auf der Basis der Nachricht(en) einen oder mehrere Datenterme berechnen, die ein oder mehrere Pixel aus der ersten Gruppe im ersten Abstandsbild angeben, die mit einem oder mehreren Pixeln aus der zweiten Gruppe im zweiten Abstandsbild übereinstimmen. Der Datenterm kann verwendet werden, weil das physische Objekt und/oder die Tiefensensoren sich zwischen den Bildern bewegen. Variablen wie Tiefenfluss, Reflektivität, Farbwerte, Intensität, Time of Flight (ToF), Textur, Rücklaufverhalten und/oder andere Information (wie z. B. die durch LiDAR-Daten oder in LiDAR-Abstandsbildern dargestellte) können im Datenterm analysiert werden. In Beispielen kann ein physisches Objekt für eine oder mehrere dieser Variablen relativ konstant sein. Ein physisches Objekt kann sich zum Beispiel mit einem gleichartigen Tiefenfluss bewegen, da es sich als Einheit bewegt. Als weiteres Beispiel kann der Reflexionsgrad je nach physischem Objekt unterschiedlich sein (z. B. kann ein lackiertes Fahrzeug einen höheren Reflexionsgrad als ein Fußgänger aufweisen).
  • In Ausführungsformen berechnet der Belief-Propagator 114 mindestens zum Teil auf der Basis der Nachricht(en) einen oder mehrere Glättungsterme, die revidierte Tiefenflusswerte für die Gruppe von Pixeln im Tiefenflussbild anzeigen. Der Glättungsterm kann angeben, welcher Wert für den Tiefenfluss für Pixel, die demselben physischen Objekt entsprechen, annähernd korrekt ist. Ein sich im Raum bewegendes physisches Objekt bewegt sich in der Regel als eine Einheit. Daher können die unvollständigen und ungenauen Daten einiger Pixel durch benachbarte Pixel angepasst und beeinflusst werden, um diese Information zu berücksichtigen. Zum Beispiel werden jedem Pixel abhängig davon, wie zuverlässig die darin enthaltenen Daten sind, Kosten zugewiesen. Pixeln mit unvollständigen Daten (z. B. kein Rücklauf zum LiDAR-Sensor) können niedrige Kosten zugewiesen werden, sodass sie mit größerer Wahrscheinlichkeit durch den Belief Propagation-Algorithmus von ihren Nachbarpixeln beeinflusst werden. Dies ermöglicht die Erzeugung eines dichten Bewegungsfelds trotz fehlender Daten aus der ursprünglichen LiDAR-Abtastung.
  • In Ausführungsformen kann der Belief Propagator 114 die Nachrichtenweitergabe über Grenzen, die verschiedenen physischen Objekten entsprechen, hinweg verhindern. Ob zwei benachbarte Pixel demselben Objekt entsprechen, kann durch Vergleichen der relativen Tiefe und/oder des Tiefenflusses, die zwei jeweiligen Pixeln zugeordnet sind, berechnet werden. Benachbarte Pixel, für welche berechnet wird, dass sie nicht demselben physischen Objekt in der physischen Umgebung entsprechen (z. B., weil eine detektierte Differenz in der Tiefe oder im Reflexionsvermögen zwischen beiden Pixeln einen bestimmten Schwellenwert übersteigt), dürfen untereinander keine Nachrichten weitergeben (z. B. dürfen zwischen Knoten, die Pixeln in einer Darstellung des Bilds wie z. B. einer Matrix, Tabelle, Graphen usw. entsprechen, keine Nachrichten weitergegeben werden). Diese Pixel dürfen ihre Nachbarpixel nicht beeinflussen, da sie unterschiedlichen physischen Objekten entsprechen. Dadurch kann die Unterschiedlichkeit zwischen diesen benachbarten Pixeln nicht durch den Belief Propagation-Algorithmus beeinflusst werden.
  • In Ausführungsformen kann der Belief Propagator 114 mindestens zum Teil auf der Basis von Tiefendaten aus den zweiten LiDAR-Daten bestimmen, dass das Subjekt-Pixel einem Subjekt-Objekt entspricht, das sich von einem benachbarten Objekt unterscheidet, das dem benachbarten Pixel entspricht. Auf der Basis dieser Bestimmung kann die Weitergabe einer Nachricht zwischen dem Subjekt-Pixel und dem benachbarten Pixel gestoppt oder verhindert werden. Die Verhindern der Nachrichtenweitergabe kann zum Beispiel erfolgen, indem (vor dem Senden einer Nachricht) bestimmt wird, ob die betroffenen Pixel demselben physischen Objekt entsprechen. In anderen Ausführungsformen kann das Verhindern der Nachrichtenweitergabe erfolgen, indem eine virtuelle Barriere um Pixel gelegt wird, die demselben Objekt entsprechen, sodass die Bestimmung in nachfolgenden Iterationen des Prozesses nicht erneut durchgeführt werden muss. In weiteren Ausführungsformen kann das Verhindern der Nachrichtenweitergabe erfolgen, indem mindestens einem Pixel, das das physische Objekt anzeigt, ein Label (wie z.B. eine Objekt-Bezugsnummer oder ein anderer Indikator) hinzugefügt wird. In dieser Ausführungsform können die Meldungen zwar weitergegeben, die empfangenen Meldungen jedoch ignoriert werden, wenn das Label nicht demselben Objekt wie das Subjekt-Pixel entspricht.
  • Das System 100 kann einen Szenenflussgenerator 116 umfassen, der - z. B. unter Verwendung des Koordinatenwandlers 110 - die 2,5D-Information des optischen Flusses oder Tiefenflusses (z. B. nach der Nachrichtenweitergabe) in den 3D-Raum rückkonvertieren kann, um einen Szenenfluss zu generieren. Zum Beispiel wird durch Weitergabe und Analyse dieser Nachrichten zwischen Pixeln (z. B. Knoten, die Pixeln in einer Darstellung des Tiefenflussbilds entsprechen) desselben Tiefenflussbilds die Genauigkeit der verschiedenen Daten an jedem Pixel zu einem verfeinerten 2D-Bewegungsvektor verbessert. Der verfeinerte 2D-Bewegungsvektor kann eine optische und/oder Tiefenflussänderung für das physische Objekt anzeigen, das dem Subjekt-Pixel entspricht. Auch fehlende oder unvollständige Daten für andere Pixel können mindestens zum Teil auf der Basis des verfeinerten 2D-Bewegungsvektors geschätzt und verfeinert werden.
  • Der Szenenflussgenerator 116 kann mindestens zum Teil auf der Basis des oder der Datenterme und des oder der Glättungsterme einen oder mehrere Bewegungsvektoren berechnen, die der zweiten Gruppe von Pixeln entsprechen, wobei der oder die Bewegungsvektoren für relative Pixelpositionen zwischen dem ersten Abstandsbild und dem zweiten Abstandsbild repräsentativ sein können. Die relative Pixelposition kann die Bewegung des physischen Objekts in der Nähe des Tiefenperzeptionssensors 102 in der Umgebung angeben.
  • In Ausführungsformen der vorliegenden Erfindung kann der Szenenflussgenerator 116 Bewegungsvektoren im 2D- oder 2,5D-Raum berechnen und die Bewegungsvektoren dann in den 3D-Raum konvertieren, um einen oder mehrere 3D-Bewegungsvektoren zu generieren. In Ausführungsformen konvertiert der Prozessor den bestimmten 2D-Bewegungsvektor mindestens zum Teil auf der Basis der Information im 2D-Vektor und der entsprechenden LiDAR-Daten für diesen 2D-Vektor in einen 3D-Raum. Die 2D-Vektoren, auch als 2,5D-Bewegungsvektoren bezeichnet, da sie Tiefeninformation enthalten, können anhand bekannter Entsprechungen zwischen 2D-Bildraum- und 3D-Weltraum-Positionen (z. B. durch intrinsische und/oder extrinsische Sensorparameter) in den 3D-Raum rückkonvertiert werden. Dadurch kann ein 3D-Bewegungsvektor für Punkte in den LiDAR-Punktwolken berechnet werden, wobei die 3D-Bewegungsvektoren verschiedene Informationen über die Verschiebung der 3D-Punkte der Punktwolke darstellen - z. B. die Verschiebung von physischen Objekten über der LiDAR-Datenframes hinweg. Der Message Passing Belief Propagation-Algorithmus ermöglicht es, diese komplexe Analyse zu vereinfachen und abzuschließen, bevor in den 3D-Raum zurückgekehrt und dann in den 3D-Raum konvertiert wird, um 3D-Szenenflussinformation zu generieren.
  • Der Szenenflussgenerator 116 kann einen Szenenfluss generieren, der mindestens zum Teil auf 3D-Bewegungsvektor(en) basiert, die einen Szenenfluss zwischen dem ersten Abstandsbild und dem zweiten Abstandsbild darstellen. Der Szenenfluss kann verwendet werden, um verschiedene physische Objekte in der Umgebung des Fahrzeugs 800 - z. B. im Sicht- oder Sensorfeld der Tiefenperzeptionssensoren 102 - zu erkennen, zu identifizieren und/oder zu verfolgen.
  • In 6A-6B werden beispielhafte Szenenflüsse 602 zusammen mit einem entsprechenden Abstandsbild 604 dargestellt. Zum Beispiel zeigt 6A einen beispielhaften Szenenfluss 602 aus einer ersten Orientierung, und 6B zeigt den beispielhaften Szenenfluss 602 von 6A aus einer zweiten Orientierung (und z. B. herangezoomt). Der beispielhafte Szenenfluss 602 zeigt die detektierten Objekte 606 und eine Anzeige der entsprechenden Bewegungen der detektierten Objekte. Zum Beispiel weist der Szenenfluss 602 einen zentralen Bereich 608 auf, der leer ist und einer Position des Tiefenperzeptionssensors 102 entspricht (auch wenn dieser in 6A oder 6B nicht dargestellt ist), sowie einen sich darum erstreckenden Radius. Am Rand des zentralen Bereichs 608 ist eine Reihe von konzentrischen Kreisen 610 vorhanden, die anzeigen können, dass für diesen Bereich Information verfügbar ist, jedoch kein Hindernis detektiert wurde. Wenn Hindernisse 606 detektiert werden, kann in den konzentrischen Kreisen 610 eine Behinderung auftreten, und hinter den Hindernissen 606 (aus der Perspektive des Tiefenperzeptionssensors 102) können verdeckte Bereiche 612 (durch leere weiße Flächen angezeigt) vorhanden sein. Verdeckte Objekte können in weiteren Iterationen des Prozesses sichtbar werden, wenn die Hindernisse und/oder die Perzeptionssensoren sich relativ zueinander bewegen, wodurch die Verdeckungen beseitigt werden.
  • Auf 1A Bezug nehmend, kann das System 100 eine Fahrzeugsteuerung 118 umfassen, die die Information im Szenenfluss analysieren kann, um Hindernisse in der physischen Umgebung des Tiefenperzeptionssensors 102 zu bestimmen. Die Fahrzeugsteuerung 118 kann dann auf der Basis des bestimmten Hindernisses eine oder mehrere Fahrzeug-Aktionen wie z. B. das Betätigen einer Bremse oder ein Wenden des Fahrzeugs anweisen. Zum Beispiel kann die Fahrzeugsteuerung 118 einen Software-Stapel für autonomes Fahren ausführen, der eine Perzeptionsebene, eine Weltmodell-Managementebene, eine Planungsebene, eine Steuerungsebene, eine Betätigungsebene, eine Hindernisvermeidungsebene und/oder eine oder mehrere andere Ebenen umfassen kann.
  • Nun auf 1B Bezug nehmend, zeigt 1B ein Zeitablaufdiagramm, das eine beispielhafte Ausführungsform des Systems 100 über ein Zeitintervall darstellt. Wie zum Beispiel in 1B gezeigt, werden an einem Zeitpunkt T1 während des Betriebs des Systems 100 LiDAR-Daten 150 gesammelt. Die LiDAR-Daten 150 werden zu einer 3D-LiDAR-Punktwolke 152 zusammengefasst, die 3D-LiDAR-Punktwolke wird projiziert, um ein Abstandsbild zu generieren. Ein beispielhaftes Abstandsbild wird in 5 gezeigt. An einem (auf den Zeitpunkt T1 folgenden) Zeitpunkt T2 werden die LiDAR-Daten 150 erneut gesammelt und zu einer zweiten 3D-LiDAR-Punktwolke 152 zusammengefasst, die LiDAR-Punktwolke wird projiziert, um ein Abstandsbild zu generieren, und das oder die Abstandsbilder werden verwendet, um ein zweites 2,5D-Tiefenflussbild 154 zu generieren. In diesem 2,5D-Tiefenflussbild 154 können die verschiedenen Pixel (z. B. den Pixeln entsprechende Knoten) über einen Message Passing-Algorithmus 156 untereinander Nachrichten weitergeben. Während die Nachrichten in einer ersten Iteration weitergegeben werden, können die Werte des Tiefenflusses (und möglicherweise andere Label und Werte) verfeinert werden, um verfeinerte Werte 158 zu erzeugen, und mit den Abstandsbildern verglichen werden. Nach einer gewissen Anzahl von Iterationen können ein 2,5D-Tiefenflussbild 160 und ein 3D-Szenenfluss 162 generiert werden. LiDAR-Daten, die an einem Zeitpunkt T3 gesammelt werden (nicht gezeigt), werden weiterverarbeitet und mit den Daten vom Zeitpunkt T2 verglichen, um den 3D-Szenenfluss im Laufe der Zeit weiter zu verfeinern.
  • Nun auf 7 Bezug nehmend, umfasst jeder Block des hier beschriebenen Verfahrens 700 einen Rechenprozess, der mit einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Zum Beispiel können verschiedene Funktionen durch einen Prozessor durchgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 700 kann auch in Form von computerausführbaren Anweisungen, die auf Computer-Speichermedien gespeichert sind, ausgeführt sein. Das Verfahren 700 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige Beispiele zu nennen. Darüber hinaus wird das Verfahren 700 in Bezug auf das Szenenflussgenerierungssystem 100 von 1A beispielhaft beschrieben. Dieses Verfahren kann jedoch zusätzlich oder alternativ dazu von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich der hier beschriebenen, ohne darauf beschränkt zu sein.
  • 7 ist ein Ablaufplan, der ein Verfahren 700 zum Generieren eines Szenenflusses gemäß Ausführungsformen der vorliegenden Erfindung zeigt. Das Verfahren 700 umfasst in Block B702 das Generieren mindestens eines ersten Abstandsbilds und eines zweiten Abstandsbilds. Zum Beispiel kann ein erstes Abstandsbild, das einem ersten LiDAR-Datensatz an einem ersten Zeitpunkt entspricht, und ein zweites Abstandsbild, das einem zweiten LiDAR-Datensatz an einem zweiten Zeitpunkt nach dem ersten Zeitpunkt entspricht, generiert werden. Die Abstandsbilder können verschiedene Informationen wie z.B. Tiefe, Intensität, ToF usw. kodieren.
  • Das Verfahren 700 umfasst in Block B704 das Generieren eines Tiefenflussbilds unter Verwendung des ersten Abstandsbilds und des zweiten Abstandsbilds. Zum Beispiel können mindestens Tiefenwerte, die dem ersten Abstandsbild und dem zweiten Abstandsbild entsprechen, verglichen werden, um Tiefenflusswerte zu bestimmen, die für bestimmte (z. B. übereinstimmende) Pixel oder Punkte in den Abstandsbildern Änderungen der Tiefe im Zeitverlauf anzeigen. Um die zwei Abstandsbilder zu vergleichen, kann eines der Abstandsbilder in einen Koordinatenraum des anderen Abstandsbilds konvertiert werden, wobei die Konvertierung auf der Basis der verfolgten Ego-Bewegung des Fahrzeugs 800 zwischen der Erfassung der ersten LiDAR-Daten und der zweiten LiDAR-Daten, die zum Generieren der Abstandsbilder verwendet wurden, ausgeführt werden kann.
  • Das Verfahren 700 umfasst in Block B706 das Weitergeben von Nachrichten zwischen Pixeln des Tiefenflussbilds. Um zum Beispiel die Werte im Tiefenflussbild zu aktualisieren und/oder fehlende Information in fehlenden oder unvollständigen Daten zu ergänzen, können Nachrichten über einen Belief Propagation-Algorithmus zwischen Knoten weitergegeben werden, die Pixeln einer Darstellung des Bilds entsprechen (z. B. einer Matrix, eines Graphen, einer Tabelle usw.).
  • Das Verfahren 700 umfasst in Block B708 das Berechnen eines Datenterms, der angibt, welche Pixel welchen physischen Objekten entsprechen, was einen Vergleich mit dem ersten Tiefenflussbild beinhalten kann.
  • Das Verfahren 700 umfasst in Block B710 das Berechnen eines Glättungsterms, der die Werte der Label auf der Basis der Information anpasst, die von den benachbarten Pixeln empfangen wird.
  • Das Verfahren 700 umfasst in Block B712 das Berechnen und/oder Verfeinern von Bewegungsvektoren mindestens zum Teil auf der Basis des Datenterms und des Glättungsterms. In Ausführungsformen kann das Verfahren 700 mehrere Iterationen einer Schleife der Blöcke B706 bis B712 umfassen, in welchen der Glättungsterm die Werte anpasst, während der Datenterm die Objekte identifiziert.
  • Nach Erreichen eines bestimmten Schwellenwerts kann das Verfahren 700 in Block B714 das Generieren eines Szenenflusses auf der Basis der Bewegungsvektoren umfassen. Zum Beispiel kann der Szenenfluss aus 3D-Bewegungsvektoren generiert werden, die bestimmt werden, indem 2,5D-Bewegungsvektoren in den 3D-Raum konvertiert werden.
  • Das Verfahren 700 umfasst in Block B716 das Identifizieren von Hindernissen mindestens zum Teil auf der Basis des Szenenflusses. Hindernisse können zum Beispiel physische Objekte umfassen, die sich direkt oder indirekt auf das autonome Fahrzeug 800 auswirken können. Die Hindernisse können in Bewegung sein, wie z. B. andere Fahrzeuge oder Fußgänger, oder sie können stationär sein, wie z. B. Gebäude oder Bäume. Hindernisse können eine Position relativ zum Fahrzeug, einen 3D-Bewegungsvektor (der eine Beschleunigung, Drehung oder eine andere Bewegungsangabe umfassen kann) und eine relative Größe (auf der Basis der Anzahl der dem Hindernis entsprechenden Pixel) haben. In Ausführungsformen kann das System 100 mindestens zum Teil auf der Basis der Information über das Hindernis eine Wahrscheinlichkeit bestimmen, dass das Hindernis das Fahrzeug beeinträchtigen wird, und das System kann eine oder mehrere Abhilfemaßnahmen bestimmen, die durchzuführen sind, um das Hindernis zu vermeiden. Die Fahrzeugsteuerung 118 kann zum Beispiel bestimmen, dass das Fahrzeug bremsen, Wenden oder beschleunigen soll, um das Hindernis zu vermeiden. In Fällen, bei denen ein Hindernis nicht vermieden werden kann, kann das System 100 bestimmen, dass eine oder mehrere Abhilfemaßnahmen wie das Minimieren von Schäden oder das Aktivieren anderer Sicherheitsfunktionen ergriffen werden sollten.
  • Das Verfahren 700 umfasst in Block 718 die Steuerung des Fahrzeugs, um die identifizierten Hindernisse durch Ergreifen der identifizierten Abhilfemaßnahm(en) zu vermeiden. Die Steuerung des Fahrzeugs kann das Senden eines Befehls an eines der zahlreichen Fahrzeugsysteme umfassen, wie z. B. die in 8A-8D beschriebenen.
  • BEISPIELHAFTES AUTONOMES FAHRZEUG
  • 8A ist eine Darstellung eines beispielhaften autonomen Fahrzeugs 800 gemäß Ausführungsformen der vorliegenden Erfindung. Das autonome Fahrzeug 800 (hier alternativ als „Fahrzeug 800“ bezeichnet) kann, ohne darauf beschränkt zu sein, ein Personenfahrzeug wie z. B. einen Lkw, einen Bus, ein Rettungsfahrzeug, einen Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, einen Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne, Fahrzeug mit Anhänger und/oder eine andere Art von Fahrzeug (z. B. ein unbemanntes Fahrzeug und/oder ein Fahrzeug, das einen oder mehrere Fahrgäste aufnimmt) umfassen. Autonome Fahrzeuge werden allgemein in Form von Automatisierungsgraden 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 künftige Versionen dieses Standards) definiert werden. Das Fahrzeug 800 kann in der Lage sein, Funktionalitäten zu erfüllen, die einer oder mehreren der autonomen Fahrstufen 3 bis 5 entsprechen. Zum Beispiel kann das Fahrzeug 800 je nach Ausführungsform zur bedingten Automatisierung (Level 3), Hochautomatisierung (Level 4) und/oder Vollautomatisierung (Level 5) fähig sein.
  • Das Fahrzeug 800 kann Komponenten wie ein z. B. Fahrgestell, eine Karosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Fahrzeugkomponenten umfassen. Das Fahrzeug 800 kann ein Antriebssystem 850 wie z. B. eine Brennkraftmaschine, einen Hybrid-Elektroantrieb, einen reinen Elektromotor und/oder ein Antriebssystem anderen Typs umfassen. Das Antriebssystem 850 kann mit einem Antriebsstrang des Fahrzeugs 800 verbunden sein, der ein Getriebe umfassen kann, um den Antrieb des Fahrzeugs 800 zu ermöglichen. Das Antriebssystem 850 kann in Reaktion auf den Empfang von Signalen von einem Gashebel/Beschleuniger 852 gesteuert werden.
  • Ein Lenksystem 854, das ein Lenkrad umfassen kann, kann verwendet werden, um ein Fahrzeug 800 zu lenken (z. B. entlang eines gewünschten Weges oder einer Route), wenn das Antriebssystem 850 in Betrieb ist (z. B., wenn das Fahrzeug in Bewegung ist). Das Lenksystem 854 kann von einem Lenkaktuator 856 Signale empfangen. Das Lenkrad kann für die vollautomatische Funktionalität (Level 5) optional sein.
  • Das Bremssensorsystem 846 kann verwendet werden, um die Fahrzeugbremsen in Reaktion auf den Empfang von Signalen von den Bremsaktuatoren 848 und/oder Bremssensoren zu betätigen.
  • Controller 836, die, ohne darauf beschränkt zu sein, ein oder mehrere Ein-Chip-Systeme (SoCs) 804 (8C) und/oder GPU(s) umfassen können, können einer oder mehreren Komponenten und/oder Systemen des Fahrzeugs 800 Signale (die z. B. für Befehle stehen) bereitstellen. Zum Beispiel können die Controller Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 848, zur Betätigung des Lenksystems 854 über einen oder mehrere Lenkaktuatoren 856 und zur Betätigung des Antriebssystems 850 über einen oder mehrere Drossel-Beschleunigungsregler 852 senden. Controller 836 können eine oder mehrere eingebaute (z. B. integrierte) Recheneinheiten (z. B. Supercomputer) umfassen, die Sensorsignale verarbeiten und Betriebsbefehle (z. B. Signale, die für Befehle stehen) ausgeben, um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Fahren des Fahrzeugs 800 zu unterstützen. Die Controller 836 können einen erste Controller 836 für autonome Fahrfunktionen, einen zweiten Controller 836 für funktionale Sicherheitsfunktionen, einen dritten Controller 836 für die Funktionalität der künstlichen Intelligenz (z. B. Computer-Vision), einen vierten Controller 836 für die Infotainment-Funktionalität, einen fünften Controller 836 zur Redundanz in Notfällen und/oder andere Controller umfassen. In einigen Beispielen kann ein einziger Controller 836 zwei oder mehr der obigen Funktionalitäten übernehmen, zwei oder mehr Controller 836 können eine einzige Funktionalität übernehmen, und/oder eine beliebige Kombination daraus.
  • Controller 836 können die Signale bereitstellen, um in Reaktion auf Sensordaten, die von einem oder mehreren Sensoren (z. B. Sensoreingaben) empfangen werden, ein oder mehrere Komponenten und/oder Systeme des Fahrzeugs 800 zu steuern. Die Sensordaten können zum Beispiel, ohne darauf beschränkt zu sein, von globalen Satellitennavigationssystem-Sensor(en) 858 (z. B., GPS-Sensor(en)), RADAR-Sensor(en) 860, Ultraschallsensor(en) 862, LIDAR-Sensor(en) 864, Trägheitsmesseinheit (IMU)-Sensor(en) 866 (z. B. Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 896, Stereokamera(s) 868, Weitwinkelkamera(s) 870 (z. B., Fischaugenkameras), Infrarotkamera(s) 872, Surround-Kamera(s) 874 (z. B. 360 Grad-Kameras), Weitbereichs- und/oder Mittelbereichskamera(s) 898, Drehzahlsensor(en) 844 (z. B. zur Messung der Geschwindigkeit des Fahrzeugs 800), Vibrationssensor(en) 842, Lenksensor(en) 840, Bremssensor(en) (z. B. als Teil des Bremssensorsystems 846) und/oder anderen Sensortypen ermpfangen werden.
  • Ein oder mehrere Controller 836 können Eingaben (z. B. in Form von Eingabedaten) von einem Kombi-Instrument 832 des Fahrzeugs 800 empfangen und über eine Mensch-Maschine-Schnittstelle (HMI)-Anzeige 834, einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 800 Ausgaben (z. B. in Form von Ausgabedaten, Anzeigedaten usw.) bereitstellen. Die Ausgaben können Information wie z.B. die Fahrzeuggeschwindigkeit, die Drehzahl, die Zeit, Kartendaten (z. B. die HD-Karte 822 von 8C), Positionsdaten (z. B. die Position des Fahrzeugs 800, z. B. auf einer Karte), Richtung, Standort anderer Fahrzeuge (z. B. ein Belegungsraster), Information über Objekte und den Status von Objekten, wie von dem/den Controller(n) 836 wahrgenommen, usw. umfassen. Zum Beispiel kann die HMI-Anzeige 834 Information über das Vorhandensein eines oder mehrerer Objekte (z. B. ein Straßenschild, ein Warnschild, eine umschaltende Ampel usw.) und/oder Information ü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 800 umfasst außerdem eine Netzschnittstelle 824, die drahtlose Antenne(n) 826 und/oder Modem(s) verwenden kann, um über ein oder mehrere Netzwerke zu kommunizieren. Die Netzschnittstelle 824 kann zum Beispiel die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. ermöglichen. Drahtlose Antenne(n) 826 können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeugen, mobilen Geräten usw.) ermöglichen, indem sie lokale Netze wie z. B. Bluetooth, Bluetooth LE Z-Wave, ZigBee usw. und/oder Low-Power-Weitverkehrsnetze (LPWANs) wie z. B. LoRaWAN, SigFox usw. verwenden.
  • 8B ist ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug 800 von 8A gemäß Ausführungsformen der vorliegenden Erfindung. Die Kameras und ihre jeweiligen Sichtfelder sind eine beispielhafte Ausführungsform und nicht einschränkend zu verstehen. Zum Beispiel können zusätzliche und/oder alternative Kameras enthalten sein, und/oder Kameras können an anderen Stellen des Fahrzeugs 800 angeordnet sein.
  • Die Kameratypen für die Kameras können, ohne darauf beschränkt zu sein, Digitalkameras umfassen, die zur Verwendung mit Komponenten und/oder Systemen des Fahrzeugs 800 angepasst sein können. Die Kamera(s) können bei der Kraftfahrzeug-Sicherheitsintegrationsstufe (ASIL) B und/oder einer anderen ASIL-Stufe betrieben werden. Die Kameratypen können in der Lage sein, eine Bildaufzeichnungsrate wie z. B. 60 Einzelbildern pro Sekunde (fps), 120 fps, 240 fps usw. zu erreichen. Die Kameras können Rollling-Shutters, Global Shutters, einen anderen Verschlusstyp oder eine Kombination daraus 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 ein Farbfilter-Array anderen Typs umfassen. In einigen Ausführungsformen können zur Erhöhung der Lichtempfindlichkeit Klarpixelkameras 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 adaptive Fahrerassistenzsystemen (ADAS)-Funktionen auszuführen (z. B. als Teil eines redundanten oder ausfallsicheren Designs). Zum Beispiel kann eine Multifunktions-Monokamera installiert sein, um Funktionen einschließlich Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitzustellen. Eine oder mehrere der Kameras (z. B. alle Kameras) können gleichzeitig Bilddaten (z. B. Video) aufzeichnen und bereitstellen
  • Eine oder mehrere der Kameras können in einer Montagehalterung montiert sein, z. B. in einer kundenspezifisch entworfenen (3D-gedruckten) Halterung, um Streulicht und Reflexionen aus dem Fahrzeuginnenraum (z. B. Reflexionen vom Armaturenbrett, die in Spiegeln der Windschutzscheibe reflektiert werden) auszuschalten, die die Bilddatenerfassungsfähigkeiten der Kamera beeinträchtigen könnten. Was Seitenspiegel-Montagehalterungen anbetrifft, können die Seitenspiegelhalterungen kundenspezifisch so 3D-gedruckt werden, dass die Kameramontageplatte der Form des Seitenspiegel entspricht. In einigen Beispielen können Kamera(s) im Seitenspiegel integriert sein. Bei Seitenansicht-Kameras können die Kameras auch in den vier Säulen an jeder Ecke der Fahrgastzelle integriert sein.
  • Kameras mit einem Sichtfeld, das vor dem Fahrzeug 800 liegende Teile der Umgebung einschließt (z. B. nach vorne gerichtete Kameras), können für die Rundumsicht verwendet werden, um die Erkennung von Wegen und Hindernissen in der Vorwärtsrichtung zu unterstützen und mithilfe eines oder mehrerer Controller 836 und/oder Steuer-SoCs Information bereitzustellen, die für die Erstellung eines Belegungsraster und/oder die Bestimmung bevorzugter Fahrzeug-Wege kritisch sind. Nach vorne gerichtete Kameras können verwendet werden, um viele derselben ADAS-Funktionen wie LIDAR zu erfüllen, einschließlich, ohne darauf beschränkt zu sein, Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorne gerichtete Kameras könne auch für ADAS-Funktionen und -Systeme verwendet werden, einschließlich, ohne darauf beschränkt zu sein, auf Spurverlassenswarnungen (LDW), autonome Geschwindigkeitsregelung (ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung.
  • Verschiedene Kameras können in einer nach vorne gerichteten Konfiguration verwendet werden, z. B. eine monokulare Kameraplattform mit einem CMOS (Complementary Metal Oxide Semiconductor)-Farbbildsensor . Ein weiteres Beispiel sind Weitwinkelkameras 870, die verwendet werden können, um Objekte zu erkennen, die von der Peripherie her ins Blickfeld geraten (z. B. Fußgänger, Querverkehr oder Fahrräder). Auch wenn in 8B nur eine Weitwinkelkamera dargestellt ist, kann eine beliebige Anzahl von Weitwinkelkameras 870 am Fahrzeug 800 vorhanden sein. Darüber hinaus können Weitbereichskameras 898 (z. B. ein Weitbereich-Stereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für welche ein neuronales Netz noch nicht trainiert wurde. Weitbereichskameras 898 können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
  • Eine oder mehrere Stereokameras 868 können auch in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 868 können eine integrierte Steuereinheit mit einer skalierbaren Verarbeitungseinheit umfassen, die eine programmierbare Logik (FPGA) und einen Multicore-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Solch eine Einheit kann verwendet werden, um eine 3D-Karte der Umgebung des Fahrzeugs zu erzeugen, einschließlich einer Abstandsschätzung für alle Punkte im Bild. Alternative Stereokameras 868 können kompakte Stereo-Vision-Sensor(en) umfassen, die zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip umfassen können, der den Abstand vom Fahrzeug zum Zielobjekt messen und die erzeugte Information (z. B. Metadaten) verwenden kann, um autonome Notbrems- und Spurhaltewarnfunktionen zu aktivieren. Andere Arten von Stereokameras 868 können zusätzlich oder alternativ zu den hier beschriebenen verwendet werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 800 enthält (z. B. Seitenansicht-Kameras), können für die Rundumansicht verwendet werden und Information bereitstellen, die zur Erstellung und Aktualisierung des Belegungsrasters sowie zur Erzeugung von Seitenaufprallwarnungen verwendet werden. Zum Beispiel können Surround-View-Kamera(s) 874 (z. B. vier Surround-View-Kameras 874, wie in 8B dargestellt) am Fahrzeug 800 angeordnet sein. Umgebungskameras 874 können Weitwinkelkamera(s) 870, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder dergleichen umfassen. Zum Beispiel können vier Fischaugenkameras an der Front, am Heck und an den Seiten des Fahrzeugs angeordnet sein. In einer alternativen Anordnung kann das Fahrzeug drei Surround-View-Kameras 874 (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 nutzen.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 800 einschließt (z. B. Hecksicht-Kameras) können für die Einparkhilfe, die Rundumsicht, Heckkollisionswarnungen und zum Generieren und Aktualisieren von Belegungsrastern verwendet werden. Es kann eine große Auswahl von Kameras verwendet werden, einschließlich, ohne darauf beschränkt zu sein, Kameras, die auch als nach vorne gerichtete Kameras geeignet sind (z. B. Weitbereichs- und/oder Mittelbereichskamera(s) 898, Stereokamera(s) 868, Infrarotkamera(s) 872 usw.), wie hier beschrieben.
  • 8C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 800 von 8A gemäß Ausführungsformen der vorliegenden Erfindung. Es versteht sich, dass diese und andere Anordnungen, die hier beschrieben werden, lediglich beispielhaft sind. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, Funktionsgruppen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können auch ganz entfallen. Ferner sind viele der Elemente, die hier beschrieben werden, 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 Funktionen, die hier als von Einheiten ausgeführt beschrieben werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Zum Beispiel können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Alle Komponenten, Merkmale und Systeme des Fahrzeugs 800 in 8C sind als über einen Bus 802 verbunden dargestellt. Der Bus 802 kann eine Controller Area Network (CAN)-Datenschnittstelle (hier alternativ als „CAN-Bus“ bezeichnet) umfassen. Ein CAN kann ein im Fahrzeug 800 befindliches Netzwerk sein, das zur Unterstützung der Steuerung verschiedener Eigenschaften und Funktionalitäten des Fahrzeugs 800 wie z. B. Betätigung der Bremsen, Beschleunigung, Bremsung, Lenkung, Scheibenwischer usw. verwendet wird. Ein CAN-Bus kann dazu konfiguriert sein, Dutzende oder sogar Hunderte von Knoten zu haben, 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 Motordrehzahl pro Minute (RPM), Knopfstellungen und/oder andere Fahrzeugzustandsindikatoren zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
  • Auch wenn der Bus 802 hier als CAN-Bus beschrieben wird, ist dies nicht einschränkend zu verstehen. Zum Beispiel können FlexRay und/oder Ethernet zusätzlich oder alternativ zum CAN-Bus verwendet werden. Auch wenn eine einzige Leitung verwendet wird, um de, Bus 802 darzustellen, ist dies nicht einschränkend zu verstehen. Zum Beispiel kann eine beliebige Anzahl von Bussen 802 vorhanden sein, die ein oder mehr CAN-Busse, ein oder mehr FlexRay-Busse, ein oder mehr Ethernet-Busse und/oder ein oder mehr Busse anderen Typs mit einem anderen Protokoll umfassen können. In einigen Beispielen können zwei oder mehr Busse 802 verwendet werden, um verschiedene Funktionen auszuführen, und/oder sie können zur Redundanz verwendet werden. Zum Beispiel kann ein erster Bus 802 für die Funktionalität der Kollisionsvermeidung verwendet werden, und ein zweiter Bus 802 kann für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 802 mit beliebigen Komponenten des Fahrzeugs 800 kommunizieren, und zwei oder mehr Busse 802 können mit denselben Komponenten kommunizieren. In einigen Beispielen kann jedes SoC 804, jeder Controller 836 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf dieselben Eingabedaten haben (z. B. Eingaben von Sensoren des Fahrzeugs 800) und mit einem gemeinsamen Bus wie z. B. dem CAN-Bus verbunden sein.
  • Das Fahrzeug 800 kann einen oder mehrere Controller 836 wie jene umfassen, die hier Bezug nehmend auf 8A beschrieben wurden. Controller 836 können für eine Vielzahl von Funktionen verwendet werden. Controller 836 können mit verschiedenen anderen Komponenten und Systemen des Fahrzeugs 800 gekoppelt sein und für die Steuerung des Fahrzeugs 800, die künstliche Intelligenz des Fahrzeugs 800, das Infotainment für das Fahrzeug 800 und/oder dergleichen verwendet werden.
  • Das Fahrzeug 800 kann ein oder mehrere Ein-Chip-Systeme (SoC) 804 umfassen. Das SoC 804 kann CPU(s) 806, GPU(s) 808, Prozessor(en) 810, Cache(s) 812, Beschleuniger 814, Datenspeicher 816 und/oder andere, nicht dargestellte Komponenten und Merkmale umfassen. SoC(s) 804 können in einer Vielzahl von Plattformen und Systemen zur Steuerung des Fahrzeugs 800 verwendet werden. Zum Beispiel können SoC(s) 804 in einem System (z. B. dem System des Fahrzeugs 800) mit einer HD-Karte 822 kombiniert sein, die über eine Netzschnittstelle 824 von einem oder mehreren Servern (z. B. Server(n) 878 von 8D) Kartenauffrischungen und/oder - updates empfangen kann.
  • Die CPU(s) 806 können einen CPU-Cluster oder CPU-Komplex (hier auch als „CCPLEX“ bezeichnet) umfassen. CPU(s) 806 können mehrere Kerne und/oder L2-Caches enthalten. In einigen Ausführungsformen können CPU(s) 806 zum Beispiel acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In einigen Ausführungsformen können CPU(s) 806 vier Dual-Core-Cluster umfassen, wobei jeder Cluster einen dedizierten L2-Cache (z. B. einen 2 MB L2-Cache) aufweist. Die CPU(s) 806 (z. B. der CCPLEX) können dazu konfiguriert sein, den Cluster-Simultanbetrieb zu unterstützen, sodass jede Cluster-Kombination von CPU(s) 806 jederzeit aktiv sein kann.
  • CPU(s) 806 können Energieverwaltungsfunktionen implementieren, die eine oder mehrere der folgenden Funktionen umfassen: einzelne 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-Anweisungen nicht auf aktive Weise Anweisungen ausführt; jeder Kern kann unabhängig stromgesteuert sein; jeder Kerncluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder stromgesteuert sind; und/oder jeder Kerncluster kann unabhängig stromgesteuert sein, wenn alle Kerne stromgesteuert sind. CPU(s) 806 können außerdem einen erweiterten Algorithmus zur Verwaltung von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufweckzeiten festgelegt werden und die Hardware/der Mikrocode den besten Energiezustand für den Kern, Cluster und CCPLEX bestimmt. Die Prozessorkerne können vereinfachte Sequenzen zur Eingabe des Energiezustands in Software unterstützen, wodurch die Arbeitslast auf Mikrocode abwälzt wird.
  • GPU(s) 808 können eine integrierte GPU (hier alternativ dazu als „iGPU“ bezeichnet) umfassen. GPU(s) 808 können programmierbar und effizient für parallele Arbeitslasten sein. GPU(s) 808 können in einigen Beispielen einen erweiterten Tensor-Anweisungsssatz verwenden. GPU(s) 808 können einen oder mehrere Streaming-Mikroprozessoren umfassen, wobei jeder Streaming-Mikroprozessor einen L1-Cache umfassen kann (z. B. einen L1-Cache mit mindestens 96 KB Speicherkapazität), und zwei oder mehr Streaming-Mikroprozessoren können einen L2-Cache (z. B. einen L2-Cache mit 512 KB Speicherkapazität) gemeinsam benutzen. In einigen Ausführungsformen können die GPU(s) 808 mindestens acht Streaming-Mikroprozessoren umfassen. GPU(s) 808 können eine oder mehrere Berechnungs-Programmierschnittstellen (API(s)) verwenden. Darüber hinaus können GPU(s) 808 eine oder mehrere parallele Computerplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
  • GPU(s) 808 können zur optimalen Leistung in Automobilanwendungen und eingebetteten Anwendungen energieoptimiert sein. GPU(s) 808 können zum Beispiel auf einem Fin-Feldeffekttransistor (FinFET) hergestellt sein. Dies ist jedoch nicht einschränkend zu verstehen, und GPU(s) 808 können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von Prozessorkernen mit gemischter Genauigkeit umfassen, die in mehrere Blöcke unterteilt sind. Zum Beispiel können 64 PF32-Kerne und 32 PF64-Kerne in vier Prozessorblöcke unterteilt sein, ohne darauf beschränkt zu sein. In solch einem Beispiel können jedem Prozessorblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Genauigkeit für Deep-Learning-Matrixarithmetik, ein L0-Anweisungscache, ein Warp-Scheduler, eine Dispatch-Einheit und/oder eine 64 KB-Registerdatei zugewiesen sein. Darüber hinaus können Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkomma-Datenpfade umfassen, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnungen und Adressierungsberechnungen zu ermöglichen. Streaming-Mikroprozessoren können eine unabhängige Thread-Scheduling-Fähigkeit umfassen, um eine feinkörnigere Synchronisierung und Kooperation zwischen parallelen Threads zu ermöglichen. Streaming-Mikroprozessoren können einen kombinierten L1-Datencache und eine gemeinsam benutzte Speichereinheit umfassen, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
  • GPU(s) 808 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 bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zum HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) wie z. B. ein „graphics double data rate type five synchronous random-access memory“ (GDDR5) verwendet werden,
  • GPU(s) 808 können eine Unified-Memory-Technologie mit Zugriffszählern umfassen, um eine genauere Zuweisung von Speicherseiten an den Prozessor zu ermöglichen, der am häufigsten auf diese zugreift, und dadurch die Effizienz von Speicherbereichen, die von mehreren Prozessoren gemeinsam genutzt werden, zu erhöhen. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, um GPU(s) 808 den direkten Zugriff auf Seitentabellen von CPU(s) 806 zu ermöglichen. In solchen Beispielen kann eine Adressübersetzungsanforderung an die CPU(s) 806 gesendet werden, wenn die Speicherverwaltungseinheit (MMU) von GPU(s) 808 einen Fehlschlag erleidet. In Reaktion darauf können CPU(s) 806 in ihren Seitentabellen nach einer virtuell-physikalischen Zuordnung für die Adresse suchen und die Übersetzung an GPU(s) 808 zurücksenden. Dadurch kann Unified-Memory-Technologie einen einzigen einheitlichen virtuellen Adressraum für den Speicher sowohl von CPU(s) 806 als auch von GPU(s) 808 ermöglichen, wodurch die Programmierung von GPU(s) 808 und die Portierung von Anwendungen auf GPU(s) 808 vereinfacht wird.
  • Darüber hinaus können GPU(s) 808 einen Zugriffszähler umfassen, der die Zugriffshäufigkeit der GPU(s) 808 auf den Speicher anderer Prozessoren verfolgen kann. Der Zugriffszähler kann dazu beitragen, sicherzustellen, dass Speicherseiten in den physischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
  • SoC(s) 804 können eine beliebige Anzahl von Cache(s) 812 umfassen, einschließlich der hier beschriebenen. Zum Beispiel können die Cache(s) 812 einen L3-Cache umfassen, der sowohl für CPU(s) 806 als auch für GPU(s) 808 verfügbar ist (z. B. weil er sowohl mit CPU(s) 806 als auch mit GPU(s) 808 verbunden ist). Cache(s) 812 können einen Write-Back-Cache umfassen, der z. B. durch Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.) den Zustand von Zeilen verfolgen kann. Der L3-Cache kann je nach Ausführung 4 MB oder mehr aufweisen, obwohl auch kleinere Cache-Größen verwendet werden können.
  • SoC(s) 804 können eine arithmetische Logikeinheit(en) (ALU(s)) enthalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der vielen Tasks oder Operationen des Fahrzeugs 800 - wie der Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus können SoC(s) 804 eine oder mehrere Gleitkommaeinheiten (FPU(s)) - oder andere mathematische Coprozessor- oder numerische Coprozessor-Typen - zur Durchführung mathematischer Operationen innerhalb des Systems umfassen. Zum Beispiel können SoC(s) 104 eine oder mehrere FPUs umfassen, die in einer oder mehreren CPU(s) 806 und/oder GPU(s) 808 als Ausführungseinheiten integriert sind.
  • SoC(s) 804 können einen oder mehrere Beschleuniger 814 umfassen (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination daraus). Zum Beispiel können SoC(s) 804 einen Hardwarebeschleunigungscluster umfassen, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher umfassen kann. Der große On-Chip-Speicher (z. B. 4 MB SRAM) kann dem Hardwarebeschleunigungscluster die Beschleunigung neuronaler Netze und anderer Berechnungen ermöglichen. Der Hardwarebeschleunigungscluster kann zur Ergänzung der GPU(s) 808 und zur Übernahme einiger Tasks von GPU(s) 808 verwendet werden (z. B., um mehr Zyklen der GPU(s) 808 für die Durchführung anderer Taskts freizugeben). Zum Beispiel können Beschleuniger 814 für gezielte Arbeitslasten (z. B. Perzeption, konvolutionale neuronale Netze (CNNs) usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung zu geeignet zu sein. Der Begriff „CNN“, wie hier verwendet, kann alle Arten von CNNs umfassen, einschließlich regionenbasierter oder regionaler konvolutionale neuronaler Netze (RCNNs) und Fast RCNNs (z. B. für die Objekterkennung).
  • Beschleuniger 814 (z. B. der Hardwarebeschleunigungscluster) können einen Deep-Learning-Beschleuniger (DLA) umfassen. DLA(s) können eine oder mehrere Tensor-Verarbeitungseinheiten (TPUs) umfassen, die dazu konfiguriert sein können, zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Learning-Anwendungen und das Inferencing bereitstellen. TPUs können Beschleuniger sein, die dazu konfiguriert und optimiert sind, Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) durchzuführen. DLA(s) können darüber hinaus für eine bestimmte Gruppe von neuronalen Netztypen und Gleitkommaoperationen sowie für das Inferencing optimiert sein. Das Design der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Universal-GPU und übertrifft die Leistung einer CPU bei weitem. TPU(s) können mehrere Funktionen durchführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datentypen sowohl für Merkmale als auch für Gewichtungen unterstützt, sowie Postprozessorfunktionen.
  • DLA(s) können schnell und effizient neuronale Netze, insbesondere CNNs, mit verarbeiteten oder unverarbeiteten Daten für verschiedene Funktionen ausführen, zum Beispiel einschließlich, ohne darauf beschränkt zu sein: ein CNN zur Identifizierung und Erkennung von Objekten unter Verwendung von Daten von Kamerasensoren; ein CNN zur Abstandsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN zur Erkennung und Identifizierung von Einsatzfahrzeugen unter Verwendung von Daten von Mikrofonen; ein CNN zur Gesichtserkennung und Identifizierung von Fahrzeugbesitzern unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsbezogene Ereignisse.
  • DLA(s) können jede Funktion von GPU(s) 808 durchführen, und ein Entwickler kann die Verwendung eines Inferencing-Beschleunigers zum Beispiel für jede Funktion der DLA(s) oder GPU(s) 808 vorsehen. Der Entwickler kann zum Beispiel die Verarbeitung von CNNs und Gleitkommaoperationen auf DLA(s) konzentrieren und andere Funktionen den GPU(s) 808 und/oder anderen Beschleunigern 814 überlassen.
  • Beschleuniger 814 (z. B. Hardwarebeschleunigungscluster) können einen programmierbaren Visionsbeschleuniger (PVA) umfassen, der hier auch als Computer-Visionsbeschleuniger bezeichnet wird. Die PVA(s) können so konzipiert und konfiguriert sein, dass sie Computer-Vision-Algorithmen für erweiterte Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented-Reality- (AR) und/oder Virtual-Reality-Anwendungen (VR) beschleunigen. PVA(s) können ein Gleichgewicht zwischen Leistung und Flexibilität bieten. Zum Beispiel kann jeder PVA, ohne darauf beschränkt zu sein, eine beliebige Anzahl von Rechenkernen mit reduziertem Anweisungssatz (RISC), direkten Speicherzugriff (DMA) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
  • RISC-Kerne können mit Bildsensoren (z. B. Bildsensoren einer der Kameras, die hier beschrieben werden), Bildsignalprozessoren und/oder dergleichen zusammenwirken. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher umfassen. RISC-Kerne können je nach Ausführungsform eine Reihe von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. RISC-Kerne können mit einer oder mehreren integrierten Schaltungen, anwendungsspezifischen integrierten Schaltungen (ASICs) und/oder Speicherbausteinen implementiert sein. die RISC-Kerne können zum Beispiel einen Anweisungscache und/oder einen eng gekoppelten RAM enthalten.
  • Die DMA kann es Komponenten von PVA(s) ermöglichen, unabhängig von CPU(s) 806 auf den Systemspeicher zuzugreifen. Die DMA kann eine beliebige Anzahl von Merkmalen zur Optimierung der PVA unterstützen, einschließlich, ohne darauf beschränkt zu sein, die Unterstützung mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. In einigen Beispielen kann die DMA bis zu sechs oder mehr Adressierungsdimensionen unterstützen, die, ohne darauf beschränkt zu sein, Blockbreite, Blockhöhe, Blocktiefe, horizontale Blockstaffelung, vertikale Blockstaffelung und/oder Tiefenstaffelung umfassen können.
  • Die Vektorprozessoren können programmierbare Prozessoren sein, die dazu ausgelegt sein können, die Programmierung von Computer-Vision-Algorithmen effizient und flexibel auszuführen und Signalverarbeitungsfähigkeiten bereitzustellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungssubsystem-Partitionen umfassen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA-Engine(s) (z. B. zwei DMA-Engines) und/oder andere Peripheriegeräte umfassen. Das Vektorverarbeitungssubsystem kann als Primärverarbeitungsengine der PVA arbeiten und eine Vektorverarbeitungseinheit (VPU), einen Anweisungscache und/oder einen Vektorspeicher (z. B. VMEM) umfassen. Ein VPU-Kern kann einen digitalen Signalprozessor wie z. B. einen digitalen „Single Instruction, Multiple Data“ (SIMD), „Very Long Instruction Word“ (VLIW)-Signalprozessor umfassen. Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
  • Jeder der Vektorprozessoren kann einen Anweisungscache umfassen und mit dediziertem Arbeitsspeicher gekoppelt sein. Dadurch kann in einigen Beispielen jeder der Vektorprozessoren dazu konfiguriert sein, unabhängig von anderen Vektorprozessoren zu arbeiten. In anderen Beispielen können Vektorprozessoren, die in einer bestimmten PVA enthalten sind, dazu konfiguriert sein, Datenparallelität zu verwenden. Zum Beispiel können mehrere Vektorprozessoren, die in einer Einzel-PVA enthalten sind, denselben Computer-Vision-Algorithmus ausführen, jedoch für unterschiedliche Bereiche eines Bilds. In anderen Beispielen können Vektorprozessoren, die in einer bestimmten PVA enthalten sind, gleichzeitig verschiedene Bildverarbeitungsalgorithmen am selben Bild ausführen, oder sogar verschiedene Algorithmen an aufeinanderfolgenden Bildern oder Teilen eines Bilds ausführen. Unter anderem kann eine beliebige Anzahl von PVAs im Hardware-Beschleunigungscluster enthalten sein, und in jedem PVA kann eine beliebige Anzahl von Vektorprozessoren enthalten sein. Zudem können PVA(s) einen zusätzlichen Speicher mit Fehlerkorrekturcode (ECC) umfassen, um die Gesamtsystemsicherheit zu erhöhen.
  • Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) können ein Ein-Chip-Computer-Vision-Netz und einen statischen Direktzugriffsspeicher (SRAM) umfassen, um Beschleunigern 814 einen SRAM mit hoher Bandbreite und geringer Latenz bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM umfassen, der zum Beispiel, ohne darauf beschränkt zu sein, aus acht feldkonfigurierbaren Speicherblöcken besteht, auf welche sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine Advanced Peripheral Bus (APB)-Schnittstelle, Konfigurationsschaltung, einen Controller und einen Multiplexer umfassen. Jede Art von Speicher kann verwendet werden. Der PVA und der DLA können über ein Backbone auf den Speicher zugreifen, das dem PVA und der DLA einen Hochgeschwindigkeitszugriff auf den Speicher ermöglicht. Das Backbone kann ein Ein-Chip-Computer-Vision-Netz umfassen, das den PVA und den DLA (z. B. über APB) mit dem Speicher verbindet.
  • Das Ein-Chip-Computer-Vision-Netz kann eine Schnittstelle umfassen, die vor der Übertragung von Steuersignalen/Adressen/Daten feststellt, dass sowohl der PVA als auch der DLA vollständige und gültige Signale bereitstellen. Solch eine 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 mit den ISO 26262- oder IEC 61508-Normen konform sein, auch wenn andere Normen und Protokolle verwendet werden können.
  • In einigen Beispielen können die SoC(s) 804 einen Echtzeit-Raytracing-Hardwarebeschleuniger enthalten, wie z.B. in der US-Patentanmeldung Nr. 16/101.232 beschrieben, die am 10. August 2018 eingereicht wurde. Der Echtzeit-Strahlenverfolgungs-Hardwarebeschleuniger kann zur schnellen und effizienten Bestimmung der Position und Ausdehnung von Objekten (z. B. innerhalb eines Weltmodells), zur Erzeugung von Echtzeit-Visualisierungssimulationen, zur RADAR-Signalinterpretation, zur Schallausbreitungssynthese und/oder -analyse, zur Simulation von SONAR-Systemen, zur allgemeinen Wellenausbreitungssimulation, zum Vergleich mit LIDAR-Daten zu Lokalisierungszwecken und/oder andere Funktionen und/oder zu anderen Zwecken verwendet werden. In einigen Ausführungsformen können eine oder mehrere Tree Traversal Units (TTUs) zur Ausführung einer oder mehrerer Operationen im Zusammenhang mit der Strahlenverfolgung verwendet werden.
  • Beschleuniger 814 (z. B. der Hardwarebeschleunigungscluster) haben eine weite Bandbreite von Einsatzmöglichkeiten für das autonome Fahren. Der PVA kann ein programmierbarer Visionsbeschleuniger sein, der für Schlüsselverarbeitungsschritte in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten von PVAs sind gut für algorithmische Bereiche geeignet, die eine vorhersehbare Verarbeitung bei geringer Leistungsaufnahme und niedriger Latenz erfordern. Mit anderen Worten, der PVA eignet sich gut für halbdichte oder dichte regelmäßige Berechnungen, selbst bei kleinen Datensätzen, die vorhersehbare Laufzeiten mit geringer Latenz und niedriger Leistungsaufnahme erfordern. Im Kontext von Plattformen für autonome Fahrzeuge sind PVAs daher dazu ausgelegt, klassische Computer-Vision-Algorithmen auszuführen, da sie bei der Objekterkennung effizient sind und mathematisch mit Ganzzahlen arbeiten.
  • Zum Beispiel wird der PVA gemäß einer Ausführungsform der Technologie verwendet, um Computer-Stereovision durchzuführen. In einigen Beispielen kann ein Semi-Global-Matching-Algorithmus verwendet werden, obwohl dies nicht einschränkend zu verstehen ist. Viele Anwendungen für autonomes Fahren der Level 3 bis 5 erfordern eine Bewegungsschätzung/einen Stereoabgleich während der Fahrt (z. B. Bewegungsstruktur, Fußgängererkennung, Fahrspurerkennung usw.). der PVA kann auf der Basis der Eingaben von zwei monokularen Kameras eine Computer-Stereovision-Funktion durchführen.
  • In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss zu realisieren. Zum Beispiel durch Verarbeitung von RADAR-Rohdaten (z. B. mit einer 4D-Fast-Fourier-Transformation), um verarbeitete RADAR-Daten bereitzustellen. In anderen Beispielen wird PVA für die Time-of-flight (ToF)-Tiefenverarbeitung verwendet, zum Beispiel durch Verarbeitung von Time-of-flight -Rohdaten, um verarbeitete Time-of-flight-Daten bereitzustellen.
  • Der DLA kann verwendet werden, um jede Art von Netz zur Verbesserung der Steuerung und Fahrsicherheit zu betreiben, einschließlich zum Beispiel eines neuronales Netzes, das ein Konfidenzmaß für jede Objekterkennung ausgibt. Solch ein Konfidenzwert kann als eine Wahrscheinlichkeit interpretiert werden, oder als Bereitstellung einer relativen „Gewichtung“ jeder Detektion im Vergleich zu anderen Detektionen. Dieser Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als richtig positive Detektionen und nicht als falsch positive Detektionen zu betrachten sind. Zum Beispiel kann das System einen Schwellenwert für die Konfidenz festlegen und nur Detektionen, die den Schwellenwert übersteigen, als echte positive Detektionen betrachten. Bei einem automatischen Notbremssystem (AEB) würden falsch positive Detektionen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was offensichtlich unerwünscht ist. Deshalb sollten nur die sichersten Detektionen als Auslöser für die Notbremsung (AEB) in Betracht gezogen werden. Der DLA kann ein neuronales Netz zur Regression des Konfidenzwerts ausführen. Das neuronale Netz kann als Eingabe mindestens eine Teilmenge von Parametern verwenden, wie z. B., unter anderem, Begrenzungsrahmen-Abmessungen, die (z. B. von einem anderen Teilsystem) erhaltene Schätzung der Grundebene, die Ausgabe von IMU-Sensor(en) 866, die mit der Orientierung des Fahrzeugs 800 korreliert, die Entfernung, 3D-Positionsschätzungen eines Objekts, die vom neuronalen Netz und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 864 oder RADAR-Sensor(en) 860) erhalten wurden..
  • SoC(s) 804 können Datenspeicher 816 (z. B. Arbeitsspeicher) umfassen. Datenspeicher 816 können On-Chip-Speicher von SoC(s) 804 sein, die neuronale Netze speichern können, die auf der GPU und/oder dem DLA ausgeführt werden. In einigen Beispielen kann die Kapazität von Datenspeichern 816 groß genug sein, um zur Redundanz und Sicherheit mehrere Instanzen von neuronalen Netzen zu speichern. Datenspeicher 812 können L2- oder L3-Cache(s) 812 umfassen. Datenspeicher 816 kann sich auf den Arbeitsspeicher beziehen, der dem PVA, DLA und/oder anderen Beschleunigern 814 zugeordnet ist, wie hier beschrieben.
  • SoC(s) 804 können einen oder mehrere Prozessoren 810 (z. B. eingebettete Prozessoren) umfassen. Prozessoren 810 können einen Boot- und Energieverwaltungssprozessor umfassen, die ein dedizierter Prozessor und ein Subsystem sein können, die Boot- und Energieverwaltungsfunktionen sowie die diesbezügliche Sicherheitsdurchsetzung übernehmen. Der Boot- und Energieverwaltungsprozessor kann Teil der Bootsequenz von SoC(s) 804 sein und Laufzeitenergieverwaltungsdienste bereitstellen. Der Boot- und Energieverwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Systemübergängen in einen niedrigen Leistungszustand, die Steuerung von SoC(s) 804-Termiken und Temperatursensoren und/oder die Steuerung von SoC(s) 804-Leistungszuständen bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgabefrequenz proportional zur Temperatur ist, und die SoC(s) 804 können die Ringoszillatoren verwenden, um die Temperatur der CPU(s) 806, GPU(s) 808 und/oder Beschleuniger 814 zu detektieren. Wenn bestimmt wird, dass Temperaturen einen Schwellenwert übersteigen, der Boot- und Energieverwaltungsprozessor eine Temperaturfehlerroutine einleiten und SoC(s) 804 in einen niedrigen Leistungszustand versetzen und/oder das Fahrzeug 800 in einen Haltemodus versetzen (z. B. das Fahrzeug 800 zu einem sicheren Halt bringen).
  • Prozessoren 810 können außerdem eine Reihe von eingebetteten Prozessoren umfassen, die als Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audio-Subsystem sein, das eine volle Hardwareunterstützung für Mehrkanalton ü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.
  • Prozessoren 810 können außerdem eine ständig eingeschaltete Prozessor-Engine umfassen, die notwendige Hardware-Funktionen zur Unterstützung des Low-Power-Managements der Sensoren und der Aufweck-Anwendungsfälle bereitstellen kann. Die ständig eingeschaltete Prozessor-Engine kann einen Prozessorkern, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Taktgeber und Unterbrechungssteuerungen), verschiedene E/A-Steuerungsperipheriegeräte und Routing-Logik umfassen.
  • Prozessoren 810 können außerdem eine Sicherheits-Cluster-Engine umfassen, die ein spezielles Prozessor-Subsystem für das Sicherheitsmanagement von Automobilanwendungen umfasst. Die Sicherheits-Cluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Taktgeber, eine Unterbrechungssteuerung usw.) und/oder Routing-Logik umfassen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem in einem Gleichschritt (Lockstep)-Modus arbeiten und als ein Einzelkern mit einer Vergleichslogik zur Erkennung von Unterschieden zwischen ihren Operationen funktionieren.
  • Prozessoren 810 können außerdem eine Echtzeit-Kamera-Engine umfassen, die ein spezielles Prozessor-Subsystem für das Echtzeit-Kamera-Management umfassen kann.
  • Prozessoren 810 können außerdem einen Signalprozessor mit hohem Dynamikbereich umfassen, der einen Bildsignalprozessor umfassen kann, der eine Hardware-Engine ist, die Teil der Kameraverarbeitungs-Pipeline ist.
  • Prozessoren 810 können einen Videobild-Kompositor umfassen, der ein (z. B. auf einem Mikroprozessor implementierter) Verarbeitungsblock sein kann, der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Abspielfenster zu erzeugen. Der Videobild-Kompositor kann an Weitwinkelkamera(s) 870, an Surround-View-Kamera(s) 874 und/oder an Innenraumüberwachungskamerasensoren eine Linsenverzerrungskorrektur vornehmen. Der Kamerasensor zur Innenraumüberwachung wird bevorzugt von einem neuronalen Netz überwacht, das auf einer anderen Instanz des Advanced SoC läuft und dazu konfiguriert ist, Ereignisse im Innenraum zu identifizieren und entsprechend zu reagieren. Ein Innenraumsystem kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, EMails zu diktieren, den Zielort des Fahrzeugs zu ändern, das Infotainmentsystem und 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 Videobild-Kompositor kann eine verbesserte zeitliche Rauschunterdrückung sowohl für räumliche als auch für zeitliche Rauschunterdrückung umfassen. Wenn zum Beispiel in einem Video eine Bewegung auftritt, wird räumliche Information durch Rauschunterdrückung auf geeignete Weise gewichtet, wodurch die Gewichtung der Information von benachbarten Einzelbildern reduziert wird. Wenn ein Bild oder ein Teil eines Bilds keine Bewegung enthält, kann die vom Videobild-Kompositor durchgeführte Rauschunterdrückung zeitliche Information aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
  • Der Videobild-Kompositor kann auch dazu konfiguriert sein, eine Stereorektifizierung an eingegebenen Stereobildern vorzunehmen. Der Videobild-Kompositor auch zur Gestaltung der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und keine GPUs 808 zum kontinuierlichen Rendern neuer Oberflächen benötigt werden. Selbst wenn GPUs 808 eingeschaltet sind und aktiv 3D-Rendering betreiben, kann der Videobild-Compositor verwendet werden, um GPUs 808 zu entlasten und dadurch die Leistung und Reaktionsfähigkeit zu verbessern.
  • SoC(s) 804 können außerdem eine serielle MIPI-Kameraschnittstelle für den Empfang von Video und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock umfassen, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. SoC(s) 804 können außerdem einen oder mehrere Eingabe/Ausgabe-Controller umfassen, die durch Software gesteuert werden können und zum Empfang von E/A-Signalen verwendet werden können, die keiner spezifischen Aufgabe zugeordnet sind.
  • SoC(s) 804 können außerdem eine breite Palette von Peripherieschnittstellen umfassen, um die Kommunikation mit Peripheriegeräten, Audio-Codecs, der Energieverwaltung und/oder anderen Geräten zu ermöglichen. SoC(s) 804 können zur Verarbeitung von Daten aus Kameras (z. B. über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LIDAR-Sensor(en) 864, RADAR-Sensor(en) 860 usw., die über Ethernet angeschlossen werden können), Daten aus dem Bus 802 (z. B. Geschwindigkeit des Fahrzeugs 800, Lenkradposition usw.), Daten aus GNSS-Sensor(en) 858 (z. B. über Ethernet oder CAN-Bus angeschlossen) usw. verwendet werden. SoC(s) 804 können außerdem dedizierte Hochleistungs-Massenspeicher-Controller enthalten, die ihre eigenen DMA-Engines enthalten können und dazu verwendet werden können, die CPU(s) 806 von Routineaufgaben der Datenverwaltung zu entlasten.
  • SoC(s) 804 können eine End-to-End-Plattform mit flexibler Architektur sein, die die Automatisierungsstufen 3 bis 5 abdeckt und dadurch eine umfassende funktionale Sicherheitsarchitektur bereitstellt, die Computer-Vision- und ADAS-Techniken effizient nutzt, um die Diversität und Redundanz gewährleisten, und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Deep-Learning-Tools bereitstellt. SoC(s) 804 können schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Zum Beispiel können die Beschleuniger 814 in Kombination mit CPU(s) 806, GPU(s) 808 und Datenspeicher(n) 816 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Level 3-5 bilden.
  • Die Technologie bietet daher Fähigkeiten und Funktionen, die mit herkömmlichen Systemen nicht erreichbar sind. Zum Beispiel können Computer-Vision-Algorithmen auf CPUs ausgeführt werden, die unter Verwendung einer höheren Programmiersprache wie z. B. der Programmiersprache C dazu konfiguriert werden können, eine Vielzahl von Verarbeitungsalgorithmen für eine große Vielfalt von visuellen Daten auszuführen. CPUs sind jedoch oft nicht in der Lage, die Leistungsanforderungen vieler Computer-Vision-Anwendungen zu erfüllen, wie z. B. jene bezüglich der Ausführungszeit und des Stromverbrauchs. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, was eine Anforderung in ADAS-Anwendungen in Fahrzeugen ist und bei autonomen Fahrzeugen der Level 3-5 eine Anforderung ist.
  • Im Gegensatz zu herkömmlichen Systemen ermöglicht es die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardwarebeschleunigungsclusters, mehrere neuronale Netze gleichzeitig und/oder aufeinanderfolgend auszuführen und die Ergebnisse miteinander zu kombinieren, um autonome Fahrfunktionen der Level 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA (Deep-Learning-Beschleuniger) oder einer dGPU (z. B. GPU(s) 820) ausgeführt wird, eine Text- und Worterkennung einschließen, die es dem Supercomputer ermöglicht, Verkehrszeichen zu lesen und zu verstehen, einschließlich Zeichen, für die das neuronale Netz nicht speziell trainiert wurde. Der DLA kann außerdem ein neuronales Netz umfassen, das in der Lage ist, Zeichen zu identifizieren, zu interpretieren und semantisch zu verstehen und dieses semantische Verständnis an Wegplanungsmodule weiterzugeben, die auf CPU-Komplex laufen.
  • Ein weiteres Beispiel ist, dass mehrere neuronale Netze gleichzeitig laufen können, wie dies für das Fahren auf Level 3, 4 oder 5 erforderlich ist. Zum Beispiel kann ein Warnschild mit der Aufschrift „Achtung: Blinklichter weisen auf Glatteis hin“ zusammen mit einem elektrischen Licht unabhängig oder von mehreren neuronalen Netzen gemeinsam interpretiert werden. Das Schild selbst von einem ersten eingesetzten neuronalen Netz (z. B. einem trainierten neuronalen Netz) als Verkehrsschild identifiziert werden, der Text „Blinklichter deuten auf Glatteis hin“ kann von einem zweiten eingesetzten neuronalen Netz interpretiert werden, das die Wegplanungssoftware des Fahrzeugs (die bevorzugt auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass Glatteis vorliegt, wenn blinkende Lichter erkannt werden. Das Blinklicht kann identifiziert werden, indem ein drittes eingesetztes neuronales Netz über mehrere Einzelbilder hinweg betrieben wird und die Software für die Wegplanung des Fahrzeugs über das Vorhandensein (oder die Abwesenheit) von Blinklichtern informiert. Alle drei neuronalen Netze können gleichzeitig laufen, z. B. im DLA und/oder auf GPU(s) 808.
  • 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 800 zu erkennen. Die ständig eingeschaltete Sensor-Verarbeitungsengine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn der Besitzer sich der Fahrertür nähert, und das Licht einschaltet, und um das Fahrzeug im Sicherheitsmodus zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgen SoC(s) 804 für Sicherheit gegen Diebstahl und/oder Carjacking.
  • In einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 896 verwenden, um Sirenen von Einsatzfahrzeugen zu detektieren und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Detektion von Sirenen und manuellen Extraktion von Merkmalen verwenden, verwenden die SoC(s) 804 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung visueller Daten. In einer bevorzugten Ausführungsform wird das CNN, das auf einem DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit eines Einsatzfahrzeugs zu erkennen (z. B. durch Nutzung des Dopplereffekts). Das CNN kann auch darauf trainiert sein, Einsatzfahrzeuge zu identifizieren, die spezifisch für das Gebiet sind, wie es von GNSS-Sensor(en) 858 identifiziert wird. Zum Beispiel wird das CNN in Europa versuchen, europäische Sirenen zu detektieren, und in den Vereinigten Staaten versucht das CNN, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Einsatzfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge auszuführen, die das Fahrzeug mit Unterstützung von Ultraschallsensoren 862 verlangsamt, an den Straßenrand fährt, das Fahrzeug parkt und/oder das Fahrzeug im Leerlauf laufen lässt, bis die Einsatzfahrzeuge vorbeigefahren sind.
  • Das Fahrzeug kann CPU(s) 818 (z. B. diskrete CPU(s) oder dCPU(s)) umfassen, die über eine Hochgeschwindigkeitsverbindung (z. B. PCIe) mit SoC(s) 804 gekoppelt sein können. CPU(s) 818 können zum Beispiel einen X86-Prozessor umfassen. CPU(s) 818 können zur Durchführung verschiedener Funktionen verwendet werden, einschließlich zum Beispiel der Arbitrierung potenziell uneinheitlicher Ergebnisse zwischen ADAS-Sensoren SoC(s) 804 und/oder der Überwachung des Status und des Zustands der Controller 836 und/oder des Infotainment-SoC 830.
  • Das Fahrzeug 800 kann CPU(s) 820 (z. B. diskrete CPU(s) oder dCPU(s)) umfassen, die über eine Hochgeschwindigkeitsverbindung (z. B. NVIDIA's NVLINK) mit SoC(s) 804 gekoppelt sein können. GPU(s) 820 können zusätzliche KI-Funktionalität wie z. B. durch Ausführung redundanter und/oder anderer neuronaler Netze bereitstellen, und können dazu verwendet werden, neuronale Netze mindestens zum Teil auf der Basis von Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 800 zu trainieren und/oder zu aktualisieren.
  • Das Fahrzeug 800 kann außerdem eine Netzschnittstelle 824 umfassen, die eine oder mehrere drahtlose Antennen 826 (z. B. eine oder mehrere drahtlose Antennen für verschiedene Kommunikationsprotokolle, wie z. B. eine Mobilfunkantenne, eine Bluetooth-Antenne usw.) umfassen kann. Die Netzschnittstelle 824 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit Servern 878 und/oder anderen Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Computergeräten (z. B. Client-Geräten von Fahrgästen) zu ermöglichen. Zur Kommunikation mit anderen Fahrzeugen kann eine direkte Verbindung zwischen zwei Fahrzeugen und/oder eine indirekte Verbindung (z. B. über Netzwerke und das Internet) hergestellt werden. Direkte Verbindungen können über eine Fahrzeug-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 800 Information über Fahrzeuge in der Nähe des Fahrzeugs 800 (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 800) bereitstellen. Diese Funktionalität kann Teil einer kooperierenden adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 800 sein.
  • Die Netzschnittstelle 824 kann ein SoC umfassen, das Modulations- und Demodulationsfunktionalität bereitstellt und es Controllern 836 ermöglicht, über drahtlose Netzwerke zu kommunizieren. Die Netzschnittstelle 824 kann ein Hochfrequenz-Frontend für die Aufwärtskonvertierung von Basisband auf Hochfrequenz und die Abwärtskonvertierung von Hochfrequenz auf Basisband umfassen. Frequenzumwandlungen durch wohlbekannte Verfahren und/oder durch Super-Heterodyn-Verfahren erfolgen. In einigen Beispielen kann die Hochfrequenz-Frontend-Funktionalität durch einen separaten Chip bereitgestellt werden. Die Netzschnittstelle kann drahtlose Funktionalitäten für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle umfassen.
  • Das Fahrzeug 800 kann außerdem einen oder mehrere Datenspeicher 828 umfassen, die auch Off-Chip-Speicher (z. B. Off-SoC(s) 804) umfassen können. Datenspeicher 828 können ein oder mehrere Speicherelemente einschließlich RAM, SRAM, DRAM VRAM Flash, Festplatten und/oder andere Komponenten und/oder Geräte umfassen, die mindestens ein Datenbit speichern können.
  • Das Fahrzeug 800 kann außerdem GNSS-Sensor(en) 858 umfassen. GNSS-Sensor(en) 858 (z. B. GPS, unterstützte GPS-Sensoren, Differential-GPS (DGPS)-Sensoren usw.) umfassen, um die Kartierung, Perzeption, Erzeugung von Belegungsrastern und/oder Wegplanungsfunktionen zu unterstützen. Eine beliebige Anzahl von GNSS-Sensoren 858 kann verwendet werden, z. B. und, darauf beschränkt zu sein, ein GPS, das einen USB-Anschluss mit einer Ethernet-zu-Seriell-Brücke (z. B. RS-232) verwendet.
  • Das Fahrzeug 800 kann außerdem RADAR-Sensor(en) 860 umfassen. RADAR-Sensor(en) 860 können vom Fahrzeug 800 selbst bei Dunkelheit und/oder schlechten Wetterbedingungen zur Weitbereichs-Fahrzeugdetektion verwendet werden. Die funktionalen RADAR-Sicherheitsstufen können ASIL, B sein. RADAR-Sensor(en) 860 können den CAN und/oder Bus 802 (z. B. zur Übertragung von Daten, die von RADAR-Sensor(en) 860 erzeugt wurden) zur Steuerung und für den Zugriff auf Objektverfolgungsdaten verwenden, wobei der Zugriff auf Rohdaten in einigen Beispielen über Ethernet erfolgt. Eine Vielzahl von RADAR-Sensortypen kann verwendet werden. Zum Beispiel können RADAR-Sensor(en) 860 zur Verwendung als Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensor(en) verwendet.
  • RADAR-Sensor(en) 860 können verschiedene Konfigurationen aufweisen, z. B. mit langer Reichweite und engem Sichtfeld, mit kurzer Reichweite und breitem Sichtfeld, mit kurzer Reichweite und seitlicher Abdeckung usw. In einigen Beispielen kann RADAR mit großer Reichweite zur adaptiven Geschwindigkeitsregelung verwendet werden. 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. RADAR-Sensor(en) 860 können dazu beitragen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und können von ADAS-Systemen zur Notbremsunterstützung und Frontallkollisionswarnung verwendet werden. RADAR-Sensoren mit großer Reichweite können ein monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und eine Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle umfassen. In einem Beispiel mit sechs Antennen können die vier zentrale Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu ausgelegt ist, die Umgebung des Fahrzeugs 800 bei höheren Geschwindigkeiten mit minimaler Störung durch Verkehr in benachbarten Fahrspuren zu aufzuzeichnen. Die zwei anderen Antennen können das Sichtfeld erweitern, um die schnelle Erkennung von Fahrzeugen zu ermöglichen, die in die Fahrspur des Fahrzeugs 800 einfahren oder diese verlassen.
  • RADAR-Systeme mit mittlerer Reichweite können zum Beispiel eine Reichweite von bis zu 860m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 850 Grad (hinten) aufweisen. RADAR-Systeme mit kurzer Reichweite können, ohne darauf beschränkt zu sein, RADAR-Sensoren umfassen, die dazu ausgelegt sind, an beiden Enden des Heckstoßfängers installiert zu werden. Wenn es an beiden Enden des Heckstoßfängers installiert ist, kann solch ein RADAR-Sensorsystem zwei Strahlen erzeugen, die den Totwinkel im hinteren Bereich und neben dem Fahrzeug konstant überwachen.
  • RADAR-Systeme mit kurzer Reichweite können im ADAS-System zur Totwinkelerkennung und/oder zur Spurwechselunterstützung verwendet werden.
  • Das Fahrzeug 800 kann außerdem Ultraschallsensor(en) 862 umfassen. Ultraschallsensoren 862, die vorne, hinten und/oder an den Seiten des Fahrzeugs 800 angeordnet sein können, können zur Einparkhilfe und/oder zur Erzeugung und Aktualisierung eines Belegungsrasters verwendet werden. Eine große Vielfalt von Ultraschallsensoren 862 kann verwendet werden, und verschiedene Ultraschallsensoren 862 können für unterschiedliche Detektionsreichweiten (z. B. 2,5 m, 4 m) verwendet werden. Die Ultraschallsensor(en) 862 können bei funktionalen Sicherheitsstufen von ASIL B arbeiten.
  • Das Fahrzeug 800 kann LIDAR-Sensor(en) 864 umfassen. LIDAR-Sensor(en) 864 können zur Objekt- und Fußgängererkennung, für Notbremsungen, zur Kollisionsvermeidung und/oder für andere Funktionen verwendet werden. IDie LIDAR-Sensor(en) 864 können bei funktionalen Sicherheitsstufen von ASIL B arbeiten. In einigen Beispielen kann das Fahrzeug 800 mehrere LIDAR-Sensoren 864 (z. B. zwei, vier, sechs usw.) umfassen, die Ethernet verwenden können (z. B., um einem Gigabit-Ethernet-Switch Daten bereitzustellen).
  • In einigen Beispielen können LIDAR-Sensor(en) 864 in der Lage sein, für ein 360-Grad-Sichtfeld eine Liste von Objekten und deren Entfernungen bereitzustellen. Kommerziell verfügbare LIDAR-Sensoren 864 können zum Beispiel eine angegebene Reichweite von etwa 800 m haben, mit einer Genauigkeit von 2-3 cm und mit Unterstützung für eine 800 Mbps-Ethernet-Verbindung. In einigen Beispielen können ein oder mehrere nicht vorspringende LIDAR-Sensoren 864 verwendet werden. In solchen Beispielen können LIDAR-Sensor(en) 864 als kleines Gerät implementiert sein, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 800 eingebettet sein kann. LIDAR-Sensoren 864 können in solchen Beispielen selbst bei Objekten mit geringem Reflexionsvermögen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von bis zu 35 Grad mit einer Reichweite von 200 m bieten. Frontmontierte LIDAR-Sensor(en) 864 können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert sein.
  • In einigen Beispielen können auch LIDAR-Technologien wie z. B. 3D Flash LIDAR verwendet werden. 3D Flash LIDAR verwendet einen Laserblitz als Sendequelle, um die Fahrzeugumgebung in bis zu etwa 200 m Entfernung zu beleuchten. Eine Flash LIDAR-Einheit umfasst einen Empfänger, der die Laufzeit des Laserpulses und das reflektierte Licht in jedem Pixel aufzeichnet, was wiederum dem Abstand vom Fahrzeug zu den Objekten entspricht. Flash LIDAR kann mit jedem Laserblitz die Erzeugung hochgenauer und verzerrungsfreier Bilder der Umgebung ermöglichen. In einigen Beispielen können vier Flash LIDAR-Sensoren eingesetzt werden, einer auf jeder Seite des Fahrzeugs 800. Verfügbare 3D-Blitz-LIDAR-Systeme umfassen eine Festkörper-3D-Staring-Array-LIDAR-Kamera, die außer einem Lüfter keine beweglichen Teile aufweist (d. h., ein nicht abtastendes LIDAR-Gerät). Das Flash LIDAR-Gerät kann einen 5-Nanosekunden-Laserimpuls der Klasse I (augensicher) pro Einzelbild verwenden und das reflektierte Laserlicht in Form von Punktwolken im 3D-Bereich und mitregistrierten Intensitätsdaten erfassen. Durch Verwendung von Flash-LIDAR, und weil Flash-LIDAR ein Festkörperbauteil ohne bewegliche Teile ist, können LIDAR-Sensor(en) 864 weniger anfällig für Bewegungsunschärfe, Vibration und/oder Stöße sein.
  • Das Fahrzeug kann außerdem IMU-Sensor(en) 866 umfassen. IMU-Sensor(en) 866 können in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 800 angeordnet sein. IMU-Sensor(en) 866 können zum Beispiel, ohne darauf beschränkt zu sein, Beschleunigungsmesser, Magnetometer, Gyroskop(e), Magnetkompass(e) und/oder andere Sensortypen umfassen. In einigen Beispielen, wie z. B. in sechsachsigen Anwendungen, können die IMU-Sensor(en) 866 Beschleunigungsmesser und Gyroskope umfassen, während die IMU-Sensor(en) 866 in neunachsigen Anwendungen Beschleunigungsmesser, Gyroskope und Magnetometer umfassen können.
  • In einigen Ausführungsformen können IMU-Sensor(en) 866 als miniaturisiertes, hochleistungsfähiges GPS-gestütztes Trägheitsnavigationssystem (GPS/INS) implementiert sein, das mikroelektromechanische Systeme (MEMS) mit Trägheitssensoren, einem hochempfindlichen GPS-Empfänger und erweiterten Kalman-Filteralgorithmen kombiniert, um Schätzungen der Position, Geschwindigkeit und Ausrichtung bereitzustellen. In einigen Beispielen können IMU-Sensor(en) 866 es einem Fahrzeug 800 ermöglichen, den Steuerkurs zu schätzen, ohne eine Eingabe von einem Magnetsensor zu erfordern, indem Geschwindigkeitsänderungen direkt vom GPS beobachtet und mit IMU-Sensor(en) 866 korreliert werden. In einigen Beispielen können die IMU-Sensor(en) 866 und die GNSS-Sensor(en) 858 in einer einzigen integrierten Einheit kombiniert sein.
  • Das Fahrzeug kann Mikrofon(e) 896 umfassen, die im und/oder um das Fahrzeug 800 herum angeordnet sind. Die Mikrofon(e) 896 können, unter anderem, zur Detektion und Identifizierung von Noteinsatzfahrzeugen verwendet werden.
  • Das Fahrzeug kann außerdem eine beliebige Anzahl von Kameratypen umfassen, einschließlich Stereokamera(s) 868, Weitwinkelkamera(s) 870, Infrarotkamera(s) 872, Surround-View-Kamera(s) 874, Weitbereichs- und/oder Mittelbereichskamera(s) 898 und/oder anderer Kameratypen. Die Kameras können verwendet werden, um Bilddaten um den gesamten Umfang des Fahrzeugs 800 herum zu erfassen. Die verwendeten Kameratypen sind von den Ausführungsformen und Anforderungen für das Fahrzeug 800 abhängig, und jede Kombination von Kameratypen kann verwendet werden, um die erforderliche Abdeckung rund um das Fahrzeug 800 zu gewährleisten. Außerdem kann die Anzahl der Kameras je nach Ausführungsform unterschiedlich sein. Das Fahrzeug kann zum Beispiel sechs, sieben, zehn, zwölf und/oder eine andere Anzahl von Kameras umfassen. Die Kameras können zum Beispiel, ohne darauf beschränkt zu sein, Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras wird hier auf 8A und 8B Bezug nehmend ausführlicher beschrieben.
  • Das Fahrzeug 800 kann außerdem einen oder mehrere Vibrationssensoren 842 umfassen. Vibrationssensor(en) 842 können Vibrationen von Komponenten des Fahrzeugs wie z. B. der Achse(n) messen. Änderungen in Vibrationen können zum Beispiel auf eine Änderung in der Fahrbahnoberfläche hindeuten. In einem anderen Beispiel können, wenn zwei oder mehr Vibrationssensoren 842 verwendet werden und Unterschiede zwischen Vibrationen verwendet werden, um die Reibung oder den Schlupf der Fahrbahnoberfläche zu bestimmen (z. B., wenn der Vibrationsunterschied zwischen einer angetriebenen Achse und einer frei rotierenden Achse besteht).
  • Das Fahrzeug 800 kann ein ADAS-System 838 umfassen. Das ADAS-System 838 kann in einigen Beispielen ein SoC umfassen. Das ADAS-System 838 kann ein autonomes/adaptives/automatisches Geschwindigkeitsregelungssystem (ACC), ein kooperierendes adaptives Geschwindigkeitsregelungssystem (CACC), ein Frontalaufprall-Warnsystem (FCW), ein automatisches Notbremssystem (AEB), ein Spurhalte-Warnsystem (LDW), einen Spurhalteassistenten (LKA), ein Totwinkel-Warnsystem (BSW), ein Warnsystem für den Querverkehr hinten (RCTW), ein Kollisionswarnsystem (CWS), ein Spurhaltesystem (LC) und/oder anderer Systeme, Merkmale und/oder Funktionen umfassen.
  • ACC-Systeme (Geschwindigkeitsregelungen) können RADAR-Sensor(en) 860, LIDAR-Sensor(en) 864 und/oder Kamera(s) verwenden. ACC-Systeme können eine Längs-ACC und/oder eine Quer-ACC umfassen. Die Längs-ACC überwacht und regelt den Abstand zum Fahrzeug unmittelbar vor dem Fahrzeug 800 und passt die Geschwindigkeit automatisch an, um einen sicheren Abstand zum vorausfahrenden Fahrzeugen einzuhalten. Die Quer-ACC führt eine Abstandshaltung durch und weist das Fahrzeug 800 an, die Spur zu wechseln, wenn dies erforderlich ist. Die Quer-ACC ist mit anderen ADAS-Anwendungen wie z.B. LCA und CWS verwandt.
  • CACC verwendet Information von anderen Fahrzeugen, die über die Netzschnittstelle 824 und/oder die Funkantenne(n) 826 über eine drahtlose Verbindung von anderen Fahrzeugen oder indirekt über eine Netzwerkverbindung (z. B. über das Internet) empfangen werden können. Direkte Verbindungen können durch eine Fahrzeug-Fahrzeug-Kommunikationsverbindung (V2V) hergestellt werden, während indirekte Verbindungen durch eine Infrastruktur-Fahrzeug-Kommunikationsverbindung (I2V) hergestellt werden können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Information über unmittelbar vorausfahrende Fahrzeuge (z. B. Fahrzeuge unmittelbar vor und auf derselben Fahrspur wie das Fahrzeug 800), während das I2V-Kommunikationskonzept Information über den weiter davor liegenden Verkehr liefert. CACC-Systeme können sowohl I2V- als auch V2V-Informationsquellen umfassen. Aufgrund der Information über Fahrzeuge vor dem Fahrzeug 800 kann CACC zuverlässiger sein und hat das Potenzial, den Verkehrsfluss zu verbessern und Verkehrsstaus zu reduzieren.
  • FCW-Systeme sind dazu ausgelegt, den Fahrer vor einer Gefahr zu warnen, damit der Fahrer Korrekturmaßnahmen ergreifen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 860, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der mit einer Fahrer-Rückmeldung wie z. B. einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente elektrisch gekoppelt ist. FCW-Systeme können eine Warnung z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses ausgeben.
  • AEB-Systeme erkennen einen drohenden Aufprallunfall mit einem anderen Fahrzeug oder einem anderen Objekt und kann die Bremsen automatisch betätigen, wenn der Fahrer nicht innerhalb eines spezifizierten Zeit- oder Abstandsparameters korrigierend eingreift. AEB-Systeme können das AEB-System nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 860 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr erkennt, warnt es in der Regel zunächst den Fahrer, damit er korrigierend eingreift, um die Kollision zu vermeiden, und wenn der Fahrer nicht korrigierend eingreift, kann das AEB-System die Bremsen automatisch betätigen, um die Auswirkung der vorhergesagten Kollision zu verhindern oder wenigstens abzumildern. AEB-Systeme können Techniken wie eine dynamische Bremsunterstützung und/oder eine Bremsung bei einem bevorstehenden Aufprall (CIB) umfassen.
  • LDW-Systeme geben optische, akustische und/oder taktile Warnungen wie z. B. Lenkrad- oder Sitzvibrationen aus, um den Fahrer zu warnen, wenn das Fahrzeug 800 Fahrbahnmarkierungen überquert. Ein LDW-System wird nicht aktiviert, wenn der Fahrer durch Betätigen des Blinkers ein beabsichtigtes Verlassen der Fahrspur anzeigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der mit einer Fahrer-Rückmeldung wie z. B. einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente elektrisch gekoppelt ist.
  • LKA-Systeme sind eine Variante von LDW-Systemen. LKA-Systeme korrigieren das Fahrzeug 800 durch Lenkeingriffe oder Bremsen, wenn das Fahrzeug 800 beginnt, die Fahrspur zu verlassen.
  • BSW-Systeme detektieren und warnen den Fahrer vor Fahrzeugen im toten Winkel eines Fahrzeugs. BSW-Systeme können eine optische, akustische und/oder taktile Warnung ausgeben, um darauf hinzuweisen, dass das Einordnen in oder das Wechseln von Fahrspuren unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker betätigt. BSW-Systeme können nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 860 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der mit einer Fahrer-Rückmeldung wie z. B. einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente elektrisch gekoppelt ist.
  • RCTW-Systeme können eine optische, akustische und/oder taktile Meldung ausgeben, wenn beim Rückwärtsfahren des Fahrzeugs 800 ein außerhalb der Reichweite der Heckkamera legendes Objekt detektiert wird. Einige RCTW-Systeme umfassen ein automatisches Notbremssystem (AEB), um sicherzustellten, dass Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensor(en) 860 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der mit einer Fahrer-Rückmeldung wie z. B. einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente elektrisch gekoppelt ist.
  • Herkömmliche ADAS-Systeme können zu falsch positiven Ergebnissen neigen, die für den Fahrer zwar ärgerlich und ablenkend, in der Regel jedoch nicht katastrophal sind, da herkömmliche ADAS-Systeme den Fahrer warnen und ihm die Möglichkeit geben, zu entscheiden, ob eine Sicherheitsbedingung tatsächlich vorliegt, und entsprechend zu handeln. Doch bei einem autonomen Fahrzeug 800 muss das Fahrzeug 800 im Falle widersprüchlicher Ergebnisse selbst entscheiden, ob das Ergebnis eines Primärrechners oder eines Sekundärrechners (z. B. des ersten Controllers 836 oder des zweiten Controllers 836) zu beachten ist. In einigen Ausführungsformen kann das ADAS-System 838 zum Beispiel ein Backup- und/oder Sekundärcomputer sein, der einem Backup-Computer-Rationalitätsmodul Perzeptionsinformation bereitstellt. Der Backup-Computer-Rationalitätsmonitor kann auf Hardware-Komponenten eine redundante diverse Software ausführen, um Fehler in der Perzeption und in dynamischen Fahraufgaben zu detektieren. Ausgaben des ADAS-Systems 838 können an eine überwachende MCU weitergeleitet werden. Wenn Ausgaben vom Primärrechner und Sekundärrechner widersprüchlich sind, muss die überwachende MCU bestimmen, wie der Konflikt zu lösen ist, um einen sicheren Betrieb zu gewährleisten.
  • In einigen Beispielen kann der Primärcomputer dazu konfiguriert sein, der überwachenden MCU einen Konfidenzwert bereitzustellen, der das Vertrauen des Primärcomputers in das gewählte Ergebnis angibt. Wenn der Konfidenzwert einen Schwellenwert übersteigt, kann die überwachende MCU unabhängig davon, ob der Sekundärcomputer ein widersprüchliches oder inkonsistentes Ergebnis ausgibt, der Anweisung des Primärcomputers folgen. Wenn der Konfidenzwert den Schwellenwert nicht erreicht und der Primär- und Sekundärcomputer unterschiedliche Ergebnisse angeben (z. B. bei einem Konflikt), kann die überwachende MCU zwischen den Computern arbitrieren, um das geeignete Ergebnis zu bestimmen.
  • Die überwachende MCU kann dazu konfiguriert sein, ein oder mehrere neuronale Netze auszuführen, die dazu trainiert und konfiguriert sind, auf der Basis der Ausgaben des Primärcomputers und des Sekundärcomputers Bedingungen zu bestimmen, unter welchen der Sekundärcomputer Fehlalarme ausgibt. Dadurch können neuronale Netze in der überwachenden MCU lernen, wann die Ausgabe des Sekundärcomputers vertrauenswürdig ist, und wann nicht. Wenn der Sekundärcomputer zum Beispiel ein RADAR-basiertes FCW-System ist, können neuronale Netze in der übergeordneten MCU lernen, wann das FCW-System metallische Objekte identifiziert, die tatsächlich keine Gefahr darstellen, wie z. B. ein Abflussgitter oder ein Gullydeckel, die einen Alarm auslösen. Wenn der Sekundärcomputer ein kamerabasiertes LDW-System ist, kann ein neuronales Netz dementsprechend in der überwachenden MCU lernen, das LDW-System zu übersteuern, wenn Radfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, die neuronale Netze umfassen, die auf der überwachenden MCU laufen, kann die überwachende MCU mindestens einen DLA oder eine GPU mit zugehörigem Speicher umfassen, die zur Ausführung der neuronalen Netze geeignet sind. In bevorzugten Ausführungsformen kann die überwachende MCU eine Komponente der SoC(s) 804 umfassen und/oder als solche enthalten sein.
  • In anderen Beispielen kann das ADAS-System 838 einen Sekundärcomputer umfassen, der ADAS-Funktionalitäten mit herkömmlichen Regeln der Computer-Vision durchführt. Der Sekundärcomputer kann klassische Computer-Vision-Regeln (wenn-dann) verwenden, und das Vorhandensein von neuronalen Netzen in der überwachenden MCU kann die Zuverlässigkeit, Sicherheit und Leistung erhöhen. Zum Beispiel machen unterschiedliche Implementierung und die absichtliche Ungleichheit das Gesamtsystem fehlertoleranter insbesondere gegenüber Fehlern, die durch die Software (oder Software-Hardware-Schnittstellen)-Funktionalität verursacht werden. Wenn zum Beispiel in der auf dem Primärcomputer laufenden Software ein Softwarefehler auftritt und der nicht identische Softwarecode auf dem Sekundärcomputer dasselbe Gesamtergebnis liefert, kann die überwachende MCU mit größerer Sicherheit davon ausgehen, dass das Gesamtergebnis korrekt ist und der Fehler in der Software oder Hardware des Primärcomputers keinen wesentlichen Fehler verursacht.
  • In einigen Beispielen kann die Ausgabe des ADAS-Systems 838 in den Perzeptionsblock des Primärrechners und/oder in den dynamische Fahraufgaben-Block des Primärrechners eingegeben werden. Wenn das ADAS-System 838 zum Beispiel aufgrund eines unmittelbar vorausfahrenden Objekts eine Aufprallunfall-Warnung anzeigt, kann der Perzeptionsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der Sekundärcomputer über ein eigenes neuronales Netz verfügen, das trainiert ist und daher das Risiko von falschen Positiven (Fehlalarmen), wie hier beschrieben, reduziert.
  • Das Fahrzeug 800 kann außerdem das Infotainment-SoC 830 (z. B. ein bordeigenes Infotainment-System (IVI)) umfassen. Auch wenn es als SoC dargestellt und beschrieben wird, kann das Infotainment-System kein SoC sein und kann zwei oder mehr diskrete Komponenten umfassen. Das Infotainment-SoC 830 kann eine Kombination aus Hardware und Software umfassen, die verwendet werden kann, um dem Fahrzeug 800 Audio- (z. B. Musik, einen PDA, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon- (z. B. Freisprecheinrichtung), Netzwerkkonnektivität (z. B. LTE, WiFi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Einparkhilfe, ein Datenfunksystem, fahrzeugbezogene Information wie z.B. Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremsflüssigkeitsstand, Ölstand, Tür öffnen/schließen, Luftfilterinformation usw.) bereitzustellen. Zum Beispiel kann das Infotainment-SoC 830 Radios, CD-Player, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Lenkrad-Audiosteuerung, Freisprecheinrichtung, ein Heads-up-Display (HUD), ein HMI-Display 834, ein Telematikgerät, ein Bedienfeld (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten umfassen. Das Infotainment-SoC 830 kann außerdem verwendet werden, um Benutzern des Fahrzeugs Information (z. B. optisch und/oder akustisch) wie z. B. Information vom ADAS-System 838, autonome Fahrinformation wie z.B. geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformation (z. B. Kreuzungsinformation, Fahrzeuginformation, Straßeninformation usw.) und/oder andere Information bereitzustellen.
  • Das Infotainment-SoC 830 kann GPU-Funktionalität umfassen. Das Infotainment-SoC 830 kann über den Bus 802 (z. B. CAN-Bus, Ethernet usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 800 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 830 mit einer überwachenden MCU gekoppelt sein, sodass die GPU des Infotainment-Systems einige Selbstfahrfunktionen durchführen kann, falls Primärsteuereinheit(en) 836 (z. B. der Primär- und/oder Backup-Computer des Fahrzeugs 800) ausfallen. In solch einem Beispiel kann das Infotainment-SoC 830 das Fahrzeug 800 in einen Haltemodus versetzen, wie hier beschrieben.
  • Das Fahrzeug 800 kann außerdem ein Kombi-Instrument 832 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombi-Instrument, eine digitale Instrumententafel usw.) umfassen. Das Kombi-Instrument 832 kann einen Controller und/oder einen Supercomputer (z. B. einen diskreten Controller oder Supercomputer) umfassen. Das Kombi-Instrument 832 kann eine beliebige Anzahl und Kombination von Instrumenten wie z.B. Tachometer, Kraftstoffstandsanzeige, Öldruckanzeige, Drehzahlmesser, Kilometerzähler, Blinker, Schaltstellungsanzeige, Sicherheitsgurtwarnleuchte(n), Parkbremswarnleuchte(n), Motorfehlfunktionsleuchte(n), Airbagsystem (SRS)-Information, Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformation usw. umfassen. In einigen Beispielen kann Information angezeigt und/oder zwischen dem Infotainment SoC 830 und dem Kombi-Instrument 832 ausgetauscht werden. Mit anderen Worten, das Kombi-Instrument 832 kann Teil des Infotainment-SoC 830 enthalten sein, oder umgekehrt.
  • 8D ist ein Systemdiagramm für die Kommunikation zwischen Cloud-basierten Servern und dem beispielhaften autonomen Fahrzeug 800 von 8A gemäß Ausführungsformen der vorliegenden Erfindung. Das System 876 kann Server 878, Netzwerke 890 und Fahrzeuge einschließlich des Fahrzeugs 800 umfassen. Die Server 878 können eine Vielzahl von GPUs 884(A)-884(H) (hier zusammenfassend als GPUs 884 bezeichnet), PCIe-Switches 882(A)-882(D) (hier zusammenfassend als PCIe-Switches 882 bezeichnet) und/oder CPUs 880(A)-880(B) (hier zusammenfassend als CPUs 880 bezeichnet) umfassen. Die GPUs 884, CPUs 880 und PCIe-Switches können mit Hochgeschwindigkeitsverbindungen wie z. B., ohne darauf beschränkt zu sein, den von NVIDIA entwickelten NVLink-Schnittstellen 888 und/oder PCIe-Verbindungen 886 miteinander verbunden sein. In einigen Beispielen sind die GPUs 884 über ein NVLink- und/oder NVSwitch-SoC verbunden, und die GPUs 884 und die PCIe-Switches 882 sind über PCIe-Verbindungen verbunden. Auch wenn acht GPUs 884, zwei CPUs 880 und zwei PCIe-Switches dargestellt sind, ist dies nicht einschränkend zu verstehen. Je nach Ausführungsform kann jeder der Server 878 eine beliebige Anzahl von GPUs 884, CPUs 880 und/oder PCIe-Switches umfassen. Zum Beispiel können die Server 878 acht, sechzehn, zweiunddreißig und/oder mehr GPUs 884 umfassen.
  • Die Server 878 können über Netzwerk(e) 890 und von den Fahrzeugen Bilddaten empfangen, die unerwartete oder veränderte Straßenzustände wie z. B. kürzlich begonnene Straßenbauarbeiten zeigen. Die Server 878 können über Netzwerk(e) 890 und an die Fahrzeuge neuronale Netze 892, aktualisierte neuronale Netze 892 und/oder Karteninformation 894 übertragen, einschließlich Information über den Verkehr und die Straßenbedingungen. Die Aktualisierungen der Karteninformation 894 können Aktualisierungen für eine HD-Karte 822 wie z. B. Information über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse umfassen. In einigen Beispielen können neuronale Netze 892, aktualisierte neuronale Netze 892 und/oder Karteninformation 894 aus neuem Training und/oder in Daten dargestellten Erfahrungen resultieren, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden und/oder auf Training basieren, das in einem Datenzentrum (z. B. unter Verwendung der Server 878 und/oder anderen Server) durchgeführt wurde.
  • Die Server 878 können verwendet werden, um Maschinenlernmodelle (z. B. neuronale Netze) auf der Basis von Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen und/oder in einer Simulation (z. B. mit einer Spiel-Engine) erzeugt werden. In einigen Beispielen sind die Trainingsdaten markiert (z. B., wenn das zugehörige neuronale Netz vom überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht markiert und/oder vorverarbeitet sind (z. B. wenn das neuronale Netz kein überwachtes Lernen erfordert). Das Training kann einer oder mehreren Klassen von Maschinenlerntechniken entsprechend durchgeführt werden, einschließlich, ohne darauf beschränkt zu sein, Klassen wie z. B.: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, Selbstlernen, bestärkendes Lernen, föderales Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraumlernen, vielfältiges Lernen, Repräsentationslernen (einschließlich Sparse Dictionary Learning), regelbasiertes Maschinenlernen, Anomalieerkennung und jede Variante oder Kombination daraus. Sobald die Maschinenlernmodelle trainiert sind, können die Maschinenlernmodelle von den Fahrzeugen verwendet werden (z. B. über Netzwerk(e) 890 zu den Fahrzeugen übertragen werden), und/oder Maschinenlernmodelle können von Server(n) 878 zur Fernüberwachung von Fahrzeugen verwendet werden.
  • In einigen Beispielen können Server 878 von Fahrzeugen Daten empfangen und die Daten für ein intelligentes Echtzeit-Inferencing in Echtzeit auf auf dem neusten Stand befindliche neuronale Netze anwenden. Die Server 878 können Deep-Learning-Supercomputer und/oder GPU 884-gestützte dedizierte KI-Computer umfassen, wie z. B. die von NVIDIA entwickelten DGX- und DGX Station-Maschinen. In einigen Beispielen können die Server 878 jedoch eine Deep-Learning-Infrastruktur umfassen, die nur CPU-gestützte Rechenzentren verwendet.
  • Die Deep-Learning-Infrastruktur der Server 878 kann in der Lage sein, das Inferencing schnell und in Echtzeit durchzuführen, und diese Fähigkeit nutzen, um den Zustand von Prozessoren, Software und/oder zugehöriger Hardware im Fahrzeug 800 zu evaluieren und zu überprüfen. Zum Beispiel kann die Deep-Learning-Infrastruktur in mindestens einer Ausführungsform periodische Aktualisierungen vom Fahrzeug 800 empfangen, wie z. B. eine Bilderfolge und/oder Objekte, die das Fahrzeug 800 in dieser Bilderfolge lokalisiert hat (z. B. über Computer-Vision und/oder andere Maschinenlern-Objektklassifizierungstechniken). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netz ausführen, um Objekte zu identifizieren und sie mit den vom Fahrzeug 800 identifizierten Objekten zu vergleichen, und wenn die Ergebnisse nicht übereinstimmen und die Deep-Learning-Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 800 eine Fehlfunktion aufweist, kann der Server 878 ein Signal zum Fahrzeug 800 senden, das einen ausfallsicheren Computer des Fahrzeugs 800 anweist, die Steuerung zu übernehmen, die Fahrzeuginsassen zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
  • Für das Inferencing können die Server 878 GPU(s) 884 und einen oder mehrere programmierbare Inferencing-Beschleuniger (z. B. TensorRT von NVIDIA) umfassen. Die Kombination von GPU-gestützten Servern und Inferencing-Beschleunigung kann ein Echtzeit-Antwortverhalten ermöglichen. In anderen Beispielen wie z. B., wenn die Leistung z. B. weniger kritisch ist, können für das Inferencing auch durch CPU-gestützte, FPGA-gestützte und durch andere Prozessoren gestützte Server verwendet werden.
  • BEISPIELHAFTE RECHENEINHEIT
  • 9 ist ein Blockdiagramm einer beispielhaften Recheneinheit 900, die zur Verwendung in Ausführungsformen der vorliegenden Erfindung geeignet ist. Die Recheneinheit 900 kann ein Verbindungssystem 902 umfassen, das die folgenden Geräte direkt oder indirekt miteinander verbindet: Speicher 904, eine oder mehrere Zentraleinheiten (CPUs) 906, eine oder mehrere Grafikprozessoren (GPUs) 908, eine Kommunikationsschnittstelle 910, Ein-/Ausgabe (E/A)-Anschlüsse 912, Ein-/Ausgabekomponenten 914, eine Stromversorgung 916, eine oder mehrere Darstellungskomponenten 918 (z. B. Display(s)) und eine oder mehrere Logikeinheiten 920. In mindestens einer Ausführungsform können Recheneinheit(en) 900 eine oder mehrere virtuelle Maschinen (VMs) umfassen, und/oder jede ihrer Komponenten kann virtuelle Komponenten (z. B. virtuelle Hardwarekomponenten) umfassen. Als nicht einschränkende Beispiele können eine oder mehrere der GPUs 908 eine oder mehrere vGPUs umfassen, eine oder mehrere der CPUs 906 können eine oder mehrere vCPUs umfassen und/oder eine oder mehrere der Logikeinheiten 920 können eine oder mehrere virtuelle Logikeinheiten umfassen. Als solche können Recheneinheiten 900 diskrete Komponenten (z. B. eine volle GPU, die der Recheneinheit 900 fest zugeordnet ist), virtuelle Komponenten (z. B. ein Teil einer GPU, die der Recheneinheit 900 fest zugeordnet ist) oder eine Kombination daraus umfassen.
  • Obwohl die verschiedenen Blöcke in 9 als über das Verbindungssystem 902 mit Leitungen verbunden dargestellt sind, ist dies nicht einschränkend zu verstehen und dient nur der Klarheit. In einigen Ausführungsformen kann beispielsweise eine Darstellungskomponente 918 wie z. B. ein Anzeigegerät, als E/A-Komponente 914 betrachtet werden (z. B., wenn die Anzeige ein Berührungsbildschirm ist). Als weiteres Beispiel können die CPUs 906 und/oder GPUs 908 Speicher enthalten (z. B. kann der Speicher 904 ein Speichergerät zusätzlich zum Speicher der GPUs 908, der CPUs 906 und/oder anderer Komponenten darstellen). Mit anderen Worten, die Recheneinheit von 9 ist lediglich beispielhaft. Zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablett“, „Client-Gerät“, „mobiles Gerät“, „Handgerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen wird nicht unterschieden, da sie alle als im Umfang der Recheneinheit von 9 liegend betrachtet werden.
  • Das Verbindungssystem 902 kann eine oder mehrere Verbindungen oder Busse darstellen, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination daraus. Das Verbindungssystem 902 kann einen oder mehrere Bus- oder Link-Typen umfassen, z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder einen anderen Bus- oder Link-Typ. In einigen Ausführungsformen bestehen zwischen Komponenten direkte Verbindungen. Zum Beispiel kann die CPU 906 direkt mit dem Speicher 904 verbunden sein. Außerdem kann die CPU 906 direkt mit der GPU 908 verbunden sein. Bei einer direkten oder Punkt-zu-Punkt-Verbindung zwischen Komponenten kann das Verbindungssystem 902 einen PCIe-Link zur Herstellung der Verbindung enthalten. In diesen Beispielen muss in der Recheneinheit 900 kein PCI-Bus enthalten sein.
  • Der Speicher 904 kann verschiedene computerlesbare Medien umfassen. Computerlesbare Medien können jedes verfügbare Medium sein, auf welches die Recheneinheit 900 zugreifen kann. Computerlesbare Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entnehmbare und nicht entnehmbare Datenträger einschließen. Als nicht einschränkendes Beispiel können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
  • Computer-Speichermedien können sowohl flüchtige als nicht flüchtige und/oder entnehmbare als auch nicht entnehmbare Datenträger einschließen, die in einem Verfahren oder einer Technologie zur Speicherung von Information wie z. B. computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Datentypen implementiert werden. Zum Beispiel kann der Speicher 904 computerlesbare Anweisungen speichern (z. B. solche, die ein oder mehrere Programme und/oder ein oder mehrere Programmelemente darstellen, wie z. B. ein Betriebssystem). Computer-Speichermedien können, ohne darauf beschränkt zu sein, einen RAM, ROM, EEPROM, Flash-Speicher oder eine andere Speichertechnologie, eine CD-ROM, DVD oder einen anderen optischen Speicher, Magnetbandkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichergeräte oder jedes andere Medium einschließen, das verwendet werden kann, um die gewünschte Information zu speichern, und auf welches die Recheneinheit 900 zugreifen kann. Wie hier verwendet, umfassen Computerspeichermedien keine Signale an sich.
  • Die Computerspeichermedien können typischerweise computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder andere Datentypen in einem modulierten Datensignal wie z. B. einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und schließen jedes Informationsbereitstellungsmedium ein. Der Term „moduliertes Datensignal“ bedeutet ein Signal, das eine oder mehrere Eigenschaften aufweist, die eingestellt oder verändert werden, um Information in das Signal zu codieren. Zum Beispiel, ohne darauf beschränkt zu sein, können Computerspeichermedien drahtgebundene Medien wie z. B. ein verdrahtetes Netzwerk oder eine direkt verdrahtete Verbindung und drahtlose Medien wie z. B. akustische, HF-, Infrarot- und andere drahtlose Medien umfassen. Kombinationen aus den obigen Medien fallen ebenfalls in den Umfang computerlesbarer Medien.
  • Die CPU(s) 906 können dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponente(n) der Recheneinheit 900 auszuführen, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 906 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) 906 können jeden beliebigen Prozessortyp umfassen und je nach Art der implementierten Recheneinheit 900 unterschiedliche Prozessortypen enthalten (z. B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Je nach Art der Recheneinheit 900 kann der Prozessor zum Beispiel ein Advanced RISC Machines (ARM)-Prozessor sein, der mit Reduced Instruction Set Computing (RISC) arbeitet, oder ein x86-Prozessor, der mit Complex Instruction Set Computing (CISC) arbeitet. Die Recheneinheit 900 kann eine oder mehrere CPUs 906 zusätzlich zu einem oder mehreren Mikroprozessoren) oder zusätzlichen Koprozessoren wie z. B. arithmetische Coprozessoren umfassen.
  • Zusätzlich zu oder alternativ zu CPU(s) 906 können GPU(s) 908 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten der Recheneinheit 900 ausführen, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere GPU(s) 908 können eine integrierte GPU sein (z. B. mit einer oder mehreren der CPU(s) 906) und/oder eine oder mehrere GPU(s) 908 können eine diskrete GPU sein. In Ausführungsformen können eine oder mehrere GPU(s) 908 ein Koprozessor einer oder mehrerer CPU(s) 906 sein. GPU(s) 908 können von der Recheneinheit 900 zur Grafikausgabe (z. B. 3D-Grafiken) oder zur Durchführung allgemeiner Berechnungen verwendet werden. GPU(s) 908 können zum Beispiel für allgemeine Berechnungen in GPUs (GPGPU) verwendet werden. GPU(s) 908 können Hunderte oder Tausende von Kernen umfassen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. GPU(s) 908 können in Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von CPU(s) 906, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. GPU(s) 908 können Grafikspeicher wie z. B. einen Anzeigespeicher zum Speichern von Pixeldaten oder anderen geeigneten Daten wie z. B. GPGPU-Daten umfassen. Der Anzeigespeicher kann als Teil des Speichers 904 enthalten sein. GPU(s) 908 können zwei oder mehr GPUs umfassen, die (z. B. über eine Link) parallel arbeiten. Der Link kann GPUs direkt (z. B. mit NVLINK) verbinden oder über einen Schalter (z. B. mit NVSwitch) verbinden. In Kombination miteinander kann jede GPU 908 Pixeldaten oder jede GPGPU Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben erzeugen (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher haben oder den Speicher gemeinsam mit anderen GPUs benutzen.
  • Zusätzlich zu oder alternativ zu CPU(s) 906 und/oder GPU(s) 908 können Logikeinheit(en) 920 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen zur Steuerung einer oder mehrerer Komponenten der Recheneinheit 900 auszuführen, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsformen können CPU(s) 906, GPU(s) 908 und/oder Logikeinheit(en) 920 einzeln oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon durchführen. Eine oder mehrere der Logikeinheiten 920 können in einer oder mehreren CPU(s) 906 und/oder GPU(s) 908 integriert sein und/oder eine oder mehrere der Logikeinheiten 920 können Einzelkomponenten sein oder auf andere Weise außerhalb der CPU(s) 906 und/oder der GPU(s) 908 liegen. In Ausführungsformen können eine oder mehrere der Logikeinheiten 920 ein Koprozessor einer oder mehrerer CPU(s) 906 und/oder einer oder mehrerer GPU(s) 908 sein.
  • Beispiele für Logikeinheit(en) 920 schließen einen oder mehrere Rechenkerne und/oder Komponenten davon wie z. B. Tensor-Kerne (TCs), Tensor-Verarbeitungseinheiten (TPUs), Pixel Visual Cores (PVCs), Vision-Verarbeitungseinheiten (VPUs), Grafik-Verarbeitungscluster (GPCs), Textur-Verarbeitungscluster (TPCs), Streaming-Multiprocezessoren (SMs), Tree Traversal Units (TTUs), KI-Beschleuniger (AIAs), Deep Learning- Beschleuniger (DLAs), arithmetische Logikeinheiten (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 ein.
  • Die Kommunikationsschnittstelle 910 kann einen oder mehrere Empfänger, Sender und/oder Sender-Empfänger einschließen, die es der Recheneinheit 900 ermöglichen, über ein elektronisches Kommunikationsnetzwerk einschließlich drahtgebundener und/oder drahtloser Kommunikation mit anderen Recheneinheiten zu kommunizieren. Die Kommunikationsschnittstelle 910 kann Komponenten und Funktionen einschließen, die die Kommunikation über eine Anzahl verschiedener Netzwerke wie z. B. drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Low-Power-Weitverkehrsnetze (z. B. LoRaWAN, SigFox usw.) und/oder das Internet ermöglichen.
  • Die E/A-Anschlüsse 912 ermöglichen es der Recheneinheit 900, logisch mit anderen Geräten einschließlich E/A-Komponenten 914, Darstellungskomponente(n) 918 und/oder anderer Komponenten, von denen einige in der Recheneinheit 900 eingebaut (z. B. darin integriert) sein können, gekoppelt zu werden. Beispielhafte E/A-Komponenten 914 schließen ein Mikrofon, eine Maus, eine Tastatur, ein Joystick, ein Gamepad, einen Game-Controller, eine Satellitenschüssel, ein Scanner, ein Drucker, ein drahtloses Gerät usw. ein. Die E/A-Komponenten 914 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben eines Benutzers verarbeitet. In manchen Fällen können die Eingaben zur Weiterverarbeitung an ein geeignetes Netzelement ü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 weiter unten ausführlicher beschrieben) im Zusammenhang mit einer Anzeige der Recheneinheit 900 implementieren. Die Recheneinheit 900 kann Tiefenkameras wie z. B. stereoskopische Kamerasysteme, Infrarot-Kamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon zur Gestendetektion und -erkennung und -steuerung. Zusätzlich kann die Recheneinheit 900 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) einschließen, die die Detektion von Bewegungen ermöglichen. In manchen Beispielen kann die Ausgabe von Beschleunigungsmessern oder Gyroskopen von der Recheneinheit 900 verwendet werden, um immersive erweiterte Realität oder virtuelle Realität zu rendern.
  • Die Stromversorgung 916 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination daraus sein. Die Stromversorgung 916 kann die Recheneinheit 900 mit Strom versorgen, um den Betrieb der Komponenten der Recheneinheit 900 zu ermöglichen.
  • Die Darstellungskomponente(n) 918 können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Head-up-Display (HUD), andere Arten von Anzeigen oder eine Kombination daraus), Lautsprecher und/oder andere Darstellungskomponenten umfassen. Die Darstellungskomponente(n) 918 können Daten von anderen Komponenten (z. B. GPU(s) 908, CPU(s) 906 usw.) empfangen und die Daten (z. B. als Bild, Video, Ton usw.) ausgeben.
  • BEISPIELHAFTES DATENZENTRUM
  • 10 stellt ein beispielhaftes Datenzentrum 1000 dar, das in mindestens einer Ausführungsform der vorliegenden Erfindung verwendet werden kann. Das Datenzentrum 1000 kann eine Datenzentrumsinfrastrukturebene 1010, eine Framework-Ebene 1020, eine Softwareebene 1030 und/oder eine Anwendungsebene 1040 umfassen.
  • Wie in 10 dargestellt, kann die Datenzentrumsinfrastrukturebene 1010 einen Ressourcen-Orchestrator (Ressourcenverwalter) 1012, gruppierte Rechenressourcen 1014 und Knoten-Rechenressourcen („Knoten-RR“) 1016(1)-1016(N), umfassen, wobei „N“ eine beliebige positive Ganzzahl darstellt. In mindestens einer Ausführungsform können die Knoten-RR 1016(1)-1016(N), ohne darauf beschränkt zu sein, eine beliebige Anzahl von Zentraleinheiten („CPUs“) oder anderen Prozessoren (einschließlich Beschleunigern, feldprogrammierbaren Gate-Arrays (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Arbeitsspeicher (z. B., dynamischer Festwertspeicher), Speichergeräten (z. B. Festkörper- oder Plattenlaufwerke), Netzwerk-Eingabe-/Ausgabe (NW E/A")- Geräten, Netzwerk-Switches, virtuelle Maschinen („VMs“), Stromversorgungsmodulen und/oder Kühlmodulen usw. umfassen. In manchen Ausführungsformen können eine oder mehrere Knoten-RR unter den Knoten-RR 1016(1)-1016(N) einem Server entsprechen, der eine oder mehrere der obigen Rechenressourcen aufweist. Darüber hinaus können die Knoten-RR 1016(1)-10161(N) in manchen Ausführungsformen eine oder mehrere virtuelle Komponenten wie z. B. vGPUs, vCPUs und/oder dergleichen umfassen, und/oder eine oder mehrere der Knoten-RR 1016(1)-1016(N) können einer virtuellen Maschine (VM) entsprechen.
  • In mindestens einer Ausführungsform können gruppierte Computerressourcen 1014 separate Gruppierungen von Knoten-RR 1016 umfassen, die in einem oder mehreren Racks (nicht dargestellt) oder zahlreichen Racks in Datenzentren an verschiedenen geografischen Standorten (ebenfalls nicht dargestellt) untergebracht sind. Separate Gruppierungen von Knoten-RR 1016 innerhalb gruppierter Rechenressourcen 1014 können gruppierte Rechen-, Netzwerk- oder Speicher-Ressourcen umfassen, die dazu konfiguriert oder vorgesehen sein können, eine oder mehrere Arbeitslasten zu unterstützen. In mindestens einer Ausführungsform können mehrere Knoten-RR 1016, die CPUs, GPUs und/oder andere Prozessoren umfassen, in einem oder mehreren Racks gruppiert sein, um Rechenressourcen zur Unterstützung einer oder mehrerer Arbeitslasten bereitzustellen. Das oder die Racks können auch eine beliebige Anzahl von Stromversorgungsmodulen, Kühlmodulen und/oder Netzwerk-Switches in beliebiger Kombination umfassen.
  • Der Ressourcen-Orchestrator 1022 kann einen oder mehrere Knoten-RR 1016(1)-1016(N) und/oder gruppierte Rechenressourcen 1014 konfigurieren oder auf andere Weise steuern. In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 1022 ein Verwaltungsorgan für die Software-Design-Infrastruktur („SDI“) des Datenzentrums 1000 umfassen. Der Ressourcen-Orchestrator 1022 kann Hardware, Software oder einer Kombination daraus umfassen.
  • In mindestens einer Ausführungsform, wie in 10 gezeigt, kann die Framework-Ebene 1020 einen Job-Scheduler 1032, einen Konfigurationsmanager 1034, einen Ressourcenmanager 1036 und/oder ein verteiltes Dateisystem 1038 umfassen. Die Framework-Ebene 1020 kann ein System zur Unterstützung der Software 1032 der Softwareebene 1030 und/oder einer oder mehrerer Anwendung(en) 1042 der Anwendungsebene 1040 umfassen. Die Software 1032 oder die Anwendung(en) 1042 können webbasierte Dienstsoftware oder Anwendungen wie z. B. die umfassen, die Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. Die Framework-Ebene 1020 kann, ohne darauf beschränkt zu sein, ein freies und Open Source Software-Webapplikationsframework wie Apache SparkTM (im Folgenden „Spark“) sein, das zur Verarbeitung großer Datenmengen (z. B. „Big Data“) ein verteiltes Dateisystem 1038 verwenden kann. In mindestens einer Ausführungsform kann der Job Scheduler 1032 einen Spark-Treiber umfassen, um die Planung der Arbeitslasten, die von verschiedenen Ebenen des Datenzentrums 1000 unterstützt werden, zu erleichtern. Der Konfigurationsmanager 1034 kann in der Lage sein, verschiedene Ebenen wie die Softwareebene 1030 und die Framework-Ebene 1020 einschließlich Spark und des verteilten Dateisystems 1038 konfigurieren, um die Verarbeitung großer Datenmengen zu unterstützen. Der Ressourcenmanager 1036 kann in der Lage sein, gebündelte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 1038 und des Job Schedulers 1032 zugeordnet oder zugewiesen sind. In mindestens einer Ausführungsform können gebündelte oder gruppierte Computerressourcen gruppierte Computerressourcen 1014 auf der Infrastrukturebene 1010 des Datenzentrums umfassen. Der Ressourcenmanager 1036 kann sich mit dem Ressourcen-Orchestrator 1012 abstimmen, um diese zugeordneten oder zugewiesenen Computerressourcen zu verwalten.
  • IIn mindestens einer Ausführungsform kann die in der Softwareebene 1030 enthaltene Software 1032 Software umfassen, die von mindestens einem Teil der Knoten-RR 1016(1)-1016(N), der gruppierten Rechenressourcen 1014 und/oder des verteilten Dateisystems 1038 der Framework-Ebene 1020 verwendet wird. Eine oder mehrere Arten von Software können, ohne darauf beschränkt zu sein, Suchsoftware für Internet-Webseiten-, Scansoftware für E-Mail-Viren, Datenbanksoftware und Streamingsoftware für Videoinhalte umfassen.
  • In mindestens einer Ausführungsform können die in der Anwendungsebene 1040 enthaltenen Anwendung(en) 1042 eine oder mehrere Anwendungstypen umfassen, die mindestens von einem Teil der Knoten-RR 1016(1)-1016(N), der gruppierten Rechenressourcen 1014 und/oder des verteilten Dateisystem 1038 der Framework-Ebene 1020 verwendet werden. Die Anwendungstypen können, ohne darauf beschränkt zu sein, eine beliebige Zahl von Anwendungen umfassen, wie z. B. eine Genomik-Anwendung, Cognitive Computing, und eine Maschinenlern-Anwendung, einschließlich Trainings- oder Inferencing-Software, Maschinenlern-Framework-Software (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere Maschinenlern-Anwendungen, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden.
  • In mindestens einer Ausführungsform können der Konfigurationsmanager 1034, der Ressourcenmanager 1036 und der Ressourcen-Orchestrator 1012 auf der Basis einer beliebigen Menge und Art von Daten, die auf jede technisch machbare Weise erfasst werden, eine beliebige Anzahl und Art von selbstmodifizierenden Aktionen implementieren. Selbstmodifizierende Aktionen können einen Datenzentrumsbetreiber des Datenzentrums 1000 davon entbinden, möglicherweise schlechte Konfigurationsentscheidungen zu treffen, um nicht ausgelastete und/oder schlecht funktionierende Teile eines Datenzentrums zu vermeiden.
  • Das Datenzentrum 1000 kann Tools, Dienste, Software oder andere Ressourcen umfassen, um ein oder mehrere Maschinenlernmodelle zu trainieren oder Information unter Verwendung eines oder mehrerer Maschinenlernmodelle gemäß einer oder mehreren hier beschriebenen Ausführungsformen vorherzusagen oder zu inferieren. Zum Beispiel können ein oder mehrere Maschinenlernmodelle trainiert werden, indem unter Verwendung von Software und/oder Computerressourcen, die oben in Bezug auf das Datenzentrum 1000 beschrieben wurden, Gewichtungsparameter einer neuronalen Netzarchitektur berechnet werden. In mindestens einer Ausführungsform können trainierte oder eingesetzte Maschinenlernmodelle, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um unter Verwendung der oben in Bezug auf das Datenzentrum 1000 beschriebenen Ressourcen Information zu inferieren oder vorherzusagen, indem sie Gewichtungsparameter verwenden, die durch eine oder mehrere Trainingstechniken wie die hier beschriebenen berechnet wurden, ohne darauf beschränkt zu sein.
  • In mindestens einer Ausführungsform kann das Datenzentrum 1000 CPUs, anwendungsspezifische integrierte Schaltungen (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder Inferieren (Herleiten) unter Verwendung der oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der oben beschriebenen Software- und/oder Hardware-Ressourcen als Dienst konfiguriert sein, der es Benutzern ermöglicht, Information wie z. B. Bilderkennung, Spracherkennung oder andere KI-Dienste zu trainieren oder zu inferieren.
  • BEISPIELHAFTE NETZWERKUMGEBUNGEN
  • Netzwerkumgebungen, die zur Verwendung in der Implementierung von Ausführungsformen der Erfindung geeignet sind, können ein oder mehrere Client-Geräte, Server, Netzwerkspeicher (NAS), andere Backend-Geräte und/oder andere Gerätetypen umfassen. Client-Geräte, Server und/oder andere Gerätetypen (z. B. jedes Gerät) können in einer oder mehreren Instanzen der Recheneinheit(en) 900 von 9 implementiert sein - z. B. kann jedes Gerät gleiche Komponenten, Merkmale und/oder Funktionalitäten der Recheneinheit(en) 900 umfassen. Wenn Backend-Geräte (z. B. Server, NAS usw.) implementiert sind, können die Backend-Geräte außerdem Teil eines Datenzentrums 1000 sein, das hier Bezug nehmend auf 10 beispielhaft beschrieben wurde.
  • Die Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerk(e), die drahtgebunden, drahtlos oder beides sein können, miteinander kommunizieren. Das Netzwerk kann mehrere Netzwerke oder ein Netz von Netzwerken umfassen. Das Netzwerk kann beispielsweise ein oder mehrere Weitverkehrsnetze (WANs), ein oder mehrere lokale Netzwerke (LANs), ein oder mehrere öffentliche Netzwerke wie z. B. 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 z. B. eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) drahtlose Konnektivität bereitstellen.
  • Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebung(en) - in diesem Fall darf in einer Netzwerkumgebung kein Server enthalten sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall könnenin einer Netzwerkumgebung ein oder mehrere Server enthalten sein - umfassen. In Peer-to-Peer-Netzwerkumgebungen kann die Funktionalität, die hier in Bezug auf einen oder mehrere Server beschrieben wird, auf einer beliebigen Anzahl von Client-Geräten implementiert sein.
  • In mindestens einer Ausführungsform kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Rechenumgebung, eine Kombination daraus usw. umfassen. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Ebene, einen Job-Scheduler, einen Ressourcen-Manager und ein verteiltes Dateisystem umfassen, die auf einen oder mehreren Servern implementiert sind, welche einen oder mehrere Kernnetzserver und/oder Edge-Server umfassen können. Eine Framework-Ebene kann ein System zur Unterstützung der Software einer Softwareebene und/oder einer oder mehrerer Anwendungen einer Anwendungsebene umfassen. Die Software oder Anwendung(en) können auch webbasierte Dienst-Software oder -Anwendungen umfassen. In Ausführungsformen können ein oder mehrere Client-Geräte webbasierte Dienst-Software oder -Anwendungen nutzen (z. B., indem über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs) auf Dienst-Software und/oder -Anwendungen zugegriffen wird). Die Framework-Ebene kann, ohne darauf beschränkt zu sein, eine Art freies freies und Open Source Software-Webapplikationsframework wie z. B. eines sein, das ein verteiltes Dateisystem zur Verarbeitung großer Datenmengen (z. B. „Big Data“) verwendet.
  • Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination der hier beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) durchführen. Jede dieser verschiedenen Funktionen kann auf Zentral- oder Kernserver an mehreren Standorte verteilt sein (z. B. in eine, oder mehreren Datenzentren, die innerhalb eines Staats, einer Region, eines Lands, weltweit usw. verteilt sein können). Wenn eine Verbindung zu einem Benutzer (z. B. einem Client-Gerät) relativ nahe an Edge-Server(n) liegt, kann ein Kernserver einem Edge-Server mindestens einen Teil der Funktionalität 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 daraus (z. B. eine hybride Cloud-Umgebung) sein.
  • Client-Gerät(e) können mindestens einige der Komponenten, Merkmale und Funktionalitäten der beispielhaften Recheneinheit(en) 900 umfassen, die hier Bezug nehmend auf 9 beschrieben wurde. Ein Client-Gerät kann beispielsweise, ohne darauf beschränkt zu sein, als ein Personal Computer (PC), ein Laptop, ein mobiles Gerät, ein Smartphone, Tablet-Computer, eine intelligente Uhr, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein globales Positionsbestimmungssystem (GPS) oder GPS-Gerät, ein Videoplayer, eine Videokamera, ein Überwachungsgerät oder -system, ein Fahrzeug, ein Boot, ein fliegendes Wasserfahrzeug, eine virtuelle Maschine, eine Drohne, ein Roboter, ein tragbares Kommunikationsgerät, ein Klinikgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeugcomputersystem, einen Embedded-System-Controller, eine Fernbedienung, ein Zubehör, ein Unterhaltungselektronikgerät, eine Arbeitsstation, ein Edge-Gerät und eine beliebige Kombination dieser beschriebenen Geräte oder jedes andere geeignete Gerät ausgeführt sein.
  • Die Erfindung kann im allgemeinen Kontext von Computercode oder maschinenlesbaren Anweisungen, einschließlich computerausführbarer Anweisungen wie z. B. Programmmodule beschrieben werden, die von einem Computer oder einer anderen Maschine wie z. B. einem Personal Data Assistant (PDA) oder einem anderen Handheld-Gerät ausgeführt werden. Generell beziehen sich Programmmodule, die Routinen, Programme, Objekte, Komponenten, Strukturen, usw. einschließen, auf einen Code, der bestimmte Aufgaben durchführt oder bestimmte abstrakte Datentypen implementiert. Die Erfindung kann in einer Vielzahl von Systemkonfigurationen einschließlich Handheld-Geräten, Unterhaltungselektronik, Universalcomputern, Spezialcomputern usw. umgesetzt werden. Die Erfindung kann auch in verteilten Rechenumgebungen realisiert werden, in denen Aufgaben durch Fernverarbeitungseinheiten durchgeführt werden, die durch ein Kommunikationsnetzwerk miteinander verbunden sind.
  • Wenn hier zwei oder mehr Elemente durch „und/oder“ verbunden sind, ist dies als nur ein Element oder eine Kombination von Elementen aufzufassen. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C einschließen. Darüber hinaus kann „mindestens eines vom Element A oder vom Element B“ mindestens eines vom Element A, mindestens eines vom Element B oder mindestens eines vom Element A und mindestens eines vom Element B einschließen. Ferner kann „mindestens eines der Elemente A und vom Element B“ mindestens eines vom Element A, mindestens eines vom Element B oder mindestens eines vom Element A und mindestens eines vom Element B einschließen.
  • Der Gegenstand der vorliegenden Erfindung wird hier auf spezifische Weise beschrieben, um die gesetzlichen Anforderungen zu erfüllen. Die Beschreibung soll den Umfang dieser Erfindung jedoch nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise ausgeführt werden kann, um verschiedene Schritte oder Kombinationen von Schritten, die mit denen vergleichbar sind, die hier beschrieben wurden, in Verbindung mit anderen gegenwärtigen oder künftigen Technologien zu umfassen. Auch wenn hier die Begriffe „Schritt“ und/oder „Block“ verwendet wurden können, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sind die Begriffe nicht so zu interpretieren, dass sie eine bestimmte Reihenfolge unter oder zwischen verschiedenen hier offenbarten Schritten implizieren, es sei denn, die Reihenfolge von einzelnen Schritten wird explizit beschrieben.

Claims (20)

  1. Prozessor umfassend: einen oder mehrere Schaltkreise, um: ein Tiefenflussbild zu generieren, das für eine oder mehrere Änderungen in Tiefenwerten zwischen entsprechenden Pixeln von mindestens zwei aufeinanderfolgenden Abstandsbildern repräsentativ ist; durch einen Belief Propagation-Algorithmus Daten weiterzugeben, die einem oder mehreren benachbarten Pixeln des Tiefenflussbilds entsprechen, um einen oder mehrere Werte, die benachbarten Pixeln des Tiefenflussbilds zugeordnet sind, zu aktualisieren; mindestens zum Teil auf der Basis des oder der aktualisierten Werte einen oder mehrere Bewegungsvektoren im Bildraum zu berechnen, die der Bewegung des oder der benachbarten Pixel des Tiefenflussbilds zwischen den mindestens zwei aufeinanderfolgenden Abstandsbildern entsprechen; und durch Konvertieren des oder der Bewegungsvektoren in entsprechende Bewegungsvektoren im Weltraum eine Szenenflussdarstellung zu generieren.
  2. Prozessor nach Anspruch 1, wobei der Prozessor mindestens in einem enthalten ist von: einem Steuersystem für eine autonome oder halbautonome Maschine; einem Perzeptionssystem für eine autonome oder halbautonome Maschine; einem System zur Durchführung von Simulationsoperationen; einem System zur Durchführung von Deep-Learning-Operationen; einem System, das mit einem Edge-Gerät implementiert ist; einem System, das mit einem Roboter implementiert ist; einem System, das eine oder mehrere virtuelle Maschinen (VMs) integriert; einem System, das mindestens teilweise in einem Datenzentrum implementiert ist; oder einem System, das mindestens teilweise mit Cloud-Computing-Ressourcen implementiert ist.
  3. Prozessor nach Anspruch 1 oder 2, außerdem umfassend eine Verarbeitungsschaltung, um: mindestens zum Teil auf der Basis der Szenenflussdarstellung eine oder mehrere Positionen eines oder mehrerer Objekte zu bestimmen; und mindestens zum Teil auf der Basis der Positionen des oder der Objekte eine oder mehrere Operationen durchzuführen.
  4. Prozessor nach einem der vorherigen Ansprüche, außerdem umfassend Verarbeitungsschaltungen, um mindestens zum Teil auf der Basis des Szenenflusses eine oder mehrere Operationen durchzuführen.
  5. Prozessor nach einem der vorherigen Ansprüche, wobei die mindestens zwei aufeinanderfolgenden Abstandsbilder unter Verwendung entsprechender LiDAR-Punktwolken generiert werden.
  6. Prozessor nach einem der vorherigen Ansprüche, wobei, wenn bestimmt wird, dass ein Paar benachbarter Pixel nicht demselben Objekt entspricht, verhindert wird, dass diesem Paar benachbarter Pixel entsprechende Daten weitergegeben werden.
  7. Verfahren, umfassend: Generieren eines Tiefenflussbilds mindestens zum Teil auf der Basis eines ersten LiDAR-Abstandsbilds, das an einem ersten Zeitpunkt unter Verwendung eines oder mehrerer LiDAR-Sensoren generiert wurde, und eines zweiten LiDAR-Abstandsbilds, das an einem zweiten Zeitpunkt nach dem ersten Zeitpunkt unter Verwendung des oder der LiDAR-Sensoren generiert wurde, wobei das Tiefenflussbild ein oder mehrere Pixel enthält, die mit einem oder mehreren Tiefenflusswerten gekennzeichnet sind; Weitergeben von Daten, die mindestens einem Pixel von einem oder mehreren Pixeln des Tiefenflussbilds entsprechen, um ein aktualisiertes Tiefenflussbild zu generieren, wobei die weitergegebenen Daten mindestens zum Teil die jeweiligen Tiefenflusswerte des oder der Pixel und die jeweiligen Kosten des oder der Pixel angeben; und Berechnen, mindestens zum Teil auf der Basis des aktualisierten Tiefenflussbilds, eines oder mehrerer Bewegungsvektoren, die für relative Pixelpositionen zwischen dem ersten LiDAR-Abstandsbild und dem zweiten LiDAR-Abstandsbild repräsentativ sind.
  8. Verfahren nach Anspruch 7, wobei das erste LiDAR-Abstandsbild und das zweite LiDAR-Abstandsbild unter Verwendung von Daten generiert werden, die für eine oder mehrere LiDAR-Punktwolken repräsentativ sind.
  9. Verfahren nach Anspruch 7 oder 8, wobei das erste LiDAR-Abstandsbild mindestens zum Teil auf der Basis der berechneten Ego-Bewegung in dasselbe Koordinatensystem wie das zweite LiDAR-Abstandsbild konvertiert wird.
  10. Verfahren nach einem der Ansprüche 7 bis 9, wobei das erste LiDAR-Abstandsbild und das zweite LiDAR-Abstandsbild jeweils mindestens eines von Reflexionsinformation, Intensitätsinformation, Tiefeninformation, Time of Flight (ToF)-Information, Rücklaufinformation oder Klassifizierungsinformation darstellen.
  11. Verfahren nach einem der Ansprüche 7 bis 10, wobei der oder die Bewegungsvektoren im zweidimensionalen (2D) Raum berechnet werden und das Verfahren außerdem das Konvertieren des oder der Bewegungsvektoren in den 3D-Raum umfasst, um einen oder mehrere 3D-Bewegungsvektoren zu generieren.
  12. Verfahren nach Anspruch 11, wobei der oder die 3D-Bewegungsvektor(en) eine Szenenflussdarstellung zwischen dem ersten LiDAR-Abstandsbild und dem zweiten LiDAR-Abstandsbild darstellen.
  13. Verfahren nach einem der Ansprüche 7 bis 12, wobei die Daten, die mindestens einem Pixel von einem oder mehreren Pixeln entsprechen, durch einen Belief Propagation-Algorithmus weitergegeben werden.
  14. Verfahren nach Anspruch 13, wobei das Tiefenflussbild ein erstes Pixel enthält, das zu einem zweiten Pixel benachbart ist, und das Verfahren außerdem umfasst: Bestimmen, mindestens zum Teil auf der Basis von Tiefendaten aus den zweiten LiDAR-Daten, dass das erste Pixel einem zweiten Objekt entspricht, das sich von einem ersten Objekt unterscheidet, das dem zweiten Pixel entspricht; und Verhindern, mindestens zum Teil auf der Basis der Bestimmung, der Weitergabe von dem ersten Pixel entsprechenden Daten.
  15. System, umfassend: eine oder mehrere Verarbeitungseinheiten; und ein oder mehrere Speichereinheiten, die Anweisungen speichern, die, wenn sie durch die Verarbeitungseinheit(en) ausgeführt werden, die Verarbeitungseinheit(en) dazu veranlassen, Operationen auszuführen, die Folgendes umfassen: Generieren eines Tiefenflussbilds, das für eine oder mehrere Änderungen in Tiefenwerten zwischen entsprechenden Pixeln von mindestens zwei aufeinanderfolgenden Abstandsbildern repräsentativ ist; Weitergeben, durch einen Belief Propagation-Algorithmus, von Daten, die einem oder mehreren benachbarten Pixeln des Tiefenflussbilds entsprechen, um einen oder mehrere Werte, die benachbarten Pixeln des Tiefenflussbilds zugeordnet sind, zu aktualisieren; Berechnen, mindestens zum Teil auf der Basis des oder der aktualisierten Werte, eines oder mehrerer Bildraum-Bewegungsvektoren, die der Bewegung des einen oder der mehreren benachbarten Pixel des Tiefenflussbilds zwischen den mindestens zwei aufeinanderfolgenden Abstandsbildern entsprechen; und Konvertieren der Bildraum-Bewegungsvektoren in Weltraum-Bewegungsvektoren, um eine Szenenflussdarstellung zu generieren.
  16. System nach Anspruch 15, wobei das System mindestens in einem enthalten ist von: einem Steuersystem für eine autonome oder halbautonome Maschine; einem Perzeptionssystem für eine autonome oder halbautonome Maschine; einem System zur Durchführung von Simulationsoperationen; einem System zur Durchführung von Deep-Learning-Operationen; einem System, das mit einem Edge-Gerät implementiert ist; einem System, das mit einem Roboter implementiert ist; einem System, das eine oder mehrere virtuelle Maschinen (VMs) integriert; einem System, das mindestens teilweise in einem Datenzentrum implementiert ist; oder einem System, das mindestens teilweise mit Cloud-Computing-Ressourcen implementiert ist.
  17. System nach Anspruch 15 oder 16, wobei die Operationen außerdem umfassen: Bestimmen einer oder mehrerer Positionen eines oder mehrerer Objekte mindestens zum Teil auf der Basis der Szenenflussdarstellung; und Durchführen einer oder mehrerer Operationen mindestens zum Teil auf der Basis der Positionen des oder der Objekte.
  18. System nach einem der Ansprüche 15 bis 17, wobei die Operationen außerdem das Durchführen einer oder mehrerer Operationen mindestens zum Teil auf dem Basis des Szenenflusses umfassen.
  19. System nach einem der Ansprüche 15 bis 18, wobei die mindestens zwei aufeinanderfolgenden Abstandsbilder unter Verwendung entsprechender LiDAR-Punktwolken generiert werden.
  20. System nach einem der Ansprüche 15 bis 19, wobei, wenn bestimmt wird, dass ein Paar benachbarter Pixel nicht demselben Objekt entspricht, mindestens eine Nachricht daran gehindert wird, zwischen diesem Paar benachbarter Pixel weitergegeben zu werden.
DE102022118649.0A 2021-08-02 2022-07-26 Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen Pending DE102022118649A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/392,050 2021-08-02
US17/392,050 US11954914B2 (en) 2021-08-02 2021-08-02 Belief propagation for range image mapping in autonomous machine applications

Publications (1)

Publication Number Publication Date
DE102022118649A1 true DE102022118649A1 (de) 2023-02-02

Family

ID=84889707

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022118649.0A Pending DE102022118649A1 (de) 2021-08-02 2022-07-26 Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen

Country Status (4)

Country Link
US (1) US11954914B2 (de)
JP (1) JP2023021910A (de)
CN (1) CN115701623A (de)
DE (1) DE102022118649A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023037446A (ja) * 2021-09-03 2023-03-15 日本電気株式会社 無線受信装置及びその方法
CN116295158B (zh) * 2023-05-17 2023-08-08 四川华恒升科技发展有限公司 一种基于机载双频测深仪测量淤泥深度的仪器及方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6462692B2 (ja) * 2014-07-25 2019-01-30 株式会社日立製作所 自律移動装置
US9811732B2 (en) * 2015-03-12 2017-11-07 Qualcomm Incorporated Systems and methods for object tracking
US10444759B2 (en) * 2017-06-14 2019-10-15 Zoox, Inc. Voxel based ground plane estimation and object segmentation
US10929987B2 (en) * 2017-08-16 2021-02-23 Nvidia Corporation Learning rigidity of dynamic scenes for three-dimensional scene flow estimation
US10885698B2 (en) * 2018-08-10 2021-01-05 Nvidia Corporation Method for programmable timeouts of tree traversal mechanisms in hardware
JP7029479B2 (ja) * 2019-01-30 2022-03-03 バイドゥ ドットコム タイムス テクノロジー （ベイジン） カンパニー リミテッド 自動運転車のためのポイントクラウドゴースト効果検出システム
US20200256999A1 (en) * 2019-02-07 2020-08-13 Atulya Yellepeddi Lidar techniques for autonomous vehicles
US10812745B2 (en) * 2019-03-14 2020-10-20 Luminar Technologies, Inc. Bit depth reduction of image pixels
US11275673B1 (en) * 2019-06-24 2022-03-15 Zoox, Inc. Simulated LiDAR data
WO2021005609A1 (en) * 2019-07-09 2021-01-14 Shmuel Mangan Real-time motion tracking in moving scenes
WO2021010036A1 (ja) * 2019-07-18 2021-01-21 ソニーセミコンダクタソリューションズ株式会社 固体撮像素子、撮像装置および固体撮像素子の制御方法
US11613201B2 (en) * 2019-08-12 2023-03-28 Nvidia Corporation Automatic high beam control for autonomous machine applications
US20220351392A1 (en) * 2021-04-30 2022-11-03 Nvidia Corporation Object tracking using optical flow

Also Published As

Publication number Publication date
JP2023021910A (ja) 2023-02-14
CN115701623A (zh) 2023-02-10
US20230033470A1 (en) 2023-02-02
US11954914B2 (en) 2024-04-09

Similar Documents

Publication Publication Date Title
DE112021000135T5 (de) Sensorfusion für anwendungen autonomer maschinen durch maschinelles lernen
DE112020002602T5 (de) Multi-objektverfolgung mit hilfe von korrelationsfiltern in videoanalyseanwendungen
DE112020002166T5 (de) Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen
DE102021126254A1 (de) Überwachen der Aufmerksamkeit und der kognitiven Belastung der Insassen für autonome und halbautonome Fahranwendungen
DE112020006404T5 (de) Planung und steuerung von spurwechseln in autonomen maschinenapplikationen
DE112019006484T5 (de) Detektion von abständen zu hindernissen in autonomen maschinenanwendungen
DE102021121558A1 (de) Auf neuronalen netzen basierende bestimmung der blickrichtung unter verwendung räumlicher modelle
DE102020117792A1 (de) Wirksames einsetzen von hindernis- und spurerkennungen, um spurzuweisungen für objekte in einer umgebung zu bestimmen
DE102021123159A1 (de) Adaptiver objektverfolgungsalgorithmus für autonome maschinenanwendungen
DE112020001396T5 (de) Formfusion zur bildanalyse
DE102019113114A1 (de) Verhaltensgesteuerte wegplanung in autonomen maschinenanwendungen
DE112021001994T5 (de) Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen
DE102021129528A1 (de) Erkennung von Einsatzfahrzeugen für Anwendungen im Bereich des autonomen Fahrens
DE112020006181T5 (de) Blickbestimmung mit blendung als eingabe
DE102022121121A1 (de) Objektverfolgung unter Verwendung von LiDAR-Daten für autonome Maschinenanwendungen
DE112021000104T5 (de) Projizieren von mit fischaugenobjektiven aufgenommenen bildern zur merkmalserkennung in autonomen maschinenanwendungen
DE102022112748A1 (de) Verwendung von ankunftszeitpunkten und sicherheitsprozedurenin bewegungsplanungstrajektorien für autonome fahrzeuge
DE102022118649A1 (de) Belief Propagation für das Abstandsbild-Mapping in autonomen Maschinenanwendungen
DE102022104026A1 (de) Erzeugung von ground-truth-daten für die wahrnehmung durch tiefe neuronale netze in anwendungen für autonomes fahren
DE102022114516A1 (de) Spannungsüberwachung über mehrere-frequenzbereiche für autonome-maschine anwendungen
DE102020130749A1 (de) System zum maschinellen lernen zur blickbestimmung mit adaptiver gewichtung von eingaben
DE102020131353A1 (de) Auf einem neuronalen netz basierende gesichtsanalyse mittels gesichtslandmarken und zugehörigen vertrauenswerten
DE102022132478A1 (de) Blendungsminderung durch Bildkontrastanalyse für autonome Systeme und Anwendungen
DE102022124361A1 (de) Sichtweiteabschätzung unter verwendung von deep learning in autonomen maschinenanwendungen
DE102022114521A1 (de) Parallelverarbeitung einer zum einparken geeigneten fahrzeug-wegplanung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G01S0017580000

Ipc: G06V0020560000