DE112021004919T5 - Simulation von Blickpunkttransformationen für sensorunabhängiges Szenenverständnis in autonomen Systemen - Google Patents

Simulation von Blickpunkttransformationen für sensorunabhängiges Szenenverständnis in autonomen Systemen Download PDF

Info

Publication number
DE112021004919T5
DE112021004919T5 DE112021004919.4T DE112021004919T DE112021004919T5 DE 112021004919 T5 DE112021004919 T5 DE 112021004919T5 DE 112021004919 T DE112021004919 T DE 112021004919T DE 112021004919 T5 DE112021004919 T5 DE 112021004919T5
Authority
DE
Germany
Prior art keywords
camera
data
vehicle
interest
region
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
DE112021004919.4T
Other languages
English (en)
Inventor
Zongyi Yang
Mariusz Bojarski
Bernhard Firner
Urs Muller
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 DE112021004919T5 publication Critical patent/DE112021004919T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R1/00—Optical viewing arrangements; Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles
    • B60R1/20—Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles
    • B60R1/22—Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles for viewing an area outside the vehicle, e.g. the exterior of the vehicle
    • B60R1/23—Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles for viewing an area outside the vehicle, e.g. the exterior of the vehicle with a predetermined field of view
    • B60R1/24—Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles for viewing an area outside the vehicle, e.g. the exterior of the vehicle with a predetermined field of view in front of the vehicle
    • 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
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R1/00—Optical viewing arrangements; Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles
    • B60R1/20—Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles
    • B60R1/22—Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles for viewing an area outside the vehicle, e.g. the exterior of the vehicle
    • B60R1/28—Real-time viewing arrangements for drivers or passengers using optical image capturing systems, e.g. cameras or video systems specially adapted for use in or on vehicles for viewing an area outside the vehicle, e.g. the exterior of the vehicle with an adjustable field of view
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001—Planning or execution of driving tasks
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B13/00—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion
    • G05B13/02—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric
    • G05B13/0265—Adaptive control systems, i.e. systems automatically adjusting themselves to have a performance which is optimum according to some preassigned criterion electric the criterion being a learning criterion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/21—Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
    • G06F18/214—Generating training patterns; Bootstrap methods, e.g. bagging or boosting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/24—Classification techniques
    • G06F18/241—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches
    • G06F18/2413—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches based on distances to training or reference patterns
    • G06F18/24133—Distances to prototypes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/25—Fusion techniques
    • G06F18/251—Fusion techniques of input or preprocessed data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T3/00—Geometric image transformations in the plane of the image
    • G06T3/60—Rotation of whole images or parts thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T5/00—Image enhancement or restoration
    • G06T5/60—Image enhancement or restoration using machine learning, e.g. neural networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T5/00—Image enhancement or restoration
    • G06T5/80—Geometric correction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/10—Segmentation; Edge detection
    • G06T7/11—Region-based segmentation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/20—Image preprocessing
    • G06V10/25—Determination of region of interest [ROI] or a volume of interest [VOI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/70—Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/82—Arrangements for image or video recognition or understanding using pattern recognition or machine learning using neural networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/20—Image signal generators
    • H04N13/204—Image signal generators using stereoscopic image cameras
    • H04N13/239—Image signal generators using stereoscopic image cameras using two 2D image sensors having a relative position equal to or related to the interocular distance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
    • H04N23/60—Control of cameras or camera modules
    • H04N23/698—Control of cameras or camera modules for achieving an enlarged field of view, e.g. panoramic image capture
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R2300/00—Details of viewing arrangements using cameras and displays, specially adapted for use in a vehicle
    • B60R2300/30—Details of viewing arrangements using cameras and displays, specially adapted for use in a vehicle characterised by the type of image processing
    • B60R2300/306—Details of viewing arrangements using cameras and displays, specially adapted for use in a vehicle characterised by the type of image processing using a re-scaling of images
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0002—Automatic control, details of type of controller or control system architecture
    • B60W2050/0018—Method for the design of a control system
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0062—Adapting control system settings
    • B60W2050/0075—Automatic parameter input, automatic initialising or calibrating means
    • B60W2050/0083—Setting, resetting, calibration
    • B60W2050/0088—Adaptive recalibration
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2420/00—Indexing codes relating to the type of sensors based on the principle of their operation
    • B60W2420/40—Photo, light or radio wave sensitive means, e.g. infrared sensors
    • B60W2420/403—Image sensing, e.g. optical camera
    • 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/20—Special algorithmic details
    • G06T2207/20084—Artificial neural networks [ANN]
    • 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/20112—Image segmentation details
    • G06T2207/20132—Image cropping
    • 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/30241—Trajectory
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Evolutionary Biology (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Mechanical Engineering (AREA)
  • Medical Informatics (AREA)
  • Automation & Control Theory (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • General Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Image Analysis (AREA)
  • Image Processing (AREA)
  • Geometry (AREA)

Abstract

In verschiedenen Beispielen können Sensordaten, die zum Trainieren eines MI,M verwendet werden und/oder vom MI,M während des Einsatzes genutzt werden, von Sensoren mit unterschiedlichen Perspektiven (z. B. Sichtfeldern) erfasst werden. Die Sensordaten können transformiert werden - um transformierte Sensordaten zu erzeugen -, beispielsweise durch Ändern oder Entfernen von Objektivverzeichnungen, Verschieben und/oder Drehen von Bildern, die den Sensordaten entsprechen, in ein Sichtfeld eines anderen physikalischen oder virtuellen Sensors. So kann das MLM mit Sensordaten trainiert und/oder eingesetzt werden, die aus einem gleichen oder ähnlichen Sichtfeld erfasst wurden. Folglich kann das MI,M trainiert und/oder eingesetzt werden, - über eine beliebige Anzahl unterschiedlicher Fahrzeuge mit Kameras und/oder anderen Sensoren mit unterschiedlichen Perspektiven - unter Verwendung von Sensordaten, die aus derselben Perspektive wie der Referenz- oder Idealsensor stammen.

Description

  • Hintergrund der Erfindung
  • Die Entwicklung eines Systems zum autonomen Fahren eines Fahrzeugs ohne Aufsicht auf einem für die praktische Akzeptanz erforderlichen Sicherheitsniveau ist äußerst schwierig. Ein autonomes Fahrzeug sollte zumindest in der Lage sein, das funktionale Äquivalent eines aufmerksamen Fahrers zu sein, der auf ein Wahrnehmungs- und Handlungssystem zurückgreift, das die unglaubliche Fähigkeit besitzt, bewegliche und statische Hindernisse in einer komplexen Umgebung zu erkennen und darauf zu reagieren, um Kollisionen mit anderen Objekten oder Strukturen auf seinem Weg zu vermeiden. Die Wahrnehmung eines autonomen Fahrzeugs kann mithilfe von Algorithmen für das Sehen und Verstehen von Szenen erfolgen, die auf der Anwendung von Bildern, die von einer Kamera des Fahrzeugs aufgenommen wurden, auf ein Faltungsneuronales Netz (CNN) beruhen. Die Genauigkeit der Wahrnehmung verschlechtert sich, wenn Kameramerkmale wie Kamerastandort, Ausrichtung, Sichtfeld oder Objektivverzeichnung von den Werten der Kamera abweichen, die zum Trainieren des neuronalen Netzes (NN) verwendet wurde. Wird beispielsweise ein neuronales Netz mit einer Kamera trainiert, die an der Windschutzscheibe eines niedrigen Sportwagens angebracht ist, kann sich die Systemgenauigkeit verschlechtern oder das System kann sogar versagen, wenn es mit einer Kamera verwendet wird, die an einem Fahrzeug mit höherem Fahrgestell angebracht ist, wie etwa einem Geländewagen (SUV) oder LKW. Außerdem sollten die Bilder, die zum Trainieren des neuronalen Netzes verwendet werden, in der Regel ähnliche Kameramerkmale aufweisen, d. h. von derselben Kamera aufgenommen worden sein.
  • Herkömmlich werden Unterschiede in den Eigenschaften der Kameras, die zur Erzeugung von Bildern für das Training und den Einsatz verwendet werden, durch die Verwendung einer Familie von neuronalen Netzen minimiert, von denen jedes mit einheitlichen Kameramerkmalen trainiert und eingesetzt wird. Beispielsweise kann für jedes Fahrzeugjahr, jede Marke und/oder jedes Modell ein anderes neuronales Netz trainiert und eingesetzt werden, wobei durchweg einheitliche Kameramerkmale verwendet werden. Dieser Ansatz erfordert jedoch große Mengen an Trainingsdaten, deren Erfassung teuer und zeitaufwändig ist. Außerdem sind für das Training erhebliche Rechenressourcen erforderlich, da für jedes Netz ein separates Training erforderlich ist. Außerdem muss jedes neuronale Netzwerk separat gepflegt und aktualisiert werden, was Speicherplatz und Bandbreite beansprucht.
  • Zusammenfassung der Erfindung
  • Ausführungsformen der vorliegenden Offenbarung beziehen sich auf die Anwendung von Blickpunkttransformationen zum sensorunabhängigen Verständnis von Szenen. Es werden Systeme und Verfahren offenbart, die es ermöglichen, Bilddaten und/oder andere Sensordaten zu transformieren, um Unterschiede in den Sensoreigenschaften der zur Erfassung der Sensordaten verwendeten Sensoren zu kompensieren. Die transformierten Sensordaten können auf ein maschinelles Lernmodell (MLM) zum Training und/oder zur Inferenz angewendet werden, was zu einer verbesserten Wahrnehmung führt.
  • Im Gegensatz zu herkömmlichen Ansätzen, wie den oben beschriebenen, können Sensordaten, die zum Trainieren eines MLM, wie z. B. eines tiefen neuronalen Netzes (DNN), verwendet werden, und/oder Sensordaten, die vom NN während des Einsatzes verwendet werden, von Sensoren (z. B. Kameras) erfasst werden, die unterschiedliche Perspektiven (z. B. Sichtfelder, Standorte und Ausrichtungen in Bezug auf ein bestimmtes Fahrzeug, eine Bodenebene oder einen anderen Bezugspunkt usw.) haben. In solchen Beispielen können die Sensordaten transformiert werden - um transformierte Sensordaten zu erzeugen -, beispielsweise durch Ändern oder Entfernen von Objektivverzeichnungen, Verschieben, Drehen, Zuschneiden und/oder Extrahieren von mindestens einem interessierenden Bereich (ROI) aus Bildern, die den Sensordaten entsprechen, in ein Sichtfeld eines anderen physikalischen oder virtuellen Sensors. Dabei kann das MLM mit Sensordaten trainiert und/oder eingesetzt werden, die aus einem gleichen oder ähnlichen Sichtfeld erfasst wurden. Folglich kann das MLM mit Sensordaten trainiert und/oder eingesetzt werden, die dieselbe Perspektive wie der Referenz- oder Idealsensor aufweisen, und zwar für eine beliebige Anzahl verschiedener Fahrzeuge mit Kameras und/oder anderen Sensoren mit unterschiedlichen Perspektiven. Dieser Prozess erhöht die Skalierbarkeit des Systems und beseitigt gleichzeitig fahrzeugspezifische Abhängigkeiten, um ein maschinelles Lernmodell zu erstellen, das in einer beliebigen Anzahl verschiedener Fahrzeuge eingesetzt werden kann.
  • Figurenliste
  • Die vorliegenden Systeme und Verfahren zum Anwenden von Blickpunkttransformationen für sensorunabhängiges Szenenverständnis werden im Folgenden unter Bezugnahme auf die beigefügten Figuren detailliert beschrieben, wobei
    • 1A ist ein Datenflussdiagramm, das ein Beispiel für ein System zum Trainieren eines maschinellen Lernmodells darstellt, das einen Prozess zum Transformieren von Sensordaten gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchführt;
    • 1B ist ein Datenflussdiagramm, das ein Beispiel für ein maschinelles Lernmodell-Inferenz-System darstellt, das einen Prozess zum Transformieren von Sensordaten gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchführt;
    • 2A ist ein Datenflussdiagramm, das einen beispielhaften Datenfluss zum Transformieren von Sichtfeldern unter Verwendung eines interessierenden Bereichs und eines oder mehrerer Zwischenbilder gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
    • 2B ist ein Datenflussdiagramm, das einen beispielhaften Datenfluss für die Extraktion eines interessierenden Bereichs aus einem Bild unter gleichzeitigem Transformieren von Sichtfeldern gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt;
    • 3 ist ein Datenflussdiagramm, das ein Beispiel für ein maschinelles Lernmodell-Inferenz-System, das einen Prozess zum Transformieren von Sensordaten, die mit mehreren Sensoren verbunden sind, und zum Fusionieren entsprechender Vorhersagen durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt;
    • 4 ist ein Flussdiagramm, das ein Verfahren für ein maschinelles Lernmodell zum Erzeugen einer oder mehrerer Vorhersagen unter Verwendung von Bilddaten mit einem transformierten Sichtfeld gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
    • 5 ist ein Flussdiagramm, das ein Verfahren für ein maschinelles Lernmodell zum Erzeugen einer oder mehrerer Vorhersagen unter Verwendung eines interessierenden Bereichs mit einem objektivunabhängigen Format gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
    • 6 ist ein Flussdiagramm, das ein Verfahren zum Trainieren eines maschinellen Lernmodells zeigt, um eine oder mehrere Vorhersagen unter Verwendung von Bilddaten mit einem transformierten Sichtfeld zu erzeugen, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 7A zeigt ein beispielhaftes autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 7B ist ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug aus 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 7C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 7D ist ein Systemdiagramm für die Kommunikation zwischen Cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug aus 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
    • 8 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung, die zur Verwendung beim Implementieren einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
    • 9 ist ein Blockdiagramm eines beispielhaften Datenzentrums, das zur Verwendung beim Implementieren einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.
  • Detaillierte Beschreibung der Erfindung
  • Es sind Systeme und Verfahren offenbart, die sich auf die Anwendung von Blickpunkttransformationen für sensorunabhängiges Szenenverständnis beziehen. Obwohl die vorliegende Offenbarung in Bezug auf ein Beispiel für ein autonomes Fahrzeug 700 (hier alternativ als „Fahrzeug 700“ oder „Ego-Fahrzeug 700“ bezeichnet, von dem ein Beispiel in Bezug auf die 7A-7D beschrieben ist), ist dies nicht als Einschränkung zu verstehen. Beispielsweise können die hier beschriebenen Systeme und Verfahren ohne Einschränkung von nicht-autonomen Fahrzeugen, halbautonomen Fahrzeugen (z. B. in einem oder mehreren adaptiven Fahrerassistenzsystemen (ADAS)), gelenkten und ungelenkten Robotern oder Roboterplattformen, Lagerfahrzeugen, Geländefahrzeugen, Fahrzeugen, die mit einem oder mehreren Anhängern gekoppelt sind, fliegenden Schiffen, Booten, Shuttles, Notfallfahrzeugen, Motorrädern, elektrischen oder motorisierten Fahrrädern, Flugzeugen, Baufahrzeugen, Unterwasserfahrzeugen, Drohnen und/oder anderen Fahrzeugtypen verwendet werden. Obwohl die vorliegende Offenbarung in Bezug auf autonomes Fahren beschrieben wird, ist dies nicht als Einschränkung zu verstehen, und die hierin beschriebenen Systeme und Methoden können in den Bereichen erweiterte Realität, virtuelle Realität, gemischte Realität, Robotik, Sicherheit und Überwachung, autonome oder halbautonome Maschinenanwendungen und/oder in jedem anderen Technologiebereich, in dem maschinelles Lernen verwendet werden kann, eingesetzt werden. Obwohl die vorliegende Offenbarung in erster Linie anhand von Beispielen von Sensoren in Form von Kameras beschrieben wird, können die offenbarten Techniken auch zur Anwendung von Transformationen für jede geeignete Form von Sensoren verwendet werden (z. B. zur Transformation eines sensorischen Feldes).
  • In verschiedenen Ausführungsformen können Sensordaten, die zum Trainieren eines MLM, wie z. B. eines tiefen neuronalen Netzes (DNN), verwendet werden, und/oder Sensordaten, die vom NN während des Einsatzes verwendet werden, von Sensoren (z. B. Kameras) mit unterschiedlichen Perspektiven (z. B. Sichtfeldern, Standorten und Ausrichtungen in Bezug auf ein bestimmtes Fahrzeug, eine Bodenebene oder einen anderen Bezugspunkt usw.) erfasst werden. In solchen Beispielen können die Sensordaten transformiert werden - um transformierte Sensordaten zu erzeugen -, beispielsweise durch Ändern oder Entfernen von Objektivverzeichnungen, Verschieben, Drehen, Zuschneiden und/oder Extrahieren von ROIs aus Bildern, die den Sensordaten entsprechen, in ein Sichtfeld eines anderen physikalischen oder virtuellen Sensors. Dabei kann das MLM mit Sensordaten trainiert und/oder eingesetzt werden, die aus einem gleichen oder ähnlichen Sichtfeld erfasst wurden. Folglich kann das MLM mit Sensordaten trainiert und/oder eingesetzt werden, die dieselbe Perspektive wie der Referenz- oder Idealsensor aufweisen, und zwar für eine beliebige Anzahl verschiedener Fahrzeuge mit Kameras und/oder anderen Sensoren mit unterschiedlichen Perspektiven. Dieser Prozess erhöht die Skalierbarkeit des Systems und beseitigt gleichzeitig fahrzeugspezifische Abhängigkeiten, um ein maschinelles Lernmodell zu erstellen, das in einer beliebigen Anzahl verschiedener Fahrzeuge eingesetzt werden kann.
  • Das Transformieren der Sensordaten, um die Sensordaten in ein anderes Sichtfeld umzuwandeln, kann das Anpassen (z. B. Entfernen, Reduzieren oder Ändern) der durch die Sensordaten erfassten Objektivverzeichnung beinhalten. Beispielsweise kann die Objektivverzeichnung den Objektiveigenschaften einer Kamera entsprechen, die sich auf das Sichtfeld auswirken, wie etwa der Sichtwinkel. In mindestens einer Ausführungsform kann die Objektivverzeichnung eine Beleuchtungsverzeichnung (z. B. einen Vignettierungseffekt), eine perspektivische Verzeichnung (z. B. eine Weitwinkelverzeichnung oder eine Verlängerungsverzeichnung) und/oder eine Kompressionsverzeichnung umfassen. In mindestens einer Ausführungsform kann die Objektivverzeichnung eine optische Verzeichnung, wie z. B. eine tonnenförmige Verzeichnung, eine kissenförmige Verzeichnung und/oder eine Schnurrbartverzeichnung, umfassen. In einer oder mehreren Ausführungsformen kann die Objektivverzeichnung umgewandelt werden, um die Objektivverzeichnung eines anderen Objektivs und/oder einer anderen Kamera zu simulieren. In mindestens einer Ausführungsform können die Sensordaten in ein objektivunabhängiges Format umgewandelt werden, beispielsweise durch Entfernen der Objektivverzeichnung. Beispielsweise können Bilder, die für das Training und/oder den Einsatz verwendet werden, so umgewandelt werden, dass sie so aussehen, als wären sie von einer idealen Kamera aufgenommen worden (z. B. einer idealen Lochkamera, bei der für jeden Punkt der Szene ein einzelner Lichtstrahl in die Kamera eintritt).
  • Das Transformieren der Sensordaten zur Umwandlung der Sensordaten in ein anderes Sichtfeld kann das Verschieben, Drehen, Zuschneiden und/oder Extrahieren von ROIs aus Bildern (oder anderen Sensordatenformaten), die den Sensordaten entsprechen, in eine Perspektive beinhalten. Beispielsweise kann eine Blickpunkttransformation verwendet werden, um Kamerabilder zu transformieren, um eine Verschiebung und/oder Drehung der Kamera zu emulieren. Dies kann verwendet werden, um unterschiedlich positionierte Kameras und/oder Sensoren zu berücksichtigen (z. B. links oder rechts von der Mitte, oben oder unten in Bezug auf eine Grundfläche und/oder einen anderen Weltbezugspunkt usw.).
  • Das Transformieren der Sensordaten zur Umwandlung der Sensordaten in ein anderes Sichtfeld kann zusätzlich oder alternativ das Extrahieren eines interessierenden Bereichs (ROI) aus einem oder mehreren Bildern beinhalten, die den Sensordaten entsprechen. Beispielsweise können die Grenzen des ROI in einem Bild bestimmt werden, wobei die Grenzen dem Sichtfeld entsprechen. Die Pixel innerhalb der Grenzen können verwendet werden, um die ROI zu erzeugen, die dem Sichtfeld entspricht. Die ROI kann in mindestens ein Bild integriert werden, das als Eingabe für ein MLM verwendet werden kann. In mindestens einer Ausführungsform können eine oder mehrere der Grenzen im Weltraum bestimmt werden. Durch die Bestimmung einer Grenze im Weltraum kann der Inhalt der ROI für Bilder, die mit unterschiedlichen Kameramerkmalen erzeugt wurden, konsistent gemacht werden. In mindestens einer Ausführungsform können die seitlichen Grenzen bestimmt werden, um einen Winkel festzulegen, der ein horizontales Sichtfeld definiert. Unter der Annahme eines flachen Bodens kann eine obere Begrenzung so gewählt werden, dass sie mit einer Horizontlinie und/oder einer Referenzlinie übereinstimmt. Eine untere Begrenzung kann so eingestellt werden, dass sie einem Bodenabschnitt mit einer bestimmten oder festen Breite im Weltraum entspricht.
  • In mindestens einer Ausführungsform können die Grenzen verwendet werden, um eine Teilmenge von Pixeln aus einem Bild auszuwählen (z. B. zu extrahieren), die der ROI entsprechen. Eine oder mehrere der Transformationen können auf die Pixel angewendet werden, um ein anderes Bild zu erzeugen, das der ROI entspricht. Beispielsweise können eine oder mehrere Transformationen in eine Nachschlagetabelle aufgenommen werden, die für jedes Zielpixel im Bild, das der ROI entspricht, ein oder mehrere Quellpixel im Bild angibt, die zur Erzeugung des/der Zielpixel(s) verwendet werden. Die Pixel für die ROI können dann direkt nur aus den relevanten Pixeln des Quellbildes erzeugt werden. Durch die direkte Erzeugung der Pixel für die ROI können eine oder mehrere Transformationen nur auf die Pixel angewandt werden, die für die Erzeugung der ROI benötigt werden, und nicht auf das gesamte Quellbild. In einer oder mehreren Ausführungsformen kann jedoch mindestens eine Transformation auf ein Quellbild angewendet werden, um ein transformiertes Bild zu erzeugen, und dann können die Pixel für die ROI aus dem transformierten Bild bestimmt werden (z. B. durch Beschneiden des transformierten Bildes).
  • Darüber hinaus können mehrere Bilder und/oder andere sensorische Eingaben, die mit mehreren Sensoreigenschaften oder Parametern erzeugt wurden, auf dasselbe MLM angewendet werden, um Ausgabedaten zu erzeugen, die jeweils einer oder mehreren Vorhersagen entsprechen (nachdem sie transformiert wurden, um eine oder mehrere gemeinsame Kameracharakteristiken, wie hier beschrieben, widerzuspiegeln). Beispielsweise kann ein erstes Bild (bzw. können erste Bilder) mit einer ersten Kamera (bzw. ersten Kameras) erzeugt werden, die an einer ersten Position eines Fahrzeugs oder einer anderen Maschine angebracht ist (sind), und ein zweites Bild (bzw. können) mit einer zweiten Kamera (bzw. zweiten Kameras) erzeugt werden, die an einer zweiten Position des Fahrzeugs angebracht ist (sind). Die Bilder können so umgewandelt werden, dass sie den Anschein erwecken, von einer gemeinsamen Kamera aufgenommen worden zu sein, z. B. von einer der Kameras, einer anderen, nicht am Fahrzeug montierten Kamera, einer idealen oder Referenzkamera usw. Die Daten, die einer oder mehreren Vorhersagen entsprechen, können fusioniert werden, um eine fusionierte Vorhersage zu erstellen, die zur Steuerung des Fahrzeugs verwendet werden kann. Offenbartes Vorgehen kann ein größeres effektives Sichtfeld ermöglichen als die Verwendung einer einzelnen Kamera zur Erstellung von Vorhersagen, wodurch die Genauigkeit der Vorhersagen verbessert wird.
  • Mit Bezug auf die 1A und 1B: 1A ist ein Datenflussdiagramm, das ein Beispiel für ein maschinelles Lernmodell-Trainingssystem 100A darstellt, das einen Prozess zur Transformation von Sensordaten durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. 1B ist ein Datenflussdiagramm, das ein Beispiel für ein maschinelles Lernmodell-Inferenz-System 100B darstellt, das einen Prozess zur Transformation von Sensordaten durchführt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
  • Es versteht sich von selbst, dass diese und andere hier beschriebene Anordnungen nur als Beispiele zu verstehen sind. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu den gezeigten oder anstelle von ihnen verwendet werden, und einige Elemente können ganz weggelassen werden. Außerdem sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen können die hierin beschriebenen Systeme, Methoden und Prozesse unter Verwendung ähnlicher Komponenten, Merkmale und/oder Funktionen wie die des beispielhaften autonomen Fahrzeugs 700 der 7A-7D, der beispielhaften Rechenvorrichtung 800 von 8 und/oder dem Beispiel-Datenzentrum 900 von 9.
  • Das MLM-Trainingssystem 100A kann neben anderen Elementen eine Eingabedaten-Pipeline 140 und einen MLM-Trainer 108 enthalten. Das MLM-Inferenzsystem 100B kann neben anderen Elementen die Eingabedaten-Pipeline 140 und eine Steuerkomponente(n) 112 enthalten. Im gezeigten Beispiel umfasst die Eingabedaten-Pipeline 140 einen Vorprozessor 102 und einen sensorischen Transformator 104. Während der sensorische Transformator 104 in mindestens einer Ausführungsform sowohl im MLM-Trainingssystem 100A als auch im MI,M-Inferenz-System 100B gezeigt wird,
  • Als Überblick kann die Eingabedaten-Pipeline 140 so konfiguriert sein, dass sie Eingabedaten zur Verwendung beim Training eines MLM(s) und/oder bei der Durchführung von Schlussfolgerungen unter Verwendung eines MLM(s), wie z. B. eines MLM(s) 118, erzeugt, verarbeitet, vorverarbeitet, ergänzt und/oder anderweitig vorbereitet. In Ausführungsformen, die den Vorprozessor 102 enthalten, kann der Vorprozessor 102 so konfiguriert sein, dass er eine Vorverarbeitung von Eingabedaten (z. B. Daten aus der realen Welt) durchführt, wie z. B. Eingabedaten 120A oder 120B (z. B. Sensordaten und/oder Bilddaten), die mit einem oder mehreren Sensoren erzeugt wurden. Der sensorische Transformator 104 kann so konfiguriert sein, dass er Sensordaten (z. B. vorverarbeitete oder rohe Sensordaten), die den Eingabedaten 120A oder 120B entsprechen, transformiert, um transformierte Sensordaten (z. B. transformierte Daten 110A oder transformierte Daten 110B) zu erzeugen, z. B. durch Ändern oder Entfernen von Objektivverzeichnungen, Drehen, Zuschneiden und/oder Extrahieren von ROIs aus Bildern (oder anderen Sensordatenformaten), die den Sensordaten entsprechen, in ein Sichtfeld eines anderen physikalischen oder virtuellen Sensors.
  • So kann in Ausführungsformen, in denen die Eingabedaten-Pipeline 140 im MLM-Trainingssystem 100A verwendet wird, der MLM-Trainer 108 das/die MLM(s) unter Verwendung von Eingabedaten (z. B. Bilder und/oder Frames der sensorischen Eingabe) trainieren, die unter Verwendung mehrerer unterschiedlicher Sensoreigenschaften oder - parameter erzeugt wurden, die unter Verwendung des sensorischen Transformators 104 normalisiert werden können. Beispielsweise kann der sensorische Transformator 104 die Eingabedaten 120A von einer oder mehreren Kameras und/oder anderen Sensoren mit unterschiedlichen Perspektiven normalisieren - unter Verwendung von Sensordaten, die dieselbe(n) Perspektive(n) wie ein Referenz- und/oder Idealsensor(en) aufweisen, um das/die MLM(s) 118 unter Verwendung zumindest der transformierten Daten 110A zu trainieren.
  • In Ausführungsformen, in denen die Eingabedaten-Pipeline 140 im MLM-Inferenz-System 100B verwendet wird, kann/können das/die MLM, wie z. B. das MLM 118, das Inferenz unter Verwendung von Eingabedaten (z. B. Bilder und/oder Frames der sensorischen Eingabe) durchführen, die unter Verwendung mehrerer unterschiedlicher Sensoreigenschaften oder -parameter erzeugt wurden, die unter Verwendung des sensorischen Transformators 104 normalisiert werden können. Beispielsweise kann der sensorische Transformator 104 die Eingabedaten 120B von einer oder mehreren Kameras und/oder anderen Sensoren mit unterschiedlichen Perspektiven normalisieren - unter Verwendung von Sensordaten, die dieselbe(n) Perspektive(n) aufweisen wie ein Referenz- und/oder idealer Sensor bzw. ideale Sensoren, um eine Inferenz unter Verwendung des/der MLM(s) zumindest aus den transformierten Daten 110B durchzuführen. Die Steuerkomponente(n) 112 kann/können Ausgabedaten verwenden, die unter Verwendung des MLM 118 erzeugt wurden, um eine oder mehrere Steuerungsoperationen in Bezug auf eine Maschine, wie z. B. das Fahrzeug 700, durchzuführen.
  • In einer oder mehreren Ausführungsformen kann der sensorische Transformator 104 sowohl zum Trainieren des MLM 118 als auch zum Einsatz des MLM 118 verwendet werden. Beispielsweise kann der sensorische Transformator 104 für das Training im MLM-Trainingssystem 100A verwendet werden, um Eingabedaten so zu normalisieren, dass sie die Sensoreigenschaften oder Parameter eines oder mehrerer virtueller Sensoren widerspiegeln. Für den Einsatz kann der sensorische Transformator 104 auch im MLM-Inferenzsystem 100B verwendet werden, um Eingabedaten so zu normalisieren, dass sie die Sensoreigenschaften oder -parameter des/der virtuellen Sensors/Sensoren widerspiegeln.
  • In einer oder mehreren Ausführungsformen kann der sensorische Transformator 104 jedoch zum Trainieren des MLM 118 verwendet werden, ohne dass der sensorische Transformator 104 während des Einsatzes des MLM 118 verwendet wird. Beispielsweise kann der sensorische Transformator 104 für das Training im MLM-Trainingssystem 100A verwendet werden, um die Eingabedaten so zu normalisieren, dass sie die Sensoreigenschaften oder Parameter widerspiegeln, die im MLM-Inferenz-System 100B verwendet werden, um die Eingabedaten während des Einsatzes zu erzeugen, ohne den sensorischen Transformator 104 zu verwenden. So können Eingabedaten für das Training transformiert werden, um Sensoreigenschaften oder Parameter einer physikalischen Kamera(s) zu emulieren, die verwendet wird, um die Eingabedaten im Einsatz zu erzeugen.
  • In ähnlicher Weise kann in einer oder mehreren Ausführungsformen der sensorische Transformator 104 beim Einsatz für das MLM 118 verwendet werden, aber nicht für das Training des MLM 118. Beispielsweise kann der sensorische Transformator 104 im MLM-Inferenzsystem 100B verwendet werden, um Eingabedaten so zu normalisieren, dass sie Sensoreigenschaften oder -parameter widerspiegeln, die im MLM-Trainingssystem 100A verwendet werden, um die Eingabedaten ohne den sensorischen Transformator 104 während des Trainings zu erzeugen. Für den Einsatz können die Eingabedaten also so transformiert werden, dass sie die Sensoreigenschaften oder -parameter einer oder mehrerer physikalischer Kameras emulieren, die zur Erzeugung der Eingabedaten beim Training verwendet wurden.
  • Das MLM-Trainingssystem 100A und das MI,M-Inferenz-System 100B werden beispielhaft und ohne Einschränkung in Bezug auf ein MLM(s) beschrieben, das für die Verwendung bei Computer-Vision- und/oder Wahrnehmungsoperationen zur Navigation eines Fahrzeugs trainiert wird. Aspekte der Offenbarung sind jedoch allgemeiner auf jede Form von MLM anwendbar, das trainiert und/oder eingesetzt wird, um Vorhersagen basierend auf Sensordaten zu treffen. In einigen Beispielen kann/können das/die MLM 118 trainiert werden, um Trajektorienpunkte, eine Fahrzeugorientierung (z. B. in Bezug auf Merkmale der Umgebung, wie Fahrbahnmarkierungen) und/oder einen Fahrzeugzustand (z. B. in Bezug auf ein Objektmanöver, wie einen Spurwechsel, ein Abbiegen, ein Zusammenführen usw.) vorherzusagen, die zur Steuerung eines autonomen Fahrzeugs verwendet werden können. Dies ist jedoch nicht als Einschränkung zu verstehen.
  • Darüber hinaus ist die Eingabedaten-Pipeline 140 ein Beispiel für eine Eingabedaten-Pipeline 140, die in mindestens einer Ausführungsform verwendet werden kann, beispielsweise für das Training, die Inferenz und/oder den Einsatz eines MLM(s) zur Verwendung bei Computer-Vision- und/oder Wahrnehmungsoperationen zur Navigation eines Fahrzeugs oder für andere Zwecke. Die Eingabedaten-Pipeline 140 kann jedoch so variiert werden, dass sie mehr, weniger und/oder andere Komponenten und/oder Verarbeitungspfade als die in den FIGEN dargestellten umfasst. 1A und 1B dargestellt sind.
  • Obwohl der sensorische Transformator 104 sowohl im MLM-Trainingssystem 100A als auch im MI,M-Inferenz-System 100B dargestellt ist, kann der sensorische Transformator 104 in mindestens einer Ausführungsform in der Eingangsdaten-Pipeline 140 für das eine, aber nicht für das andere System enthalten sein. Auch wenn der sensorische Transformator 104 sowohl im MLM-Trainingssystem 100A als auch im MLM-Inferenz-System 100B enthalten ist, kann der sensorische Transformator 104 je nach Bedarf eine oder mehrere unterschiedliche Transformationen in Bezug auf jedes System durchführen, um die Eingangsdaten 120A und/oder die Eingangsdaten 120B zu normalisieren oder anderweitig zu transformieren.
  • In mindestens einer Ausführungsform können die Eingabedaten 120A und/oder die Eingabedaten 120B (hier auch als „Eingabedaten 120“ bezeichnet) Bilddaten, Sensordaten, Simulationsdaten, synthetische Daten und/oder andere Datentypen (z. B. Kartendaten) enthalten. Beispielhaft und ohne Einschränkung können die Bilddaten Daten enthalten, die repräsentativ für Bilder eines oder mehrerer Sichtfelder einer oder mehrerer Kameras eines Fahrzeugs sind (z.B. reale/physikalische oder simulierte Kameras), wie z.B. Stereokamera(s) 868, Weitwinkelkamera(s) 870 (z.B., Fischaugenkameras), Infrarotkamera(n) 872, Umgebungskamera(n) 874 (z. B. 360-Grad-Kameras), Fern- und/oder Mittelstreckenkamera(n) 898 und/oder andere Kameratypen des Fahrzeugs 700. In einigen Beispielen können die Bilddaten von einer einzigen Kamera mit einem nach vorne gerichteten, im Wesentlichen zentrierten Sichtfeld in Bezug auf eine horizontale Achse (z. B. von links nach rechts) des Fahrzeugs 700 erfasst werden. In einer nicht einschränkenden Ausführungsform können eine oder mehrere nach vorne gerichtete Kameras verwendet werden (z.B. eine mittig oder nahezu mittig montierte Kamera(s)), wie z.B. eine Weitwinkelkamera 770, eine Surround-Kamera 774, eine Stereokamera 768 und/oder eine Weitbereichs- oder Mittelbereichskamera 798. In einigen Beispielen kann mehr als eine Kamera oder ein anderer realer oder virtueller Sensor (z. B. LIDAR-Sensor, RADAR-Sensor, Ultraschallsensor usw.) verwendet werden, um mehrere Sichtfelder einzubeziehen (z. B. die Sichtfelder der Weitbereichskameras 798, der nach vorne gerichteten Stereokamera 768 und/oder der nach vorne gerichteten Weitwinkelkamera 770 von 7B).
  • In einigen Beispielen können die Bilddaten in einem Format (z. B. RCCB, RCCC, RBGC usw.) erfasst und dann (z. B. durch den Vorprozessor 102) in ein anderes Format umgewandelt werden. Für die Eingabedaten 120 können viele Arten von Bildern oder Formaten verwendet werden, beispielsweise komprimierte Bilder wie in den Formaten Joint Photographic Experts Group (JPEG), Red Green Blue (RGB) oder Luminance/Chrominance (YUV), komprimierte Bilder als Frames, die aus einem komprimierten Videoformat wie H.264/Advanced Video Coding (AVC) oder H.265/High Efficiency Video Coding (HEVC) stammen, oder Rohbilder, die beispielsweise von einem Red Clear Blue (RCCB), Red Clear (RCCC) oder einem anderen Typ von Bildsensor stammen. Es wird darauf hingewiesen, dass für das Training des/der maschinellen Lernmodelle(s) 118 andere Formate und/oder Auflösungen verwendet werden können als für die Inferenz (z. B. während des Einsatzes und/oder der Prüfung des/der maschinellen Lernmodelle(s) 118).
  • In einigen Ausführungsformen können ein oder mehrere Teile des Vorprozessors 102 eine Vorverarbeitungs-Bildpipeline implementieren, um ein oder mehrere Rohbilder zu verarbeiten, die von einem oder mehreren Sensoren (z. B. Kamera(s)) erfasst wurden und in den Bilddaten enthalten sind, um vorverarbeitete Bilddaten zu erzeugen, die ein oder mehrere Eingangsbilder für das oder die maschinellen Lernmodelle 118 darstellen können. Ein Beispiel für eine geeignete Vorverarbeitungs-Bildpipeline kann ein rohes RCCB-Bayer-Bild (z. B. 1-Kanal) vom Sensor verwenden und dieses Bild in ein RCB-Planarbild (z. B. 3-Kanal) umwandeln, das im Format mit fester Präzision (z. B. 16 Bit pro Kanal) gespeichert ist. Die Bildvorverarbeitungspipeline kann Dekompandierung, Rauschunterdrückung, Demosaicing, Weißabgleich, Histogrammberechnung und/oder adaptive globale Tonwertzuordnung (z. B. in dieser Reihenfolge oder in einer anderen Reihenfolge) umfassen.
  • Wird der Vorprozessor 102 zur Rauschunterdrückung eingesetzt, so kann er eine bilaterale Entrauschung im Bayer-Bereich vornehmen. Wenn der Vorprozessor 102 eine Demosaicing vornimmt, kann sie eine bilineare Interpolation umfassen. Wenn der Vorprozessor 102 eine Histogrammberechnung durchführt, kann diese die Berechnung eines Histogramms für den C-Kanal beinhalten und in einigen Beispielen mit der Dekompandierung oder Rauschunterdrückung kombiniert werden. Wenn der Vorprozessor 102 eine adaptive globale Tonwertzuordnung vornimmt, kann er eine adaptive Gamma-Log-Transformation durchführen. Dies kann die Berechnung eines Histogramms, die Ermittlung eines Mitteltonwerts und/oder die Schätzung einer maximalen Leuchtdichte mit dem Mitteltonwert umfassen.
  • In verschiedenen Beispielen können die Eingabedaten 120 die Sensordaten enthalten, die von einer beliebigen Anzahl von (physikalischen und/oder virtuellen oder simulierten) Sensoren erzeugt werden, wie beispielsweise LIDAR-Sensor(en) 764, RADAR-Sensor(en) 760, Ultraschallsensor(en) 762, Mikrofon(en) 796 und/oder anderen Sensortypen. Die Sensordaten können Sichtfelder und/oder Sensorfelder von Sensoren (z. B. LIDAR-Sensor(en) 764, RADAR-Sensor(en) 760 usw.) darstellen und/oder eine Wahrnehmung der Umgebung durch einen oder mehrere Sensoren (z. B. ein Mikrofon(e) 796) repräsentieren. Sensoren wie Bildsensoren (z. B. von Kameras), LIDAR-Sensoren, RADAR-Sensoren, SONAR-Sensoren, Ultraschallsensoren und/oder dergleichen können hier als Wahrnehmungssensoren oder Wahrnehmungssensorgeräte bezeichnet werden, und die von den Wahrnehmungssensoren erzeugten Sensordaten können hier als Wahrnehmungssensordaten bezeichnet werden. In einigen Beispielen kann eine Instanz oder Darstellung der Sensordaten durch ein von einem Bildsensor erfasstes Bild (z. B. die Bilddaten), eine von einem LIDAR-Sensor erzeugte Tiefenkarte und/oder Ähnliches dargestellt werden. LIDAR-Daten, SONAR-Daten, RADAR-Daten und/oder andere Sensordatentypen können mit den von einem oder mehreren Bildsensoren erzeugten Bilddaten korreliert oder diesen zugeordnet werden. Beispielsweise können Bilddaten, die ein oder mehrere Bilder repräsentieren, so aktualisiert werden, dass sie Daten enthalten, die sich auf LIDAR-Sensoren, SONAR-Sensoren, RADAR-Sensoren und/oder Ähnliches beziehen, so dass die Sensordaten, die für das Training und/oder die Eingabe in das MLM 118 verwendet werden, informativer oder detaillierter sein können als Bilddaten allein. Dabei kann das MLM 118 lernen, Vorhersagen unter Verwendung dieser zusätzlichen Informationen von einer beliebigen Anzahl von Wahrnehmungssensoren zu erstellen.
  • In Ausführungsformen, in denen Sensordaten verwendet werden, können die Sensoren so kalibriert werden, dass die Sensordaten mit Pixelkoordinaten in den Bilddaten verknüpft sind. Der Vorprozessor 102 kann eine Vorverarbeitung der Sensordaten durchführen, die der hier beschriebenen Vorverarbeitung von Bilddaten ähnlich sein kann. In einigen Ausführungsformen, z. B., wenn die Sensordaten die Tiefe anzeigen (z. B. RADAR-Daten, LIDAR-Daten usw.), können die Tiefenwerte mit Pixelkoordinaten in den Bilddaten korreliert und dann als zusätzlicher (oder in einigen Beispielen alternativer) Input für das/die maschinelle(n) Lernmodell(e) 118 verwendet werden. Beispielsweise kann einem oder mehreren der Pixel ein zusätzlicher Wert zugeordnet werden, der für die aus den Sensordaten ermittelte Tiefe repräsentativ ist.
  • Wie hier beschrieben, können die Eingabedaten 120 auch andere Datentypen enthalten, wie z. B. Kartendaten. Die Kartendaten können von dem/den maschinellen Lernmodell(en) 118 verwendet werden, um Ausgaben zu erzeugen. Beispielsweise können die Kartendaten niedrig aufgelöste Kartendaten enthalten (z. B. Screenshots einer 2D-Kartenanwendung mit oder ohne Führung). Diese niedrig aufgelösten Kartendaten können eine grundlegende Geometrie der Straße und/oder der Kreuzungen enthalten, z. B. ohne zusätzliche Informationen wie Fahrbahnmarkierungen, Anzahl der Fahrspuren, Standorte von Gehwegen, Straßenlampen, Stoppschildern usw. Mit anderen Worten, im Gegensatz zu den Kartendaten, die eine HD-Karte darstellen (z. B. die hier beschriebene HD-Karte und/oder die HD-Karten, auf die sich herkömmliche Systeme verlassen), können die Kartendaten weniger datenintensiv sein und nur als zusätzlicher Datenpunkt von dem/den maschinellen Lernmodell(en) 118 bei der Berechnung der Ausgaben verwendet werden.
  • Die Kartendaten können in einigen Beispielen einen Screenshot oder ein Bild (oder Daten, die dafür repräsentativ sind) enthalten, die eine aktuelle Fahrspur des Fahrzeugs, eine Zielfahrspur des Fahrzeugs, das Fahrzeug selbst und/oder eine Darstellung des Pfades, den das Fahrzeug beim Fahrspurwechsel nehmen soll, zeigen. In einigen Beispielen kann der Pfad des Fahrzeugs, der für die Kartendaten für das Training verwendet wird, automatisch während der vom Menschen gesteuerten Teile des Fahrzeugbetriebs erzeugt werden (z. B. wird der Pfad über die Karte aufgefüllt, wenn das Fahrzeug durch die Umgebung gesteuert wird). Beispielsweise können die Kartendaten Befehle enthalten, wie „an der nächsten Kreuzung rechts abbiegen“ oder ähnliches, und das/die maschinelle(n) Lernmodell(e) 118 kann/können diese Informationen zur Erstellung von Vorhersagen verwenden. In jedem Beispiel können die Kartendaten automatisch generiert werden (z. B. während der Steuerung des Fahrzeugs durch einen Menschen) und/oder durch manuelle Beschriftung erzeugt werden.
  • In einer oder mehreren Ausführungsformen können zumindest einige der Eingabedaten 120 unter Verwendung eines Simulators erzeugt werden, wie z. B. eines oder mehrerer Simulatoren, die so konfiguriert sind, dass sie Bilder und/oder Sensordateneingaben aus einer oder mehreren virtuellen Umgebungen (z. B. einer 3D-Darstellung und/oder Simulation der realen Welt) wiedergeben oder anderweitig bestimmen. In einer oder mehreren Ausführungsformen können die Eingabedaten 120 alle realen Eingabedaten, alle simulierten oder synthetischen Eingabedaten oder eine Kombination davon enthalten. Wenn simulierte oder synthetische Eingabedaten in den Eingabedaten 120 enthalten sind, kann der sensorische Transformator 104 verwendet werden, um zumindest einige der synthetischen Eingabedaten zu erzeugen. Beispielsweise kann zumindest ein Teil der Funktionalität des Vorprozessors 102 und/oder des sensorischen Umwandlers 104 in den Simulator integriert werden und/oder auf andere Weise durch den Simulator berücksichtigt werden.
  • Wie hierin beschrieben, kann der sensorische Transformator 104 so konfiguriert sein, dass er Sensordaten (z. B. vorverarbeitete oder rohe Sensordaten), die den Eingabedaten 120 entsprechen, transformiert, um transformierte Sensordaten (z. B. transformierte Daten 110A oder transformierte Daten 110B) zu erzeugen, z. B. durch Ändern oder Entfernen von Objektivverzeichnungen, Drehen, Zuschneiden und/oder Extrahieren von ROIs aus Bildern (oder anderen Sensordatenformaten), die den Sensordaten entsprechen, in ein Sichtfeld eines anderen physikalischen oder virtuellen Sensors.
  • Das/die MLM(s) 118 kann/können als Eingabe ein oder mehrere Bilder oder andere Datendarstellungen oder Instanzen (z. B. LIDAR-Daten, RADAR-Daten, SONAR-Daten, Ultraschalldaten usw.) verwenden, die durch die transformierten Daten 110A und/oder die transformierten Daten 110B (hier auch als „transformierte Daten 110“ bezeichnet) dargestellt werden, um Ausgabe(n) zu erzeugen. In einem nicht einschränkenden Beispiel kann das MLM 118 als Eingabe ein Bild(er) nehmen, das durch die Eingabedaten dargestellt wird (z. B. nachdem sie unter Verwendung der Eingabedaten-Pipeline 140 verarbeitet wurden, um Trajektoriendaten, die Fahrzeugorientierung und/oder einen Fahrzeugzustand vorherzusagen). Obwohl hier Beispiele in Bezug auf die Verwendung von neuronalen Netzen, insbesondere Faltungsneuronalen Netzen, als MLM(s) 118 beschrieben werden, ist dies nicht als Einschränkung zu verstehen. Beispielsweise und ohne Einschränkung können die hier beschriebenen MLM(s) 118 eine oder mehrere beliebige Arten von maschinellen Lernmodellen umfassen, wie etwa maschinelle Lernmodelle unter Verwendung von linearer Regression, logistischer Regression, Entscheidungsbäumen, Support Vector Machines (SVM), Naive Bayes, k-nearest neighbor (Knn), K-Means-Clustering, Random Forest, Dimensionalitätsreduktionsalgorithmen, Gradient-Boosting-Algorithmen, neuronalen Netzen (z. B., Autocodierer, Faltungsalgorithmen, rekurrente Algorithmen, Perzeptrone, Long/Short Term Memory (LSTM), Hopfield, Boltzmann, Deep Belief, Deconvolutional, Generative Adversarial, Liquid State Machine usw.) und/oder andere Arten von maschinellen Lernmodellen.
  • In mindestens einer Ausführungsform kann der sensorische Transformator 104 eine oder mehrere Transformationen auf die Eingangsdaten anwenden, um die transformierten Daten 110 zu erzeugen. Beispielsweise kann der sensorische Transformator 104 die von den Eingabedaten 120 erfasste Objektivverzeichnung anpassen (z. B. entfernen, reduzieren oder ändern). Die Objektivverzeichnung kann den Objektiveigenschaften und/oder den Eigenschaften einer Kamera und/oder eines anderen Sensors entsprechen, die zur Erzeugung der Eingabedaten 120 verwendet werden, was sich auf das in den Eingabedaten 120 widergespiegelte Sichtfeld auswirken kann, z. B. auf den Sichtwinkel. Beispielsweise kann der sensorische Transformator 104 neben anderen Transformationen den Blickwinkel horizontal, vertikal und/oder diagonal transformieren.
  • In mindestens einer Ausführungsform kann der sensorische Transformator 104 eine oder mehrere Transformationen auf die Eingabedaten 120 anwenden, um eine Objektivverzeichnung hinzuzufügen, zu entfernen oder zu reduzieren, die eine perspektivische Verzeichnung, wie z. B. eine Weitwinkelverzeichnung oder eine Verlängerungsverzeichnung und/oder eine Kompressionsverzeichnung umfasst. In mindestens einer Ausführungsform kann der sensorische Transformator 104 eine oder mehrere Transformationen auf die Eingabedaten 120 anwenden, um eine Objektivverzeichnung hinzuzufügen, zu entfernen oder zu verringern, die eine optische Verzeichnung umfasst, wie z. B. eine tonnenförmige Verzeichnung, eine Nadelkissenverzeichnung und/oder eine Schnurrbartverzeichnung. In einer oder mehreren Ausführungsformen kann die in den Eingabedaten 120 reflektierte Objektivverzeichnung umgewandelt werden, um die Objektivverzeichnung eines anderen Objektivs und/oder einer anderen Kamera zu simulieren. In mindestens einer Ausführungsform können die Sensordaten in ein objektivunabhängiges Format umgewandelt werden, beispielsweise durch Entfernen der Objektivverzeichnung. Beispielsweise können die durch die umgewandelten Daten 110 dargestellten Bilder so umgewandelt werden, dass sie so aussehen, als ob sie von einer idealen Kamera aufgenommen worden wären (z. B. einer idealen Lochkamera, bei der für jeden Punkt in der Szene ein einzelner Lichtstrahl in die Kamera eintritt), wie in 2A.
  • Bezugnehmend auf 2A, ist 2A ein Datenflussdiagramm, das einen beispielhaften Datenfluss 200A zur Transformation von Sichtfeldern unter Verwendung eines interessierenden Bereichs und eines oder mehrerer Zwischenbilder gemäß einigen Ausführungsformen der vorliegenden Offenbarung darstellt. Wie gezeigt, kann der Datenfluss 200A beinhalten, dass der sensorische Transformator 104 ein Bild 202, das den Eingabedaten 120 entspricht, in ein Bild 204 transformiert, das zumindest auf der Modifizierung der in dem Bild 202 dargestellten Objektivverzeichnung basiert. Beispielsweise kann die Transformation bewirken, dass das Bild 204 so aussieht, als wäre es mit einer idealen Lochkamera aufgenommen worden. In einer oder mehreren Ausführungsformen kann die vom sensorischen Wandler 104 durchgeführte(n) Transformation(en) eine Bildentzerrung unter Verwendung des Bildes 202 zur Erzeugung des Bildes 204 umfassen. Die Transformation kann Verzeichnungen entfernen, die für das zur Aufnahme des Bildes 202 verwendete Kameraobjektiv spezifisch sind, wodurch das Bild 204 objektivunabhängig wird. Ähnliche Ansätze können in Ausführungsformen verwendet werden, bei denen die Objektivverzeichnung so umgewandelt wird, dass sie die Objektivverzeichnung eines anderen Objektivs emuliert.
  • In mindestens einer Ausführungsform kann der sensorische Transformator 104 eine oder mehrere Transformationen auf die Eingabedaten 120 anwenden, um Bilder (oder andere Datendarstellungen), die den Eingabedaten 120 entsprechen, zu verschieben, zu drehen, zu beschneiden und/oder ROIs aus ihnen zu extrahieren und in ein Sichtfeld eines anderen physikalischen oder virtuellen Sensors zu übertragen. Beispielsweise können eine oder mehrere Blickpunkttransformationen verwendet werden, um Kamerabilder und/oder andere Sensordaten zu transformieren, um eine Verschiebung und/oder Drehung des Sensors zu emulieren, wie in 2A. Dies kann verwendet werden, um unterschiedlich positionierte Kameras und/oder Sensoren zu berücksichtigen (z. B. links oder rechts von der Mitte, oben oder unten in Bezug auf eine Grundfläche und/oder einen anderen Weltbezugspunkt usw.).
  • Wie in 2A gezeigt, kann der Datenfluss 200A beispielsweise beinhalten, dass der sensorische Transformator 104 das Bild 204 in ein Bild 206 umwandelt, das zumindest auf der Anwendung einer oder mehrerer Blickpunkttransformationen basiert, um den Standort, die Position und die Ausrichtung oder Aspekte einer Pose der Kamera zu ändern. Insbesondere können die Änderungen bewirken, dass das Bild 206 so erscheint, als ob es unter Verwendung einer Kamera mit einer anderen Pose aufgenommen worden wäre.
  • Als nicht einschränkendes Beispiel können ein oder mehrere Aspekte der Pose relativ zu einer Hinterachse des Fahrzeugs 700 (und/oder einem anderen Referenzpunkt) bestimmt werden. Beispielsweise kann der sensorische Transformator 104 Transformationen anwenden, so dass die transformierten Bilder so erscheinen, als ob sie unter Verwendung einer Kamera - beispielsweise und ohne Einschränkung - 1,47 Meter über der Hinterachse und 1,77 Meter vor der Hinterachse entlang der Mittellinie des Fahrzeugs 700 aufgenommen wurden. In mindestens einer Ausführungsform können diese Zahlen der tatsächlichen Kameraplatzierung an den für die Datenerfassung verwendeten Fahrzeugen entsprechen. Für andere Fahrzeuge, bei denen sich die Kamera an einer anderen Stelle befinden kann, kann diese Transformation auf die verarbeiteten Bilder angewandt werden, um von der genauen Kameraposition am Fahrzeug nahezu unabhängig zu werden.
  • Wie beispielsweise in 2A gezeigt, kann der Datenfluss 200A beinhalten, dass der sensorische Transformator 104 das Bild 206 in ein Bild 208 zuschneidet oder anderweitig eine ROI aus dem Bild 206 extrahiert, um einem Sichtfeld eines anderen physikalischen oder virtuellen Sensors zu entsprechen. Beispielsweise können eine oder mehrere Grenzen 210A, 210B, 210C und/oder 210D (hier auch als „Grenzen 210“ bezeichnet) der ROI in einem Bild, wie dem Bild 206, bestimmt werden, wobei die Grenzen 210 mindestens dem Sichtfeld entsprechen und darauf basieren. Pixel innerhalb der Grenzen 210 können verwendet werden, um die ROI zu erzeugen, die dem Sichtfeld entspricht (z. B. um den Inhalt der ROI und/oder zumindest einige der visuellen Informationen zu definieren, die zur Erzeugung der ROI verwendet werden). Die ROI kann in mindestens ein Bild, wie das Bild 208, integriert werden, das als Eingabe für das MLM 118 verwendet werden kann. In weiteren Beispielen kann die ROI als Tensor-Eingangsdaten des MLM 118 erzeugt werden, ohne zunächst ein kleineres Zwischenbild zu erzeugen.
  • In mindestens einer Ausführungsform können eine oder mehrere der Grenzen 210 im Weltraum bestimmt werden (z. B. in 3D-Weltkoordinaten und nicht im Bildraum). Durch die Bestimmung einer Grenze im Weltraum kann der Inhalt der ROI für Bilder, die mit unterschiedlichen Sensoreigenschaften erzeugt wurden, konsistent gemacht werden. In mindestens einer Ausführungsform können Seitengrenzen, wie die Grenzen 210D und 210B, bestimmt werden, um einen Winkel festzulegen, der ein horizontales Sichtfeld definiert. Unter der Annahme eines flachen Bodens kann eine obere Begrenzung 210A so gewählt werden, dass sie mit einer Horizontlinie und/oder einer Referenzlinie übereinstimmt. Eine untere Begrenzung 210C kann so eingestellt werden, dass sie einem Bodenabschnitt mit einer bestimmten oder festen (z. B. vorgegebenen) Breite im Weltraum entspricht.
  • In einer oder mehreren Ausführungsformen kann die ROI wie folgt definiert werden: Zunächst wird das horizontale Sichtfeld (als nicht einschränkendes Beispiel) auf eine Breite von 53° festgelegt. Dann wird unter der Annahme eines flachen Bodens der obere Rand der ROI so gewählt, dass er mit dem Horizont übereinstimmt. Schließlich wird der untere Teil der ROI so angepasst, dass er einem 7,6 m breiten Bodenabschnitt entspricht. Unter Berücksichtigung dieser Anpassungen können die Bilder linear skaliert werden, so dass das resultierende Bild (als nicht begrenzte Ausführungsform) 209 Pixel breit und 65 Pixel hoch ist.
  • Offenbart können die ROI so definiert werden, dass Daten, die den Himmel repräsentieren, eliminiert (vernachlässigt) oder anderweitig nicht verwendet werden können, da der Himmel für das Fahren kaum von Bedeutung ist. Vorausgesetzt, die Originalkameras haben eine ausreichende Auflösung, können standardisierte ROIs definiert werden, die weitgehend unabhängig von den Kameraeigenschaften sind. Da es Teile der Straße geben kann, die von einem Kamerastandort aus sichtbar sind und von einem anderen nicht, sind diese Diskrepanzen gering, wenn Teile der Straße betrachtet werden, die sich mehr als ein paar Meter vor dem Fahrzeug befinden.
  • In mindestens einer Ausführungsform kann der sensorische Transformator 104 eine oder mehrere der Transformationen durchführen, die zumindest auf der Abbildung von Quellbereichen (die jeweils ein oder mehrere Pixel eines Bildes aufweisen) eines durch die Quellbereiche gebildeten Gitters oder einer Matrix auf Zellen einer Matrix basieren, die entsprechende Zellen und/oder Pixel der ROI definieren. Beispielsweise kann jeder Quellbereich eines Gitters innerhalb der Grenzen 210 des Bildes 206 ein einzelnes Pixel oder mehrere Pixel umfassen. Und jede Zelle, die dem Bild 208 entspricht, kann einem einzelnen Pixel oder mehreren Pixeln entsprechen.
  • In verschiedenen Beispielen kann der sensorische Transformator 104 Quellbereiche des durch die Quellbereiche gebildeten Gitters oder der Matrix auf Zellen der Matrix abbilden, die der ROI entsprechen. 3D-Transformationen können mithilfe einer oder mehrerer Transformationsmatrizen durchgeführt werden. Beispielsweise kann für eine gegebene Transformation eine 4x4-Matrix verwendet werden, ohne dass dies eine Einschränkung darstellt. Geht man beispielsweise von einer Vektorschreibweise für die Quelldaten aus, kann der sensorische Transformator 104 eine Transformation anwenden, die zumindest auf der Multiplikation aller zu transformierenden Vektoren mit der Transformationsmatrix basiert. Wenn beispielsweise die Vektoren im 3D-Raum A waren, kann die Transformationsmatrix eine neue Position des 3D-Raums A relativ zum 3D-Raum B beschreiben. Nach der Multiplikation können die Vektoren dann im 3D-Raum B beschrieben werden.
  • Während der Datenfluss 200A verschiedene Zwischenbilder zwischen dem Bild 202 und dem Bild 208 umfasst, können in mindestens einer Ausführungsform mehr oder weniger Zwischenbilder verwendet werden. 2B ist ein Datenflussdiagramm, das einen beispielhaften Datenfluss 200B zum Extrahieren eines interessierenden Bereichs aus einem Bild bei gleichzeitiger Transformation von Sichtfeldern gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Wie in 2B angedeutet, können die Pixel und/oder andere Daten (Tensordaten), die dem ROI entsprechen, direkt aus dem Bild 202 extrahiert werden, ohne irgendwelche Zwischenbilder zu erzeugen (in anderen Beispielen können weniger Zwischenbilder als in 2A unter Verwendung ähnlicher Techniken verwendet werden).
  • In mindestens einer Ausführungsform können die Grenzen 230 verwendet werden, um eine Untergruppe von Pixeln aus dem Bild 202 auszuwählen (z. B. zu extrahieren), die der ROI entsprechen. Eine oder mehrere der Transformationen können auf die Pixel angewendet werden, um das der ROI entsprechende Bild 208 zu erzeugen. Beispielsweise können eine oder mehrere Transformationen in eine Nachschlagetabelle aufgenommen werden, die für jedes Zielpixel in dem Bild 208, das der ROI entspricht, ein oder mehrere Quellpixel in dem Bild 202 angibt, die zur Erzeugung des/der Zielpixel(s) verwendet werden. In mindestens einer Ausführungsform kann die Nachschlagetabelle die gleichen Abmessungen haben wie die extrahierte ROI. Für jede Zelle kann die Nachschlagetabelle die entsprechenden X- und Y-Koordinaten (oder den Bereich) des Bildes 202 angeben oder anderweitig kennzeichnen.
  • Der sensorische Transformator 104 kann die Nachschlagetabelle verwenden, um die Pixel für die ROI direkt aus nur den relevanten Pixeln des Bildes 202 zu erzeugen. Durch die direkte Erzeugung der Pixel für die ROI können eine oder mehrere Transformationen nur auf Pixel angewendet werden, die für die Erzeugung der ROI benötigt werden, im Gegensatz zu einem gesamten Bild 202. Beispielsweise müssen Pixel außerhalb der Grenzen 230 nicht für die Erzeugung des Bildes 204 und des Bildes 206 verwendet werden, da sie für die Erzeugung des Bildes 208 nicht erforderlich sind. Dieser Ansatz kann dazu dienen, Speicher- und Verarbeitungskosten zu sparen. Während beispielsweise die Bilder 202, 204 und 206 in 2A im Allgemeinen gleich groß dargestellt sind, kann die Durchführung einer oder mehrerer Transformationen die für ein Zwischenbild erforderliche Auflösung erhöhen. Beispielsweise kann im Datenfluss 200A ein Bild mit einer Auflösung von 1920x1208, das ein Sichtfeld von 60 Grad erfasst, auf ein Bild mit 2400x1600 und einem Sichtfeld von 120 Grad projiziert werden. Im Datenfluss 200B kann die ROI jedoch direkt extrahiert werden, ohne dass das 2400x1600-Zwischenbild erzeugt werden muss.
  • Zusätzliche oder alternative Transformationen können für andere Zwecke auf die Eingabedaten 120 angewendet werden. In mindestens einer Ausführungsform kann ein Resimulator verwendet werden, um Daten für mindestens einige der Trainingsdatensätze und/oder zum Testen des MLM 118 zu erzeugen. Der Resimulator kann verwendet werden, um realen Tests Rechnung zu tragen, die zeitaufwändig, nicht leicht reproduzierbar und riskant oder unsicher sind. In mindestens einer Ausführungsform kann der Resimulator Tests im geschlossenen Regelkreis wie in einem synthetischen Simulator ermöglichen, wobei jedoch reale Sensoraufzeichnungen anstelle von synthetischen Daten verwendet werden. In offenbaren Beispielen kann der Resimulator Blickpunkt-Transformationen verwenden, um die Trainingsdaten auf Bereiche auszudehnen, die nicht durch menschliches Fahren erfasst werden. Dieselbe Strategie kann genutzt werden, um Testumgebungen aus gesammelten Videos oder Bildern zu erzeugen. Der Resimulator kann simulierte Daten liefern, ohne dass simulierte Städte und Straßen entworfen werden müssen (z. B. in einer fotorealistischen Simulation, die durch das Rendern von 3D-Grafiken erzeugt wird), während die gleichen oder ähnliche Szenarien realer Ausfälle reproduziert werden, die für die Simulation nützlich sind.
  • Der Resimulator kann analog zur Videowiedergabe arbeiten, wobei das zu prüfende System das Fahrzeug wie in einer synthetischen Simulation steuern kann. Bei jedem neuen Simulationszustand können die Sensordaten für die Kameras durch eine Blickpunkttransformation aus dem nächstgelegenen Bild der Aufzeichnung erzeugt werden. Die Eingabedaten 120 können so erzeugt worden sein, dass das Fahrzeug ungefähr in der Mitte der Straße stand. Die Blickpunkttransformation kann verwendet werden, um das Fahren des Fahrzeugs an verschiedenen Stellen der Straße zu simulieren, z. B. außermittig, beim Abbiegen, usw. Solange das zu prüfende System nicht zu sehr von der aufgezeichneten Strecke abweicht, können die Sensordaten immer verfügbar sein. Weicht das Netz zu stark von der aufgezeichneten Strecke ab, stehen möglicherweise nicht genügend Sensordaten zur Verfügung, um Transformationen durchzuführen; daher kann das simulierte Fahrzeug in diesen Fällen auf die Mitte der Straße zurückgesetzt werden. In mindestens einer Ausführungsform können die Blickpunkttransformationen in die vom sensorischen Transformator 104 im Datenfluss 200A oder im Datenfluss 200B durchgeführten Transformationen einbezogen werden (z. B. durch Transformation der Eingabedaten in die Lage relativ zum Fahrzeug unter Berücksichtigung der Lage des Fahrzeugs in der Welt).
  • Dieselbe Strategie kann genutzt werden, um Testumgebungen aus gesammelten Videos oder Bildern zu erzeugen. Der Resimulator kann simulierte Daten liefern, ohne dass simulierte Städte und Straßen entworfen werden müssen (z. B. in einer fotorealistischen Simulation, die durch das Rendern von 3D-Grafiken erzeugt wird), während die gleichen oder ähnliche Szenarien realer Ausfälle reproduziert werden, die für die Simulation nützlich sind.
  • Nun auf 3 bezugnehmend, ist 3 ein Datenflussdiagramm, das ein Beispiel für ein maschinelles Lernmodell-Inferenz-System 300 darstellt, das einen Prozess zur Umwandlung von Sensordaten, die mit mehreren Sensoren verbunden sind, und zum Fusionieren entsprechender Vorhersagen gemäß einigen Ausführungsformen der vorliegenden Offenbarung durchführt. Das MI,M-Inferenz-System 300 kann eine beliebige Anzahl von Sensoren umfassen, wie z. B. einen Sensor 302A (z. B. eine erste Kamera) und einen Sensor 302B (z. B. eine zweite Kamera), wobei das MLM 118 einen Satz von einer oder mehreren Vorhersagen für jeden Sensor (oder Satz von Sensoren) durchführen kann. Beispielsweise können die Eingabedaten 120B vom Sensor 302A unter Verwendung der Eingabedaten-Pipeline 140 transformiert und dann auf das MLM 118 angewendet werden, um Ausgabedaten 310A zu erzeugen, die einen ersten Satz von Vorhersagen anzeigen. Die Eingabedaten 120B vom Sensor 302B können ebenfalls unter Verwendung der Eingabedaten-Pipeline 140 transformiert und dann auf das MLM 118 angewandt werden, um Ausgabedaten 310B zu erzeugen, die einen zweiten Satz von Vorhersagen anzeigen. Der Vorhersage-Fusionsoperator 310 kann den ersten Satz von Vorhersagen mit dem zweiten Satz von Vorhersagen fusionieren, um einen fusionierten Satz von Vorhersagen zu erzeugen. Der fusionierte Satz von Vorhersagen kann dann von der Steuerkomponente 112 verwendet werden.
  • Unter Verwendung des MLM-Inferenzsystems 300 können mehrere Bilder und/oder andere sensorische Eingaben, die unter Verwendung mehrerer Sensoreigenschaften oder -parameter erzeugt wurden, auf dasselbe MLM 118 angewendet werden, um die Ausgabedaten 310A und 310B zu erzeugen, die jeweils einer oder mehreren Vorhersagen entsprechen (nachdem sie transformiert wurden, um eine oder mehrere gemeinsame Kameracharakteristiken widerzuspiegeln, wie hier beschrieben). Beispielsweise kann ein erstes Bild bzw. können erste Bilder unter Verwendung des Sensors 302A erzeugt werden, der an einer ersten Position des Fahrzeugs 700 angebracht ist, und ein zweites Bild bzw. können zweite Bilder unter Verwendung des Sensors 302B erzeugt werden, der an einer zweiten Position des Fahrzeugs 700 angebracht ist. Die Bilder können so transformiert werden, dass sie den Anschein erwecken, von einer gemeinsamen Kamera aufgenommen worden zu sein (z. B. in Bezug auf Perspektive, Objektivverzeichnung, Sichtfeld und/oder andere Kameracharakteristika), wie z. B. einem der Sensoren 302A oder 302B, einem anderen Sensor, der nicht am Fahrzeug 700 angebracht ist (z. B. für das Training des MLM 118 verwendet), einem idealen oder Referenzsensor usw. Der Vorhersage-Fusionsoperator 310 kann jeden geeigneten Ansatz verwenden, um die Vorhersagesätze zu fusionieren, was das Kombinieren, Auswählen und/oder anderweitige Aggregieren entsprechender Vorhersagen über Sätze hinweg beinhalten kann. Offenbartes Vorgehen kann ein größeres effektives Sichtfeld ermöglichen als die Verwendung eines einzelnen Sensors zur Erstellung von Vorhersagen, wodurch die Genauigkeit der Vorhersagen verbessert wird.
  • Es werden zwar zwei Sensoren 302A und 302B gezeigt, doch kann eine beliebige Anzahl von Sensoren verwendet werden. Ferner kann sich die Eingangsdaten-Pipeline 140 auf dieselbe Instanz der Eingangsdaten-Pipeline 140 oder auf mehrere Instanzen der Eingangsdaten-Pipeline 140 beziehen (z. B. jede mit einer anderen Konfiguration, um etwaige Unterschiede zwischen den Sensoren 302A und 302B und/oder den entsprechenden Eingangsdaten 120B zu berücksichtigen). Die Verwendung mehrerer Instanzen der Eingabedaten-Pipeline 140 kann es ermöglichen, dass die Eingabedaten 120B von jedem Sensor 302A und 302B parallel verarbeitet werden (z. B. anstatt seriell unter Verwendung einer einzigen Instanz). In ähnlicher Weise kann sich das MLM 118 auf dieselbe Instanz des MLM 118 oder auf mehrere Instanzen oder Kopien des MLM 118 beziehen. Die Verwendung mehrerer Instanzen des MLM 118 kann es ermöglichen, dass die transformierten Daten 110B von jedem Sensor 302A und 302B parallel verarbeitet werden (z. B. anstatt seriell unter Verwendung einer einzigen Instanz).
  • In mindestens einer Ausführungsform kann es sich bei der/den Steuerkomponente(n) 112 des MLM-Inferenz-Systems 100B um ein autonomes Fahrzeug handeln, und während des Einsatzes kann/können die Ausgabe(n) des MLM 118 von der/den Steuerkomponente(n) 112 des autonomen Fahrzeugs (z. B. dem/den Controller(n) 736, dem ADAS-System 738, dem/den SOC(s) 704 und/oder anderen Komponenten des autonomen Fahrzeugs 700) verwendet werden, um das Fahrzeug bei der Navigation (z. B. der Wegplanung) in einer Umgebung zu unterstützen. Beispielsweise kann die Ausgabe von der/den Steuerkomponente(n) 112 einer oder mehreren anderen Komponenten des Fahrzeugs und/oder des Software-Stacks für autonomes Fahren (z. B. Komponente(n) einer Planungsschicht, einer Steuerungsschicht, einer Wahrnehmungsschicht und/oder einer anderen Schicht des Stacks) zugeordnet werden.
  • In mindestens einer Ausführungsform kann der MLM-Trainer 108 des MLM-Trainingssystems 100A das MLM 118 mit einem beliebigen geeigneten Ansatz trainieren. Als nicht einschränkendes Beispiel kann der MLM-Trainer 108 aus den Eingangsdaten, die über die Eingangsdaten-Pipeline 140 bereitgestellt werden, Bilddaten verwenden, die für ein oder mehrere Bilder (oder andere Datendarstellungen) repräsentativ sind, und die Daten in Form eines mehrdimensionalen Arrays/einer mehrdimensionalen Matrix in den Speicher laden (in einigen Beispielen alternativ als Tensor oder genauer gesagt als Eingangstensor bezeichnet). Die Arraygröße kann als W × H × C berechnet und/oder dargestellt werden, wobei W für die Bildbreite in Pixeln, H für die Höhe in Pixeln und C für die Anzahl der Farbkanäle steht. Ohne Verlust der Allgemeingültigkeit sind auch andere Arten und Anordnungen von Eingangsbildkomponenten möglich. Darüber hinaus kann die Stapelgröße B als eine Dimension (z. B. eine zusätzliche vierte Dimension) verwendet werden, wenn eine Stapelverarbeitung eingesetzt wird. Die Stapelverarbeitung kann für das Training und/oder für die Inferenz verwendet werden. So kann der Eingabetensor ein Feld der Dimensionen W × H × C × B darstellen. Die Reihenfolge der Dimensionen kann beliebig sein, was von der jeweiligen Hardware und Software abhängt, die zur Implementierung des Sensordaten-Vorprozessors verwendet wird. Diese Anordnung kann gewählt werden, um die Trainings- und/oder Ableitungsleistung des MLM (der MLMs) 118 zu maximieren.
  • Nun auf 4 bezugnehmend, weist jeder Block des Verfahrens 400 und anderer hierin beschriebener Verfahren einen Rechenprozess auf, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Die Verfahren können auch in Form von computerverwendbaren Anweisungen auf Computerspeichermedien gespeichert sein. Die Methoden können durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige zu nennen. Darüber hinaus wird die Methode 400 beispielhaft in Bezug auf 1 beschrieben. Diese Verfahren können jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
  • 4 ist ein Flussdiagramm, das ein Verfahren 400 für ein maschinelles Lernmodell zur Erzeugung einer oder mehrerer Vorhersagen unter Verwendung von Bilddaten mit einem transformierten Sichtfeld gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 400 umfasst im Block B402 den Empfang von Bilddaten, die unter Verwendung einer Kamera erzeugt wurden. Beispielsweise kann der sensorische Transformator 104 Bilddaten empfangen, die mit einer ersten Kamera mit einem ersten Sichtfeld erzeugt wurden. Die erste Kamera ist mit dem Fahrzeug 700 in einer Umgebung verbunden.
  • Das Verfahren 400 umfasst in Block B404 das Anwenden einer Transformation auf die Bilddaten, um das erste Sichtfeld in ein zweites Sichtfeld umzuwandeln. Beispielsweise kann der sensorische Transformator 104 eine Transformation auf die Bilddaten anwenden, um transformierte Bilddaten zu erzeugen. Die Transformation kann das erste Sichtfeld in ein zweites Sichtfeld einer zweiten Kamera umwandeln.
  • Das Verfahren 400 umfasst in Block B406 das Anwenden der transformierten Bilddaten auf ein maschinelles Lernmodell. Beispielsweise können die transformierten Bilddaten auf das MLM 118 angewendet werden, das unter Verwendung von Trainingsbildern, die dem zweiten Sichtfeld der zweiten Kamera entsprechen, trainiert worden sein kann.
  • Das Verfahren 400 umfasst in Block B408 das Berechnen von Ausgabedaten unter Verwendung des maschinellen Lernmodells. Beispielsweise kann das MLM 118 verwendet werden, um Ausgabedaten zu berechnen, die für eine mit dem MLM 118 gemachte Vorhersage repräsentativ sind.
  • Das Verfahren 400 umfasst in Block B410 das Durchführen einer oder mehrerer Computeroperationen unter Verwendung der Ausgabedaten. Beispielsweise können die Ausgabedaten an die Steuerkomponente 112 übertragen werden, um das Fahrzeug 700 zu veranlassen, eine oder mehrere Operationen durchzuführen, die zumindest auf der Vorhersage basieren.
  • Nun auf 5 bezugnehmend, ist 5 ein Flussdiagramm, das ein Verfahren 500 für ein maschinelles Lernmodell zur Erzeugung einer oder mehrerer Vorhersagen unter Verwendung eines interessierenden Bereichs mit einem objektivunabhängigen Format gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 500 umfasst im Block B502 das Identifizieren eines interessierenden Bereichs in einem unter Verwendung einer Kamera erzeugten Bild, mindestens basierend auf einem Sichtfeld. Beispielsweise kann der sensorische Transformator 104 einen interessierenden Bereich in einem unter Verwendung einer Kamera erzeugten Bild identifizieren, mindestens basierend auf einem Sichtfeld, das in Trainingsbildern dargestellt ist, die zum Trainieren des MLM 118 verwendet werden.
  • Das Verfahren 500 umfasst in Block B504 das Umwandeln mindestens des interessierenden Bereichs in ein objektivunabhängiges Format, das für die Trainingsbilder verwendet wird. Beispielsweise kann der sensorische Transformator 104 zumindest den interessierenden Bereich in ein objektivunabhängiges Format umzuwandeln, das für die Trainingsbilder verwendet wird.
  • Das Verfahren 500 umfasst in Block B506 das Bestimmen einer oder mehrerer Vorhersagen aus dem interessierenden Bereich unter Verwendung eines maschinellen Lernmodells. Beispielsweise kann das MLM 118 verwendet werden, um eine oder mehrere Vorhersagen aus dem interessierenden Bereich mit dem objektivunabhängigen Format zu bestimmen.
  • Das Verfahren 500 umfasst im Block B508 das Durchführen einer oder mehrerer Computeroperationen unter Verwendung der Ausgabedaten. Beispielsweise können die Ausgabedaten an die Steuerkomponente 112 übertragen werden, um das Fahrzeug 700 zu veranlassen, eine oder mehrere Operationen durchzuführen, die zumindest auf der Vorhersage basieren.
  • Nun auf 6 bezugnehmend, ist 6 ein Flussdiagramm, das ein Verfahren 600 zum Trainieren eines maschinellen Lernmodells zeigt, um eine oder mehrere Vorhersagen unter Verwendung von Bilddaten mit einem transformierten Sichtfeld gemäß einigen Ausführungsformen der vorliegenden Offenbarung zu erzeugen. Das Verfahren 600 umfasst im Block B602 das Empfangen von Bilddaten, die unter Verwendung einer Kamera mit einem ersten Sichtfeld in einer Umgebung erzeugt werden. Beispielsweise kann der sensorische Transformator 104 Bilddaten empfangen, die unter Verwendung einer Kamera mit einem ersten Sichtfeld in einer Umgebung erzeugt wurden.
  • Das Verfahren 600 umfasst in Block B604 das Anwenden einer Transformation auf die Bilddaten, um das erste Sichtfeld in ein zweites Sichtfeld umzuwandeln. Beispielsweise kann der sensorische Transformator 104 eine Transformation auf die Bilddaten anwenden, um transformierte Bilddaten zu erzeugen. Die Transformation kann das erste Sichtfeld in ein zweites Sichtfeld umwandeln.
  • Das Verfahren 600 umfasst in Block B606 das Trainieren eines maschinellen Lernmodells, um eine oder mehrere Vorhersagen aus den transformierten Bilddaten zu erzeugen. Beispielsweise kann der MLM-Trainer 108 das MLM 118 trainieren, um eine oder mehrere Vorhersagen aus den transformierten Bilddaten zu erzeugen.
  • Beispielhaftes autonomes Fahrzeug
  • 7A ist eine Illustration eines beispielhafte autonomen Fahrzeugs 700 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 700 (hier alternativ als „Fahrzeug 700“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug, wie z. B. einen Pkw, einen Lkw, einen Bus, ein Ersthelferfahrzeug, einen Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, einen Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne, ein an einen Anhänger gekoppeltes Fahrzeug und/oder eine andere Art von Fahrzeug (z. B., das unbemannt ist und/oder einen oder mehrere Fahrgäste aufnimmt) umfassen. Autonome Fahrzeuge werden im Allgemeinen in Form von Automatisierungsstufen beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (Standard Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert werden. Das Fahrzeug 700 kann in der Lage sein, Funktionen in Übereinstimmung mit einer oder mehreren der Stufen 3 bis 5 der autonomen Fahrstufen auszuführen. Das Fahrzeug 700 kann Funktionen gemäß einem oder mehreren der Level 1 - Level 5 der autonomen Fahrstufen aufweisen. Beispielsweise kann das Fahrzeug 700 je nach Ausführungsform Fahrerassistenz (Stufe 1), Teilautomatisierung (Stufe 2), bedingte Automatisierung (Stufe 3), hohe Automatisierung (Stufe 4) und/oder vollständige Automatisierung (Stufe 5) bieten. Der Begriff „autonom“, wie er hier verwendet wird, kann jede und/oder alle Arten von Autonomie für das Fahrzeug 700 oder eine andere Maschine umfassen, wie z. B. vollständig autonom, hochgradig autonom, bedingt autonom, teilautonom, unterstützende Autonomie, teilautonom, primär autonom oder eine andere Bezeichnung.
  • Das Fahrzeug 700 kann Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs umfassen. Das Fahrzeug 700 kann ein Antriebssystem 750 umfassen, wie z. B. einen Verbrennungsmotor, ein Hybrid-Elektrokraftwerk, einen reinen Elektromotor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 750 kann mit einem Antriebsstrang des Fahrzeugs 700 verbunden sein, der ein Getriebe umfassen kann, um den Antrieb des Fahrzeugs 700 zu ermöglichen. Das Antriebssystem 750 kann in Reaktion auf den Empfang von Signalen von der Drosselklappe/Gaspedal 752 gesteuert werden.
  • Ein Lenksystem 754, das ein Lenkrad umfassen kann, kann verwendet werden, um das Fahrzeug 700 zu lenken (z. B. entlang eines gewünschten Weges oder einer Route), wenn das Antriebssystem 750 in Betrieb ist (z. B., wenn das Fahrzeug in Bewegung ist). Das Lenksystem 754 kann Signale von einem Lenkaktuator 756 empfangen. Das Lenkrad kann optional für die vollständige Automatisierung (Stufe 5) eingesetzt werden.
  • Das Bremssensorsystem 746 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf den Empfang von Signalen von den Bremsaktuatoren 748 und/oder Bremssensoren zu betätigen.
  • Die Controller 736, die ein oder mehrere System-on-Chips (SoCs) 704 (7C) und/oder GPU(s) umfassen kann (können), kann (können) Signale (z. B. repräsentativ für Befehle) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 700 senden. Beispielsweise kann/können der/die Controller Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 748, zur Betätigung des Lenksystems 754 über einen oder mehrere Lenkaktuatoren 756 und zur Betätigung des Antriebssystems 750 über einen oder mehrere Drossel-Beschleunigungsregler 752 senden. Der/die Controller 736 kann/können eine oder mehrere fahrzeuginterne (z. B. integrierte) Rechenvorrichtungen (z. B. Supercomputer) umfassen, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z. B. Signale, die Befehle darstellen), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Führen des Fahrzeugs 700 zu unterstützen. Der/die Controller 736 kann/können einen ersten Controller 736 für autonome Fahrfunktionen, einen zweiten Controller 736 für funktionale Sicherheitsfunktionen, einen dritten Controller 736 für Funktionen der künstlichen Intelligenz (z. B. Computer-Vision), einen vierten Controller 736 für Infotainment-Funktionen, einen fünften Controller 736 für Redundanz unter Notfallbedingungen und/oder andere Controller umfassen. In einigen Beispielen kann ein einziger Controller 736 zwei oder mehr der oben genannten Funktionen übernehmen, zwei oder mehr Controller 736 können eine einzige Funktion übernehmen und/oder eine beliebige Kombination davon.
  • Der/die Controller 736 kann/können die Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 700 als Reaktion auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren (z. B. Sensoreingaben) empfangen werden. Die Sensordaten können beispielsweise und ohne Einschränkung von (einem) Sensor(en) des globalen Navigationssatellitensystems 758 (z.B. Global Positioning System-Sensor(en)), RADAR-Sensor(en) 760, Ultraschallsensor(en) 762, LIDAR-Sensor(en) 764, Trägheitsmesseinheit (IMU)-Sensor(en) 766 (z.B., Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 796, Stereokamera(s) 768, Weitwinkelkamera(s) 770 (z. B., Fischaugenkameras), Infrarotkamera(s) 772, Surround-Kamera(s) 774 (z. B. 360-Grad-Kameras), Fernbereichs- und/oder Mittelbereichskamera(s) 798, Geschwindigkeitssensor(en) 744 (z. B. zur Messung der Geschwindigkeit des Fahrzeugs 700), Vibrationssensor(en) 742, Lenksensor(en) 740, Bremssensor(en) (z. B. als Teil des Bremssensorsystems 746) und/oder andere Sensortypen.
  • Ein oder mehrere Controller 736 können Eingaben (z. B. in Form von Eingabedaten) von einem Kombiinstrument 732 des Fahrzeugs 700 empfangen und Ausgaben (z. B. in Form von Ausgabedaten, Anzeigedaten usw.) über eine Mensch-Maschine-Schnittstelle (HMI)-Anzeige 734, einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 700 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z. B. die HD-Karte 722 von 7C), Standortdaten (z. B. der Standort des Fahrzeugs 700, z. B. auf einer Karte), Richtung, Standort anderer Fahrzeuge (z. B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie von dem/den Controller(n) 736 wahrgenommen, usw. umfassen. Beispielsweise kann die HMI-Anzeige 734 Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. ein Straßenschild, ein Warnschild, eine sich ändernde Ampel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z. B. Fahrspurwechsel jetzt, Ausfahrt 34B in zwei Meilen usw.).
  • Das Fahrzeug 700 umfasst ferner eine Netzwerkschnittstelle 724, die eine oder mehrere drahtlose Antenne(n) 726 und/oder Modem(e) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Beispielsweise kann die Netzwerkschnittstelle 724 in der Lage sein, über LTE, WCDMA, UMTS, GSM, CDMA2000, etc. zu kommunizieren. Die drahtlose(n) Antenne(n) 726 kann/können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Geräte usw.) über lokale Netzwerke wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Low Power Wide Area Networks (LPWANs) wie LoRaWAN, SigFox usw. ermöglichen.
  • 7B ist ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug 700 von 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die jeweiligen Sichtfelder sind ein Ausführungsbeispiel und nicht als Einschränkung zu verstehen. Beispielsweise können zusätzliche und/oder alternative Kameras enthalten sein und/oder die Kameras können an verschiedenen Stellen des Fahrzeugs 700 angeordnet sein.
  • Die Kameratypen für die Kameras können unter anderem Digitalkameras sein, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 700 angepasst werden können. Die Kamera(s) kann/können mit der Sicherheitsstufe B (ASIL) und/oder einer anderen ASIL betrieben werden. Die Kameratypen können je nach Ausführungsform eine beliebige Bildaufnahmerate aufweisen, z. B. 60 Bilder pro Sekunde (fps), 120 fps, 240 fps usw. Die Kameras können Rollblendenverschluss, globalen Blendenverschluss, einen anderen Verschlusstyp oder eine Kombination davon verwenden. In einigen Beispielen kann die Farbfilteranordnung eine Rot-Klar-Klar-Klar-Farbfilteranordnung (RCCC), eine Rot-Klar-Klar-Blau-Farbfilteranordnung (RCCB), eine Rot-Blau-Grün-Klar-Farbfilteranordnung (RBGC), eine Foveon X3-Farbfilteranordnung, eine Bayer-Sensor-Farbfilteranordnung (RGGB), eine Monochromsensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung umfassen. In einigen Ausführungsformen können Kameras mit klaren Pixeln, wie z. B. Kameras mit einer RCCC-, einer RCCB- und/oder einer RBGC-Farbfilteranordnung, verwendet werden, um die Lichtempfindlichkeit zu erhöhen.
  • In einigen Beispielen können eine oder mehrere der Kameras verwendet werden, um erweiterte Fahrerassistenzsysteme (ADAS) auszuführen (z. B. als Teil einer redundanten oder ausfallsicheren Konstruktion). Beispielsweise kann eine Multifunktions-Monokamera installiert werden, um Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitzustellen. Eine oder mehrere der Kameras (z. B. alle Kameras) können gleichzeitig Bilddaten (z. B. Video) aufzeichnen und liefern.
  • Eine oder mehrere Kameras können in einer Montagevorrichtung, z. B. einer kundenspezifischen (3-D-gedruckten) Vorrichtung, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z. B. Reflexionen vom Armaturenbrett, die sich in den Windschutzscheibenspiegeln spiegeln) auszuschalten, die die Bilddatenerfassung der Kamera beeinträchtigen könnten. Bei der Montage von Außenspiegeln können die Außenspiegel kundenspezifisch in 3D gedruckt werden, so dass die Kameramontageplatte der Form des Außenspiegels entspricht. In einigen Beispielen kann die Kamera bzw. können die Kameras in den Außenspiegel integriert werden. Bei Seitenkameras können die Kameras auch in die vier Säulen an jeder Ecke der Kabine integriert werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 700 einschließt (z. B. nach vorne gerichtete Kameras), können für die Umgebungsansicht verwendet werden, um dabei zu helfen, nach vorne gerichtete Pfade und Hindernisse zu identifizieren, sowie mit Hilfe eines oder mehrerer Controller 736 und/oder Steuer-SoCs Informationen bereitzustellen, die für die Erstellung eines Belegungsgitters und/oder die Bestimmung der bevorzugten Fahrzeugpfade entscheidend sind. Nach vorne gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorne gerichtete Kameras können auch für ADAS-Funktionen und -Systeme wie Spurverlassenswarnungen (LDW), autonome Geschwindigkeitsregelung (ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung verwendet werden.
  • Eine Vielzahl von Kameras kann in einer nach vorne gerichteten Konfiguration verwendet werden, beispielsweise eine monokulare Kameraplattform, die einen CMOS-Farbbildsensor (Komplementär-Metalloxid-Halbleiter) enthält. Ein weiteres Beispiel sind die Weitwinkelkamera(n) 770, die zur Wahrnehmung von Objekten verwendet werden können, die von der Peripherie her ins Blickfeld kommen (z. B. Fußgänger, kreuzende Fahrzeuge oder Fahrräder). Obwohl in 7B nur eine Weitwinkelkamera dargestellt ist, kann das Fahrzeug 700 mit einer beliebigen Anzahl von Weitwinkelkameras 770 ausgestattet sein. Darüber hinaus kann/können die Fernbereichskamera(s) 798 (z. B. ein Fernbereichs-Stereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert wurde. Die Langstreckenkamera(s) 798 kann/können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung eingesetzt werden.
  • Eine oder mehrere Stereokameras 768 können auch in einer nach vorne gerichteten Konfiguration enthalten sein. Die Stereokamera(s) 768 kann/können eine integrierte Steuereinheit aufweisen, die eine skalierbare Verarbeitungseinheit aufweist, die eine programmierbare Logik (FPGA) und einen Multi-Core-Mikroprozessor mit integrierter CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Mit einer solchen Einheit kann eine 3-D-Karte der Fahrzeugumgebung erstellt werden, einschließlich einer Entfernungsschätzung für alle Punkte im Bild. Eine alternative Stereokamera(n) 768 kann/können einen kompakten Stereosicht-Sensor(en) umfassen, der/die zwei Kameraobjektive (je eine auf der linken und rechten Seite) und einen Bildverarbeitungschip enthält/enthalten, der den Abstand zwischen dem Fahrzeug und dem Zielobjekt messen und die erzeugten Informationen (z. B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurhaltewarnfunktionen verwenden kann. Zusätzlich oder alternativ zu den hier beschriebenen Stereokameras können auch andere Typen von Stereokameras (768) verwendet werden.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 700 einschließt (z. B. Seitenkameras), können für die Umgebungsansicht verwendet werden und Informationen liefern, die zur Erstellung und Aktualisierung des Belegungsrasters sowie zur Erzeugung von Kollisionswarnungen bei Seitenaufprall verwendet werden. Beispielsweise kann (können) die Umgebungskamera(s) 774 (z. B. vier Umgebungskameras 774, wie in 7B dargestellt) am Fahrzeug 700 positioniert werden. Die Umgebungskamera(s) 774 kann/können Weitwinkelkamera(s) 770, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches umfassen. Beispielsweise können vier Fischaugenkameras an der Vorderseite, dem Heck und den Seiten des Fahrzeugs positioniert werden. In einer alternativen Anordnung kann das Fahrzeug drei Umgebungskameras 774 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z. B. eine nach vorne gerichtete Kamera) als vierte Umgebungskamera nutzen.
  • Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 700 einschließt (z. B. Rückfahrkameras), können für die Einparkhilfe, die Umgebungsansicht, die Heckkollisionswarnung und die Erstellung und Aktualisierung des Belegungsrasters verwendet werden. Es kann eine Vielzahl von Kameras verwendet werden, einschließlich, aber nicht beschränkt auf Kameras, die auch als nach vorne gerichtete Kamera(s) geeignet sind (z. B. Fern- und/oder Mittelstreckenkamera(s) 798, Stereokamera(s) 768, Infrarotkamera(s) 772 usw.), wie hier beschrieben.
  • 7C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 700 von 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es sollte verstanden werden, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der dargestellten verwendet werden, und einige Elemente können ganz weggelassen werden. Außerdem sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
  • Alle Komponenten, Merkmale und Systeme des Fahrzeugs 700 in 7C sind als über den Bus 702 verbunden dargestellt. Der Bus 702 kann eine Controller Area Network (CAN)-Datenschnittstelle enthalten (hier alternativ als „CAN-Bus“ bezeichnet). Bei einem CAN-Bus kann es sich um ein Netzwerk innerhalb des Fahrzeugs 700 handeln, das zur Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 700 verwendet wird, z. B. zur Betätigung von Bremsen, Beschleunigung, Bremsen, Lenkung, Scheibenwischern usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten hat, von denen jeder seine eigene eindeutige Kennung hat (z. B. eine CAN-ID). Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, die Fahrgeschwindigkeit, die Motordrehzahl (RPM), die Tastenpositionen und/oder andere Fahrzeugstatusanzeigen zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
  • Obwohl der Bus 702 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Beispielsweise können zusätzlich oder alternativ zum CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Auch wenn der Bus 702 durch eine einzige Leitung dargestellt wird, ist dies nicht als Einschränkung zu verstehen. Beispielsweise kann es eine beliebige Anzahl von Bussen 702 geben, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Arten von Bussen mit einem anderen Protokoll umfassen können. In einigen Beispielen können zwei oder mehr Busse 702 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder sie können zur Redundanz verwendet werden. Beispielsweise kann ein erster Bus 702 für die Kollisionsvermeidungsfunktionalität und ein zweiter Bus 702 für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 702 mit einer beliebigen Komponente des Fahrzeugs 700 kommunizieren, und zwei oder mehr Busse 702 können mit denselben Komponenten kommunizieren. In einigen Beispielen kann jeder SoC 704, jeder Controller 736 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf dieselben Eingangsdaten haben (z. B. Eingaben von Sensoren des Fahrzeugs 700) und mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
  • Das Fahrzeug 700 kann einen oder mehrere Controller 736 enthalten, wie sie hier in Bezug auf 7A beschrieben sind. Der/die Controller 736 kann/können für eine Vielzahl von Funktionen verwendet werden. Der/die Controller 736 kann/können mit den verschiedenen anderen Komponenten und Systemen des Fahrzeugs 700 gekoppelt werden und kann/können zur Steuerung des Fahrzeugs 700, zur künstlichen Intelligenz des Fahrzeugs 700, zum Infotainment für das Fahrzeug 700 und/oder dergleichen verwendet werden.
  • Das Fahrzeug 700 kann ein oder mehrere System(e) auf einem Chip (SoC) 704 enthalten. Der SoC 704 kann CPU(s) 706, GPU(s) 708, Prozessor(en) 710, Cache(s) 712, Beschleuniger 714, Datenspeicher 716 und/oder andere nicht dargestellte Komponenten und Merkmale umfassen. Der/die SoC(s) 704 kann/können zur Steuerung des Fahrzeugs 700 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise können der/die SoC(s) 704 in einem System (z. B. dem System des Fahrzeugs 700) mit einer HD-Karte 722 kombiniert werden, die über eine Netzwerkschnittstelle 724 von einem oder mehreren Servern (z. B. dem/den Server(n) 778 von 7D) Kartenauffrischungen und/oder - aktualisierungen erhalten kann.
  • Die CPU(s) 706 kann/können einen CPU-Cluster oder CPU-Komplex (hier auch als „CCPLEX“ bezeichnet) umfassen. Die CPU(s) 706 kann/können mehrere Kerne und/oder L2-Caches enthalten. Beispielsweise können in einigen Ausführungsformen die CPU(s) 706 acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In einigen Ausführungsformen kann (können) die CPU(s) 706 vier Dual-Core-Cluster umfassen, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z. B. einen 2 MB L2-Cache). Die CPU(s) 706 (z. B. der CCPLEX) kann/können so konfiguriert werden, dass sie den gleichzeitigen Betrieb von Clustern unterstützt/unterstützen, so dass eine beliebige Kombination von Clustern der CPU(s) 706 zu einem bestimmten Zeitpunkt aktiv sein kann.
  • Die CPU(s) 706 kann/können Energieverwaltungsfunktionen implementieren, die eines oder mehrere der folgenden Merkmale umfassen: einzelne Hardwareblöcke können im Leerlauf automatisch taktgesteuert werden, um dynamische Energie zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig stromgesteuert werden; jeder Kerncluster kann unabhängig taktgesteuert werden, wenn alle Kerne taktgesteuert oder stromgesteuert sind; und/oder jeder Kerncluster kann unabhängig stromgesteuert werden, wenn alle Kerne stromgesteuert sind. Die CPU(s) 706 kann/können darüber hinaus einen erweiterten Algorithmus zur Verwaltung von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufwachzeiten festgelegt werden und die Hardware/der Mikrocode den besten Energiezustand für den Kern, den Cluster und CCPLEX bestimmt. Die Prozessorkerne können vereinfachte Sequenzen für den Eintritt in den Energiezustand in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
  • Der/die Grafikprozessor(en) 708 kann/können ein integrierter Grafikprozessor sein (hier alternativ als „iGPU“ bezeichnet). Die GPU(s) 708 kann/können programmierbar und für parallele Arbeitslasten effizient sein. Die GPU(s) 708 kann/können in einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Die GPU(s) 708 kann/können einen oder mehrere Streaming-Mikroprozessoren enthalten, wobei jeder Streaming-Mikroprozessor einen L1-Cache (z. B. einen L1-Cache mit mindestens 96 KB Speicherkapazität) enthalten kann und zwei oder mehr der Streaming-Mikroprozessoren sich einen L2-Cache (z. B. einen L2-Cache mit 512 KB Speicherkapazität) teilen können. In einigen Ausführungsformen kann die GPU (bzw. können die GPUs) 708 mindestens acht Streaming-Mikroprozessoren umfassen. Die GPU(s) 708 kann (können) eine oder mehrere Programmierschnittstellen (API(s)) für Berechnungen verwenden. Darüber hinaus können die GPU(s) 708 eine oder mehrere parallele Rechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
  • Der/die Grafikprozessor(en) 708 kann/können für die beste Leistung in Automobil- und eingebetteten Anwendungsfällen optimiert werden. Beispielsweise können die GPU(s) 708 auf einem Fin-Feldeffekttransistor (FinFET) hergestellt werden. Dies ist jedoch nicht als Einschränkung zu verstehen, und die GPU(s) 708 können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von in mehrere Blöcke unterteilten gemischt-präzisen Rechenkernen enthalten. Beispielsweise können 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke unterteilt werden. In einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Präzision für Deep-Learning-Matrixarithmetik, ein L0-Befehlscache, ein Warp-Scheduler, eine Dispatch-Einheit und/oder eine 64-KB-Registerdatei zugewiesen werden. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkomma-Datenpfade enthalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnungen und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfunktion enthalten, um eine feinere Synchronisierung und Zusammenarbeit zwischen parallelen Threads zu ermöglichen.
  • Die Streaming-Mikroprozessoren können einen kombinierten L1-Datencache und eine gemeinsame Speichereinheit enthalten, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
  • Der/die Grafikprozessor(en) 708 kann/können einen Speicher mit hoher Bandbreite (HBM) und/oder ein 16-GB-HBM2-Speicher-Subsystem umfassen, um in einigen Beispielen eine Spitzen-Speicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zum HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) verwendet werden, beispielsweise ein synchroner Grafik-Doppeldatenraten-Direktzugriffsspeicher vom Typ 5 (GDDR5).
  • Die GPU(s) 708 kann/können eine einheitliche Speichertechnologie mit Zugriffszählern enthalten, um eine genauere Zuweisung von Speicherseiten an den Prozessor zu ermöglichen, der am häufigsten auf sie zugreift, und so die Effizienz der von den Prozessoren gemeinsam genutzten Speicherbereiche zu verbessern. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (Address Translation Services, ATS) verwendet werden, damit die GPU(s) 708 direkt auf die Seitentabellen der CPU(s) 706 zugreifen können. In solchen Beispielen kann, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 708 einen Fehler feststellt, eine Adressübersetzungsanforderung an die CPU(s) 706 übermittelt werden. Als Reaktion darauf kann die CPU(s) 706 in ihren Seitentabellen nach der virtuell-physikalischen Zuordnung für die Adresse suchen und die Übersetzung an die GPU(s) 708 zurückübertragen. So kann die Unified-Memory-Technologie einen einzigen, einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 706 als auch der GPU(s) 708 ermöglichen und dadurch die Programmierung der GPU(s) 708 und die Portierung von Anwendungen auf die GPU(s) 708 vereinfachen.
  • Darüber hinaus können die GPU(s) 708 einen Zugriffszähler enthalten, der die Häufigkeit des Zugriffs der GPU(s) 708 auf den Speicher anderer Prozessoren verfolgt. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physikalischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
  • Der/die SoC(s) 704 kann/können eine beliebige Anzahl von Cache(s) 712 enthalten, einschließlich der hier beschriebenen. Beispielsweise kann (können) der (die) Cache(s) 712 einen L3-Cache enthalten, der sowohl der (den) CPU(s) 706 als auch der (den) GPU(s) 708 zur Verfügung steht (z. B. der sowohl mit der (den) CPU(s) 706 als auch mit der (den) GPU(s) 708 verbunden ist). Der/die Cache(s) 712 kann/können einen Write-Back-Cache umfassen, der die Zustände von Zeilen verfolgen kann, z. B. durch Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann je nach Ausführungsform 4 MB oder mehr umfassen, obwohl auch kleinere Cache-Größen verwendet werden können.
  • Der/die SoC(s) 704 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) enthalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der verschiedenen Aufgaben oder Operationen des Fahrzeugs 700 - wie der Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus kann/können der/die SoC(s) 704 eine Gleitkommaeinheit(en) (FPU(s)) - oder andere mathematische Coprozessoren oder numerische Coprozessortypen - zur Durchführung mathematischer Operationen innerhalb des Systems enthalten. Beispielsweise können die SoC(s) 104 eine oder mehrere FPUs enthalten, die als Ausführungseinheiten in eine CPU(s) 706 und/oder GPU(s) 708 integriert sind.
  • Der/die SoC(s) 704 kann/können einen oder mehrere Beschleuniger 714 enthalten (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Beispielsweise können die SoC(s) 704 einen Hardware-Beschleunigungscluster enthalten, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher umfassen kann. Der große On-Chip-Speicher (z. B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster in die Lage versetzen, neuronale Netzwerke und andere Berechnungen zu beschleunigen. Der Hardware-Beschleunigungscluster kann zur Ergänzung der GPU(s) 708 und zur Entlastung einiger Aufgaben der GPU(s) 708 verwendet werden (z. B. um mehr Zyklen der GPU(s) 708 für die Durchführung anderer Aufgaben freizugeben). Beispielsweise kann/können der/die Beschleuniger 714 für gezielte Arbeitslasten (z. B. Wahrnehmung, Faltungsneuronale Netze (CNNs) usw.) verwendet werden, die stabil genug sind, um beschleunigt werden zu können. Der hier verwendete Begriff „CNN“ kann alle Arten von CNNs umfassen, einschließlich regionenbasierter oder regionaler neuronaler Faltungsnetze (RCNNs) und schneller RCNNs (z. B. für die Objekterkennung).
  • Der/die Beschleuniger 714 (z. B. der Hardware-Beschleunigungscluster) kann/können einen Deep-Learning-Beschleuniger (DLA) enthalten. Der/die DLA(s) kann/können eine oder mehrere Tensor Processing Units (TPUs) umfassen, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Learning-Anwendungen und Inferenz bereitstellen. Bei den TPUs kann es sich um Beschleuniger handeln, die für die Ausführung von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Die DLA(s) kann/können darüber hinaus für einen bestimmten Satz neuronaler Netzwerktypen und Gleitkommaoperationen sowie für die Inferenz optimiert sein. Das Design der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Allzweck-GPU und übertrifft die Leistung einer CPU bei weitem. Die TPU(s) kann/können mehrere Funktionen ausführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die beispielsweise INT8-, INT16- und FP16-Datentypen sowohl für Merkmale als auch für Gewichte unterstützt, sowie Postprozessorfunktionen.
  • Die DLA(s) können schnell und effizient neuronale Netze, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, darunter beispielsweise und ohne Einschränkung: ein CNN für die Identifizierung und Erkennung von Objekten unter Verwendung von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Erkennung und Identifizierung von Einsatzfahrzeugen und die Erkennung unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und die Identifizierung von Fahrzeugbesitzern unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsbezogene Ereignisse.
  • Die DLA(s) können jede Funktion der GPU(s) 708 ausführen, und durch die Verwendung eines Inferenzbeschleunigers kann ein Entwickler beispielsweise entweder die DLA(s) oder die GPU(s) 708 für eine beliebige Funktion einsetzen. Beispielsweise kann der Entwickler die Verarbeitung von CNNs und Gleitkommaoperationen auf die DLA(s) konzentrieren und andere Funktionen der GPU(s) 708 und/oder anderen Beschleunigern 714 überlassen.
  • Der/die Beschleuniger 714 (z. B. der Hardware-Beschleunigungscluster) kann/können einen programmierbaren Bildverarbeitungsbeschleuniger (PVA) umfassen, der hier alternativ als Computer-Vision-Beschleuniger bezeichnet werden kann. Der/die PVA(s) kann/können zur Beschleunigung von Computer-Vision-Algorithmen für fortschrittliche Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented-Reality- (AR) und/oder Virtual-Reality- (VR) Anwendungen entwickelt und konfiguriert werden. Die PVA(s) können ein Gleichgewicht zwischen Leistung und Flexibilität bieten. Beispielsweise kann jede PVA eine beliebige Anzahl von RISC-Kernen (Computer mit reduziertem Befehlssatz), direkten Speicherzugriff (DMA) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
  • Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren einer der hier beschriebenen Kameras), Bildsignalprozessoren und/oder dergleichen zusammenwirken. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher enthalten. Die RISC-Kerne können je nach Ausführungsform eine beliebige Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. Die RISC-Kerne können mit einem oder mehreren integrierten Schaltkreisen, anwendungsspezifischen integrierten Schaltkreisen (ASICs) und/oder Speicherbausteinen implementiert werden. Beispielsweise können die RISC-Kerne einen Befehls-Cache und/oder ein eng gekoppeltes RAM enthalten.
  • Der DMA kann es Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 706 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Funktionen unterstützen, die zur Optimierung der PVA verwendet werden, einschließlich, aber nicht beschränkt auf die Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. In einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die Blockbreite, Blockhöhe, Blocktiefe, horizontale Blockabstufung, vertikale Blockabstufung und/oder Tiefenabstufung umfassen können.
  • Bei den Vektorprozessoren kann es sich um programmierbare Prozessoren handeln, die so konzipiert sein können, dass sie die Programmierung von Computer-Vision-Algorithmen effizient und flexibel ausführen und Signalverarbeitungsfunktionen bereitstellen. In einigen Beispielen kann die PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen umfassen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA-Engine(s) (z.B. zwei DMA-Engines) und/oder andere Peripheriegeräte umfassen. Das Vektorverarbeitungs-Teilsystem kann als primäre Verarbeitungseinheit der PVA fungieren und eine Vektorverarbeitungseinheit (VPU), einen Befehlscache und/oder einen Vektorspeicher (z. B. VMEM) umfassen. Ein VPU-Kern kann einen digitalen Signalprozessor enthalten, beispielsweise einen digitalen Signalprozessor mit einer einzigen Anweisung und mehreren Daten (SIMD) und sehr langen Anweisungsworten (VLIW). Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
  • Jeder der Vektorprozessoren kann einen Befehls-Cache enthalten und mit einem dedizierten Speicher gekoppelt sein. Folglich kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren arbeitet. In anderen Beispielen können die Vektorprozessoren, die in einer bestimmten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität verwenden. Beispielsweise kann in einigen Ausführungsformen die Mehrzahl der in einer einzigen PVA enthaltenen Vektorprozessoren denselben Computer-Vision-Algorithmus ausführen, jedoch für unterschiedliche Bereiche eines Bildes. In anderen Beispielen können die in einer bestimmten PVA enthaltenen Vektorprozessoren gleichzeitig verschiedene Computer-Vision-Algorithmen für dasselbe Bild oder sogar verschiedene Algorithmen für aufeinander folgende Bilder oder Teile eines Bildes ausführen. Unter anderem kann eine beliebige Anzahl von PVAs im Hardware-Beschleunigungscluster enthalten sein und eine beliebige Anzahl von Vektorprozessoren in jeder der PVAs. Darüber hinaus können die PVA(s) einen zusätzlichen ECC-Speicher (Error Correcting Code) enthalten, um die Sicherheit des Systems insgesamt zu erhöhen.
  • Der (die) Beschleuniger 714 (z. B. der Hardware-Beschleunigungscluster) kann (können) ein Computer-Vision-Netzwerk auf dem Chip und SRAM enthalten, um ein SRAM mit hoher Bandbreite und niedriger Latenz für den (die) Beschleuniger 714 bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM umfassen, der beispielsweise und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl die PVA als auch die DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine APB-Schnittstelle (Advanced Peripheral Bus), Konfigurationsschaltungen, einen Controller und einen Multiplexer umfassen. Es kann jeder beliebige Speichertyp verwendet werden. Die PVA und die DLA können auf den Speicher über ein Backbone zugreifen, das der PVA und der DLA einen Hochgeschwindigkeitszugriff auf den Speicher ermöglicht. Das Backbone kann ein Computer-Vision-Netzwerk auf dem Chip umfassen, das die PVA und die DLA mit dem Speicher verbindet (z. B. unter Verwendung des APB).
  • Das Computer-Vision-Netz auf dem Chip kann eine Schnittstelle enthalten, die vor der Übertragung von Steuersignalen/Adressen/Daten feststellt, dass sowohl die PVA als auch die DLA einsatzbereite und gültige Signale liefern. Eine solche Schnittstelle kann getrennte Phasen und getrennte Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-Kommunikation für die kontinuierliche Datenübertragung vorsehen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, es können aber auch andere Normen und Protokolle verwendet werden.
  • In einigen Beispielen können die SoC(s) 704 einen Echtzeit-Raytracing-Hardwarebeschleuniger enthalten, wie er in der US-Patentanmeldung Nr. 16/101,232 beschrieben ist, die am 10. August 2018 eingereicht wurde. Der Echtzeit-Raytracing-Hardwarebeschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeit-Visualisierungssimulationen zu erzeugen, für die RADAR-Signalinterpretation, für die Schallausbreitungssynthese und/oder -analyse, für die Simulation von SONAR-Systemen, für die allgemeine Wellenausbreitungssimulation, für den Vergleich mit LIDAR-Daten zum Zweck der Lokalisierung und/oder für andere Funktionen und/oder für andere Zwecke. In einigen Ausführungsformen können eine oder mehrere Tree Traversal Units (TTUs) für die Ausführung einer oder mehrerer Operationen im Zusammenhang mit der Strahlenverfolgung verwendet werden.
  • Der/die Beschleuniger 714 (z. B. der Hardware-Beschleuniger-Cluster) kann/können für das autonome Fahren auf vielfältige Weise eingesetzt werden. Der PVA kann ein programmierbarer Bildverarbeitungsbeschleuniger sein, der für wichtige Verarbeitungsschritte in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten der PVA eignen sich gut für algorithmische Bereiche, die eine vorhersehbare Verarbeitung bei geringem Stromverbrauch und geringer Latenzzeit erfordern. Mit anderen Worten: Die PVA eignet sich gut für halbdichte oder dichte reguläre Berechnungen, selbst bei kleinen Datensätzen, die vorhersehbare Laufzeiten mit geringer Latenz und geringem Stromverbrauch erfordern. Im Zusammenhang mit Plattformen für autonome Fahrzeuge sind die PVAs daher für die Ausführung klassischer Computer-Vision-Algorithmen konzipiert, da sie bei der Objekterkennung und der Verarbeitung ganzzahliger mathematischer Daten effizient sind.
  • Beispielsweise wird gemäß einer Ausführungsform der Technologie die PVA zur Durchführung von Computer-Stereovision verwendet. In einigen Beispielen kann ein auf semiglobaler Anpassung basierender Algorithmus verwendet werden, obwohl dies nicht als Einschränkung gedacht ist. Viele Anwendungen für das autonome Fahren der Stufen 3 bis 5 erfordern eine Bewegungsabschätzung/Stereoabgleich während der Fahrt (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Die PVA kann eine Computer-Stereosichtfunktion mit Eingaben von zwei monokularen Kameras durchführen.
  • In einigen Beispielen kann die PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Entsprechend der Verarbeitung von RADAR-Rohdaten (z. B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um verarbeitete RADAR-Daten zu erhalten. In anderen Beispielen wird die PVA zur Laufzeittiefenverarbeitung verwendet, indem beispielsweise Laufzeit-Rohdaten verarbeitet werden, um verarbeitete Laufzeitdaten zu erhalten.
  • Mit dem DLA kann jede Art von Netz zur Verbesserung der Kontrolle und der Fahrsicherheit betrieben werden, beispielsweise ein neuronales Netz, das für jede Objekterkennung einen Vertrauenswert ausgibt. Ein solcher Konfidenzwert kann als Wahrscheinlichkeit interpretiert werden oder eine relative „Gewichtung“ jeder Erkennung im Vergleich zu anderen Erkennungen darstellen. Dieser Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als echte positive Erkennungen und welche als falsch-positive Erkennungen betrachtet werden sollten. Beispielsweise kann das System einen Schwellenwert für die Konfidenz festlegen und nur die Erkennungen, die diesen Schwellenwert überschreiten, als echte positive Erkennungen betrachten. In einem automatischen Notbremssystem (AEB) würden falsch positive Erkennungen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was natürlich unerwünscht ist. Daher sollten nur die sichersten Erkennungen als Auslöser für AEB in Betracht gezogen werden. Die DLA kann ein neuronales Netz zur Regression des Vertrauenswertes einsetzen. Das neuronale Netz kann als Eingabe zumindest eine Teilmenge von Parametern verwenden, wie z. B. die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Teilsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des IMU-Sensors 766, die mit der Ausrichtung des Fahrzeugs 700 korreliert, die Entfernung, die Schätzungen der 3D-Position des Objekts, die vom neuronalen Netz und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 764 oder RADAR-Sensor(en) 760) erhalten werden, und andere.
  • Der/die SoC(s) 704 kann/können Datenspeicher 716 (z. B. Speicher) enthalten. Bei dem/den Datenspeicher(n) 716 kann es sich um einen On-Chip-Speicher des/der SoC(s) 704 handeln, in dem neuronale Netze gespeichert werden können, die auf der GPU und/oder dem DLA ausgeführt werden sollen. In einigen Beispielen kann die Kapazität des/der Datenspeicher(s) 716 groß genug sein, um mehrere Instanzen von neuronalen Netzen aus Gründen der Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 712 kann/können L2 oder L3 Cache(s) 712 aufweisen. Der Verweis auf den/die Datenspeicher 716 kann einen Verweis auf den Speicher beinhalten, der mit der PVA, DLA und/oder anderen Beschleunigern 714 verbunden ist, wie hier beschrieben.
  • Der/die SoC(s) 704 kann/können einen oder mehrere Prozessor(en) 710 (z. B. eingebettete Prozessoren) enthalten. Der/die Prozessor(en) 710 kann/können einen Boot- und Energieverwaltungsprozessor enthalten, der ein dedizierter Prozessor und ein Subsystem sein kann, um die Boot-Energie- und Verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Energieverwaltungsprozessor kann Teil der Bootsequenz des/der SoC(s) 704 sein und kann Laufzeit-Energieverwaltungsdienste bereitstellen. Der Boot-Energieversorgungs- und -Verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Systemübergängen in einen Zustand mit niedriger Leistung, Verwaltung von SoC(s) 704-Temperaturen und Temperatursensoren und/oder Verwaltung der SoC(s) 704-Energieversorgungszustände bieten. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und der/die SoC(s) 704 kann/können die Ringoszillatoren verwenden, um die Temperaturen der CPU(s) 706, der GPU(s) 708 und/oder des/der Beschleuniger(s) 714 zu erfassen. Wenn festgestellt wird, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Energieverwaltungsprozessor in eine Temperaturfehlerroutine eintreten und den/die SoC(s) 704 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 700 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen (z. B. das Fahrzeug 700 zu einem sicheren Halt bringen).
  • Der (die) Prozessor(en) 710 kann (können) außerdem eine Reihe eingebetteter Prozessoren enthalten, die als Audioverarbeitungs-Engine dienen können. Bei der Audioverarbeitungs-Engine kann es sich um ein Audio-Subsystem handeln, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen sowie eine breite und flexible Palette von Audio-I/O-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM
  • Der (die) Prozessor(en) 710 kann (können) außerdem eine ständig eingeschaltete Prozessor-Engine enthalten, die die notwendigen Hardware-Funktionen zur Unterstützung der Sensorverwaltung mit geringem Stromverbrauch und des Aufwachens von Anwendungsfällen bereitstellen kann. Die ständig eingeschaltete Prozessor-Engine kann einen Prozessorkern, einen eng gekoppelten Arbeitsspeicher, unterstützende Peripheriegeräte (z. B. Zeitgeber und Interrupt-Controller), verschiedene I/O-Controller-Peripheriegeräte und Routing-Logik umfassen.
  • Der (die) Prozessor(en) 710 kann (können) außerdem eine Sicherheits-Cluster-Engine enthalten, die ein spezielles Prozessor-Subsystem für das Sicherheitsmanagement von Kfz-Anwendungen umfasst. Die Safety-Cluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten Arbeitsspeicher, unterstützende Peripheriegeräte (z. B. Zeitgeber, einen Interrupt-Controller usw.) und/oder Routing-Logik umfassen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Gleichschrittmodus arbeiten und als ein einziger Kern mit einer Vergleichslogik zur Erkennung von Unterschieden zwischen ihren Operationen fungieren.
  • Der/die Prozessor(en) 710 kann/können außerdem eine Echtzeit-Kamera-Engine enthalten, die ein spezielles Prozessor-Subsystem für die Verwaltung der Echtzeit-Kamera umfassen kann.
  • Der (die) Prozessor(en) 710 kann (können) außerdem einen Signalprozessor mit hohem Dynamikbereich enthalten, der einen Bildsignalprozessor umfassen kann, der eine Hardware-Engine ist, die Teil der Kameraverarbeitungspipeline ist.
  • Der/die Prozessor(en) 710 kann/können einen Videobild-Compositor enthalten, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Player-Fenster zu erzeugen. Der Videobild-Compositor kann eine Obj ektivverzeichnungskorrektur an der (den) Weitwinkelkamera(s) 770, der (den) Surround-Kamera(s) 774 und/oder an den Kamerasensoren für die Überwachung in der Kabine vornehmen. Der kabineninterne Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netz überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein System in der Kabine kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, das Fahrtziel zu ändern, das Infotainmentsystem und die Einstellungen des Fahrzeugs zu aktivieren oder zu ändern oder sprachgesteuertes Surfen im Internet zu ermöglichen. Bestimmte Funktionen stehen dem Fahrer nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
  • Der Videobild-Compositor kann eine verbesserte zeitliche Rauschunterdrückung sowohl zur räumlichen als auch zur zeitlichen Rauschunterdrückung enthalten. Beispielsweise gewichtet die Rauschunterdrückung bei Bewegung in einem Video die räumlichen Informationen entsprechend und verringert das Gewicht der Informationen, die von benachbarten Frames geliefert werden. Wenn ein Bild oder ein Teil eines Bildes keine Bewegung enthält, kann die vom Video-Compositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
  • Der Videobild-Compositor kann auch so konfiguriert sein, dass er eine Stereoentzerrung der eingegebenen Stereoobjektivbilder durchführt. Der Videobild-Compositor kann außerdem für die Gestaltung der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 708 nicht ständig neue Oberflächen rendern muss. Selbst wenn der/die Grafikprozessor(en) 708 eingeschaltet und aktiv mit dem 3D-Rendering beschäftigt ist/sind, kann der Videobild-Compositor verwendet werden, um den/die Grafikprozessor(en) 708 zu entlasten und die Leistung und Reaktionsfähigkeit zu verbessern.
  • Der/die SoC(s) 704 kann/können außerdem eine serielle MIPI-Kameraschnittstelle zum Empfang von Video und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock enthalten, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Der/die SoC(s) 704 kann/können außerdem einen Eingangs-/Ausgangs-Controller enthalten, der/die durch Software gesteuert werden kann/können und für den Empfang von I/O-Signalen verwendet werden kann/können, die nicht an eine bestimmte Rolle gebunden sind.
  • Der/die SoC(s) 704 kann/können außerdem eine breite Palette von Peripherieschnittstellen enthalten, um die Kommunikation mit Peripheriegeräten, Audiocodecs, Energieverwaltung und/oder anderen Geräten zu ermöglichen. Der/die SoC(s) 704 kann/können zur Verarbeitung von Daten von Kameras (z. B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LIDAR-Sensor(en) 764, RADAR-Sensor(en) 760 usw., die über Ethernet verbunden sein können), Daten vom Bus 702 (z. B. Geschwindigkeit des Fahrzeugs 700, Lenkradposition usw.), Daten von GNSS-Sensor(en) 758 (z. B. verbunden über Ethernet oder CAN-Bus) verwendet werden. Der (die) SoC(s) 704 kann (können) ferner spezielle Hochleistungs-Massenspeicher-Controller enthalten, die ihre eigenen DMA-Engines enthalten können und die dazu verwendet werden können, die CPU(s) 706 von routinemäßigen Datenverwaltungsaufgaben zu entlasten.
  • Der/die SoC(s) 704 kann/können eine End-to-End-Plattform mit einer flexiblen Architektur sein, die die Automatisierungsstufen 3 bis 5 abdeckt und dadurch eine umfassende funktionale Sicherheitsarchitektur bietet, die Computer-Vision- und ADAS-Techniken für Diversität und Redundanz nutzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Deep-Learning-Tools bereitstellt. Die SoC(s) 704 können schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Beispielsweise kann der/die Beschleuniger 714 in Kombination mit der/den CPU(s) 706, der/den GPU(s) 708 und dem/den Datenspeicher(n) 716 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Stufe 3-5 bilden.
  • Die Technologie bietet somit Fähigkeiten und Funktionen, die mit herkömmlichen Systemen nicht erreicht werden können. Beispielsweise können Computer-Vision-Algorithmen auf CPUs ausgeführt werden, die mit Hilfe von Hochsprachen wie der Programmiersprache C so konfiguriert werden können, dass sie eine Vielzahl von Verarbeitungsalgorithmen für eine Vielzahl von visuellen Daten ausführen können. Allerdings sind CPUs oft nicht in der Lage, die Leistungsanforderungen vieler Bildverarbeitungsanwendungen zu erfüllen, beispielsweise in Bezug auf die Ausführungszeit und den Stromverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, was eine Voraussetzung für fahrzeuginterne ADAS-Anwendungen und eine Voraussetzung für praktische autonome Fahrzeuge der Stufe 3-5 ist.
  • Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungs-Clusters, dass mehrere neuronale Netze gleichzeitig und/oder nacheinander ausgeführt und die Ergebnisse miteinander kombiniert werden können, um autonome Fahrfunktionen der Stufe 3-5 zu ermöglichen. Beispielsweise kann ein CNN, das auf der DLA oder dGPU (z. B. die GPU(s) 720) ausgeführt wird, eine Text- und Worterkennung umfassen, die es dem Supercomputer ermöglicht, Verkehrsschilder zu lesen und zu verstehen, einschließlich Schildern, für die das neuronale Netz nicht speziell trainiert wurde. Die DLA kann ferner ein neuronales Netz enthalten, das in der Lage ist, das Verkehrszeichen zu identifizieren, zu interpretieren und semantisch zu verstehen und dieses semantische Verständnis an die auf dem CPU-Komplex laufenden Wegplanungsmodule weiterzugeben.
  • Ein weiteres Beispiel ist, dass mehrere neuronale Netze gleichzeitig betrieben werden können, wie es für das Fahren der Stufen 3, 4 oder 5 erforderlich ist. So kann beispielsweise ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Glatteis hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzen unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netz (z. B. einem trainierten neuronalen Netz) als Verkehrsschild identifiziert werden, der Text „Blinkende Lichter deuten auf Glatteis hin“ kann von einem zweiten eingesetzten neuronalen Netz interpretiert werden, das die Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass, wenn blinkende Lichter erkannt werden, Glatteis vorliegt. Das Blinklicht kann durch den Betrieb eines dritten neuronalen Netzes über mehrere Frames hinweg identifiziert werden, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. Alle drei neuronalen Netze können gleichzeitig laufen, z. B. innerhalb der DLA und/oder auf der/den GPU(s) 708.
  • 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 700 zu erkennen. Die ständig eingeschaltete Sensorverarbeitungs-Engine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn der Besitzer sich der Fahrertür nähert und die Lichter einschaltet, und um im Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgen die SoC(s) 704 für Sicherheit gegen Diebstahl und/oder Carjacking.
  • In einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 796 verwenden, um Sirenen von Einsatzfahrzeugen zu erkennen und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Erkennung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, nutzen die SoC(s) 704 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung visueller Daten. In einer bevorzugten Ausführungsform wird der CNN, der auf dem DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu erkennen (z. B. durch Verwendung des Dopplereffekts). Das CNN kann auch so trainiert werden, dass es Einsatzfahrzeuge erkennt, die spezifisch für das örtliche Gebiet sind, in dem das Fahrzeug unterwegs ist, wie es von dem/den GNSS-Sensor(en) 758 identifiziert wird. So wird beispielsweise bei einem Einsatz in Europa das CNN versuchen, europäische Sirenen zu erkennen, und bei einem Einsatz in den Vereinigten Staaten wird das CNN versuchen, nur nordamerikanische Sirenen zu erkennen. Sobald ein Einsatzfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge auszuführen, das Fahrzeug zu verlangsamen, an den Straßenrand zu fahren, das Fahrzeug zu parken und/oder das Fahrzeug mit Hilfe der Ultraschallsensoren 762 im Leerlauf laufen zu lassen, bis das/die Einsatzfahrzeug(e) vorbeifahren.
  • Das Fahrzeug kann eine oder mehrere CPU(s) 718 (z. B. diskrete CPU(s) oder dCPU(s)) enthalten, die über eine Hochgeschwindigkeitsverbindung (z. B. PCIe) mit dem/den SoC(s) 704 gekoppelt sein können. Die CPU(s) 718 kann/können beispielsweise einen X86-Prozessor enthalten. Die CPU(s) 718 kann/können verwendet werden, um eine Vielzahl von Funktionen auszuführen, einschließlich der Schlichtung potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und dem/den SoC(s) 704 und/oder der Überwachung des Status und Zustands des/der Controller(s) 736 und/oder des Infotainment-SoC 730, beispielsweise.
  • Das Fahrzeug 700 kann eine oder mehrere GPU(s) 720 (z. B. diskrete GPU(s) oder dGPU(s)) enthalten, die über eine Hochgeschwindigkeitsverbindung (z. B. NVIDIAs NVLINK) mit dem/den SoC(s) 704 gekoppelt sein können. Der/die Grafikprozessor(en) 720 kann/können zusätzliche Funktionen der künstlichen Intelligenz bereitstellen, z. B. durch die Ausführung redundanter und/oder unterschiedlicher neuronaler Netze, und kann/können zum Trainieren und/oder Aktualisieren neuronaler Netze basierend auf Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 700 verwendet werden.
  • Das Fahrzeug 700 kann ferner die Netzwerkschnittstelle 724 enthalten, die eine oder mehrere drahtlose Antennen 726 umfassen kann (z. B. eine oder mehrere drahtlose Antennen für verschiedene Kommunikationsprotokolle, wie eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzwerkschnittstelle 724 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit dem/den Server(n) 778 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 den beiden Fahrzeugen und/oder eine indirekte Verbindung hergestellt werden (z. B. über Netzwerke und das Internet). Direkte Verbindungen können über eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 700 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 700 liefern (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 700). Diese Funktion kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 700 sein.
  • Die Netzwerkschnittstelle 724 kann einen SoC enthalten, der Modulations- und Demodulationsfunktionen bereitstellt und den/die Controller 736 in die Lage versetzt, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 724 kann ein Funkfrequenz-Frontend für die Aufwärtskonvertierung von Basisband auf Funkfrequenz und die Abwärtskonvertierung von Funkfrequenz auf Basisband enthalten. Die Frequenzumwandlungen können mit bekannten Verfahren und/oder mit Superheterodyn-Verfahren durchgeführt werden. In einigen Beispielen kann die Hochfrequenz-Front-End-Funktionalität durch einen separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann drahtlose Funktionen für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle enthalten.
  • Das Fahrzeug 700 kann ferner einen oder mehrere Datenspeicher 728 umfassen, die außerhalb des Chips (z. B. außerhalb der SoC(s) 704) gespeichert werden können. Der/die Datenspeicher 728 kann/können ein oder mehrere Speicherelemente wie RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte umfassen, die mindestens ein Datenbit speichern können.
  • Das Fahrzeug 700 kann außerdem GNSS-Sensor(en) 758 enthalten. Der/die GNSS-Sensor(en) 758 (z. B. GPS, unterstützte GPS-Sensoren, Differential-GPS-Sensoren (DGPS) usw.) unterstützen bei der Kartierung, Wahrnehmung, Erstellung von Belegungsrastern und/oder Pfadplanungsfunktionen. Es kann eine beliebige Anzahl von GNSS-Sensoren 758 verwendet werden, beispielsweise und ohne Einschränkung ein GPS, das einen USB-Anschluss mit einer Ethernet-zu-Seriell (RS-232)-Brücke verwendet.
  • Das Fahrzeug 700 kann außerdem RADAR-Sensor(en) 760 enthalten. Der/die RADAR-Sensor(en) 760 kann/können vom Fahrzeug 700 für die Fahrzeugerkennung über große Entfernungen verwendet werden, selbst bei Dunkelheit und/oder schlechten Wetterbedingungen. Der/die RADAR-Sensor(en) 760 kann/können den CAN-Bus und/oder den Bus 702 (z. B. zur Übertragung der von dem/den RADAR-Sensor(en) 760 erzeugten Daten) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten nutzen, wobei in einigen Beispielen der Zugriff auf Rohdaten über Ethernet möglich ist. Es kann eine Vielzahl von RADAR-Sensortypen verwendet werden. Beispielsweise und ohne Einschränkung kann der RADAR-Sensor (bzw. können die RADAR-Sensoren) 760 für den Front-, Heck- und Seiten-RADAR-Einsatz geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensoren verwendet.
  • Der/die RADAR-Sensor(en) 760 kann/können verschiedene Konfigurationen umfassen, wie z. B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit breitem Sichtfeld, seitliche Abdeckung kurzer Reichweite usw. In einigen Beispielen kann RADAR mit großer Reichweite für die adaptive Geschwindigkeitsregelung verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein breites Sichtfeld bieten, das durch zwei oder mehr unabhängige Abtastungen realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 760 kann/können helfen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und kann/können von ADAS-Systemen für Notbremsassistenten und Vorwärtskollisionswarnungen verwendet werden. Zu den RADAR-Langstreckensensoren können monostatische multimodale RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle gehören. In einem Beispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu dient, die Umgebung des Fahrzeugs bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den angrenzenden Fahrspuren zu erfassen. Die beiden anderen Antennen können das Sichtfeld erweitern, so dass Fahrzeuge, die in die Fahrspur des Fahrzeugs einfahren oder diese verlassen, schnell erfasst werden können.
  • RADAR-Systeme mit mittlerer Reichweite können beispielsweise eine Reichweite von bis zu 760 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 750 Grad (hinten) aufweisen. Zu den RADAR-Systemen mit geringer Reichweite können unter anderem RADAR-Sensoren gehören, die an beiden Enden des hinteren Stoßfängers angebracht werden. Wenn ein solches RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers angebracht ist, kann es zwei Strahlen erzeugen, die den toten Winkel hinter und neben dem Fahrzeug ständig überwachen.
  • RADAR-Systeme mit geringer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder als Spurwechselassistent eingesetzt werden.
  • Das Fahrzeug 700 kann außerdem einen oder mehrere Ultraschallsensoren 762 enthalten. Der/die Ultraschallsensor(en) 762, der/die vorne, hinten und/oder an den Seiten des Fahrzeugs 700 angebracht sein kann/können, kann/können zur Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsrasters verwendet werden. Es kann eine Vielzahl von Ultraschallsensoren 762 verwendet werden, und unterschiedliche Ultraschallsensoren 762 können für unterschiedliche Erfassungsbereiche (z. B. 2,5 m, 4 m) eingesetzt werden. Der/die Ultraschallsensor(en) 762 kann/können bei funktionalen Sicherheitsstufen von ASIL B arbeiten.
  • Das Fahrzeug 700 kann LIDAR-Sensor(en) 764 enthalten. Der/die LIDAR-Sensor(en) 764 kann/können für Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 764 kann/können der funktionalen Sicherheitsstufe ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 700 mehrere LIDAR-Sensoren 764 (z. B. zwei, vier, sechs usw.) umfassen, die Ethernet verwenden können (z. B. um Daten an einen Gigabit-Ethernet-Switch zu liefern).
  • In einigen Beispielen kann der/die LIDAR-Sensor(en) 764 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld zu liefern. Im Handel erhältliche LIDAR-Sensoren 764 können eine Reichweite von etwa 700 m haben, mit einer Genauigkeit von 2 cm bis 3 cm, und beispielsweise eine Ethernet-Verbindung mit 700 Mbit/s unterstützen. In einigen Beispielen können ein oder mehrere nicht vorspringende LIDAR-Sensoren 764 verwendet werden. In solchen Beispielen kann/können der/die LIDAR-Sensor(en) 764 als ein kleines Gerät implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 700 eingebettet werden kann. Der/die LIDAR-Sensor(en) 764 kann/können in solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von 35 Grad bieten, mit einer Reichweite von 200 m, selbst bei Objekten mit geringer Reflektivität. Der/die frontmontierte(n) LIDAR-Sensor(en) 764 kann/können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert werden.
  • In einigen Beispielen können auch LIDAR-Technologien wie 3D-Flash-LIDAR eingesetzt werden. 3D-Flash-LIDAR verwendet einen Laserblitz als Übertragungsquelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von etwa 200 m zu beleuchten. Eine Flash-LIDAR-Einheit umfasst einen Empfänger, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum der Entfernung zwischen dem Fahrzeug und den Objekten entspricht. Mit Flash-LIDAR lassen sich mit jedem Laserblitz hochpräzise und verzeichnungsfreie Bilder der Umgebung erzeugen. In einigen Beispielen können vier Flash-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 700. Zu den verfügbaren 3D-Flash-LIDAR-Systemen gehört eine Festkörper-3D-Star-Array-LIDAR-Kamera, die außer einem Gebläse keine beweglichen Teile aufweist (z. B. ein nicht scannendes LIDAR-Gerät). Das Flash-LIDAR-Gerät kann einen 5-Nanosekunden-Laserimpuls der Klasse I (augensicher) pro Bild verwenden und das reflektierte Laserlicht in Form von 3D-Entfernungspunktwolken und gemeinsam registrierten Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR und weil Flash-LIDAR ein Festkörpergerät ohne bewegliche Teile ist, kann der/die LIDAR-Sensor(en) 764 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße sein.
  • Das Fahrzeug kann außerdem IMU-Sensor(en) 766 enthalten. Der/die IMU-Sensor(en) 766 kann/können in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 700 angeordnet sein. Der (die) IMU-Sensor(en) 766 kann (können) beispielsweise und ohne Einschränkung einen (mehrere) Beschleunigungsmesser, einen (mehrere) Magnetometer, ein (mehrere) Gyroskop(e), einen (mehrere) Magnetkompass(e) und/oder andere Sensortypen umfassen. In einigen Beispielen, beispielsweise bei sechsachsigen Anwendungen, kann/können der/die IMU-Sensor(en) 766 Beschleunigungsmesser und Gyroskope umfassen, während bei neunachsigen Anwendungen der/die IMU-Sensor(en) 766 Beschleunigungsmesser, Gyroskope und Magnetometer umfassen können.
  • In einigen Ausführungsformen kann/können der/die IMU-Sensor(en) 766 als ein miniaturisiertes, hochleistungsfähiges GPS-gestütztes Trägheitsnavigationssystem (GPS/INS) implementiert werden, das mikroelektromechanische Trägheitssensoren (MEMS), einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage zu liefern. So kann in einigen Beispielen der/die IMU-Sensor(en) 766 das Fahrzeug 700 in die Lage versetzen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem die Geschwindigkeitsänderungen von GPS direkt beobachtet und mit dem/den IMU-Sensor(en) 766 korreliert werden. In einigen Beispielen können der/die IMU-Sensor(en) 766 und der/die GNSS-Sensor(en) 758 in einer einzigen integrierten Einheit kombiniert werden.
  • Das Fahrzeug kann ein oder mehrere Mikrofone 796 enthalten, die im und/oder um das Fahrzeug 700 herum angebracht sind. Das/die Mikrofon(e) 796 kann/können u. a. zur Erkennung und Identifizierung von Einsatzfahrzeugen verwendet werden.
  • Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen enthalten, einschließlich Stereokamera(s) 768, Weitwinkelkamera(s) 770, Infrarotkamera(s) 772, Umgebungskamera(s) 774, Fern- und/oder Mittelbereichskamera(s) 798 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten rund um den gesamten Umfang des Fahrzeugs 700 zu erfassen. Die verwendeten Kameratypen hängen von den Ausführungsformen und Anforderungen an das Fahrzeug 700 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 700 herum zu gewährleisten. Darüber hinaus kann die Anzahl der Kameras je nach Ausführungsform unterschiedlich sein. Beispielsweise kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras enthalten. Die Kameras können, beispielsweise und ohne Einschränkung, Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras wird hierin in Bezug auf 7A und 7B ausführlicher beschrieben.
  • Das Fahrzeug 700 kann außerdem einen oder mehrere Schwingungssensoren 742 enthalten. Der/die Schwingungssensor(en) 742 kann/können Schwingungen von Komponenten des Fahrzeugs, wie z. B. der Achse(n), messen. Beispielsweise können Änderungen der Schwingungen eine Änderung der Straßenoberfläche anzeigen. Werden beispielsweise zwei oder mehr Schwingungssensoren 742 verwendet, können die Unterschiede zwischen den Schwingungen zur Bestimmung der Reibung oder des Schlupfes der Fahrbahnoberfläche herangezogen werden (z. B., wenn der Unterschied in den Schwingungen zwischen einer angetriebenen Achse und einer frei drehenden Achse besteht).
  • Das Fahrzeug 700 kann ein ADAS-System 738 enthalten. Das ADAS-System 738 kann in einigen Beispielen einen SoC enthalten. Das ADAS-System 738 kann einen autonomen/adaptiven/automatischen Geschwindigkeitsregler (ACC), einen kooperativen adaptiven Geschwindigkeitsregler (CACC), eine Auffahrwarnung (FCW), eine automatische Notbremsung (AEB), eine Spurverlassenswarnung (LDW), einen Spurhalteassistenten (LKA), einen Toter-Winkel-Warner (BSW), einen Querverkehrswarner (RCTW), ein Kollisionswarnsystem (CWS), eine Fahrspurzentrierung (LC) und/oder andere Merkmale und Funktionen umfassen.
  • Die ACC-Systeme können RADAR-Sensor(en) 760, LIDAR-Sensor(en) 764 und/oder eine Kamera(en) verwenden. Die ACC-Systeme können einen ACC in Längsrichtung und/oder einen ACC in Querrichtung umfassen. Der ACC in Längsrichtung überwacht und steuert den Abstand zu dem unmittelbar vor dem Fahrzeug 700 befindlichen Fahrzeug und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Der seitliche ACC sorgt für die Einhaltung des Abstands und rät dem Fahrzeug 700, wenn nötig die Spur zu wechseln. Lateral ACC ist mit anderen ADAS-Anwendungen wie LCA und CWS verwandt.
  • CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 724 und/oder die Funkantenne(n) 726 von anderen Fahrzeugen über eine drahtlose Verbindung oder indirekt über eine Netzwerkverbindung (z. B. über das Internet) empfangen werden können. Direkte Verbindungen können über eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung (V2V) hergestellt werden, während indirekte Verbindungen eine Infrastruktur-zu-Fahrzeug-Kommunikationsverbindung (I2V) sein können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Informationen über die unmittelbar vorausfahrenden Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem Fahrzeug 700 und auf derselben Fahrspur wie dieses befinden), während das I2V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr liefert. CACC-Systeme können eine oder beide I2V- und V2V-Informationsquellen enthalten. Angesichts der Informationen über die Fahrzeuge vor dem Fahrzeug 700 kann CACC zuverlässiger sein und hat das Potenzial, den Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
  • FCW-Systeme sind so konzipiert, dass sie den Fahrer vor einer Gefahr warnen, so dass er korrigierend eingreifen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 760, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung ausgeben, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
  • AEB-Systeme erkennen einen drohenden Zusammenstoß mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines bestimmten Zeit- oder Entfernungsparameters korrigierend eingreift. AEB-Systeme können nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 760 verwenden, die mit einem speziellen 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. Wenn der Fahrer keine korrigierenden Maßnahmen ergreift, kann das AEB-System automatisch die Bremsen betätigen, um die Auswirkungen der vorhergesagten Kollision zu verhindern oder zumindest abzumildern. AEB-Systeme können Techniken wie die dynamische Bremsunterstützung und/oder die Crash-Imminent-Bremsung umfassen.
  • LDW-Systeme warnen den Fahrer durch optische, akustische und/oder taktile Signale, z. B. durch Vibrationen am Lenkrad oder am Sitz, wenn das Fahrzeug 700 die Fahrbahnmarkierungen überfährt. 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 speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • LKA-Systeme sind eine Variante von LDW-Systemen. LKA-Systeme sorgen für einen Lenkeingriff oder eine Bremsung, um das Fahrzeug 700 zu korrigieren, wenn das Fahrzeug 700 beginnt, die Fahrspur zu verlassen.
  • BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen im toten Winkel des Fahrzeugs. BSW-Systeme können ein optisches, akustisches und/oder taktiles Warnsignal ausgeben, um darauf hinzuweisen, dass das Zusammenführen oder Wechseln der Fahrspur unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker betätigt. BSW-Systeme können nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 760 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente.
  • RCTW-Systeme können eine optische, akustische und/oder taktile Benachrichtigung ausgeben, wenn beim Rückwärtsfahren des Fahrzeugs 700 ein Objekt außerhalb des Bereichs der Heckkamera erkannt wird. Einige RCTW-Systeme umfassen AEB, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensoren 760 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit dem Fahrerfeedback gekoppelt ist, z. B. mit einem Display, Lautsprecher und/oder einer vibrierenden Komponente.
  • Bei herkömmlichen ADAS-Systemen kann es zu falsch-positiven Ergebnissen kommen, die für den Fahrer ärgerlich und ablenkend sein können, aber in der Regel nicht katastrophal sind, weil die ADAS-Systeme den Fahrer warnen und ihm die Möglichkeit geben, zu entscheiden, ob wirklich ein Sicherheitszustand vorliegt und entsprechend zu handeln. In einem autonomen Fahrzeug 700 muss das Fahrzeug 700 jedoch im Falle widersprüchlicher Ergebnisse selbst entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. eines ersten Controllers 736 oder eines zweiten Controllers 736) beherzigen soll. Beispielsweise kann in einigen Ausführungsformen das ADAS-System 738 ein Backup- und/oder Sekundärcomputer sein, der Wahrnehmungsinformationen an ein Rationalitätsmodul des Backup-Computers liefert. Der Rationalitätsmonitor des Backup-Rechners kann eine redundante, diverse Software auf Hardwarekomponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahraufgaben zu erkennen. Die Ausgaben des ADAS-Systems 738 können an eine Überwachungs-MCU weitergeleitet werden. Wenn die Ausgaben des Primärrechners und des Sekundärrechners kollidieren, muss die Überwachungs-MCU bestimmen, wie der Konflikt gelöst werden kann, um einen sicheren Betrieb zu gewährleisten.
  • In einigen Beispielen kann der Primärcomputer so konfiguriert sein, dass er der Überwachungs-MCU einen Konfidenzwert liefert, der das Vertrauen des Primärcomputers in das gewählte Ergebnis angibt. Übersteigt der Konfidenzwert einen Schwellenwert, kann die Überwachungs-MCU der Anweisung des Primärcomputers folgen, unabhängig davon, ob der Sekundärcomputer ein widersprüchliches oder inkonsistentes Ergebnis liefert. Erreicht der Konfidenzwert den Schwellenwert nicht und geben der primäre und der sekundäre Computer unterschiedliche Ergebnisse an (z. B. den Konflikt), kann die Überwachungs-MCU zwischen den Computern vermitteln, um das geeignete Ergebnis zu bestimmen.
  • Die Überwachungs-MCU kann so konfiguriert sein, dass sie ein neuronales Netz(e) ausführt, das so trainiert und konfiguriert ist bzw. sind, dass es basierend auf den Ausgaben des Primärcomputers und des Sekundärcomputers die Bedingungen bestimmt, unter denen der Sekundärcomputer Fehlalarme auslöst. So kann das neuronale Netz(e) in der Überwachungs-MCU lernen, wann der Ausgabe des Sekundärcomputers vertraut werden kann und wann nicht. Handelt es sich beispielsweise bei dem sekundären Computer um ein RADARbasiertes FCW-System, kann ein neuronales Netzwerk in der Überwachungs-MCU lernen, wann das FCW-System metallische Objekte identifiziert, die in Wirklichkeit keine Gefahren darstellen, wie etwa ein Abflussgitter oder ein Schachtdeckel, der einen Alarm auslöst. Wenn der Sekundärcomputer ein kamerabasiertes LDW-System ist, kann ein neuronales Netz in der Überwachungs-MCU lernen, das LDW-System zu übergehen, wenn Radfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, in denen ein neuronales Netz bzw. neuronale Netze auf der Überwachungs-MCU laufen, kann die Überwachungs-MCU mindestens eine DLA oder eine GPU enthalten, die für den Betrieb des neuronalen Netzes bzw. der neuronalen Netze mit zugehörigem Speicher geeignet ist. In bevorzugten Ausführungsformen kann die Überwachungs-MCU das aufweisen und/oder als eine Komponente des/der SoC(s) 704 enthalten sein.
  • In anderen Beispielen kann das ADAS-System 738 einen sekundären Computer umfassen, der die ADAS-Funktionen unter Verwendung herkömmlicher Regeln der Computer Vision ausführt. Der sekundäre Computer kann also klassische Regeln der Computer Vision verwenden (wenn-dann), und das Vorhandensein eines neuronalen Netzes (von neuronalen Netzen) in der Überwachungs-MCU kann die Zuverlässigkeit, Sicherheit und Leistung verbessern. Beispielsweise wird das Gesamtsystem durch die unterschiedliche Implementierung und die absichtliche Nichtidentität fehlertoleranter, insbesondere gegenüber Fehlern, die durch Softwarefunktionen (oder Software-Hardware-Schnittstellen) verursacht werden. Wenn beispielsweise ein Softwarefehler in der auf dem Primärcomputer laufenden Software auftritt und der nicht identische Softwarecode auf dem Sekundärcomputer das gleiche Gesamtergebnis liefert, kann die Überwachungs-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 738 in den Wahrnehmungsblock des Primärrechners und/oder in den Block für dynamische Fahraufgaben des Primärrechners eingespeist werden. Wenn beispielsweise das ADAS-System 738 eine Warnung vor einem Aufprall aufgrund eines unmittelbar vorausfahrenden Objekts anzeigt, kann der Wahrnehmungsblock 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 somit das Risiko von Fehlalarmen reduziert, wie hier beschrieben.
  • Das Fahrzeug 700 kann außerdem das Infotainment-SoC 730 (z. B. ein bordeigenes Infotainment-System (IVI)) enthalten. Obwohl das Infotainment-System als SoC dargestellt und beschrieben wird, muss es nicht unbedingt ein SoC sein, sondern kann auch zwei oder mehr diskrete Komponenten umfassen. Das Infotainment-SoC 730 kann eine Kombination aus Hardware und Software enthalten, die zur Bereitstellung von Audio (z. B. Musik, einem persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon (z. B. Freisprechen), Netzwerkkonnektivität (z. B., LTE, Wi-Fi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Einparkhilfe hinten, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremskraftstoffstand, Ölstand, Tür öffnen/schließen, Luftfilterinformationen usw.) an das Fahrzeug 700. Beispielsweise kann der Infotainment-SoC 730 Radios, Plattenspieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Audiobedienelemente am Lenkrad, Freisprecheinrichtung, ein Heads-up-Display (HUD), ein HMI-Display 734, ein Telematikgerät, ein Bedienfeld (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten umfassen. Der Infotainment-SoC 730 kann ferner verwendet werden, um einem oder mehreren Nutzern des Fahrzeugs Informationen (z. B. visuell und/oder akustisch) bereitzustellen, wie etwa Informationen vom ADAS-System 738, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
  • Der Infotainment-SoC 730 kann GPU-Funktionen enthalten. Der Infotainment-SoC 730 kann über den Bus 702 (z. B. CAN-Bus, Ethernet usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 700 kommunizieren. In einigen Beispielen kann der Infotainment-SoC 730 mit einer Überwachungs-MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primäre(n) Steuereinheit(en) 736 (z. B. die primären und/oder Backup-Computer des Fahrzeugs 700) ausfallen. In einem solchen Beispiel kann der Infotainment-SoC 730 das Fahrzeug 700 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen, wie hier beschrieben.
  • Das Fahrzeug 700 kann ferner ein Kombiinstrument 732 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) enthalten. Das Kombiinstrument 732 kann einen Controller und/oder einen Supercomputer (z. B. einen diskreten Controller oder einen Supercomputer) enthalten. Das Kombiinstrument 732 kann eine Reihe von Instrumenten enthalten, wie z. B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltstellungsanzeige, Sicherheitsgurt-Warnleuchte(n), Feststellbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Informationen über das Airbag-System (SRS), Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen usw. In einigen Beispielen können die Informationen vom Infotainment-SoC 730 und dem Kombiinstrument 732 angezeigt und/oder gemeinsam genutzt werden. Mit anderen Worten: Das Kombiinstrument 732 kann Teil des Infotainment-SoC 730 sein oder umgekehrt.
  • 7D ist ein Systemdiagramm für die Kommunikation zwischen cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug 700 aus 7A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System 776 kann den/die Server 778, das/die Netzwerk(e) 790 und die Fahrzeuge, einschließlich des Fahrzeugs 700, umfassen. Der (die) Server 778 kann (können) eine Vielzahl von GPUs 784(A)-784(H) (hier zusammenfassend als GPUs 784 bezeichnet), PCIe-Switches 782(A)-782(H) (hier zusammenfassend als PCIe-Switches 782 bezeichnet) und/oder CPUs 780(A)-780(B) (hier zusammenfassend als CPUs 780 bezeichnet) umfassen. Die GPUs 784, die CPUs 780 und die PCIe-Switches können mit Hochgeschwindigkeitsverbindungen wie beispielsweise und ohne Einschränkung mit den von NVIDIA entwickelten NVLink-Schnittstellen 788 und/oder PCIe-Verbindungen 786 miteinander verbunden werden. In einigen Beispielen sind die GPUs 784 über NVLink und/oder NVSwitch SoC und die GPUs 784 und die PCIe-Switches 782 über PCIe-Verbindungen verbunden. Obwohl acht GPUs 784, zwei CPUs 780 und zwei PCIe-Switches abgebildet sind, ist dies nicht als Einschränkung zu verstehen. Je nach Ausführungsform kann jeder der Server 778 eine beliebige Anzahl von GPUs 784, CPUs 780 und/oder PCIe-Switches umfassen. Beispielsweise können die Server 778 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 784 enthalten.
  • Der (die) Server 778 kann (können) über das (die) Netzwerk(e) 790 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenzustände zeigen, z. B. kürzlich begonnene Straßenarbeiten. Der (die) Server 778 kann (können) über das (die) Netzwerk(e) 790 und an die Fahrzeuge neuronale Netze 792, aktualisierte neuronale Netze 792 und/oder Karteninformationen 794, einschließlich Informationen über Verkehrs- und Straßenbedingungen, übertragen. Die Aktualisierungen der Karteninformationen 794 können Aktualisierungen für die HD-Karte 722 enthalten, z. B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In einigen Beispielen können die neuronalen Netze 792, die aktualisierten neuronalen Netze 792 und/oder die Karteninformationen 794 aus neuem Training und/oder Erfahrungen resultieren, die in Daten dargestellt sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder auf einem Training basieren, das in einem Datenzentrum durchgeführt wurde (z. B. unter Verwendung des/der Server(s) 778 und/oder anderer Server).
  • Der/die Server 778 kann/können verwendet werden, um maschinelle Lernmodelle (z. B. neuronale Netze) basierend auf 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 werden die Trainingsdaten mit Tags versehen (z. B., wenn das neuronale Netz vom überwachten Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B., wenn das neuronale Netz kein überwachtes Lernen benötigt). Das Training kann nach einer oder mehreren Klassen von maschinellen Lerntechniken durchgeführt werden, einschließlich, aber nicht beschränkt auf Klassen wie: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, selbstlernendes Lernen, Verstärkungslernen, föderiertes Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraumlernen, vielfältiges Lernen, Repräsentationslemen (einschließlich Lernen mit Ersatzwörterbüchern), regelbasiertes maschinelles Lernen, Anomalieerkennung und alle Varianten oder Kombinationen davon. Sobald die maschinellen Lernmodelle trainiert sind, können die maschinellen Lernmodelle von den Fahrzeugen verwendet werden (z. B. durch Übertragung an die Fahrzeuge über das/die Netzwerk(e) 790 und/oder die maschinellen Lernmodelle können von dem/den Server(n) 778 zur Fernüberwachung der Fahrzeuge verwendet werden.
  • In einigen Beispielen kann der Server 778 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Netze in Echtzeit anwenden, um intelligente Schlussfolgerungen in Echtzeit zu ziehen. Der/die Server 778 kann/können Deep-Learning-Supercomputer und/oder dedizierte KI-Computer umfassen, die von GPUs 784 angetrieben werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen können die Server 778 jedoch auch Deep-Learning-Infrastrukturen umfassen, die nur CPU-betriebene Rechenzentren verwenden.
  • Die Deep-Learning-Infrastruktur des Servers 778 kann zu schnellem Echtzeit-Inferenz fähig sein und kann diese Fähigkeit nutzen, um den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware im Fahrzeug 700 zu bewerten und zu überprüfen. Beispielsweise kann die Deep-Learning-Infrastruktur regelmäßige Aktualisierungen vom Fahrzeug 700 erhalten, wie etwa eine Abfolge von Bildern und/oder Objekten, die das Fahrzeug 700 in dieser Abfolge von Bildern lokalisiert hat (z. B. über Computer Vision und/oder andere maschinelle Objektklassifizierungstechniken). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netz laufen lassen, um die Objekte zu identifizieren und sie mit den vom Fahrzeug 700 identifizierten Objekten zu vergleichen. Wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 700 nicht richtig funktioniert, kann der Server (oder die Server) 778 ein Signal an das Fahrzeug 700 senden, das einen ausfallsicheren Computer des Fahrzeugs 700 anweist, die Kontrolle zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
  • Zur Inferenz kann der/die Server 778 die GPU(s) 784 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT von NVIDIA) enthalten. Die Kombination von GPU-gesteuerten Servern und Inferenzbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, etwa wenn die Leistung weniger kritisch ist, können Server mit CPUs, FPGAs und anderen Prozessoren für die Inferenz verwendet werden.
  • Beispielhafte Rechenvorrichtung
  • 8 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung(en) 800, die zur Verwendung beim Implementieren einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist. Die Rechenvorrichtung 800 kann ein Verbindungssystem 802 enthalten, das direkt oder indirekt die folgenden Vorrichtungen koppelt: Speicher 804, eine oder mehrere Zentraleinheiten (CPUs) 806, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 808, eine Kommunikationsschnittstelle 810, Ein-/Ausgabe (I/O) Ports 812, Ein-/Ausgabekomponenten 814, eine Stromversorgung 816, eine oder mehrere Präsentationskomponenten 818 (z. B. Anzeige(n)) und eine oder mehrere Logikeinheiten 820. In mindestens einer Ausführungsform kann das (die) Computergerät(e) 800 eine oder mehrere virtuelle Maschinen (VMs) aufweisen, und/oder jede der Komponenten davon kann virtuelle Komponenten aufweisen (z. B. virtuelle Hardwarekomponenten). Als nicht einschränkende Beispiele können eine oder mehrere der GPUs 808 eine oder mehrere vGPUs aufweisen, eine oder mehrere der CPUs 806 können eine oder mehrere vCPUs aufweisen, und/oder eine oder mehrere der Logikeinheiten 820 können eine oder mehrere virtuelle Logikeinheiten aufweisen. Als solche kann (können) eine (mehrere) Rechenvorrichtung(en) 800 diskrete Komponenten (z. B. eine vollständige GPU, die der Rechenvorrichtung 800 gewidmet ist), virtuelle Komponenten (z. B. einen Teil einer GPU, die der Rechenvorrichtung 800 gewidmet ist) oder eine Kombination davon umfassen.
  • Obwohl die verschiedenen Blöcke in 8 als über das Verbindungssystem 802 mit Leitungen verbunden dargestellt sind, ist dies nicht als Einschränkung zu verstehen und dient nur der Klarheit. Beispielsweise kann in einigen Ausführungsformen eine Präsentationskomponente 818, wie ein Anzeigegerät, als I/O-Komponente 814 betrachtet werden (z. B., wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 806 und/oder GPUs 808 Speicher enthalten (z. B. kann der Speicher 804 zusätzlich zum Speicher der GPUs 808, der CPUs 806 und/oder anderer Komponenten ein Speichergerät darstellen). Mit anderen Worten, die Rechenvorrichtung von 8 ist lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da sie alle in den Anwendungsbereich der Rechenvorrichtung von 8 fallen.
  • Das Verbindungssystem 802 kann eine oder mehrere Verbindungen oder Busse darstellen, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verbindungssystem 802 kann einen oder mehrere Bus- oder Verbindungstypen 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 eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen den Komponenten. Beispielsweise kann die CPU 806 direkt mit dem Speicher 804 verbunden sein. Außerdem kann die CPU 806 direkt mit der GPU 808 verbunden sein. Bei direkten oder Punkt-zu-Punkt-Verbindungen zwischen Komponenten kann das Verbindungssystem 802 eine PCIe-Verbindung enthalten, um die Verbindung herzustellen. In diesen Beispielen muss ein PCI-Bus nicht in der Datenverarbeitungsvorrichtung 800 enthalten sein.
  • Der Speicher 804 kann aus einer Vielzahl von computerlesbaren Medien bestehen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Computergerät 800 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie entfernbare und nicht-entfernbare Medien umfassen. Beispielsweise können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien aufweisen, ohne darauf beschränkt zu sein.
  • Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen wie computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Beispielsweise kann der Speicher 804 computerlesbare Anweisungen speichern (z.B., die ein oder mehrere Programme und/oder ein oder mehrere Programmelemente darstellen, wie z.B. ein Betriebssystem. Zu den Computerspeichermedien können unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium gehören, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das die Rechenvorrichtung 800 zugreifen kann. Wie hierin verwendet, weisen Computerspeichermedien nicht per se Signale auf.
  • Die Computerspeichermedien können computerlesbare Befehle, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal wie z. B. einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und umfassen beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert sind, dass Informationen in dem Signal kodiert werden. Beispielsweise können die Computerspeichermedien verdrahtete Medien, wie ein verdrahtetes Netzwerk oder eine Direktverbindung, und drahtlose Medien, wie akustische, RF- , Infrarot- und andere drahtlose Medien, umfassen. Kombinationen der oben genannten Medien sollten ebenfalls in den Bereich der computerlesbaren Medien fallen.
  • Die CPU(s) 806 kann/können so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Computergeräts 800 zu steuern und eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 806 kann/können jeweils einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) umfassen, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 806 kann/können jeden Prozessortyp umfassen und je nach Art der implementierten Rechenvorrichtung 800 unterschiedliche Prozessortypen umfassen (z. B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Beispielsweise kann der Prozessor je nach Art der Rechenvorrichtung 800 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 800 kann eine oder mehrere CPUs 806 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Co-Prozessoren, wie z. B. mathematischen Co-Prozessoren, enthalten.
  • Zusätzlich zu oder alternativ zu der/den CPU(s) 806 kann/können die GPU(s) 808 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Computergeräts 800 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 808 können eine integrierte GPU sein (z.B. mit einer oder mehreren der CPU(s) 806 und/oder eine oder mehrere der GPU(s) 808 können eine diskrete GPU sein. In Ausführungsformen kann eine oder mehrere der GPU(s) 808 ein Koprozessor einer oder mehrerer der CPU(s) 806 sein. Der/die Grafikprozessor(en) 808 kann/können von der Rechenvorrichtung 800 verwendet werden, um Grafiken (z. B. 3D-Grafiken) zu rendern oder allgemeine Berechnungen durchzuführen. Beispielsweise kann/können die GPU(s) 808 für General-Purpose-Computing auf GPUs (GPGPU) verwendet werden. Die GPU(s) 808 kann/können Hunderte oder Tausende von Kernen umfassen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 808 kann/können als Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von der/den CPU(s) 806, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 808 kann/können einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, z. B. GPGPU-Daten, enthalten. Der Anzeigespeicher kann als Teil des Speichers 804 enthalten sein. Die GPU(s) 808 kann/können zwei oder mehr GPUs umfassen, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt verbinden (z. B. mit NVLINK) oder über einen Switch (z. B. mit NVSwitch). Wenn sie miteinander kombiniert werden, kann jede GPU 808 Pixeldaten oder GPGPU-Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben erzeugen (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher haben oder sich den Speicher mit anderen GPUs teilen.
  • Zusätzlich zu oder alternativ zu der (den) CPU(s) 806 und/oder der (den) GPU(s) 808 kann (können) die Logikeinheit(en) 820 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt (ausführen), um eine oder mehrere Komponenten des Computergeräts 800 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsformen können die CPU(s) 806, die GPU(s) 808 und/oder die Logikeinheit(en) 820 diskret oder gemeinsam eine beliebige Kombination der Methoden, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 820 können Teil einer oder mehrerer der CPU(s) 806 und/oder der GPU(s) 808 sein und/oder eine oder mehrere der Logikeinheiten 820 können diskrete Komponenten oder anderweitig außerhalb der CPU(s) 806 und/oder der GPU(s) 808 sein. In Ausführungsformen kann eine oder mehrere der Logikeinheiten 820 ein Koprozessor einer oder mehrerer der CPU(s) 806 und/oder einer oder mehrerer der GPU(s) 808 sein.
  • Beispiele für die Logikeinheit(en) 820 umfassen einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie Datenverarbeitungseinheiten (DPUs), Tensorkerne (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Tree Traversierung Units (TTUs), Artificial Intelligence Accelerators (AIAs), Deep Learning Accelerators (DLAs), Arithmetik-LogikEinheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkomma-Einheiten (FPUs), Input/Output (I/O)-Elemente, Peripheral Component Interconnect (PCI)- oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
  • Die Kommunikationsschnittstelle 810 kann einen oder mehrere Empfänger, Sender und/oder Transceiver enthalten, die es dem Computergerät 800 ermöglichen, mit anderen Computergeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 810 kann Komponenten und Funktionen enthalten, die die Kommunikation über eine Reihe verschiedener Netzwerke ermöglichen, wie z. B. drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weitverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet. In einer oder mehreren Ausführungsformen können die Logikeinheit(en) 820 und/oder die Kommunikationsschnittstelle 810 eine oder mehrere Datenverarbeitungseinheiten (DPUs) enthalten, um über ein Netzwerk und/oder über das Verbindungssystem 802 empfangene Daten direkt an (z. B. einen Speicher) eine oder mehrere GPU(s) 808 zu übertragen.
  • Über die I/O-Ports 812 kann das Computergerät 800 logisch mit anderen Geräten gekoppelt werden, darunter die I/O-Komponenten 814, die Präsentationskomponente(n) 818 und/oder andere Komponenten, von denen einige in das Computergerät 800 eingebaut (z. B. integriert) sein können. Illustrative I/O-Komponenten 814 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die I/O-Komponenten 814 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben eines Benutzers verarbeitet. In einigen Fällen können die Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch in der Nähe des Bildschirms, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten ausführlicher beschrieben) in Verbindung mit einer Anzeige des Computergeräts 800 implementieren. Die Computervorrichtung 800 kann Tiefenkameras, wie stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung enthalten. Darüber hinaus kann das Computergerät 800 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) enthalten, die die Erkennung von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Rechenvorrichtung 800 verwendet werden, um immersive Augmented Reality oder Virtual Reality darzustellen.
  • Die Stromversorgung 816 kann eine festverdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon sein. Die Stromversorgung 816 kann das Computergerät 800 mit Strom versorgen, um den Betrieb der Komponenten des Computergeräts 800 zu ermöglichen.
  • Die Präsentationskomponente(n) 818 kann/können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 818 kann/können Daten von anderen Komponenten (z. B. der/den GPU(s) 808, der/den CPU(s) 806, DPUs usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
  • Beispielhaftes Datenzentrum
  • 9 zeigt ein Beispiel für ein Datenzentrum 900, das in mindestens einer Ausführungsform der vorliegenden Offenbarung verwendet werden kann. Das Datenzentrum 900 kann eine Datenzentrum-Infrastrukturschicht 910, eine Framework-Schicht 920, eine Softwareschicht 930 und/oder eine Anwendungsschicht 940 umfassen.
  • Wie in 9 dargestellt, kann die Datenzentrum-Infrastrukturschicht 910 einen Ressourcen-Orchestrator 912, gruppierte Rechenressourcen 914 und Knotenrechenressourcen („Knoten-C.R.s“) 916(1)-916(N) umfassen, wobei „N“ eine beliebige ganze, positive Zahl darstellt. In mindestens einer Ausführungsform können die Knoten C.R.s 916(1)-916(N) eine beliebige Anzahl von Zentraleinheiten (CPUs) oder anderen Prozessoren (einschließlich DPUs, Beschleunigern, Field Programmable Gate Arrays (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Speichervorrichtungen (z. B., dynamischer Festwertspeicher), Speichergeräte (z. B. Festkörper- oder Festplattenlaufwerke), Netzwerk-Eingabe-/Ausgabegeräte (NW I/O), Netzwerk-Switches, virtuelle Maschinen (VMs), Stromversorgungsmodule und/oder Kühlmodule, usw. In einigen Ausführungsformen können ein oder mehrere Knoten-C.R.s unter den Knoten-C.R.s 916(1)-916(N) einem Server entsprechen, der eine oder mehrere der oben genannten Rechenressourcen besitzt. Darüber hinaus können in einigen Ausführungsformen die Knoten C.R.s 916(1)-9161(N) eine oder mehrere virtuelle Komponenten enthalten, wie z. B. vGPUs, vCPUs und/oder dergleichen, und/oder einer oder mehrere der Knoten C.R.s 916(1)-916(N) können einer virtuellen Maschine (VM) entsprechen.
  • In mindestens einer Ausführungsform können die gruppierten Rechenressourcen 914 separate Gruppierungen von Knoten-CRs 916 umfassen, die in einem oder mehreren Racks (nicht dargestellt) oder in vielen Racks in Datenzentren an verschiedenen geografischen Standorten (ebenfalls nicht dargestellt) untergebracht sind. Getrennte Gruppierungen von Knoten-C.R.s 916 innerhalb gruppierter Rechenressourcen 914 können gruppierte Rechen-, Netzwerk-, Speicher- oder Speicherressourcen umfassen, die zur Unterstützung einer oder mehrerer Arbeitslasten konfiguriert oder zugewiesen werden können. In mindestens einer Ausführungsform können mehrere Knoten-CRs 916 mit CPUs, GPUs, DPUs und/oder anderen Prozessoren in einem oder mehreren Racks gruppiert werden, um Rechenressourcen zur Unterstützung einer oder mehrerer Arbeitslasten bereitzustellen. Das eine oder die mehreren Racks können auch eine beliebige Anzahl von Stromversorgungsmodulen, Kühlmodulen und/oder Netzwerk-Switches in beliebiger Kombination enthalten.
  • Der Ressourcen-Orchestrator 912 kann einen oder mehrere Knoten-CRs 916(1)-916(N) und/oder gruppierte Rechenressourcen 914 konfigurieren oder anderweitig steuern. In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 912 eine Software-Design-Infrastruktur (SDI)-Verwaltungseinheit für das Datenzentrum 900 umfassen. Der Ressourcen-Orchestrator 912 kann Hardware, Software oder eine Kombination davon umfassen.
  • In mindestens einer Ausführungsform, wie in 9 gezeigt, kann die Framework-Schicht 920 einen Job-Scheduler 933, einen Konfigurationsmanager 934, einen Ressourcenmanager 936 und/oder ein verteiltes Dateisystem 938 enthalten. Die Framework-Schicht 920 kann einen Rahmen zur Unterstützung der Software 932 der Softwareschicht 930 und/oder einer oder mehrerer Anwendungen 942 der Anwendungsschicht 940 enthalten. Die Software 932 oder die Anwendung(en) 942 können jeweils webbasierte Dienstsoftware oder Anwendungen umfassen, wie sie von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. Bei der Framework-Schicht 920 kann es sich um eine Art freies und quelloffenes Software-Webanwendungs-Framework wie Apache Spark™ (im Folgenden „Spark“) handeln, das ein verteiltes Dateisystem 938 für die Verarbeitung großer Datenmengen (z. B. „Big Data“) nutzen kann, ohne darauf beschränkt zu sein. In mindestens einer Ausführungsform kann der Job-Scheduler 933 einen Spark-Treiber enthalten, um die Planung von Arbeitslasten zu erleichtern, die von verschiedenen Schichten des Datenzentrums 900 unterstützt werden. Der Konfigurationsmanager 934 kann in der Lage sein, verschiedene Schichten zu konfigurieren, z. B. die Softwareschicht 930 und die Framework-Schicht 920 einschließlich Spark und das verteilte Dateisystem 938 zur Unterstützung der Verarbeitung großer Datenmengen. Der Ressourcenmanager 936 kann in der Lage sein, geclusterte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 938 und des Job-Schedulers 933 zugeordnet sind. In mindestens einer Ausführungsform können geclusterte oder gruppierte Rechenressourcen gruppierte Rechenressourcen 914 auf der Datenzentrum-Infrastrukturschicht 910 umfassen. Der Ressourcenmanager 936 kann sich mit dem Ressourcen-Orchestrator 912 abstimmen, um diese zugeordneten oder zugewiesenen Computerressourcen zu verwalten.
  • In mindestens einer Ausführungsform kann die in der Softwareschicht 930 enthaltene Software 932 Software enthalten, die von mindestens Teilen der Knoten C.R.s 916(1)-916(N), der gruppierten Rechenressourcen 914 und/oder des verteilten Dateisystems 938 der Framework-Schicht 920 verwendet wird. Eine oder mehrere Arten von Software können u. a. Internet-Suchsoftware, E-Mail-Virenscan-Software, Datenbanksoftware und Software für Streaming-Videoinhalte umfassen.
  • In mindestens einer Ausführungsform kann (können) die in der Anwendungsschicht 940 enthaltene(n) Anwendung(en) 942 eine oder mehrere Arten von Anwendungen umfassen, die von mindestens Teilen der Knoten C.R.s 916(1)-916(N), den gruppierten Rechenressourcen 914 und/oder dem verteilten Dateisystem 938 der Framework-Schicht 920 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl von Genomanwendungen, kognitiven Berechnungen und Anwendungen für maschinelles Lernen umfassen, einschließlich Trainings- oder Inferenzsoftware, Framework-Software für maschinelles Lernen (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere Anwendungen für maschinelles Lernen, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden, sind aber nicht darauf beschränkt.
  • In mindestens einer Ausführungsform können der Konfigurationsmanager 934, der Ressourcenmanager 936 und der Ressourcen-Orchestrator 912 eine beliebige Anzahl und Art von selbstmodifizierenden Aktionen implementieren, die auf einer beliebigen Menge und Art von Daten basieren, die auf jede technisch machbare Weise erfasst wurden. Selbstmodifizierende Aktionen können einen Datenzentrumsbetreiber des Datenzentrums 900 davon entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Teile eines Datenzentrums zu vermeiden.
  • Das Datenzentrum 900 kann Werkzeuge, Dienste, Software oder andere Ressourcen enthalten, um ein oder mehrere maschinelle Lernmodelle zu trainieren oder Informationen unter Verwendung eines oder mehrerer maschineller Lernmodelle gemäß einer oder mehrerer hierin beschriebener Ausführungsformen vorherzusagen oder abzuleiten. Beispielsweise kann ein maschinelles Lernmodell bzw. können maschinelle Lernmodelle trainiert werden, indem Gewichtsparameter gemäß einer neuronalen Netzwerkarchitektur unter Verwendung von Software und/oder Computerressourcen berechnet werden, die oben in Bezug auf das Datenzentrum 900 beschrieben wurden. In mindestens einer Ausführungsform können trainierte oder eingesetzte maschinelle Lernmodelle, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um Informationen abzuleiten oder vorherzusagen, wobei die oben beschriebenen Ressourcen in Bezug auf das Datenzentrum 900 verwendet werden, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere Trainingstechniken berechnet werden, wie z. B., aber nicht nur, die hier beschriebenen.
  • In mindestens einer Ausführungsform kann das Datenzentrum 900 CPUs, anwendungsspezifische integrierte Schaltkreise (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder die Inferenz unter Verwendung der oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der oben beschriebenen Software- und/oder Hardwareressourcen als Dienst konfiguriert werden, um Benutzern das Training oder die Inferenz von Informationen zu ermöglichen, wie z. B. Bilderkennung, Spracherkennung oder andere Dienste der künstlichen Intelligenz.
  • Beispielhafte Netzwerkumgebungen
  • Netzwerkumgebungen, die zur Verwendung beim Implementieren von Ausführungsformen der Offenbarung geeignet sind, können ein oder mehrere Client-Geräte, Server, Network Attached Storage (NAS), andere Backend-Geräte und/oder andere Gerätetypen umfassen. Die Client-Geräte, Server und/oder anderen Gerätetypen (z. B. jedes Gerät) können auf einer oder mehreren Instanzen der Rechenvorrichtung(en) 800 von 8 implementiert werden - z. B. kann jedes Gerät ähnliche Komponenten, Merkmale und/oder Funktionalität der Rechenvorrichtung(en) 800 enthalten. Wenn Backend-Geräte (z. B. Server, NAS usw.) implementiert sind, können die Backend-Geräte außerdem Teil eines Datenzentrums 900 sein, dessen Beispiel hier in Bezug auf 9 näher beschrieben wird.
  • Die Komponenten einer Netzwerkumgebung können über ein oder mehrere Netze miteinander kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netz kann mehrere Netze oder ein Netz von Netzen umfassen. Beispielsweise kann das Netzwerk ein oder mehrere Wide Area Networks (WANs), ein oder mehrere Local Area Networks (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonnetz (PSTN) und/oder ein oder mehrere private Netzwerke umfassen. Wenn das Netz ein drahtloses Telekommunikationsnetzumfasst, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Konnektivität bieten.
  • Zu den kompatiblen Netzwerkumgebungen gehören eine oder mehrere Peer-to-Peer-Netzwerkumgebungen - in diesem Fall kann ein Server nicht in einer Netzwerkumgebung enthalten sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung enthalten sein. In Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Geräten implementiert werden.
  • In mindestens einer Ausführungsform kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. umfassen. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Job-Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem umfassen, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzwerkserver und/oder Edge-Server umfassen können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Softwareschicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht umfassen. Die Software oder die Anwendung(en) können jeweils webbasierte Dienstsoftware oder Anwendungen umfassen. In Ausführungsformen können ein oder mehrere Client-Geräte die webbasierte Dienstsoftware oder Anwendungen nutzen (z. B. durch Zugriff auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs)). Bei der Framework-Schicht kann es sich um eine Art von freiem und quelloffenem Software-Webanwendungs-Framework handeln, das z. B. ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwendet, ohne darauf beschränkt zu sein.
  • 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) ausführen. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von zentralen oder Kernservern (z. B. von einem oder mehreren Datenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Befindet sich eine Verbindung zu einem Benutzer (z. B. einem Client-Gerät) relativ nahe an einem oder mehreren Edge-Servern, kann ein Kernserver zumindest einen Teil der Funktionalität dem oder den Edge-Servern zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat (z. B. auf eine einzelne Organisation beschränkt), öffentlich (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z. B. eine hybride Cloud-Umgebung) sein.
  • Das (die) Client-Gerät(e) kann (können) zumindest einige der Komponenten, Merkmale und Funktionen der hier in Bezug auf 8 beschriebenen beispielhaften Rechenvorrichtung(en) 800 enthalten. Ein Client-Gerät kann beispielsweise ein Personal Computer (PC), ein Laptop, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smartwatch, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder ein Gerät, ein Videoplayer, eine Videokamera, ein Überwachungsgerät oder -system, ein Fahrzeug ein Boot, ein fliegendes Schiff, eine virtuelle Maschine, eine Drohne, ein Roboter, ein tragbares Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeugcomputersystem, einen eingebetteten Systemcontroller, eine Fernbedienung, ein Gerät, ein Unterhaltungselektronikgerät, eine Workstation, ein Edge-Gerät, eine beliebige Kombination dieser beschriebenen Geräte oder jedes andere geeignete Gerät.
  • Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen, einschließlich computerausführbarer Anweisungen wie Programmmodule, beschrieben werden, die von einem Computer oder einer anderen Maschine, wie einem persönlichen Datenassistenten oder einem anderen Handgerät, ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen angewendet werden, einschließlich Handheld-Geräten, Unterhaltungselektronik, Allzweckcomputern, spezielleren Datenverarbeitungsgeräten usw. Die Offenbarung kann auch in verteilten Computerumgebungen angewandt werden, in denen Aufgaben von ferngesteuerten Geräten ausgeführt werden, die über ein Kommunikationsnetz verbunden sind.
  • Wenn hier von „und/oder“ in Bezug auf zwei oder mehr Elemente die Rede ist, sollte dies so verstanden werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. Beispielsweise kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C umfassen. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B einschließen.
  • Der Gegenstand der vorliegenden Offenbarung wird hier mit einer Genauigkeit beschrieben, die den gesetzlichen Anforderungen entspricht. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente der angewandten Methoden zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbart dargestellten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • mindestens Teilen der Knoten C.R.s 916(1)-916 [0199]
    • Knoten C.R.s 916(1)-916 [0200]

Claims (20)

  1. Computerimplementiertes Verfahren, das aufweist: Empfangen von Bilddaten, die unter Verwendung einer ersten Kamera mit einem ersten Sichtfeld erzeugt werden, wobei die erste Kamera mit einem Fahrzeug in einer Umgebung verbunden ist; Anwenden einer Transformation auf die Bilddaten, um transformierte Bilddaten zu erzeugen, wobei die Transformation das erste Sichtfeld umwandelt, um ein zweites Sichtfeld einer zweiten Kamera zu simulieren, die mit dem Fahrzeug in der Umgebung verbunden ist; Anwenden der transformierten Bilddaten auf ein maschinelles Lernmodell, das unter Verwendung von Trainingsbildern trainiert wurde, die dem zweiten Sichtfeld der zweiten Kamera entsprechen; Berechnen unter Verwendung des maschinellen Lernmodells von Ausgabedaten, die für eine oder mehrere Vorhersagen repräsentativ sind, die unter Verwendung des maschinellen Lernmodells gemacht wurden; und Übertragen der Ausgabedaten, um das Fahrzeug zu veranlassen, eine oder mehrere Operationen durchzuführen, die mindestens auf der einen oder den mehreren Vorhersagen basieren.
  2. Computerimplementiertes Verfahren nach Anspruch 1, wobei die erste Kamera eine physikalische Kamera und die zweite Kamera eine virtuelle Kamera ist.
  3. Computerimplementiertes Verfahren nach Anspruch 1, wobei das Umwandeln aufweist: Umwandeln einer ersten Objektivverzeichnung, die von den Bilddaten erfasst wird und mit der ersten Kamera verbunden ist, in eine zweite Objektivverzeichnung, die mit der zweiten Kamera verbunden ist; und Extrahieren eines interessierenden Bereichs aus einem oder mehreren Bildern, die den Bilddaten entsprechen.
  4. Computerimplementiertes Verfahren nach Anspruch 1, wobei das Umwandeln aufweist: Bestimmen von Grenzen, die einen interessierenden Bereich definieren, der dem zweiten Sichtfeld im Weltraum entspricht; und Extrahieren des interessierenden Bereichs aus einem oder mehreren Bildern, die den Bilddaten entsprechen.
  5. Computerimplementiertes Verfahren nach Anspruch 1, wobei das Umwandeln aufweist: Bestimmen von Grenzen, die einen interessierenden Bereich definieren, der dem zweiten Sichtfeld in einem oder mehreren Bildern entspricht, die den Bilddaten entsprechen; Identifizieren von Pixeln, die dem interessierenden Bereich entsprechen, unter Verwendung der Grenzen; und Anwenden einer Blickpunkttransformation auf die Pixel, die unter Verwendung der Grenzen identifiziert werden, um den interessierenden Bereich aus dem einen oder den mehreren Bildern zu extrahieren.
  6. Computerimplementiertes Verfahren nach Anspruch 1, wobei es sich bei der einen oder mehreren Vorhersagen um eine oder mehrere erste Vorhersagen handelt und das Verfahren ferner aufweist: Bestimmen, unter Verwendung des maschinellen Lernmodells, einer oder mehrerer zweiter Vorhersagen aus Bilddaten, die unter Verwendung einer dritten Kamera mit einem dritten Sichtfeld erzeugt und in das zweite Sichtfeld der zweiten Kamera umgewandelt werden; und Fusionieren der einen oder mehreren ersten Vorhersagen mit der einen oder den mehreren zweiten Vorhersagen, um eine oder mehrere fusionierte Vorhersagen zu bestimmen, wobei die eine oder mehreren Operationen mindestens auf der einen oder mehreren fusionierten Vorhersagen basieren.
  7. Computerimplementiertes Verfahren nach Anspruch 1, wobei die eine oder mehrere Vorhersagen einen oder mehrere Trajektorienpunkte im Weltraum einer Trajektorie für das Fahrzeug durch die Umgebung aufweisen.
  8. Computerimplementiertes Verfahren nach Anspruch 1, wobei das Umwandeln aus einem oder mehreren einer Ausrichtung, Position oder Drehung der Kamera in Bezug auf einen oder mehrere mit dem Fahrzeug verbundene Referenzpunkte besteht.
  9. System, das aufweist: eine oder mehrere Verarbeitungseinheiten zum Ausführen von Operationen, die aufweisen: Identifizieren eines interessierenden Bereichs in einem Bild, das unter Verwendung einer Kamera erzeugt wird, basierend auf mindestens einem Sichtfeld, das in Trainingsbildern dargestellt ist, die verwendet werden, um ein maschinelles Lernmodell zu trainieren; Umwandeln mindestens des interessierenden Bereichs in ein objektivunabhängiges Format, das für die Trainingsbilder verwendet wird; Bestimmen, unter Verwendung des maschinellen Lernmodells, einer oder mehrerer Vorhersagen aus dem interessierenden Bereich, der das objektivunabhängige Format aufweist; und Übertragen von Daten, um eine Maschine, die mit der Kamera verbunden ist, zu veranlassen, eine oder mehrere Operationen auszuführen, die mindestens auf der einen oder den mehreren Vorhersagen basieren.
  10. System nach Anspruch 9, wobei das Umwandeln mindestens des interessierenden Bereichs in das objektivunabhängige Format das Entfernen von Objektivverzeichnungen in mindestens dem interessierenden Bereich aufweist, die durch ein Objektiv der Kamera verursacht werden.
  11. System nach Anspruch 9, wobei das Umwandeln mindestens des interessierenden Bereichs in das objektivunabhängige Format aufweist: Anpassen der Objektivverzeichnung des Bildes, um ein Zwischenbild im objektivunabhängigen Format zu erzeugen; und Freistellen des interessierenden Bereichs aus dem Zwischenbild mindestens basierend auf dem Identifizieren, um ein Eingabebild des interessierenden Bereichs zu erzeugen, wobei die eine oder mehreren Vorhersagen aus dem Eingabebild bestimmt werden.
  12. System nach Anspruch 9, wobei das Umwandeln mindestens des interessierenden Bereichs in das objektivunabhängige Format aufweist: Auswählen eines Satzes von Pixeln in dem Bild, die dem interessierenden Bereich entsprechen, mindestens basierend auf dem Identifizieren; und Anpassen der in dem Satz von Pixeln dargestellten Objektivverzeichnung, um ein Eingabebild des interessierenden Bereichs in dem objektivunabhängigen Format zu erzeugen, wobei die eine oder die mehreren Vorhersagen aus dem Eingabebild bestimmt werden.
  13. System nach Anspruch 9, das ferner das Anwenden einer Blickpunkttransformation auf mindestens den interessierenden Bereich aufweist, mindestens basierend auf dem Sichtfeld.
  14. System nach Anspruch 9, wobei das Identifizieren des interessierenden Bereichs das Bestimmen von Grenzen des interessierenden Bereichs entsprechend dem Sichtfeld im Weltraum aufweist.
  15. Prozessor, der aufweist: eine oder mehrere Schaltungen, um: Bilddaten zu empfangen, die unter Verwendung einer Kamera mit einem ersten Sichtfeld in einer Umgebung erzeugt wurden, eine Transformation auf die Bilddaten anzuwenden, um transformierte Bilddaten zu erzeugen, wobei die Transformation das erste Sichtfeld umwandelt, um ein zweites Sichtfeld zu simulieren, und ein maschinelles Lernmodell zu trainieren, um eine oder mehrere Vorhersagen aus den transformierten Bilddaten zu erzeugen, die das zweite Sichtfeld erfassen.
  16. Prozessor nach Anspruch 15, wobei die Kamera eine erste Kamera ist und das zweite Sichtfeld von einer zweiten Kamera stammt und der Prozessor ferner dazu dient, das maschinelle Lernmodell mindestens auf dem Anwenden mindestens eines Bildes, das mit der zweiten Kamera erzeugt wird und das zweite Sichtfeld darstellt, auf das maschinelle Lernmodell zu trainieren.
  17. Prozessor nach Anspruch 15, wobei die Kamera eine physikalische Kamera ist und das zweite Sichtfeld von einer virtuellen Kamera stammt.
  18. Prozessor nach Anspruch 15, wobei das Umwandeln aufweist: Bestimmen von Grenzen, die einen interessierenden Bereich definieren, der dem zweiten Sichtfeld im Weltraum entspricht; und Extrahieren des interessierenden Bereichs aus einem oder mehreren Bildern, die den Bilddaten entsprechen.
  19. Prozessor nach Anspruch 15, wobei das Umwandeln aufweist: Bestimmen von Grenzen, die einen interessierenden Bereich definieren, der dem zweiten Sichtfeld in einem oder mehreren Bildern entspricht, die den Bilddaten entsprechen; Identifizieren von Pixeln, die dem interessierenden Bereich entsprechen, unter Verwendung der Grenzen; und Anwenden einer Blickpunkttransformation auf die Pixel, die unter Verwendung der Grenzen identifiziert werden, um den interessierenden Bereich aus dem einen oder den mehreren Bildern zu extrahieren.
  20. Prozessor nach Anspruch 15, wobei die Kamera an einer Maschine angebracht ist und das Umwandeln aus einem oder mehreren einer Ausrichtung, Position oder Drehung der Kamera in Bezug auf einen oder mehrere mit der Maschine verbundene Referenzpunkte besteht.
DE112021004919.4T 2020-09-21 2021-09-21 Simulation von Blickpunkttransformationen für sensorunabhängiges Szenenverständnis in autonomen Systemen Pending DE112021004919T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202063081008P 2020-09-21 2020-09-21
US63/081,008 2020-09-21
US17/448,247 US20220092317A1 (en) 2020-09-21 2021-09-21 Simulating viewpoint transformations for sensor independent scene understanding in autonomous systems
US17/448,247 2021-09-21
PCT/US2021/051286 WO2022061289A1 (en) 2020-09-21 2021-09-21 Simulating viewpoint transformations for sensor independent scene understanding in autonomous systems

Publications (1)

Publication Number Publication Date
DE112021004919T5 true DE112021004919T5 (de) 2023-07-13

Family

ID=80740536

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021004919.4T Pending DE112021004919T5 (de) 2020-09-21 2021-09-21 Simulation von Blickpunkttransformationen für sensorunabhängiges Szenenverständnis in autonomen Systemen

Country Status (3)

Country Link
US (1) US20220092317A1 (de)
DE (1) DE112021004919T5 (de)
WO (1) WO2022061289A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115107653A (zh) * 2022-07-29 2022-09-27 山东浪潮科学研究院有限公司 基于fpga的电子后视镜系统

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018175441A1 (en) * 2017-03-20 2018-09-27 Mobileye Vision Technologies Ltd. Navigation by augmented path prediction
US10997433B2 (en) * 2018-02-27 2021-05-04 Nvidia Corporation Real-time detection of lanes and boundaries by autonomous vehicles
US11675359B2 (en) * 2018-06-13 2023-06-13 Nvidia Corporation Path detection for autonomous machines using deep neural networks
DE112019005750T5 (de) * 2018-11-16 2021-08-05 Nvidia Corporation Erlernen des Erzeugens synthetischer Datensätze zum Trainieren neuronalerNetze
US10832418B1 (en) * 2019-05-09 2020-11-10 Zoox, Inc. Object velocity from images
US11170524B1 (en) * 2019-06-21 2021-11-09 Amazon Technologies, Inc. Inpainting image feeds of operating vehicles
US11788861B2 (en) * 2019-08-31 2023-10-17 Nvidia Corporation Map creation and localization for autonomous driving applications
US11823433B1 (en) * 2020-01-21 2023-11-21 Lina M. Paz-Perez Shadow removal for local feature detector and descriptor learning using a camera sensor sensitivity model
US20230274151A1 (en) * 2020-03-30 2023-08-31 Google Llc Multi-modal neural network architecture search
US11107228B1 (en) * 2020-04-02 2021-08-31 Ford Global Technologies, Llc Realistic image perspective transformation using neural networks
WO2022031228A1 (en) * 2020-08-07 2022-02-10 Grabtaxi Holdings Pte. Ltd Method of predicting road attributes, data processing system and computer executable code
US11804042B1 (en) * 2020-09-04 2023-10-31 Scale AI, Inc. Prelabeling of bounding boxes in video frames
US20220092349A1 (en) * 2020-09-21 2022-03-24 Nvidia Corporation Measuring the effects of augmentation artifacts on a machine learning network
US20230110713A1 (en) * 2021-10-08 2023-04-13 Nvidia Corporation Training configuration-agnostic machine learning models using synthetic data for autonomous machine applications
US20230259540A1 (en) * 2022-02-17 2023-08-17 Nvidia Corporation Conversational ai platform with extractive question answering

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Knoten C.R.s 916(1)-916
mindestens Teilen der Knoten C.R.s 916(1)-916

Also Published As

Publication number Publication date
WO2022061289A1 (en) 2022-03-24
US20220092317A1 (en) 2022-03-24

Similar Documents

Publication Publication Date Title
DE112020003043T5 (de) Erkennung und klassifizierung von kreuzungsregionen für autonome maschinenanwendungen
DE112020006410T5 (de) Dreidimensionale kreuzungsstrukturvorhersage für anwendungen zum autonomen fahren
DE112021000135T5 (de) Sensorfusion für anwendungen autonomer maschinen durch maschinelles lernen
DE112020002126T5 (de) Erkennung von kreuzungsposen in autonomen maschinenanwendungen
DE112020001897T5 (de) Trainieren neuronaler Netze unter Verwendung von Grundwahrheitsdaten, die mit Karteninformationen ergänzt wurden, für autonome Maschinenanwendungen
DE112020002166T5 (de) Simulation realistischer testdaten aus transformierten sensordaten der realen welt für autonome maschinenanwendungen
DE112019006484T5 (de) Detektion von abständen zu hindernissen in autonomen maschinenanwendungen
DE112020002602T5 (de) Multi-objektverfolgung mit hilfe von korrelationsfiltern in videoanalyseanwendungen
DE102021123159A1 (de) Adaptiver objektverfolgungsalgorithmus für autonome maschinenanwendungen
DE102020117792A1 (de) Wirksames einsetzen von hindernis- und spurerkennungen, um spurzuweisungen für objekte in einer umgebung zu bestimmen
DE112020000413T5 (de) Detektion von orientierungspunkten unter verwendung von kurvenanpassung für anwendungen für autonomes fahren
DE112020006404T5 (de) Planung und steuerung von spurwechseln in autonomen maschinenapplikationen
DE102021100065A1 (de) Verwendung neuronaler netze zur fehlererkennung bei anwendungen für autonomes fahren
DE112021001994T5 (de) Modellbasiertes bestärkendes lernen zur verhaltensvorhersage in autonomen systemen und anwendungen
DE102021125234A1 (de) Datenerweiterung einschliesslich hintergrundmodifikation für robuste vorhersage mit neuronalen netzwerken
DE102019113114A1 (de) Verhaltensgesteuerte wegplanung in autonomen maschinenanwendungen
DE112021000104T5 (de) Projizieren von mit fischaugenobjektiven aufgenommenen bildern zur merkmalserkennung in autonomen maschinenanwendungen
DE102022121121A1 (de) Objektverfolgung unter Verwendung von LiDAR-Daten für autonome Maschinenanwendungen
DE102022111322A1 (de) Engine für adaptive maschinelle lernmodelle zur augenverfolgung
DE102022104026A1 (de) Erzeugung von ground-truth-daten für die wahrnehmung durch tiefe neuronale netze in anwendungen für autonomes fahren
DE102022124361A1 (de) Sichtweiteabschätzung unter verwendung von deep learning in autonomen maschinenanwendungen
DE102021105245A1 (de) Verwenden von bildaugmentation mit simulierten objekten zum trainieren von maschinenlernmodellen in autonomen fahranwendungen
DE102020130749A1 (de) System zum maschinellen lernen zur blickbestimmung mit adaptiver gewichtung von eingaben
DE102023120759A1 (de) Adaptive cruise control using future trajectory prediction for autonomous systems and applications
DE102023105837A1 (de) Gefahrenerkennung unter verwendung von belegungsrastern für autonome systeme und anwendungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed