DE102022104026A1

DE102022104026A1 - Erzeugung von ground-truth-daten für die wahrnehmung durch tiefe neuronale netze in anwendungen für autonomes fahren

Info

Publication number: DE102022104026A1
Application number: DE102022104026.7A
Authority: DE
Inventors: Tilman Wekel; Joachim Pehserl; Jacob Meyer; Jake Guza; Anton Mitrokhin; Richard Whitcomb; Marco Scoffier; David Nister; Grant Monroe
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2021-02-26
Filing date: 2022-02-21
Publication date: 2022-09-01
Also published as: CN114973050A; JP2022132075A; US20220277193A1

Abstract

Eine Annotationspipeline kann verwendet werden, um 2D- und/oder 3D-Ground-Truth-Daten für tiefe neuronale Netze, wie z.B. autonome oder halbautonome Fahrzeugwahrnehmungsnetzwerke, zu erzeugen. Zu Beginn können Sensordaten mit verschiedenen Sensortypen erfasst und synchronisiert werden, um Bilder von Sensordaten abzugleichen, welche einen ähnlichen Zustand der Welt darstellen. Die abgeglichenen Bilder können abgetastet und in eine Sequenz von zu annotierenden Annotationsszenen verpackt werden. Ein Annotationsprojekt kann in modulare Aufgaben zerlegt und in einem Kennzeichnungswerkzeug kodiert sein, welches die Aufgaben Kennzeichnern zuweist und die Reihenfolge von Eingaben mit Hilfe eines Assistenten festlegt, der die Aufgaben schrittweise durchläuft. Während der Aufgaben kann jede Art von Sensordaten in einer Annotationsszene gleichzeitig dargestellt werden, und eine Information kann über verschiedene Sensormodalitäten projiziert werden, um eine nützliche Kontextinformation bereitzustellen. Nach Abschluss aller Annotationsaufgaben können die resultierenden Ground-Truth-Daten in jedes geeignete Format exportiert werden.

Description

HINTERGRUND
Ein System zu entwickeln, das ein Fahrzeug autonom und sicher ohne Aufsicht steuert, ist enorm schwierig. Ein autonomes Fahrzeug sollte zumindest in der Lage sein, als funktionales Äquivalent eines aufmerksamen Fahrers zu fungieren - der auf ein Wahrnehmungs- und Handlungssystem zurückgreift, das eine unglaubliche Fähigkeit besitzt, bewegliche und statische Hindernisse in einer komplexen Umgebung zu erkennen und darauf zu reagieren - um eine Kollision mit anderen Objekten oder Strukturen entlang des Fahrwegs zu vermeiden. Daher ist die Fähigkeit, belebte Objekte (z. B. Autos, Fußgänger usw.) und andere Teile der Umgebung zu erkennen, für Wahrnehmungssysteme beim autonomen Fahren oft entscheidend. Herkömmliche Wahrnehmungsverfahren stützen sich oft auf Kameras oder LiDAR-Sensoren, um Objekte in einer Umgebung zu erkennen. Es wurden verschiedene Ansätze entwickelt, bei denen tiefe neuronale Netze (Deep Neural Networks (DNNs)) für die Wahrnehmung mittels LiDAR und Kamera eingesetzt werden. Klassen solcher DNNs weisen DNNs, die eine panoptische Segmentierung von Kamerabildern in einer perspektivischen Ansicht durchführen, und DNNs, die eine Objekterkennung mittels Top-Down-Ansicht (Ansicht von oben nach unten) oder „Bird's Eye View“ (BEV) aus LiDAR-Punktwolken durchführen, auf.
Um ein DNN so zu trainieren, dass es eine Wahrnehmung mit einem angemessenen Grad an Genauigkeit durchführen kann, muss das DNN mit genauen Ground-Truth-Daten trainiert werden. Eine Echtzeit-DNN-Wahrnehmung wird aufgrund von Rechenbeschränkungen in der Regel in zwei Dimensionen (2D) durchgeführt, so dass die Ground-Truth-Daten für diese Netze bzw. Netzwerke in der Regel in 2D vorliegen. Mit dem technologischen Fortschritt wird die dreidimensionale (3D) Wahrnehmung jedoch allmählich praktisch relevant, und es besteht ein unerfüllter Bedarf an qualitativ hochwertigen 3D-Ground-Truth-Daten.
Herkömmliche Verfahren zur Erzeugung von Ground-Truth-Daten für die DNN-Wahrnehmung bei autonomen Fahranwendungen haben eine Reihe von Nachteilen. Bei dem oben beschriebenen Beispiel führt ein erstes DNN eine panoptische Segmentierung von Kamerabildern in der perspektivischen Ansicht durch, und ein zweites DNN führt eine Objekterkennung aus Top-Down-Projektionen von LiDAR-Punktwolken durch. In diesem Fall benötigt das erste DNN Kamerabilder mit Ground-Truth-Annotationen und das zweite DNN Top-Down-LiDAR-Projektionen mit Ground-Truth-Annotationen. Normalerweise werden diese Arten von Ground-Truth-Annotationen in separaten Kennzeichnungsverfahren erzeugt. Unter bestimmten Umständen ist es jedoch schwierig oder sogar unmöglich, genaue Kennzeichen zu erzeugen. Bei einem Beispiel einer LiDAR- und RADAR-Kennzeichnung erzeugen diese Modalitäten nur spärliche Daten, und manchmal fehlt es an der Granularität und dem Kontext, die für eine genaue Kennzeichnung erforderlich sind. Bei Top-Down-Ansichten kann es schwierig oder sogar unmöglich sein, Fußgänger oder Fahrräder zu unterscheiden, da Top-Down-Ansichten dieser Objekte oft ähnlich aussehen wie Top-Down-Ansichten anderer Objekte wie Masten, Baumstämme oder Büsche. Daher können herkömmliche Kennzeichnungsverfahren zu fehlerhaften Ground-Truth-Daten führen. Im Idealfall werden diese Fehler bei einer Qualitätsprüfung erkannt, beeinträchtigen aber dennoch den Durchsatz und die Effizienz und verschwenden Rechenressourcen.
ZUSAMMENFASSUNG
Ausführungsformen der vorliegenden Offenbarung beziehen sich auf eine Annotationspipeline bzw. Anmerkungspipeline, die 2D- und/oder 3D-Ground-Truth-Daten für tiefe neuronale Netze (DNNs) erzeugt, wie z.B. solche, die die Wahrnehmung in autonomen oder halbautonomen Fahrzeugen, Robotern oder anderen Objekttypen durchführen.
Im Allgemeinen handelt es sich bei der hier beschriebenen Annotationspipeline um einen verbesserten Arbeitsablauf und eine verbesserte Software-Schnittstelle, die die Produktion von qualitativ hochwertigen Ground-Truth-Daten optimieren. Zunächst können während einer Aufnahmesitzung Sensordaten mit verschiedenen Arten von Sensoren (Sensormodalitäten) erfasst werden. Die Daten der verschiedenen Sensoren können synchronisiert werden, um Bilder von Sensordaten abzugleichen, die einen ähnlichen Zustand der Welt bzw. World State darstellen. In einem Beispiel mit LiDAR und Kameras kann, während eine LiDAR-Drehung fortschreitet und verschiedene Abschnitte der Umgebung betrachtet, das zeitlich nächstgelegene Kamerabild für eine bestimmte LiDAR-Drehung ausgewählt werden, und zwar auf der Grundlage des Blickwinkels der Kamera relativ zum Startwinkel der LiDAR-Drehung und der Zeit, die die LiDAR-Drehung braucht, um sich mit dem Sichtfeld der Kamera auszurichten. Bei einigen Ausführungsformen können Zeit- oder Index-Offsets pro Kamera relativ zum LiDAR-Drehungs-Start bestimmt und/oder angewendet werden, um Kamerabilder für jede Kamera mit LiDAR-Bildern abzugleichen. Im Allgemeinen können Bilder verschiedener Sensordatentypen ausgerichtet, abgetastet und zu einer Sequenz von zu annotierenden Annotationsszenen zusammengefasst werden.
Bei einigen Ausführungsformen kann ein Annotationsprojekt in modulare Aufgaben zerlegt werden, die verschiedenen Kennzeichnern zugewiesen werden können. Bei einem nicht einschränkenden Beispiel mit Kameras und LiDAR können zunächst einige oder alle Kamerabilder in einer Sequenz annotiert werden, dann können einige oder alle LiDAR-Bilder in der Sequenz annotiert werden (z.B. zuerst Top-Down-2D-Bounding-Boxen, dann 3D Bounding-Boxen), Objekte, die in aufeinanderfolgenden Annotationsszenen erscheinen, können verknüpft bzw. verbunden werden, und dann können Objekte, die in beiden Sensormodalitäten (LiDAR- und Kamerabildern) erscheinen, miteinander verknüpft werden. Die Annotationsaufgaben können in einem Annotationswerkzeug kodiert werden, das die Aufgaben den Kennzeichnern zuweist und die Reihenfolge der Eingaben mit Hilfe eines Assistenten festlegt, der die Kennzeichner durch die Aufgaben führt. Während der Annotationsaufgaben kann dem Kennzeichner jede Art von Sensordaten in einer Annotationsszene präsentiert werden (z.B. nebeneinander) und/oder es können Informationen über die Sensormodalitäten hinweg projiziert werden, um nützliche Kontextinformationen wie z.B. Korrespondenzen zwischen den verschiedenen Arten von Sensordaten bereitzustellen. Bei einigen Ausführungsformen kann das Annotationswerkzeug den Kennzeichner durch ein Annotationsverfahren pro Objekt für jede Annotationsszene in einer Sequenz führen.
Nachdem einige oder alle Annotationsaufgaben in einem Annotationsprojekt abgeschlossen sind, können die resultierenden Ground-Truth-Daten in jedem geeigneten Format exportiert werden. So können ein oder mehrere Modelle zum maschinellen Lernen anhand der exportierten Ground-Truth-Daten trainiert werden.
Figurenliste
Die vorliegenden Systeme und Verfahren zum Erzeugen von Ground-Truth-Daten für die Wahrnehmung durch tiefe neuronale Netze werden im Folgenden unter Bezugnahme auf die beigefügten Figuren detailliert beschrieben, wobei gilt:

1 ist ein Datenflussdiagramm, das gemäß einigen Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Annotationspipeline illustriert;
2 ist ein Diagramm, das gemäß einiger Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Ausrichtung zwischen einer LiDAR-Drehung und zwei Kameras illustriert;
3 ist eine Tabelle, die eine beispielhafte Ausrichtung von Sensordatenindizes gemäß einigen Ausführungsformen der vorliegenden Offenbarung illustriert;
4 ist ein Diagramm, das gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Beispiel für eine Datenerfassungssitzung, Annotationsszenen und Segmente von Annotationsszenen darstellt;
5 ist eine Illustration einer beispielhaften Benutzeroberfläche für die Bildkennzeichnung gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
6 ist eine Illustration einer beispielhaften Benutzerschnittstelle für die kameragestützte LiDAR-Kennzeichnung gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
7 ist eine Illustration einer beispielhaften Benutzerschnittstelle für die kameragestützte LiDAR-Kennzeichnung mit einem Orientierungsvektor gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8 ist eine Illustration einer beispielhaften Benutzerschnittstelle für kameragestützte LiDAR-Kennzeichnungen mit dreidimensionalen (3D) Bounding-Boxen gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
9 ist eine Illustration einer beispielhaften Benutzerschnittstelle für die LiDAR-Verfolgung gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
10 ist eine Illustration einer beispielhaften Benutzeroberfläche für die Kamera-LiDAR-Verknüpfung gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
11 ist eine Illustration von beispielhaften Ground-Truth-Annotationen gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
12 ist ein Flussdiagramm, das ein Verfahren zur Erzeugung von Ground-Truth-Annotationen von Sensordaten verschiedener Sensortypen gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
13 ist ein Flussdiagramm, das ein Verfahren zur Erzeugung von Ground-Truth-Annotationen von LiDAR- und Kamera-Bildern gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
14A ist eine Illustration eines Beispiels für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
14B ist ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug aus 14A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
14C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 14A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
14D ist ein Systemdiagramm für die Kommunikation zwischen einem oder mehreren Cloud-basierten Servern und dem beispielhaften autonomen Fahrzeug aus 14A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
15 ist ein Blockdiagramm einer beispielhaften Recheneinrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
16 ist ein Blockdiagramm eines beispielhaften Rechenzentrums, das sich für die Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung eignet.

DETAILLIERTE BESCHREIBUNG
Eine mögliche Lösung für die oben beschriebenen Probleme ist eine Projektion von Informationen über Sensormodalitäten hinweg, was den Kennzeichner durch die Bereitstellung nützlicher Kontextinformationen unterstützen kann. Diese Möglichkeit wirft jedoch eine Reihe von Herausforderungen auf. Konventionell waren Ground-Truth LiDAR-Annotationen auf Top-Down-2D-Bounding-Boxen bzw. von oben nach unten dargestellten 2D-Bounding-Boxen beschränkt, aber Top-Down-Bounding-Boxen lassen sich nicht gut in einen Kameraraum projizieren und bieten möglicherweise nicht genug zusätzlichen Kontext, um den Kennzeichnern zu helfen. Darüber hinaus ist es schwierig, wenn nicht gar unmöglich, eine perfekte zeitliche Abstimmung zwischen verschiedenen Sensormodalitäten zu erreichen. Selbst wenn man von einer Konfiguration mit mehreren Sensoren ausgeht (z.B. Kameras und ein LiDAR-Sensor), wird im Idealfall zu einem bestimmten Zeitpunkt ein Auslöser betätigt und alle Sensoren lösen zur gleichen Zeit aus. In der Realität ist dieses ideale Szenario fast nie möglich, da es Probleme mit der Synchronisierung der Kameras, der Synchronisierung verschiedener Sensortypen, Unterschieden in Verzögerungsleitungen, Unterschieden in Abtastfrequenzen (z.B. Kameras, die mit 30 Bildern pro Sekunde arbeiten, gegenüber einem LiDAR, das mit 10 Bildern pro Sekunde arbeitet) und dergleichen gibt. Bei einem konkreten Beispiel von einem LiDAR und Kameras: Ein LiDAR-Sensor benötigt Zeit, um sich zu drehen (z.B. 100 Millisekunden pro Umdrehung), so dass die perfekte Synchronisierung einer bestimmten Kamera in Bezug auf den Ort einer LiDAR-Drehung bzw. eines LiDAR-Spins eine Herausforderung und oft praktisch unmöglich ist. Auch bei der räumlichen Ausrichtung der Sensoren kann es praktische Grenzen geben, da die individuelle Kalibrierung der einzelnen Sensoren oft nicht alle Freiheitsgrade abdecken kann, die für eine perfekte Ausrichtung erforderlich sind. Infolgedessen kann die Projektion von Informationen über verschiedene Sensormodalitäten hinweg Informationen aus unterschiedlichen Zuständen der Welt vermischen, was den Nutzen möglicherweise zunichtemacht.
Um diese und andere Herausforderungen zu bewältigen, werden Systeme und Verfahren offenbart, die sich auf eine Annotationspipeline beziehen, die 2D- und/oder 3D-Ground-Truth-Daten für tiefe neuronale Netze bzw. Deep Neural Networks (DNNs) erzeugt, wie z.B. solche, die die Wahrnehmung in autonomen oder halbautonomen Fahrzeugen, Robotern oder anderen Objekttypen durchführen. Obwohl die vorliegende Offenbarung in Bezug auf ein Beispiel für ein autonomes Fahrzeug 1400 beschrieben werden kann (hier auch als „Fahrzeug 1400“ oder „Ego-Fahrzeug 1400“ bezeichnet, von dem ein Beispiel in den 14A-14D beschrieben ist), ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können die hier beschriebenen Systeme und Verfahren verwendet werden, um Ground-Truth-Trainingsdaten für DNNs in nicht-autonomen Fahrzeugen, halbautonomen Fahrzeugen (z.B. in einem oder mehreren fortgeschrittenen Fahrerassistenzsystemen (ADAS)), Robotern, Lagerfahrzeugen, Geländewagen, Luftschiffen, Booten und/oder anderen Fahrzeugtypen zu erzeugen). Auch wenn die vorliegende Offenbarung in Bezug auf das autonome Fahren beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können die hier beschriebenen Systeme und Verfahren verwendet werden, um Trainingsdaten für DNNs in der Robotik (z.B. Pfadplanung für einen Roboter), in Flugsystemen (z.B. Pfadplanung für eine Drohne oder ein anderes Luftfahrzeug), in Bootssystemen (z.B. Pfadplanung für ein Boot oder ein anderes Wasserfahrzeug) und/oder in anderen Technologiebereichen zu erzeugen, wie z.B. für Lokalisierung, Pfadplanung und/oder andere Verfahren.
Im Allgemeinen handelt es sich bei der hier beschriebenen Annotationspipeline um einen verbesserten Arbeitsablauf und eine Software-Schnittstelle, die die Herstellung von Ground-Truth-Daten von höherer Qualität als bei früheren Verfahren optimieren. Zunächst werden während einer Aufnahmesitzung Sensordaten mit verschiedenen Arten von Sensoren (Sensormodalitäten) erfasst. Um nützliche Kontextinformationen zu identifizieren, die bei der Annotationsaufgabe helfen können, werden die Daten der verschiedenen Sensormodalitäten synchronisiert, um eine Sequenz von Annotationsszenen zu erstellen (z.B. Sätze von Sensordaten, die ungefähr zur gleichen Zeit aufgenommen wurden). Ein gewünschtes Segment der Sequenz kann ausgewählt und für die Kennzeichnung bestimmt werden, und die gewünschten Annotationen können in eine Menge von linearen Aufgaben zerlegt werden. Die verschiedenen Aufgaben können je nach Sensortyp, Art des zu kennzeichnenden Objekts, Detaillierungsgrad der Annotation und/oder auf andere Weise aufgeteilt werden. Die Aufgaben können in ein Kennzeichnungswerkzeug eingegeben oder anderweitig kodiert werden, das Aufgaben den Kennzeichnern zuweist und die Reihenfolge der Eingaben mit Hilfe eines Assistenten festlegt, der die Kennzeichner durch die Aufgaben führt. Während der Annotationsaufgaben kann dem Kennzeichner jede Art von Sensordaten in einer Annotationsszene präsentiert werden (z.B. nebeneinander), und/oder es können Informationen über die Sensormodalitäten hinweg projiziert werden, um nützliche Kontextinformationen zu liefern, wie z.B. Zuordnungen zwischen den verschiedenen Arten von Sensordaten. In manchen Fällen können einige Arten von Annotationen automatisch generiert werden. Wenn einige oder alle Annotationsaufgaben abgeschlossen sind, kann das Kennzeichnungswerkzeug die resultierenden Ground-Truth-Annotationen in jedem geeigneten Format exportieren.
Bei einigen Ausführungsformen kann ein Annotationsprojekt in modulare Aufgaben zerlegt werden, die verschiedenen Kennzeichnern zugewiesen werden können. In einem nicht einschränkenden Beispiel mit Kameras und LiDAR werden zunächst einige oder alle Kamerabilder in einer Sequenz gekennzeichnet, dann werden einige oder alle LiDAR-Bilder in der Sequenz gekennzeichnet (z.B. zuerst Top-Down-2D-Bounding-Boxen, dann 3D Bounding-Boxen), Objekte, die in aufeinanderfolgenden Annotationsszenen erscheinen, können verknüpft werden, und dann werden Objekte, die in beiden Sensormodalitäten erscheinen, miteinander verknüpft. Zusätzlich oder alternativ kann ein Annotationsprojekt in mehrere Phasen oder Aufgaben aufgeteilt werden, die auf der Art der Kennzeichen (z.B. in einer bestimmten Aufgabe nur Autos, Verkehrsschilder oder andere Elemente in einer Straßenszene), dem Detaillierungsgrad (z.B. in einer bestimmten Aufgabe nur Linienzüge für eine Objektgrundfläche oder eine vollständige 3D Bounding-Box) und/oder auf andere Weise basieren. Durch die Zerlegung eines Annotationsprojekts und eine Aufforderung an die Kennzeichner, einzelne projektspezifische Aufgaben auszuführen, kann die Annotationspipeline modularisiert werden, so dass sich die Kennzeichner jeweils auf eine bestimmte Aufgabe konzentrieren können.
Während einer beliebigen Annotationsaufgabe kann eine Schnittstelle des Kennzeichnungswerkzeugs die verschiedenen Arten von Sensordaten in einer Annotationsszene darstellen (z.B. nebeneinander) und/oder Informationen über Sensormodalitäten hinweg projizieren, um nützliche Kontextinformationen bereitzustellen. Die projizierten Informationen können Sensordetektionen (z.B. Punkte, Ebenen, Scanlinien), Annotationen, eine Eingabeprobe, die eine bestimmte Position innerhalb eines Bildes von Sensordaten angibt, und/oder andere Informationen aufweisen. Durch die Bereitstellung von Kontextinformationen während der Annotationsaufgaben sind die Kennzeichner in der Lage, genauere Kennzeichen zu vergeben. Zum Beispiel kann eine Gruppe von Fußgängern in einem bestimmten Bild der LiDAR-Daten nur mit einigen wenigen Punkten dargestellt sein. Wenn jedoch ein entsprechendes Kamerabild angezeigt wird, können die Kennzeichner die in den LiDAR-Daten versteckten Fußgänger leicht erkennen. Bei einigen Ausführungsformen kann ein Kennzeichner, der sich nicht sicher ist, welche Art von Hindernis eine bestimmte LiDAR-Erkennung darstellt, auf die LiDAR-Erkennung klicken und eine Visualisierung an einem entsprechenden Punkt des Kamerabildes anzeigen lassen (z.B. die Erkennung eines Pickup-Trucks). Der Kennzeichner kann dann das richtige Kennzeichen auf das LiDAR-Bild aufbringen.
Das Kennzeichnungswerkzeug und die hier beschriebene Annotationspipeline können eine Reihe von Vorteilen gegenüber früheren Verfahren bieten. Im Allgemeinen verbessert die Bereitstellung von zusätzlichem Kontext für einen menschlichen Kennzeichner, der die Sensordaten betrachtet, die Genauigkeit und Effizienz der manuellen Kennzeichnung und ermöglicht einige Arten von Ground-Truth-Kennzeichen, die zuvor nicht möglich waren. Indem beispielsweise LiDAR-Daten mit zusätzlichem Kontext wie einem (zusammengesetzten) Kamerabild präsentiert werden, können Kennzeichner jetzt präzise 3D-LiDAR-Kennzeichen wie 3D-Bounding-Boxen erstellen. Mit 3D-Bounding-Boxen, die im LiDAR-Raum annotiert sind, können diese Kennzeichen in ein entsprechendes Kamerabild projiziert werden, um einen nützlichen Kontext für die Kamerakennzeichnung bereitzustellen, der es den Kennzeichnern ermöglicht, genauere Kamerakennzeichen zu erstellen. Infolgedessen ermöglichen die hier beschriebenen Verfahren die Angabe einer genaueren Darstellung von Ground-Truth, was zum Trainieren genauerer DNNs verwendet werden kann.
Wenn einem Kennzeichner während der Kennzeichnung zusätzlicher Kontext präsentiert wird, fällt es dem Kennzeichner im Allgemeinen leichter, Kennzeichen zu erstellen. Wenn beispielsweise verschiedene Arten von Sensordaten nebeneinander dargestellt werden und/oder Zuordnungen zwischen verschiedenen Sensormodalitäten veranschaulicht werden, fällt es dem Kennzeichner leichter, die Daten zu verstehen, was die kognitive Belastung verringert und die Wahrnehmung beschleunigt. Infolgedessen macht das hier beschriebene Kennzeichnungswerkzeug die Interaktion des Kennzeichners mit dem Computer im Vergleich zu früheren Verfahren effizienter. Diese Verbesserung kommt dem gesamten Arbeitsablauf in Bezug auf Effizienz und Durchsatz zugute und verringert somit den Bedarf an Computerressourcen im Vergleich zu früheren Verfahren. Mit anderen Worten: Je besser die Werkzeuge sind, desto effizienter ist die Kennzeichnung und desto höher ist der Durchsatz. Indem die Werkzeuge benutzerfreundlicher sind, beschleunigen verschiedene Aspekte der vorliegenden Verfahren den Arbeitsablauf bei der Annotation, indem der Umfang der Nacharbeit im Vergleich zu früheren Verfahren verringert wird.
Außerdem wird durch die Aufteilung der Annotationsaufgaben und die Zerlegung eines Annotationsprojekts in leicht zu verarbeitende Aufgaben das Annotationsverfahren gestrafft und die Informationsflut verringert. Viele Unternehmen weisen die Kennzeichner üblicherweise an, alle Annotationsaufgaben, die für jedes Bild von Sensordaten ausführbar sind, auf einmal durchzuführen, was zu einem komplexen Kennzeichnungsverfahren führt, das ein umfangreiches Training erfordert. Durch die Aufteilung der erforderlichen Annotationen in kleinere, überschaubare Aufgaben können die Aufgaben vielen Kennzeichnern zugewiesen werden, wodurch die Annotationspipeline besser skalierbar wird. Durch die Aufteilung der Annotationsaufgaben nach Sensortyp ist das Kennzeichnungsverfahren außerdem nicht so empfindlich gegenüber zeitlichen oder räumlichen Abweichungen zwischen den Sensormodalitäten. Selbst wenn beispielsweise ein LiDAR-Bild und ein entsprechendes Kamerabild nicht perfekt ausgerichtet bzw. abgeglichen sind, ist die Auswirkung auf die Genauigkeit der Kennzeichen minimal, da eine LiDAR-Annotationsaufgabe direkt im LiDAR-Bild durchgeführt wird. In diesem Beispiel wird das entsprechende Kamerabild nur als weiche Orientierungshilfe verwendet, so dass eine Fehlausrichtung nicht als Ground-Truth fest kodiert wird. In Ausführungsformen, die eine Verknüpfungsaufgabe aufweisen, bei der ein Kennzeichner zuvor vorgenommene Annotationen über verschiedene Sensormodalitäten und/oder Annotationsszenen hinweg miteinander verknüpft, kann diese Verknüpfungsaufgabe als Qualitätskontrolle dienen, da der Kennzeichner in der Lage ist, die Annotationen beider Sensormodalitäten und/oder Annotationsszenen zu überprüfen. Durch die Verwendung dieser Verknüpfungsaufgabe entfällt die Notwendigkeit einer separaten Qualitätsprüfung, was darüber hinaus den gesamten Arbeitsablauf verbessert.
Wie es hier beschrieben ist, können das Kennzeichnungswerkzeug und die Annotationspipeline verwendet werden, um eine genauere Darstellung der Ground-Truth zu erzeugen, die zum Trainieren genauerer DNNs verwendet werden kann.
BEISPIEL EINER GROUND-TRUTH-ANNOTATIONSPIPELINE
Tiefe neuronale Netze (Deep Neural Networks, DNNs) wurden für eine Vielzahl von Aufgaben wie Objekterkennung und -klassifizierung eingesetzt. Um Trainingsdaten für DNNs wie diese zu erhalten, kann eine Annotationspipeline verwendet werden, um Ground-Truth-Daten zu erzeugen. Im Allgemeinen können die Ground-Truth-Daten, die von einer Annotationspipeline erzeugt werden, je nach Art des zu trainierenden DNN angepasst werden. Für DNNs, die Wahrnehmungen durchführen, kann eine Annotationspipeline so angepasst werden, dass sie 2D- und/oder 3D-Ground-Truth-Daten erzeugt, wie z.B. gekennzeichnete Kamerabilder (z.B. in der perspektivischen Ansicht), LiDAR- oder RADAR-Daten (z.B. in der Top-Down-Ansicht) und/oder andere Sensordaten. Obwohl bestimmte Ausführungsformen in Bezug auf DNNs beschrieben werden, die Wahrnehmungen durchführen, können die hier beschriebenen Verfahren angepasst werden, um Ground-Truth-Daten für andere Arten von DNNs zu erzeugen.
1 ist ein Datenflussdiagramm, das gemäß einiger Ausführungsformen der vorliegenden Offenbarung ein Beispiel für eine Annotationspipeline 100 zeigt. Es versteht sich von selbst, dass diese und andere Anordnungen, wie es hier beschrieben ist, nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z.B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, 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. Darüber hinaus 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 sein können. Verschiedene Funktionen, wie es hier beschrieben ist, 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.
Auf einer hohen Ebene kann die Annotationspipeline 100 einen Arbeitsablauf und eine Softwareschnittstelle aufweisen, die die Produktion von qualitativ hochwertigen Ground-Truth-Daten optimieren. In dem in 1 dargestellten Beispiel weist die Annotationspipeline 100 eine Datenerfassung 110, einen Sensordatenabgleich 120, eine Szenenerzeugung 130, eine Szenenkuratierung 140, eine Annotation 150, eine Nachbearbeitung 160, eine Qualitätskontrolle 170, einen Export von Ground-Truth-Daten 180 und einen Verbrauch bzw. Einsatz von Ground-Truth-Daten 190 auf. Beispielsweise kann die Datenerfassung 110 mit realen Daten durchgeführt werden, um Sensordaten von verschiedenen Sensortypen (Sensormodalitäten) zu sammeln, und der Sensordatenabgleich 120 der verschiedenen Sensordatentypen kann durchgeführt werden, um die Sensordaten zu synchronisieren, so dass Sensordaten ähnlicher Zustände der Welt (z. B. Sensordaten, die im Wesentlichen zur gleichen Zeit erfasst wurden) gruppiert und während der Annotationsaufgaben präsentiert werden können. Die Szenenerzeugung 130 kann verwendet werden, um eine Sequenz von Annotationsszenen zusammenzustellen (z.B. Sätze von Sensordaten, die ungefähr zur gleichen Zeit aufgenommen wurden, wie die Szenensequenz 145). Zum Beispiel kann der Sensordatenabgleich 120 ein Hinzufügen von Offsets zu den Erfassungszeiten oder einen anderen Index für die Sensordaten beinhalten, und die Szenenerzeugung 130 kann ein Abtasten von Sensordaten und/oder ein Erzeugen von Projektionsbildern für jede Annotationsszene in einer Sequenz beinhalten. Die Szenenkuratierung 140 kann durchgeführt werden, um ein oder mehrere Segmente der Annotationsszenen auszuwählen (z.B. ein Segment einer Datenerfassung ohne Regen) und um das (die) Segment(e) für die Annotation zu bestimmen.
Auf hohem Niveau kann ein Software-Tool (auch Kennzeichnungswerkzeug genannt) wie ein Web-Tool verwendet werden, um die Annotation 150 zu ermöglichen. Im Allgemeinen kann ein bestimmtes Annotationsprojekt in eine Reihe von linearen Aufgaben zerlegt und/oder gegliedert werden, die ein Kennzeichnungsrezept bilden, das das Projekt aufteilt und verschiedene Aufgaben auf der Grundlage des Sensortyps, der Art der zu kennzeichnenden Objekte, des Detaillierungsgrads der Annotation und/oder auf andere Weise festlegt. Die Aufgaben können in das Kennzeichnungswerkzeug eingegeben oder anderweitig kodiert werden. Das Werkzeug kann den Kennzeichnern Aufgaben zuweisen und die Reihenfolge von Eingaben mithilfe eines Assistenten festlegen, der die Kennzeichner durch die Annotationsaufgaben führt. In einem beispielhaften Annotationsprojekt für LiDAR- und Kamera-Ground-Truth-Daten werden zunächst einige oder alle Kamerabilder in einer Sequenz gekennzeichnet, dann werden einige oder alle LiDAR-Bilder in der Sequenz gekennzeichnet (z.B. Kamera- und LiDAR-Ausgabe 152), dann werden Objekte, die in mehreren LiDAR-Bildern vorkommen, einander zugeordnet (z.B. LiDAR-Trackingausgabe bzw. LiDAR-Verfolgungsausgabe 154), dann werden Objekte, die in mehreren Sensormodalitäten vorkommen, miteinander verknüpft (z.B. Kamera- und LiDAR-Verknüpfungsausgabe 156). Bei einigen Ausführungsformen kann die LiDAR-Kennzeichnung zunächst die Kennzeichnung von LiDAR-Bildern mit 2D-Bounding-Boxen und dann das Kennzeichnen der LiDAR-Bilder mit 3D-Bounding-Boxen oder Quadern umfassen (z. B. 3D-LiDAR-Kennzeichnungsausgabe 155). Das Kennzeichnungswerkzeug und dieses beispielhafte Annotationsprojekt werden im Folgenden näher beschrieben.
Nachdem die Kennzeichner die Annotationsaufgaben in dem Projekt abgeschlossen haben, kann die Nachbearbeitung 160 angewendet werden, um Annotationen zu erzeugen, die ein Mensch normalerweise nicht erstellen kann, z. B. die Erzeugung von Tiefenwerten. Bei einigen Ausführungsformen kann eine Qualitätssicherungsprüfung 170 für die gekennzeichneten Daten durchgeführt werden, um potenzielle Fehler zu identifizieren und bestimmte Szenen für die Nachbearbeitung zu kennzeichnen. Bei einigen Ausführungsformen kann die Qualitätssicherungsprüfung 170 zumindest teilweise in eine Annotationsaufgabe während der Annotation 150 integriert werden, z. B. in eine Verknüpfungsaufgabe, wodurch eine separate Qualitätssicherungsprüfung nach der Nachbearbeitung 160 überflüssig wird. Nachdem einige oder alle Annotationsaufgaben abgeschlossen sind, können die resultierenden Ground-Truth-Daten aus dem Kennzeichnungswerkzeug in jedem geeigneten Format exportiert werden, unabhängig davon, ob dies automatisch oder manuell ausgelöst wird (Ground-Truth-Daten-Export 180), und die Ground-Truth-Daten können verbraucht bzw. eingesetzt werden (Einsatz von Ground-Truth-Daten 190), zum Beispiel durch Verwendung der Ground-Truth-Daten zum Trainieren eines entsprechenden DNN.
Im Allgemeinen können die Ground-Truth-Daten zumindest teilweise aus realen Daten generiert werden. Dementsprechend können bei einigen Ausführungsformen der Datenerfassung 110 ein oder mehrere Fahrzeuge (z.B. das Fahrzeug 1400 der 14A-D) Sensordaten von einem oder mehreren Sensoren des Fahrzeugs (der Fahrzeuge) in realen (z.B. physischen) Umgebungen erfassen. Die Sensoren des Fahrzeugs (der Fahrzeuge) können ohne Einschränkung aufweisen Sensoren des globalen Navigationssatellitensystems 1458 (z.B. Sensoren eines Global Positioning System), RADAR-Sensoren 1460, Ultraschallsensoren 1462, LiDAR-Sensoren 1464, Sensoren einer Trägheitsmesseinheit (IMU) 1466 (z.B., Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Ego-Bewegungssensor(en), Mikrofon(e) 1496, Stereokamera(s) 1468, Weitwinkelkamera(s) 1470 (z.B., Fischaugenkameras), Infrarotkamera(s) 1472, Umgebungskamera(s) 1474 (z.B. 360-Grad-Kameras), Langstrecken- und/oder Mittelstreckenkamera(s) 1498, Geschwindigkeitssensor(en) 1444 (z.B. zur Messung der Geschwindigkeit des Fahrzeugs (der Fahrzeuge)), Vibrationssensor(en) 1442, Lenksensor(en) 1440, Bremssensor(en) (z.B. als Teil des Bremssensorsystems 1446) und/oder andere Sensortypen. Das Fahrzeug (die Fahrzeuge) kann (können) autonome Fahrzeuge, halbautonome Fahrzeuge, nichtautonome Fahrzeuge und/oder andere Objekte oder Fahrzeuge als die Fahrzeuge 1400 aufweisen, wie z.B. Roboter, Drohnen, Wasserfahrzeuge, Flugzeuge, unbemannte Luftfahrzeuge (UAVs), etc.
Das Fahrzeug (die Fahrzeuge) kann (können) verschiedene Arten von Fahrzeug-Hardware aufweisen. Die Fahrzeughardware kann zum Beispiel für die Verwaltung der von den Sensoren erzeugten Sensordaten verantwortlich sein (z.B. mit Hilfe eines Sensor-Managers eines Software-Stacks für autonomes Fahren, der von der Fahrzeughardware ausgeführt wird). Bei einigen Ausführungsformen kann das Fahrzeug einen Software-Stack für autonomes Fahren mit einem Weltzustandsmanager aufweisen, der die Welt mit Hilfe einer oder mehrerer Karten (z.B. 3D-Karten), Lokalisierungskomponenten, Wahrnehmungskomponenten und/oder ähnlichem verwaltet. Der Software-Stack für autonomes Fahren kann eine oder mehrere Planungskomponenten (z.B. als Teil einer Planungsschicht), eine oder mehrere Steuerungskomponenten (z.B. als Teil einer Steuerungsschicht), eine oder mehrere Betätigungskomponenten (z.B. als Teil einer Betätigungsschicht), eine oder mehrere Hindernisvermeidungskomponenten (z.B. als Teil einer Hindernisvermeidungsschicht) und/oder andere Komponenten aufweisen. Bei einigen Ausführungsformen kann die Fahrzeughardware Hardware aufweisen, die zur Steuerung des Fahrzeugs bzw. der Fahrzeuge durch reale Umgebungen auf der Grundlage der Sensordaten, eines oder mehrerer Modelle zum maschinellen Lernen (z.B. neuronale Netze) und/oder Ähnlichem verwendet wird. So können verschiedene Arten einer Fahrzeug-Hardware für den Einbau in das Fahrzeug und/oder für die Verwendung durch das Fahrzeug bei der Ausführung eines Software-Stacks für autonomes Fahren ausgestaltet sein, der zumindest teilweise die Navigation des Fahrzeugs durch eine reale physikalische Umgebung steuert.
Im Allgemeinen kann die Datenerfassung 110 ein Erfassen von Sensordaten durch Beobachtung einer realen Umgebung mit verschiedenen Arten von Sensoren (Sensormodalitäten) umfassen, wie z.B. LiDAR und eine oder mehrere am Fahrzeug montierte Kameras. Im Allgemeinen können Sensordaten aus verschiedenen Gründen von unterschiedlichen Sensoren mit unterschiedlichen Frequenzen erfasst werden, z.B. wegen unterschiedlicher Verzögerungsleitungen, unterschiedlicher Abtastfrequenzen (z.B. Kameras mit 30 Bildern pro Sekunde im Vergleich zu LiDAR mit 10 Bildern pro Sekunde), unterschiedlicher Auslösezeiten und anderer Gründe. Um die Gruppierung zu erleichtern und Sensordaten ähnlicher Weltzustände zu präsentieren (z.B. Sensordaten, die im Wesentlichen zur gleichen Zeit aufgenommen wurden), kann der Sensordatenabgleich 120 durchgeführt werden, um die Sensordaten der verschiedenen Sensormodalitäten zu synchronisieren. Bei einigen Ausführungsformen kann ein bestimmter Sensor als Referenzsensor verwendet werden. Nicht-Referenzsensoren können als untergeordnete Sensoren bezeichnet werden. Für ein bestimmtes Bild von Sensordaten des Referenzsensors (Referenzbild) kann ein Offset, z.B. ein Zeitdelta, zwischen dem Referenzbild und dem zeitlich nächstgelegenen Bild von Sensordaten jedes untergeordneten Sensors ermittelt werden. Der Offset für jeden untergeordneten Sensor kann aufgezeichnet und/oder auf die Erfassungszeiten oder einen anderen Index für die Sensordaten des untergeordneten Sensors angewendet werden.
Bei einem bestimmten Beispiel mit einem LiDAR und Kameras kann bei einigen Ausführungsformen das LiDAR als Referenzsensor ausgewählt werden, und das zeitlich nächstgelegene Bild für jede Kamera kann auf der Grundlage des Blickwinkels der Kamera relativ zum LiDAR-Drehungs-Startwinkel ausgewählt werden, und es können Zeit- oder Index-Offsets pro Kamera relativ zum LiDAR-Drehungs-Start angewendet werden. 2 ist ein Diagramm, das gemäß einiger Ausführungsformen der vorliegenden Offenbarung eine beispielhafte Ausrichtung zwischen einer LiDAR-Drehung und zwei Kameras zeigt. Es wird eine abgeschlossene LiDAR-Drehung mit einem Referenzzeitstempel t, der sich auf den Start der Drehung (t + 0ms) bezieht, betrachtet. Es wird angenommen, dass ein LiDAR-Sensor 100 ms braucht, um eine Drehung bzw. einen Spin abzuschließen (Dauer der Drehung), und dass die Drehfrequenz 10 Hz beträgt. In 2 wurde ein beispielhaftes LiDAR-Bild 210 mit einem Kreis überlagert, um den zeitlichen Verlauf der LiDAR-Drehung darzustellen. In diesem Beispiel stellt der Pfeil 220 die Ausrichtung des Zentrums des Sichtfeldes der LiDAR-Drehung zur Zeit t + 0ms dar, wenn die Drehung begonnen hat. Die Drehung bewegt sich im Uhrzeigersinn weiter bis zum Pfeil 225 bei t + 50ms, zum Pfeil 230 bei t + 75ms und zurück zum Pfeil 220 bei t + 100ms, der anzeigt, wo die Drehung beendet ist.
In 2 sind die Sichtfelder der beiden Kameras, der nach vorne gerichteten Kamera 240 und der nach hinten gerichteten Kamera 250, ebenfalls über das LiDAR-Bild 210 gelegt worden. Um das Bild jeder Kamera zu identifizieren, das dem LiDAR-Bild 210 zeitlich am nächsten liegt, können der Verlauf und die Ausrichtung der LiDAR-Drehung in Bezug auf jede Kamera bestimmt werden, und für jede Kamera kann ein Offset relativ zum LiDAR bestimmt werden, der darauf basiert, wann die LiDAR-Drehung das Sichtfeld der Kamera erreicht. Bei t + 50 ms (Pfeil 225) ist die LiDAR-Drehung beispielsweise in das Sichtfeld der nach vorne gerichteten Kamera 240 vorangekommen, so dass für die nach vorne gerichtete Kamera 240 ein Offset von 50 ms verwendet werden kann. Bei einigen untergeordneten Sensoren, wie z.B. der nach hinten gerichteten Kamera 250, können die vom untergeordneten Sensor beobachteten Sensordaten Sektoren aufweisen, die nicht zusammenhängenden oder unvollständigen Abschnitten einer LiDAR-Drehung entsprechen, so dass es unter Umständen nicht möglich ist, ein bestimmtes Bild der Sensordaten des untergeordneten Sensors auszuwählen, das perfekt auf die LiDAR-Drehung abgestimmt ist. Im Allgemeinen kann jedes beliebige Bild der Sensordaten des untergeordneten Sensors ausgewählt werden. In dem in 2 gezeigten Beispiel kann das Bild ausgewählt werden, das am oder nahe dem Ende der LiDAR-Drehung bei t + 100ms (Pfeil 220) aufgenommen wurde.
Ein Beispiel für die Auswahl von Bildern und die entsprechenden Offsets sind auf der Achse 260 dargestellt, mit dem Referenzbild 270 (das z.B. das LiDAR-Bild 210 repräsentiert), dem Bild 280 (z.B. für die nach vorn gerichtete Kamera 240) und dem Bild 290 (z.B. für die nach hinten gerichtete Kamera 250). Es sei angemerkt, dass das zeitlich nächstgelegene Bild von Sensordaten, die von einem untergeordneten Sensor erfasst wurden, möglicherweise nicht perfekt mit dem Abschnitt der LiDAR-Drehung übereinstimmt, der das Zentrum des Sichtfelds des untergeordneten Sensors darstellt. Zum Beispiel kann ein LiDAR-Bild (z.B. das Referenzbild 270) einen Zustand der Welt repräsentieren, der einem Bild einer nach vorne gerichteten Kamera entspricht, das bei 50 ms aufgenommen wurde, aber das zeitlich am nächsten liegende Bild, das von dieser Kamera aufgenommen wurde, kann bei 40 oder 45 ms aufgenommen worden sein (z.B. Bild 280). In diesem Fall kann das bei 45ms aufgenommene Bild ausgewählt und mit dem LiDAR-Bild gekoppelt werden und/oder ein entsprechender Offset (z.B. 45ms) kann identifiziert und mit dem entsprechenden untergeordneter Sensor (z.B. der nach vorne gerichteten Kamera 240) verknüpft werden.
Im Allgemeinen kann der für jeden untergeordneten Sensor identifizierte Offset aufgezeichnet und/oder auf die Erfassungszeiten oder einen anderen Index für die Sensordaten des untergeordneten Sensors angewendet werden. Es sei zum Beispiel angenommen, dass eine Sensoreinrichtung Rohsensordaten erzeugt, wobei die Sensordaten von jedem Sensor separat indiziert werden. Bei einigen Ausführungsformen kann der ermittelte Offset für einen bestimmten untergeordneten Sensor angewendet werden, um die Indizes der Sensordaten (oder die Indizes der abgeglichenen Sensordaten) für den untergeordneten Sensor anzupassen. Die Bestimmung und/oder Anwendung von Offsets pro Sensor kann also dazu dienen, die verschiedenen Typen von Sensordaten anzugleichen (z.B. durch Angleichung ihrer Indizes). 3 ist eine Tabelle, die gemäß einiger Ausführungsformen der vorliegenden Offenbarung ein Beispiel für die Angleichung von Sensordatenindizes zeigt. In diesem Beispiel sind die Indizes der Sensordaten in Spalte 320 (LiDAR-Bild-Indizes) und in den Spalten 330-360 (Indizes für Bilder, die von verschiedenen Kameras aufgenommen wurden) dargestellt. In diesem Beispiel ist in Spalte 310 ein chronologischer Szenenindex vorhanden, und für jeden Szenenindexwert enthält eine entsprechende Zeile in der Tabelle die Indizes, die die abgeglichenen Sensordaten identifizieren (z.B. für eine bestimmte Annotationsszene). In diesem Beispiel wurde ein identifizierter Offset für jeden untergeordneten Sensor (z.B. jede Kamera) relativ zu jedem Referenzbild angewendet, um einen entsprechenden Index für ein vorübergehendes nächstgelegenes Bild von Sensordaten zu identifizieren, die von dem untergeordneten Sensor erfasst wurden.
Um zu 1 zurückzukehren, kann die Szenenerzeugung 130 durchgeführt werden, um eine Sequenz von Annotationsszenen zusammenzustellen (z.B. Sätze von Sensordaten, die ungefähr zur gleichen Zeit aufgenommen wurden, wie die Szenensequenz 145). Im Allgemeinen können Referenzsensordaten und Daten von untergeordneten Sensoren unter Verwendung des (der) identifizierten Offsets abgetastet werden. Wenn die Rohsensordaten nicht in einem Bildformat vorliegen (z.B. eine LiDAR- oder RADAR-Punktwolke), können bei einigen Ausführungsformen die Rohsensordaten (z.B. die Punktwolke) projiziert werden, um ein Projektionsbild (z.B. ein Top-Down-Bild) zu erzeugen. Weiter mit dem Beispiel, bei dem LiDAR als Referenzsensor und Kameras als untergeordnete Sensoren verwendet werden, kann für jedes Bild der LiDAR-Daten (z.B. eine LiDAR-Punktwolke) eine Annotationsszene zusammengestellt werden, indem die LiDAR-Punktwolke projiziert wird, um ein Projektionsbild (z.B. ein Top-Down-Bild) zu erzeugen, und Bilder von jeder der Kameras abgetastet werden (z.B. auf der Grundlage entsprechender Offsets und/oder Indizes), um das vorübergehend nächstgelegene Bild zu identifizieren, das von jeder Kamera aufgenommen wurde. Das Projektionsbild (LiDAR-Bild) und die Kamerabilder (Kamerabilder und/oder ein zusammengesetztes Bild oder Panorama, das aus mehreren Bildern zusammengestellt wurde) können zu einer Annotationsszene verpackt, gruppiert oder anderweitig miteinander verbunden werden. Das Verfahren kann z.B. wiederholt werden, um für jedes Referenzbild eine Annotationsszene zu erzeugen oder anderweitig zu identifizieren. Bei einigen Ausführungsformen kann die Szenenkuratierung 140 durchgeführt werden, um ein oder mehrere Segmente von Annotationsszenen auszuwählen (z.B. ein Segment einer Datenerfassungssitzung ohne Regen) und das (die) Segment(e) für die Kennzeichnung zu bestimmen.
4 ist ein Diagramm, das gemäß einigen Ausführungsformen der vorliegenden Offenbarung ein Beispiel für eine Datenerfassungssitzung 410, Annotationsszenen 415 und Segmente 421, 422, 423 von Annotationsszenen zeigt. Es sei beispielsweise angenommen, dass die Datenerfassungssitzung 410 im Stadtzentrum einer großen Stadt durchgeführt wird, wobei die Sensoren während der Datenerfassungssitzung 410 periodisch Sensordaten erfassen. Ein nicht einschränkendes Beispiel: eine LiDAR-Drehung kann alle 100 ms stattfinden, und eine Reihe von Kameras kann alle 25 ms (oder in einem anderen Rhythmus) ein Bild aufnehmen. Aus den erfassten Daten können Szenen 415 zusammengestellt werden (in 4 sind die Unterteilungen zwischen aufeinanderfolgenden Szenen nicht dargestellt). In manchen Fällen sind nicht alle Szenen sinnvoll. Zum Beispiel können in einer Stadt, in der es häufig regnet, die Szenen 415 herausgefiltert werden, um die Szenen 415 zu entfernen, die bei Regen während der Datenerfassung 410 aufgenommen wurden (z.B. weil Regentropfen auf der Windschutzscheibe oder dem Objektiv waren). Generell kann jede Art von Filter angewendet werden (z.B. automatisch oder manuell, basierend auf numerischen oder visuellen Merkmalen, Metadaten-Tags, Zeitstempeln oder anderem). So können die Szenen 415 kuratiert sein, um bestimmte Segmente von Interesse zu identifizieren (z.B. die Segmente 421, 422, 423), und die Szenen innerhalb der identifizierten Segmente (z.B. Sensordaten von verschiedenen Sensormodalitäten) können für die Annotation gekennzeichnet (z.B. markiert oder anderweitig identifiziert) werden.
Zurück zu 1: Die Annotation 150 kann von menschlichen Kennzeichnern mit Hilfe eines Softwarewerkzeugs (auch Kennzeichnungswerkzeug genannt), z. B. eines Webwerkzeugs, vorgenommen werden. Im Allgemeinen kann das Softwarewerkzeug eine oder mehrere Schnittstellen (z.B. grafische Benutzeroberflächen) aufweisen, die Eingaben von einem Projektadministrator akzeptieren, der die zu kennzeichnenden Annotationsszenen (z.B. Sensordaten von den verschiedenen Sensormodalitäten) und eine oder mehrere Annotationsaufgaben identifiziert und/oder bereitstellt. Die gewünschten Annotationen können in eine Reihe von linearen Aufgaben zerlegt und/oder angeordnet werden, die ein Kennzeichnungsrezept bzw. Kennzeichnungsvorgehen bilden, und eine kodierte Darstellung der Aufgaben kann in das Kennzeichnungswerkzeug eingegeben werden. Die verschiedenen Aufgaben können aufgeteilt werden - und das Kennzeichnungswerkzeug kann so ausgestaltet sein, dass es die Aufgaben aufteilt und/oder kodiert - basierend auf dem Sensortyp, dem Typ oder der Klasse des zu kennzeichnenden Objekts (z.B. in einer bestimmten Aufgabe nur Kennzeichen für Autos, Verkehrsschilder oder ein anderes Element in einer Straßenszene), dem Detailgrad der Kennzeichnung (z.B., Kennzeichnung von Bounding-Boxen im Vergleich zu Silhouetten, nur Aufbringen von Linienzügen für die Umrisse eines Objekts, Aufbringen von vollständigen 3D-Bounding-Boxen, Aufbringen von Top-Down-2D-Bounding-Boxen in LiDAR und Upgrade auf 3D in einem späteren Durchgang) und/oder andere. Bei einigen Ausführungsformen können separate Aufgaben für die Kennzeichnung von Hindernissen, Fahrzeugen (z.B. Autos, Busse, Lastwagen usw.), ungeschützten Verkehrsteilnehmern (z.B. Motorräder, Fahrräder, Fußgänger usw.), Teilen der Umgebung (z.B. befahrbare Fläche, Bürgersteige, Gebäude, Bäume, Masten usw.), Unterklassen davon (z.B. gehender Fußgänger), einer Kombination davon und/oder anderen eingegeben werden.
Die Annotationsaufgaben können in das Kennzeichnungswerkzeug eingegeben oder anderweitig kodiert werden, und das Kennzeichnungswerkzeug kann die Ausführung der verschiedenen Annotationsaufgaben koordinieren. Zum Beispiel kann das Kennzeichnungswerkzeug den Kennzeichnern die Aufgaben auf jede geeignete Weise zuweisen, z.B. durch Zuweisung von Aufgaben auf der Grundlage der Verfügbarkeit der Kennzeichner, einer festgelegten Reihenfolge der Aufgaben oder auf andere Weise. Bei einigen Ausführungsformen kann das Kennzeichnungswerkzeug die Reihenfolge der Eingaben (z.B. Annotationen) für eine bestimmte Aufgabe mithilfe eines Assistenten festlegen, der die Kennzeichner durch die Aufgabe(n) führt. Bei einigen Aufgaben kann dem Kennzeichner jede Art von Sensordaten in einer Annotationsszene präsentiert werden (z.B. nebeneinander) und/oder es können Informationen über die Sensormodalitäten hinweg projiziert werden, um nützliche Kontextinformationen zu liefern, wie z.B. Zuordnungen zwischen den verschiedenen Arten von Sensordaten.
Im Allgemeinen kann das Kennzeichnungswerkzeug Eingaben akzeptieren, die Ground-Truth-Annotationen (z.B. Grenzen, eingeschlossene Regionen, Kennzeichen) spezifizieren, und das Kennzeichnungswerkzeug kann die Annotationen mit den Sensordaten verknüpfen. Sensordaten (z.B. ein Bild von LiDAR-Daten, ein RBG-Bild) können (z.B. manuell, automatisch usw.) mit Kennzeichen oder anderen Markierungen versehen werden, die die Positionen, Geometrie, Ausrichtungen und/oder Klassen der Instanzen der relevanten Objekte in den Sensordaten identifizieren. Die Annotationen können mit Hilfe von 2D- und/oder 3D-Zeichenfunktionen oder einer anderen geeigneten Softwarefunktionalität in das Kennzeichnungswerkzeug eingegeben werden und/oder von Hand gezeichnet und importiert werden. Im Allgemeinen können die Annotationen synthetisch erstellt (z.B. aus Computermodellen oder Renderings), real erstellt (z.B. aus realen Daten entworfen oder erstellt), maschinell erstellt (z.B. maschinell (z.B. durch Merkmalsanalyse und Lernen, um Merkmale aus den Daten zu extrahieren und dann Kennzeichen zu erzeugen), von Menschen erstellt (z.B. von einem Kennzeichnungs- oder Annotationsexperten, der die Annotationen eingibt) und/oder eine Kombination davon (z.B. ein Mensch identifiziert die Eckpunkte von Linienzügen, eine Maschine erzeugt Polygone mit Hilfe eines Polygonrasters). Im Allgemeinen können die Annotationen 2D- und/oder 3D-Bounding-Boxen, geschlossene Linienzüge oder andere begrenzende Formen umfassen, die gezeichnet, annotiert, überlagert und/oder anderweitig mit den Sensordaten verbunden sind.
Als nicht einschränkendes Beispiel für Kameras und LiDAR kann ein Annotationsprojekt mit geordneten Annotationsaufgaben versehen werden, so dass zunächst einige oder alle Kamerabilder in einer Sequenz gekennzeichnet werden, dann einige oder alle LiDAR-Bilder in der Sequenz (z.B., zuerst Top-Down-2D-Bounding-Boxen, dann 3D-Bounding-Boxen), dann werden Objekte, die in mehreren Annotationsszenen vorkommen, miteinander verknüpft (z.B. für Kamerabilder und LiDAR-Bilder, die bereits gekennzeichnet wurden), und dann werden Objekte, die in mehreren Sensormodalitäten vorkommen, miteinander verknüpft. Bei einigen Ausführungsformen kann das Kennzeichnungswerkzeug während einer bestimmten Kennzeichnungsaufgabe gleichzeitig beide Arten von Sensordaten in einer Annotationsszene darstellen (z.B. ein LiDAR-Bild und ein Kamerabild) und/oder Informationen über die Sensormodalitäten hinweg projizieren, um nützliche Kontextinformationen zu liefern, wie z.B. Zuordnungen zwischen den verschiedenen Arten von Sensordaten. Bei einigen Ausführungsformen kann ein unterstützendes Merkmal bei den gekennzeichneten Objekten des vorherigen Bildes wiederholt werden und den Kennzeichner auffordern, das entsprechende Objekt im aktuellen Bild zu finden.
Um bei dem Beispiel mit den Kameras und dem LiDAR zu bleiben, zeigen die 5-10 beispielhafte Benutzeroberflächen eines Kennzeichnungswerkzeugs für die unterstützte 3D Ground-Truth-Kennzeichnung von LiDAR- und Kamerabildern. Es wird ein Beispiel für ein Annotationsprojekt betrachtet, das aufweist eine erste Annotationsaufgabe, bei der ein oder mehrere Kennzeichner zunächst einige oder alle Kamerabilder in einer Sequenz kennzeichnen, eine zweite Annotationssaufgabe, bei der ein oder mehrere Kennzeichner in einem ersten Durchgang Top-Down-2D-Bounding-Boxen für einige oder alle LiDAR-Bilder in der Sequenz kennzeichnen, eine dritte Annotationsaufgabe, bei der ein oder mehrere Kennzeichner 3D-Bounding-Boxen in einem zweiten Durchgang der gekennzeichneten LiDAR-Bilder in der Sequenz kennzeichnen, eine vierte Annotationsaufgabe, bei der ein oder mehrere Kennzeichner dasselbe Objekt über verschiedene Annotationsszenen in der Sequenz hinweg verknüpfen bzw. verbinden, und eine fünfte Annotationsaufgabe, bei der ein oder mehrere Kennzeichner dasselbe Objekt über LiDAR- und Kamerabilder hinweg in jeder Annotationsszene in der Sequenz verknüpfen. 5 ist eine Illustration einer beispielhaften Benutzeroberfläche für die Kennzeichnung von Bildern (z.B. die erste Annotationsaufgabe), 6-8 sind Abbildungen von beispielhaften Benutzeroberflächen für die kameragestützte LiDAR-Kennzeichnung (z.B. die zweite und dritte Annotationsaufgabe), 9 ist eine Abbildung einer beispielhaften Benutzeroberfläche für die LiDAR-Verfolgung bzw. LiDAR-Tracking (z.B. die vierte Annotationsaufgabe), und 10 ist eine Abbildung einer beispielhaften Benutzeroberfläche für die Kamera-LiDAR-Verknüpfung (z.B. die fünfte Annotationsaufgabe), gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
5 zeigt eine beispielhafte Benutzeroberfläche 500 für die Bildkennzeichnung gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Benutzeroberfläche 500 weist ein Feld auf, in dem ein bestimmtes zu kennzeichnendes Kamerabild 510 angezeigt wird, sowie ein Kennzeichnungsfeld mit verschiedenen Interaktionselementen, die verschiedene Zeichen- und/oder Annotationsfunktionen aktivieren. In diesem Beispiel weist das Kennzeichnungsfeld eine Schaltfläche 560 auf, die, wenn sie aktiviert ist, es dem Benutzer ermöglicht, eine Begrenzung und/oder einen entsprechenden eingeschlossenen Bereich des Bildes 510 zu identifizieren und zu kennzeichnen. Im Allgemeinen kann die Benutzeroberfläche 500 jede bekannte 2D- oder 3D-Zeichen- oder Annotations-Softwarefunktionalität enthalten. Als nicht einschränkendes Beispiel kann ein Benutzer Polygone wie eine 2D-Bounding-Box bestimmen, indem er in das Bild 510 klickt (z.B. an einer Stelle, die eine erste Ecke der Bounding-Box identifiziert), die 2D-Bounding-Box von der ersten Ecke aus durch Ziehen erweitert und loslässt, wenn die Bounding-Box die gewünschte Größe aufweist (z.B. an einer Stelle, die eine zweite Ecke gegenüber der ersten Ecke identifiziert). Bei einigen Ausführungsformen kann die Benutzeroberfläche 500 dem Benutzer erlauben, das Bild 510 zu zoomen und/oder zu verschieben. So kann der Benutzer eine beliebige Anzahl von Regionen (z.B. Regionen 520) zeichnen oder anderweitig identifizieren. Bei einigen Ausführungsformen (z.B. bei einer der Benutzeroberflächen 500-1000) kann das Kennzeichnungswerkzeug einen Satz von Annotationen mit den Annotationen aus dem vorhergehenden Bild der Sensordaten initialisieren, und der Kennzeichner kann die Annotationen an das aktuelle Bild anpassen. Auf diese Weise kann das Kennzeichnungswerkzeug die Notwendigkeit verringern oder beseitigen, eine Annotation für dasselbe Objekt immer wieder neu zu erstellen.
Bei einigen Ausführungsformen (z.B. bei einer der Benutzeroberflächen 500-1000) kann das Kennzeichnungswerkzeug ein Kennzeichnungsfeld aufweisen, das eine Liste (z.B. Liste 570) oder eine andere Identifizierung von annotierten Objekten in einem bestimmten Bild der Sensordaten aufweist. Jeder Eintrag in der Liste kann ein oder mehrere Interaktionselemente, z.B. die Schaltfläche 580 und die Kommentar-Schaltfläche 585, aufweisen. Die Schaltfläche 580 (oder ein anderes Interaktionselement) kann dazu dienen, eine entsprechende Annotation im Bild auszuwählen oder zu identifizieren (z.B. um eine Eingabe zur Bearbeitung der Annotation zu ermöglichen), den Benutzer aufzufordern, ein Klassen-Kennzeichen auszuwählen oder zu bearbeiten oder ähnliches. Die Kommentar-Schaltfläche 585 kann eine Texteingabe akzeptieren, die Anmerkungen zu der Annotation enthält. Dies sind nur Beispiele, und jede geeignete Zeichen- oder Annotationsfunktion kann in das Kennzeichnungswerkzeug integriert werden. Bei einigen Ausführungsformen kann das Kennzeichnungswerkzeug eine Eingabe akzeptieren, mit der man in der Zeit zurück und vorwärts navigieren kann (d.h. zu dem vorherigen und dem nächsten Bild in einer Sequenz), um das Verständnis der Daten für den Benutzer zu verbessern. Wenn der Benutzer mit dem Kennzeichnen des Bildes fertig ist, kann er angeben, dass er fertig ist (z.B. durch Klicken auf die Schaltfläche 590).
6 zeigt eine beispielhafte Benutzeroberfläche 600 für die kameragestützte LiDAR-Kennzeichnung gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Benutzeroberfläche 600 weist ein Feld auf, das ein bestimmtes LiDAR-Bild 620 zeigt, das zu kennzeichnen ist. Bei einigen Ausführungsformen kann die Benutzeroberfläche 600 gleichzeitig ein bestimmtes LiDAR-Bild 620, das zu kennzeichnen ist, sowie ein entsprechendes Bild 610 aus der gleichen Annotationsszene anzeigen. Das präsentierte Bild kann beispielsweise eine räumlich registrierte 360-Grad-Ansicht sein, die aus Bildern derselben Annotationsszene von umliegenden Kameras zusammengesetzt ist und zu einem zusammengesetzten Bild zusammengefügt wurde. Im Allgemeinen kann die Benutzeroberfläche 600 eine Visualisierung von Zuordnungen (z.B. korrespondierenden Regionen) zwischen dem LiDAR-Bild 620 und dem Bild 610 darstellen. Bei einigen Ausführungsformen kann die Benutzeroberfläche 600 dem Benutzer erlauben, in eines der Bilder zu zoomen und/oder es zu schwenken, und die Benutzeroberfläche 600 kann eine entsprechende Anpassung für das andere Bild vornehmen.
Bei einigen Ausführungsformen kann das Kennzeichnungswerkzeug Informationen über die Sensormodalitäten hinweg projizieren, um Zuordnungen zwischen den Sensordaten zu veranschaulichen. Zum Beispiel kann eine bekannte Ausrichtung und Position einer Kamera, die ein bestimmtes Bild aufgenommen hat, verwendet werden, um das Bild in eine 3D-Darstellung der Umgebung (z.B. 3D-LiDAR-Koordinaten) zu entprojizieren und 3D-Positionen (z.B. im LiDAR-Raum) zu identifizieren, die einem bestimmten Bildpixel entsprechen. Um in die andere Richtung zu projizieren, kann eine bestimmte 3D-Position im LiDAR-Raum anhand der bekannten Ausrichtung und Position der Kamera, die das Bild aufgenommen hat, in den Bildraum projiziert werden. Im Allgemeinen können verschiedene Arten von Informationen von einem LiDAR-Bild in ein entsprechendes Bild projiziert werden, wie z.B. Erkennungen (z.B. Punkte, Ebenen), Annotationen oder andere Regionen. Bei einigen Ausführungsformen kann die Benutzeroberfläche 600 die Position einer Eingabeprobe, die sich mit den Eingaben des Benutzers bewegt, über die Sensormodalitäten hinweg projizieren. Wenn der Benutzer beispielsweise mit der Maus über das LiDAR-Bild 620 fährt, kann die Eingabeprobe 640 (auch in der vergrößerten Region 630 dargestellt) verwendet werden, um eine entsprechende 3D-Position im LiDAR-Raum zu identifizieren (z. B. durch Festlegen eines z-Werts von Null, eines z-Werts einer angepassten Grundfläche usw.), und die 3D-Position kann in den Bildraum projiziert werden, um einen entsprechenden Punkt 650 im Bild 610 darzustellen. Bei einigen Ausführungsformen kann eine Eingabeprobe zusätzlich oder alternativ in die entgegengesetzte Richtung projiziert werden (z.B. kann ein bestimmter Punkt des Bildes 610 in das LiDAR-Bild 620 projiziert werden). Durch die Darstellung von Zuordnungen zwischen den Sensormodalitäten kann die Benutzeroberfläche 600 nützliche Kontextinformationen liefern, die den Kennzeichnern helfen, genauere Annotationen zu erstellen.
Bei einigen Ausführungsformen wird der Kennzeichner bei jeder LiDAR-Drehung in einem initialen Schritt aufgefordert, eine Grundfläche an die LiDAR-Drehung anzupassen. Bei einigen Ausführungsformen kann eine angepasste Grundfläche aus einer früheren LiDAR-Drehung auf die aktuelle Drehung übertragen werden, und der Kennzeichner kann aufgefordert werden, die frühere Grundfläche auf die aktuelle Ebene abzustimmen, was das Kennzeichnungsverfahren beschleunigen kann. Bei einigen Ausführungsformen kann diese datenangepasste Grundfläche einen z-Wert für Top-Down-LiDAR-Annotationen bereitstellen. Auf diese Weise können die empfangenen Annotationen an einer bestimmten Grundfläche ausgerichtet werden, was die Genauigkeit der Annotation in der Draufsicht verbessern kann. Zusätzlich oder alternativ kann bei einigen Ausführungsformen die Benutzeroberfläche 600 einen Satz von Annotationen mit den Annotationen der vorherigen LiDAR-Drehung initialisieren, und der Kennzeichner kann die Annotationen an die aktuelle Drehung anpassen. Auf diese Weise kann das Kennzeichnungswerkzeug die Notwendigkeit verringern oder beseitigen, eine Annotation für dasselbe Objekt immer wieder neu zu erstellen.
Bei einigen Ausführungsformen kann die Benutzeroberfläche 600 Eingabeannotationen akzeptieren, die 2D-Polygonbereiche des LiDAR-Bildes 620 und/oder Ausrichtungen von Objekten bezeichnen, die durch die 2D-Polygonbereiche dargestellt werden. Da es sich bei dem LiDAR-Bild 620 um eine Projektion von 3D-Daten (z.B. einer LiDAR-Punktwolke) handeln kann, kann eine Eingabeannotation an eine entsprechende 3D-Darstellung im LiDAR-Raum angepasst werden. Zum Beispiel können in einigen Fällen, in denen das LiDAR-Bild 620 ein Top-Down-Projektionsbild ist, annotierte Regionen in der XY-Ebene in dem LiDAR-Koordinatensystem erstellt werden (z.B. mit einem z-Wert von Null, einem z-Wert einer angepassten Grundfläche), und die 2D-annotierten Regionen können auf 3D erweitert werden (z.B. in einem nachfolgenden Durchlauf durch eine Sequenz von Annotationsszenen, wie in einer nachfolgenden Annotationsaufgabe), wie es im Folgenden näher erläutert ist.
7 zeigt eine beispielhafte Benutzeroberfläche 700 für eine kameragestützte LiDAR-Kennzeichnung mit einem Orientierungsvektor gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Wie die Benutzeroberfläche 600 kann auch die Benutzeroberfläche 700 Eingaben akzeptieren, die polygonale Regionen eines LiDAR-Bildes 720 kennzeichnen. In diesem Beispiel hat ein Kennzeichner eine Bounding-Box 730 angegeben. Bei einigen Ausführungsformen kann das Kennzeichnungswerkzeug eine Eingabe akzeptieren, die einen Orientierungsvektor 740 (z.B. durch Klicken und Ziehen in die Richtung der Orientierung), ein Klassenkennzeichen 750 oder eine andere Art von Annotation angibt. Wie die Benutzeroberfläche 600 kann auch die Benutzeroberfläche 700 eine Visualisierung von Zuordnungen (z.B. korrespondierende Regionen) zwischen dem LiDAR-Bild 720 und einem Bild 710 anzeigen, um bei der Annotationsaufgabe zu unterstützen. In diesem Beispiel sind die Klasse und die Ausrichtung des in dem LiDAR-Bild 720 dargestellten Objekts in dem Bild 710 zu erkennen. Indem das Bild 710 in Verbindung (z.B. gleichzeitig) mit dem LiDAR-Bild 720 angezeigt wird, kann ein Kennzeichner die Klasse und die Ausrichtung wahrnehmen und daher die entsprechende(n) Annotation(en) kodieren.
8 zeigt eine beispielhafte Benutzeroberfläche 800 für eine kameragestützte LiDAR-Kennzeichnung mit 3D-Bounding-Boxen gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Bei einigen Ausführungsformen kann die kameragestützte LiDAR-Kennzeichnung in separate Aufgaben für 2D- und 3D-Annotationen aufgeteilt werden. 3D-Annotationen können manuell und/oder automatisch erstellt werden. Zum Beispiel kann die LiDAR-Kennzeichnung in einen ersten Durchgang, der Eingaben akzeptiert, die 2D-Annotationen (z.B. 2D Bounding-Boxen) spezifizieren, und einen zweiten Durchgang, der Eingaben akzeptiert, die die 2D-Annotationen in 3D-Annotationen (z.B. 3D-Bounding-Boxen) umwandeln, oder in eine zweite Stufe, die automatisch 3D-Annotationen von den 2D-Annotationen erzeugt (z.B. als Teil der Nachbearbeitung 160 von 1), unterteilt werden. In einer Ausführungsform, welche Eingaben akzeptiert, mit denen 2D-Annotationen in 3D-Annotationen umgewandelt werden, kann das Kennzeichnungswerkzeug nach Erhalt einer Spezifikation von 2D-Annotationen (z.B. Bounding-Boxen) während eines ersten Durchlaufs durch eine Sequenz von Top-Down-LiDAR-Bildern einen Kennzeichner durch ein objektspezifisches Verfahren führen. In diesem Beispiel kann das Kennzeichnungswerkzeug für jedes Objekt (z.B. jede 2D-Annotation, die während des ersten Durchlaufs festgelegt wurde) eine objektausgerichtete, vergrößerte Ansicht des Objekts im aktuellen LiDAR-Bild anzeigen. Beispielsweise können die Rohdaten für das aktuelle LiDAR-Bild (z.B. die LiDAR-Punktwolke) in eine oder mehrere Ansichten projiziert werden, wie z.B. eine nach vorne gerichtete Ansicht des Objekts (z.B. die nach vorn gerichtete Ansicht 830), eine seitlich gerichtete Ansicht des Objekts (z.B. die seitlich gerichtete Ansicht 820) und eine Top-Down-Ansicht des Objekts (z.B. die Top-Down-Ansicht 840), von denen jede in der Benutzeroberfläche 800 dargestellt werden kann. Bei einigen Ausführungsformen kann zusätzlich oder alternativ eine 3D-Darstellung der LiDAR-Punktwolke angezeigt werden (z.B. die 3D-Ansicht 810).
Die Benutzeroberfläche 800 kann den Kennzeichner auffordern, Abmessungen und/oder die Ausrichtung (z.B. Gieren, Neigen, Rollen) jedes Objekts in einer oder mehreren Ansichten anzugeben. In dem Beispiel, in dem ein erster Durchlauf in 2D erfolgt, kann eine erste 2D-Annotation angezeigt werden (in jeder der Ansichten 810, 820, 830, 840). Es sei angemerkt, dass eine 2D-Annotation, die in einer Top-Down-Ansicht gemacht wurde, in der Ansicht von vorn 830 und in der Ansicht von der Seite 820 zunächst als Linie dargestellt werden kann und/oder in der Top-Down-Ansicht 840 und in der 3D-Ansicht 810 in allen zwei Dimensionen dargestellt werden kann. In dem in 8 dargestellten Beispiel kann der Kennzeichner eine 2D-Annotation in eine 3D-Annotation umwandeln oder eine 3D-Annotation anderweitig spezifizieren, z.B. durch Platzieren von Eckpunkten, Ziehen von Bedienelementen oder anderweitige Definition oder Manipulation einer Darstellung der Annotation in einer beliebigen Ansicht (z.B. Bounding-Boxen 815, 825, 835, 845 in den jeweiligen Ansichten 810, 820, 830, 840). Bei einigen Ausführungsformen wird durch die Änderung der Annotation in einer Ansicht die Annotation in jeder anderen Ansicht, in der die Änderung sichtbar ist, aktualisiert. So kann ein Kennzeichner eine 3D-Annotation an LiDAR-Daten (z.B. an eine LiDAR-Punktwolke) anpassen. Nachdem der Kennzeichner eine 3D-Annotation für ein bestimmtes Objekt festgelegt hat, kann der Benutzer die Annotation übermitteln (z.B. durch Klicken auf eine Schaltfläche „Weiter“ oder ein anderes Interaktionselement), um zum nächsten Objekt im LiDAR-Bild zu gelangen.
9 zeigt eine beispielhafte Benutzeroberfläche 900 für das LiDAR-Verfolgen gemäß einigen Ausführungsformen der vorliegenden Offenbarung. In diesem Beispiel zeigt die Benutzeroberfläche 900 aufeinanderfolgende LiDAR-Bilder 910 und 920 sowie entsprechende Bilder 930 und 940 aus der gleichen Annotationsszene. Das Kennzeichnungswerkzeug kann die Objekte im vorherigen Bild durchgehen (z.B. die während einer vorherigen Annotationsaufgabe eingegebenen Annotationen), und die Benutzeroberfläche 900 kann den Kennzeichner auffordern, die entsprechende Annotation (z.B. die während einer vorherigen Annotationsaufgabe eingegebene) im aktuellen Bild zu finden. Bei einigen Ausführungsformen kann die Objekterkennung und -verfolgung angewendet werden, um die Bewegung der annotierten Objekte von Bild zu Bild im Laufe der Zeit zu verfolgen und/oder eine Verknüpfung zur Bestätigung oder Feinabstimmung durch einen menschlichen Kennzeichner zu initialisieren. In dem in 9 gezeigten Beispiel kann der Kennzeichner die Annotationen 950 und 960 als dasselbe Objekt identifizieren. In manchen Fällen können Objekte in einigen Bildern verdeckt sein, in anderen aber nicht. Bei einigen Ausführungsformen kann das Kennzeichnungswerkzeug daher eine Eingabe akzeptieren, die Objekte (Annotationen) über getrennte Bilder (z.B. Sprünge) hinweg miteinander verbindet.
Bei einigen Ausführungsformen kann die Benutzeroberfläche 900 eine vorausbestimmte Region hervorheben, in der sich ein Objekt voraussichtlich befinden wird. Beispielsweise können ein oder mehrere Positionswerte eines aktuellen oder ausgewählten Objekts in einem ersten Bild (z.B. von LiDAR-Daten) angepasst werden, um eine bekannte Eigenbewegung des Sensors, der die Daten erfasst hat, (z.B. die bekannte Eigenbewegung eines Datenerfassungsfahrzeugs) zu kompensieren. Als nicht einschränkendes Beispiel können ein oder mehrere Positionswerte einer Annotation eines Objekts (z.B. eine Bounding-Box) und/oder ein oder mehrere repräsentative Positionswerte des Objekts in einem ersten Bild von LiDAR-Daten (z.B. ein Mittelpunkt einer Bounding-Box, eine Ecke einer Bounding-Box) bezüglich einer Ego-Bewegung kompensiert werden, und die Benutzerschnittstelle 900 kann eine entsprechende vorhergesagte Region in einem zweiten Bild von LiDAR-Daten hervorheben, umreißen, ansteuern, heranzoomen und/oder anderweitig betonen. In einer beispielhaften Implementierung kann die Benutzeroberfläche 900 den Kennzeichner bei der Wiederholung der gekennzeichneten Objekte einer vorherigen Annotationsszene leiten, indem sie eine Visualisierung darstellt, wo ein gekennzeichnetes Objekt aus der vorherigen Annotationsszene in einer nachfolgenden Annotationsszene vorhergesagt wird, z. B. durch Zoomen in eine vorausbestimmte Region in den Sensordaten. Auf diese Weise kann die Benutzeroberfläche 900 einen Kennzeichner bei der Identifizierung entsprechender Objekte von Szene zu Szene unterstützen. Bei einigen Ausführungsformen kann die Benutzeroberfläche 900 auch bei relativ niedrigen Abtastraten eine nützliche Hilfestellung bieten, da die Ego-Bewegungskompensation auch bei niedrigeren Abtastraten nützliche Vorhersagen bereitstellen kann.
In 9 weist die Benutzeroberfläche 900 ein Kennzeichenfeld 970 auf, das verschiedene Interaktionselemente aufweist, die entsprechende Annotationsfunktionen aktivieren. Wenn beispielsweise die Kennzeichen-Paar-Schaltfläche 975 aktiv ist, kann ein Benutzer Annotationen identifizieren und verknüpfen (z.B. neue Verknüpfungen eingeben). Einer von Nichtübereinstimmungsgründen 980 kann ausgewählt werden, um anzuzeigen, dass eine Annotation aus einem Bild in einem benachbarten Bild nicht sichtbar oder nicht gekennzeichnet ist. Bei einigen Ausführungsformen kann das Kennzeichnungsfeld 970 Miniaturbilder (z.B. Miniaturbilder 985a, 985b) von aufeinanderfolgenden Bildern anzeigen und eine Eingabe akzeptieren, die auf Probleme mit Kamera- und/oder LiDAR-Bild-Annotationen hinweist. So kann eine Annotationsaufgabe, bei der Annotationen über mehrere Bilder von Sensordaten hinweg verknüpft werden, zumindest teilweise als Qualitätssicherungsprüfung dienen (z.B. die Qualitätssicherungsprüfung 170 in 1). Wenn der Kennzeichner die Verknüpfung von Annotationen in einem Paar benachbarter Bilder abgeschlossen hat, kann der Kennzeichner die Verknüpfungen bestätigen 990, um zum nächsten Paar benachbarter Bilder zu gelangen. Obwohl dieses Beispiel eine Annotationsaufgabe zeigt, bei der ein oder mehrere Kennzeichner Objekte verknüpfen, die in mehreren LiDAR-Bildern erscheinen, können einige Ausführungsformen zusätzlich oder alternativ eine Annotationssaufgabe aufweisen, bei der ein Kennzeichner Objekte verknüpft, die in mehreren Kamerabildern erscheinen.
10 ist eine Illustration einer beispielhaften Benutzeroberfläche 1000 für Kamera-LiDAR-Verknüpfungen gemäß einigen Ausführungsformen der vorliegenden Offenbarung. In diesem Beispiel zeigt die Benutzeroberfläche 1000 ein LiDAR-Bild 1020 sowie ein entsprechendes Bild 1010 aus derselben Annotationsszene. Das Kennzeichnungswerkzeug kann die Objekte in der Annotationsszene wiederholen (z.B. die während einer vorherigen Annotationsaufgabe eingegebenen Annotationen), und die Benutzeroberfläche 1000 kann den Kennzeichner auffordern, die entsprechende Annotation in der anderen Sensormodalität zu finden. Im Allgemeinen können Annotationen, Objektspuren und/oder Objekterkennungen aus Sensordaten eines bestimmten Sensors mit entsprechenden Annotationen, Objektspuren und/oder Objekterkennungen für dasselbe Objekt aus Sensordaten eines anderen Sensors verknüpft werden. Zum Beispiel kann der Kennzeichner die Annotationen 1040 und 1050 als dasselbe Objekt identifizieren.
Bei einigen Ausführungsformen kann die Benutzeroberfläche 1000 eine vorausbestimmte Region hervorheben, in der sich ein Objekt voraussichtlich befinden wird. Zum Beispiel können ein oder mehrere Positionswerte eines aktuellen oder ausgewählten Objekts in einem ersten Bild (z.B. einem Kamera-Bild oder LiDAR-Bild) in ein zweites Bild (z.B. ein LiDAR-Bild oder Kamera-Bild) projiziert und angepasst werden, um eine bekannte Eigenbewegung des oder der Sensoren, der (die) die Daten erfasst hat (haben) (z.B. die bekannte Eigenbewegung eines Datenerfassungsfahrzeugs), zu kompensieren. Als nicht einschränkendes Beispiel können ein oder mehrere Positionswerte einer Annotation eines Objekts (z.B. eine Bounding-Box) und/oder ein oder mehrere repräsentative Positionswerte eines Objekts in einem ersten Bild von Sensordaten (z.B. ein Mittelpunkt einer Bounding-Box, eine Ecke einer Bounding-Box) in ein zweites Bild projiziert und die Eigenbewegung kompensiert werden, und die Benutzerschnittstelle 1000 kann eine entsprechende vorhergesagte Region in dem zweiten Bild hervorheben, umreißen, darauf schwenken, zoomen und/oder anderweitig betonen. So kann die Benutzeroberfläche 1000 eine bekannte Zuordnung zwischen den Sensormodalitäten nutzen, um den Kennzeichner bei der Identifizierung entsprechender Objekte in den verschiedenen Sensormodalitäten zu unterstützen.
Wie die Benutzeroberfläche 900 weist auch die Benutzeroberfläche 1000 ein Kennzeichnungsfeld 1060 auf, das verschiedene Interaktionselemente aufweist, die entsprechende Annotationsfunktionen aktivieren. Bei einigen Ausführungsformen kann die Benutzeroberfläche 900 eine Eingabe akzeptieren, die Kamera- und/oder LiDAR-Bild-Annotationsaufgaben kennzeichnet. So kann eine Annotationsaufgabe, bei der die Annotationen über die Sensormodalitäten hinweg verknüpft werden, zumindest teilweise als Qualitätssicherungsprüfung dienen (z. B. Qualitätssicherungsprüfung 170 in 1). Wenn der Kennzeichner die Verknüpfung der Annotationen zwischen den Sensormodalitäten in einer Annotationsszene abgeschlossen hat, kann der Kennzeichner die Verknüpfungen bestätigen, um zum nächsten Paar benachbarter Bilder zu gelangen. Obwohl sich die vorangegangene Diskussion auf die Verknüpfung von LiDAR mit der Kamera konzentrierte, kann jede Art von Sensordaten mit jeder anderen Art von Sensordaten verknüpft werden (einschließlich der Verknüpfung zwischen Sensordaten von zwei verschiedenen Typen desselben Sensors, wie z.B. die Verknüpfung von Kamera zu Kamera). Zusätzlich oder alternativ können die Annotationsaufgaben konsolidiert, neu geordnet, aufgeteilt oder auf andere Art und Weise angeordnet werden. Bei einigen Ausführungsformen kann beispielsweise die LiDAR-Kennzeichnung im Rahmen derselben Annotationsaufgabe wie die LiDAR-Kamera-Verknüpfung durchgeführt werden (z.B. nach der Kennzeichnung von Objekten in Kamerabildern werden die entsprechenden Objekte in LiDAR-Bildern gleichzeitig verknüpft und gekennzeichnet). Dies sind nur Beispiele, und im Rahmen der vorliegenden Offenbarung können auch andere Varianten implementiert werden.
Zurück zu 1: Bei einigen Ausführungsformen kann eine Nachbearbeitung 160 durchgeführt werden, um automatisch Merkmale zu erkennen, die Menschen normalerweise nicht wahrnehmen können. Als nicht einschränkendes Beispiel kann die Bildverarbeitung auf Kamerabilder angewandt werden, um einen (dichten) Tiefenwert zu bestimmen (z.B. unter Verwendung eines oder mehrerer Modelle zum maschinellen Lernen, das (die) Tiefenwerte auf einer Pro-Pixel-Basis vorhersagt/en), und die Tiefenwerte oder eine Teilmenge davon (z.B. eine repräsentative Tiefe für jede Annotation, wie die nächstgelegene oder durchschnittliche Tiefe) können dem Bild zugeordnet werden. In einigen Fällen kann die Nachbearbeitung 160 erneut durchgeführt werden (z.B. auf der Grundlage einer verbesserten Kalibrierung), um automatisch erkannte Merkmale neu zu berechnen und/oder die Visualisierung von Zuordnungen zu verbessern (z.B. durch Rückprojektion von 3D-LiDAR-Kennzeichen auf ein entsprechendes Kamerabild). Bei einigen Ausführungsformen kann ein Kennzeichnungsprojekt eine oder mehrere manuelle Qualitätssicherungskontrollen 170 aufweisen, um die Genauigkeit der manuell von menschlichen Kennzeichnungsexperten und/oder automatisch (z.B. während der Nachbearbeitung 160) erzeugten Annotationen zu bestätigen. 11 ist eine Darstellung von beispielhaften Ground-Truth-Annotationen gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
Bei einigen Ausführungsformen kann die Nachbearbeitung 160 durchgeführt werden, um die Ground-Truth-Annotationen in eine kodierte Darstellung umzuwandeln, die der Ansicht, Größe und Dimensionalität der Ausgabe(n) des (der) Modelle zum maschinellen Lernen, die zu trainieren sind, entspricht. Wenn das Modell zum maschinellen Lernen beispielsweise Klassifizierungsdaten ausgibt (z.B. einen oder mehrere Kanäle, wobei jeder Kanal eine andere Klassenkonfidenzkarte ausgibt), können die Ground-Truth-Annotationen in einem bestimmten Bild der Sensordaten in eine entsprechende Klassenkonfidenzkarte für jede Klasse umgewandelt werden. Als nicht einschränkendes Beispiel können für eine bestimmte Klasse die Werte von Pixeln, die in annotierte Regionen dieser Klasse fallen, auf einen Wert gesetzt werden, der eine positive Klassifizierung (z.B. 1) anzeigt, und die Werte der anderen Pixel im Bild können auf einen Wert gesetzt werden, der eine negative Klassifizierung (z.B. 0) anzeigt. So können die verschiedenen Klassenkonfidenzkarten übereinander angeordnet werden, um einen Ground-Truth-Tensor zu bilden, der mit den Ausgaben des oder der Modelle zum maschinellen Lernen übereinstimmt.
In einem anderen Beispiel, wenn das Modell zum maschinellen Lernen Instanzregressionsdaten ausgibt (z.B. einen oder mehrere Kanäle, wobei jeder Kanal eine andere Art von Objektinstanzdaten regressiert, wie z.B. Orts-, Geometrie- und/oder Orientierungsdaten), können der Ort, die Geometrie, die Orientierung und/oder die Klasse jeder der Annotationen verwendet werden, um Objektinstanzdaten zu erzeugen, die mit der Ansicht, Größe und Dimensionalität der Ausgabe(n) des (der) zu trainierenden Modells (Modelle) zum maschinellen Lernen übereinstimmen. Zum Beispiel kann für jedes Pixel, das eine Annotation enthält, die Annotation verwendet werden, um die entsprechenden Orts-, Geometrie- und/oder Ausrichtungsinformationen zu berechnen (z.B. wo sich das Objekt - wie das Objektzentrum - relativ zu jedem Pixel befindet, die Objekthöhe, die Objektbreite, die Objektausrichtung (z.B. Drehwinkel relativ zur Ausrichtung des Projektionsbildes) und/oder ähnliches). Die berechneten Objektinstanzdaten können in einem entsprechenden Kanal eines Ground-Truth-Tensors gespeichert werden. Dies sind nur einige Beispiele, und andere Arten der Nachbearbeitung 160 können zusätzlich oder alternativ durchgeführt werden.
Nachdem einige oder alle Annotationsaufgaben in einem Annotationsprojekt abgeschlossen sind, können die resultierenden Ground-Truth-Daten in jedem geeigneten Format (z.B. Ground-Truth-Datenexport 180 von 1) exportiert werden. Die Ground-Truth-Daten können mit entsprechenden Eingabetrainingsdaten gekoppelt werden, die mit den Eingabetypen übereinstimmen, die von dem oder den zu trainierenden Modellen zum maschinellen Lernen akzeptiert werden. So können ein oder mehrere Modelle zum maschinellen Lernen unter Verwendung der eingegebenen Trainingsdaten und der exportierten Ground-Truth-Daten (z.B. dem Einsatz von Ground-Truth-Daten 190 von 1) trainiert werden. Beispielsweise können eine oder mehrere Verlustfunktionen (z.B. eine einzige Verlustfunktion, eine Verlustfunktion für jeden Ausgabetyp, wie Klassifikationsverlust und/oder Regressionsverlust usw.) verwendet werden, um die Genauigkeit der Ausgabe(n) des (der) Modells/e zum maschinellen Lernen mit der Ground-Truth zu vergleichen, und die Parameter des (der) Modells/e zum maschinellen Lernen können aktualisiert werden (z.B. unter Verwendung von Backward-Passes, Backpropagation, Forward-Passes usw.), bis die Genauigkeit ein optimales oder akzeptables Niveau erreicht.
In den 12 und 13 umfasst jeder Block der Verfahren 1200 und 1300, wie es hier beschrieben ist, einen Rechenprozess, der mit einer beliebigen Kombination aus 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, die auf Computerspeichermedien gespeichert sind, ausgeführt werden. Die Verfahren 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 können die Verfahren 1200 und 1300 beispielhaft in Bezug auf die Annotations-Pipeline 100 von 1 verstanden werden. 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.
12 ist ein Flussdiagramm, das ein Verfahren 1200 zur Erzeugung von Ground-Truth-Annotationen von Sensordaten verschiedener Sensortypen gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 1200 weist im Block B1202 ein Erfassen von Sensordaten auf, die mit verschiedenen Sensortypen während einer Erfassungssitzung erfasst werden. Beispielsweise können ein oder mehrere Fahrzeuge (z.B. das Fahrzeug 1400 der 14A-D) Sensordaten von einem oder mehreren Sensoren des Fahrzeugs bzw. der Fahrzeuge in realen (z.B. physischen) Umgebungen (z.B. als Teil der Datenerfassung 110 der 1) erfassen. Die Sensordaten können auf beliebige Weise gespeichert und abgerufen werden.
Das Verfahren 1200 weist in Block B1204 ein Identifizieren von mindestens einem Offset bzw. Versatz auf, der die Sensordaten synchronisiert, um eine Sequenz von Annotationsszenen zusammenzustellen, wobei jede Annotationsszene ein Bild der Sensordaten von zwei oder mehr der verschiedenen Sensortypen umfasst. Da die Sensordaten beispielsweise von verschiedenen Sensoren mit unterschiedlichen Frequenzen stammen können, können die Sensordaten abgeglichen werden (z.B. Sensordatenabgleich 120 in 1), um ein Gruppieren von Sensordaten mit ähnlichen Weltzuständen zu ermöglichen. Bei einigen Ausführungsformen kann ein bestimmter Sensor als Referenzsensor verwendet werden. Nicht-Referenzsensoren können als untergeordnete Sensoren bezeichnet werden. Für ein gegebenes Bild von Sensordaten des Referenzsensors (Referenzbild) kann ein Offset, wie z.B. eine Zeitdifferenz, zwischen dem Referenzbild und dem zeitlich nächstgelegenen Bild von Sensordaten jedes untergeordneten Sensors ermittelt werden. Der Offset für jeden untergeordneten Sensor kann aufgezeichnet und/oder auf die Erfassungszeiten oder einen anderen Index für die Sensordaten von dem untergeordneten Sensor angewendet werden. Im Allgemeinen können Daten des Referenzsensors und der untergeordneten Sensoren unter Verwendung des identifizierten Offsets (der identifizierten Offsets) abgetastet werden, um die Bilder der Sensordaten von verschiedenen Sensoren für jede Annotationsszene zu identifizieren und zusammenzusetzen.
Das Verfahren 1200 weist im Block B1206 ein Codieren einer Vielzahl von linearen Annotationsaufgaben in ein Kennzeichnungswerkzeug auf, um die Annotationsszenen mit Ground-Truth-Annotationen zu annotieren. Im Allgemeinen kann das Kennzeichnungswerkzeug eine oder mehrere Schnittstellen (z.B. grafische Benutzeroberflächen) aufweisen, die Eingaben von einem Projektadministrator akzeptieren, die Annotationsszenen (z.B. Sensordaten von den verschiedenen Sensormodalitäten) und eine oder mehrere Annotationsaufgaben identifizieren und/oder bereitstellen. Die gewünschten Annotationen können in eine Reihe von linearen Aufgaben zerlegt werden, und eine kodierte Darstellung der Aufgaben kann in das Kennzeichnungswerkzeug eingegeben werden (z.B. als Teil der Annotation 150 in der Annotations-Pipeline 100 von 1).
Das Verfahren 1200 weist im Block B1208 ein Verwenden des Kennzeichnungswerkzeugs auf, um einem Kennzeichner eine Aufgabe zuzuweisen. Zum Beispiel kann das Kennzeichnungswerkzeug als Teil der Annotation 150 in der Annotations-Pipeline 100 von 1 jede Annotationsaufgabe einem bestimmten Kennzeichner auf jede geeignete Weise zuweisen, z. B. durch Zuweisung von Aufgaben auf der Grundlage der Verfügbarkeit des Kennzeichners, einer festgelegten Aufgabenreihenfolge oder auf andere Weise.
Das Verfahren 1200 weist im Block B1210 ein Verwenden des Kennzeichnungswerkzeugs auf, um den Kennzeichner durch die Sequenz der Annotationsszenen zu führen. Zum Beispiel kann das Kennzeichnungswerkzeug als Teil der Annotation150 in der Annotations-Pipeline 100 von 1 die Reihenfolge der Eingaben (z.B. Annotationen) für eine bestimmte Aufgabe mit Hilfe eines Assistenten festlegen, der den Kennzeichner durch die Aufgabe(n) führt.
Das Verfahren 1200 weist in Block B1212 für jede Annotationsszene ein Verwenden des Kennzeichnungswerkzeugs auf, um Eingaben zu fordern und zu akzeptieren, die eine Menge von Ground-Truth-Annotationen spezifizieren, die durch die Annotationsaufgabe definiert werden, während die Sensordaten von zwei oder mehr der verschiedenen Sensortypen in der Annotationsszene dargestellt werden. Beispielsweise kann das Kennzeichnungswerkzeug als Teil der Kennzeichnung 150 in der Annotations-Pipeline 100 von 1 die Reihenfolge der Eingaben für eine bestimmte Aufgabe festlegen (z. B. indem ein Annotationsverfahren pro Objekt für jede Annotationsszene in einer Sequenz durchlaufen wird). 6 zeigt eine beispielhafte Ausführungsform, bei der ein Kennzeichnungswerkzeug gleichzeitig Sensordaten von verschiedenen Sensortypen darstellen und Informationen über Sensormodalitäten hinweg projizieren kann, um Zuordnungen über die Sensordaten hinweg zu veranschaulichen.
Das Verfahren 1200 weist im Block B1214 ein Exportieren einer Darstellung der Ground-Truth-Annotationen auf. Nachdem beispielsweise einige oder alle Annotationsaufgaben in einem Annotationsprojekt abgeschlossen sind, können die resultierenden Ground-Truth-Daten in jedem geeigneten Format (z.B. Ground-Truth-Datenexport 180 von 1) exportiert werden.
13 ist ein Flussdiagramm, das ein Verfahren 1300 zur Erzeugung von Ground-Truth-Annotationen von LiDAR- und Kamera-Bildern gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 1300 umfasst in Block B1302 ein Erfassen von Sensordaten, die während einer Erfassungssitzung erfasst werden, wobei die Sensordaten LiDAR-Bilder von einem LiDAR-Sensor und Kamerabilder von mindestens einer Kamera aufweisen. Beispielsweise können ein oder mehrere Fahrzeuge (z.B. das Fahrzeug 1400 der 14A-D) Sensordaten von einem oder mehreren Sensoren des Fahrzeugs bzw. der Fahrzeuge in realen (z.B. physischen) Umgebungen erfassen (z.B. als Teil der Datenerfassung 110 von 1). Die Fahrzeugsensoren können einen oder mehrere LiDAR-Sensoren und eine oder mehrere Kameras aufweisen. Auf die erfassten Sensordaten kann jederzeit zugegriffen werden.
Das Verfahren 1300 weist im Block B1304 ein Identifizieren eines Offsets für jede Kamera der mindestens einen Kamera auf, der die Kamerabilder mit den LiDAR-Bildern synchronisiert, um eine Sequenz von Annotationsszenen zusammenzustellen, wobei jede Annotationsszene eines der LiDAR-Bilder und mindestens eines der Kamerabilder umfasst. Wenn beispielsweise eine LiDAR-Drehung fortschreitet und verschiedene Abschnitte der Umgebung aufgenommen werden, kann das zeitlich nächstgelegene Kamerabild für eine bestimmte LiDAR-Drehung auf der Grundlage des Blickwinkels der Kamera relativ zum Startwinkel der LiDAR-Drehung und der Zeit, die die LiDAR-Drehung braucht, um sich mit dem Sichtfeld der Kamera (z.B. einem Abschnitt wie der Mitte) auszurichten, ausgewählt werden. Im Allgemeinen können für jede Kamera Zeit- oder Index-Offsets relativ zum LiDAR-Drehungsstart bestimmt und/oder angewendet werden, um die Kamerabilder jeder Kamera mit den LiDAR-Bildern abzugleichen. So kann jedes LiDAR-Bild und ein zeitlich nächstgelegenes Kamerabild (z.B. für jede Kamera) abgetastet und in eine entsprechende Annotationsszene verpackt werden, um die Sequenz zusammenzustellen.
Das Verfahren 1300 weist im Block B1306 ein Kodieren einer Vielzahl von linearen Annotationsaufgaben in ein Kennzeichnungswerkzeug auf, um die Annotationsszenen mit Ground-Truth-Annotationen zu annotieren. Im Allgemeinen kann das Kennzeichnungswerkzeug eine oder mehrere Schnittstellen (z.B. grafische Benutzeroberflächen) aufweisen, die Eingaben von einem Projektadministrator akzeptieren, die Annotationsszenen (z.B. Sensordaten von den verschiedenen Sensormodalitäten) und eine oder mehrere Annotationsaufgaben identifizieren und/oder bereitstellen. Die gewünschten Annotationen können in eine Reihe von linearen Aufgaben zerlegt werden, und eine kodierte Darstellung der Aufgaben kann in das Kennzeichnungswerkzeug (z. B. als Teil der Annotation 150 in der Annotations-Pipeline 100 von 1) eingegeben werden.
Das Verfahren 1300 weist im Block B1308 ein Verwenden des Kennzeichnungswerkzeugs auf, um einen Kennzeichner durch die Sequenz der Annotationsszenen zu führen. Zum Beispiel kann das Kennzeichnungswerkzeug als Teil der Annotation150 in der Annotations-Pipeline 100 von 1 die Reihenfolge der Eingaben (z.B. Annotationen) für eine bestimmte Aufgabe mit Hilfe eines Assistenten festlegen, der den Kennzeichner durch die Aufgabe(n) führt.
Das Verfahren 1300 weist in Block B 1310 für jede Annotationsszene ein Verwenden des Kennzeichnungswerkzeugs auf, um Eingaben anzufordern und zu akzeptieren, die eine Menge von Ground-Truth-Annotationen spezifizieren, die durch die Annotationsaufgabe definiert sind, während das LiDAR-Bild und das mindestens eine der Kamerabilder in der Annotationsszene dargestellt werden. Zum Beispiel kann das Kennzeichnungswerkzeug als Teil der Annotation 150 in der Annotations-Pipeline 100 von 1 die Reihenfolge der Eingaben für eine bestimmte Aufgabe festlegen (z.B. indem für jede Annotationsszene in einer Sequenz ein Annotationsverfahren pro Objekt durchlaufen wird). 6 zeigt eine beispielhafte Ausführungsform, bei der ein Kennzeichnungswerkzeug gleichzeitig LiDAR- und Kamera-Bilder darstellen und Informationen von LiDAR zur Kamera und/oder umgekehrt projizieren kann.
Das Verfahren 1300 weist im Block B1312 ein Exportieren einer Darstellung der Ground-Truth-Annotationen auf. Nachdem beispielsweise einige oder alle Annotationsaufgaben in einem Annotationsprojekt abgeschlossen wurden, können die resultierenden Ground-Truth-Daten in jedem geeigneten Format (z.B. Ground-Truth-Datenexport 180 von 1) exportiert werden. So können ein oder mehrere Modelle zum maschinellen Lernen anhand der exportierten Ground-Truth-Daten trainiert werden (z.B. Einsatz von Ground-Truth-Daten 190 von 1).
BEISPIELHAFTES AUTONOMES FAHRZEUG
14A ist eine Veranschaulichung eines Beispiels für ein autonomes Fahrzeug 1400 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 1400 (hier alternativ als „Fahrzeug 1400“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug sein, wie z. B. ein Auto, ein Lastwagen, ein Bus, ein Rettungsfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, ein Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne und/oder eine andere Art von Fahrzeug (z. B. ein unbemanntes Fahrzeug und/oder ein Fahrzeug, das einen oder mehrere Passagiere aufnimmt). Autonome Fahrzeuge sind im Allgemeinen im Hinblick auf Automatisierungslevels 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. J 3016-201806 , veröffentlicht am 15. Juni 2018, Standard Nr. J 3016-201609 , veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert sind. Das Fahrzeug 1400 kann zu einer Funktionalität gemäß einem oder mehreren von Level 3 - Level 5 der Levels für autonomes Fahren in der Lage sein. Zum Beispiel kann das Fahrzeug 1400 in Abhängigkeit von der Ausführungsform zu einer bedingten Automatisierung (Level 3), einer hohen Automatisierung (Level 4) und/oder einer vollständigen Automatisierung (Level 5) in der Lage sein.
Das Fahrzeug 1400 kann Komponenten wie etwa ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs beinhalten. Das Fahrzeug 1400 kann ein Antriebssystem 1450 beinhalten, wie z. B. einen Verbrennungsmotor, ein Hybridelektrotriebwerk, einen vollelektrischen Motor und/oder eine andere Art von Antriebssystem. Das Antriebssystem 1450 kann mit einem Antriebsstrang des Fahrzeugs 1400 verbunden sein, der ein Getriebe beinhalten kann, um den Antrieb des Fahrzeugs 1400 zu ermöglichen. Das Antriebssystem 1450 als Reaktion auf den Empfang von Signalen von der Drossel/dem Fahrpedal (1452) gesteuert werden.
Ein Lenksystem 1454, das ein Lenkrad beinhalten kann, kann verwendet werden, um das Fahrzeug 1400 zu lenken (z. B. entlang eines gewünschten Pfads oder einer gewünschten Route), wenn das Antriebssystem 1450 in Betrieb ist (z. B., wenn das Fahrzeug in Bewegung ist). Das Lenksystem 1454 kann Signale von einem Lenkungsaktor 1456 empfangen. Für die vollständige Automatisierungsfunktionalität (Level 5) kann das Lenkrad optional sein.
Das Bremssensorsystem 1446 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf den Empfang von Signalen von den Bremsaktoren 1448 und/oder Bremssensoren zu betreiben.
Die Steuerung(en) 1436, die ein oder mehrere System-on-Chips (SoCs) 1404 (14C) und/oder GPU(s) beinhalten können, können Signale (z. B. in Form von Befehlen) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 1400 bereitstellen. Beispielsweise können die Steuerung(en) Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 1448, zur Betätigung des Lenksystems 1454 über einen oder mehrere Lenkaktuatoren 1456 und zur Betätigung des Antriebssystems 1450 über einen oder mehrere Drossel-/Beschleunigungsregler 1452 senden. Die Steuerung(en) 1436 können eine oder mehrere bordeigene (z. B. integrierte) Rechenvorrichtungen (z. B. Supercomputer) beinhalten, 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 1400 zu unterstützen. Die Steuerung(en) 1436 können eine erste Steuerung 1436 für Funktionen des autonomen Fahren, eine zweite Steuerung 1436 für funktionelle Sicherheitsfunktionen, eine dritte Steuerung 1436 für eine Funktionalität der künstlichen Intelligenz (z. B. maschinelles Sehen), eine vierte Steuerung 1436 für eine Infotainment-Funktionalität, eine fünfte Steuerung 1436 für Redundanz in Notfällen und/oder andere Controller beinhalten. In einigen Beispielen kann eine einzelne Steuerung 1436 zwei oder mehrere der vorstehenden Funktionalitäten handhaben, können zwei oder mehr Steuerungen 1436 eine einzelne Funktionalität handhaben und/oder eine beliebige Kombination davon.
Die Steuerung(en) 1436 können die Signale zum Steuern einer/eines oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 1400 als Reaktion auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren empfangen werden (z. B. Sensoreingaben). Die Sensordaten zum Beispiel und ohne Einschränkung empfangen werden von Sensor(en) 1458 von globalen Navigationssatellitensystemen (z. B. Sensor(en) des globalen Positionsbestimmungssystems), RADAR-Sensor(en) 1460, Ultraschallsensor(en) 1462, LiDAR-Sensor(en) 1464, Sensor(en) 1466 einer Trägheitsmesseinheit (inertial measurement unit - „IMU“) (z. B. (einem) Beschleunigungsmesser, Gyroskop(en), Magnetkompass(en), (einem) Magnetometer usw.), Mikrofon(en) 1496, Stereokamera(s) 1468, Weitsichtkamera(s) 1470 (z. B. Fischaugenkameras), Infrarotkamera(s) 1472, Rundumkamera(s) 1474 (z. B. 360-Grad-Kameras), Langstreckenkameras und/oder Mittelstreckenkamera(s) 1498, Geschwindigkeitssensor(en) 1444 (z. B. zum Messen der Geschwindigkeit des Fahrzeugs 1400), Vibrationssensor(en) 1442, Lenksensor(en) 1440, Bremssensor(en) (z. B. als Teil des Bremssensorsystems 1446) und/oder anderen Sensorarten.
Eine oder mehrere der Steuerung(en) 1436 können Eingaben (z. B. durch Eingabedaten dargestellt) von einem Kombiinstrument 1432 des Fahrzeugs 1400 empfangen und Ausgaben (z. B. durch Ausgabedaten, Anzeigedaten usw. dargestellt) über eine Anzeige 1434 einer Mensch-Maschine-Schnittstelle (humanmachine interface - HMI), einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 1400 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z. B. die HD-Karte 1422 von 14C), Positionsdaten (z. B. die Position des Fahrzeugs 1400, z. B. auf einer Karte), Richtung, Position anderer Fahrzeuge (z. B. ein Belegungsgitter), Informationen über Objekte und den Status von Objekten, wie von der/den Steuerung(en) 1436 wahrgenommen, usw. beinhalten. Beispielsweise kann die HMI-Anzeige 1434 Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. eines Straßenschilds, eines Warnschilds, einer sich ändernden Ampel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z. B. jetzt die Spur wechseln, in zwei Meilen die Ausfahrt 34B nehmen usw.).
Das Fahrzeug 1400 beinhaltet ferner eine Netzschnittstelle 1424, die eine oder mehrere drahtlose Antenne(n) 1426 und/oder Modem(s) zum Kommunizieren über ein oder mehrere Netze verwenden kann. Die Netzwerkschnittstelle 1424 kann beispielsweise die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. ermöglichen. Die drahtlose(n) Antenne(n) 1426 kann/können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Vorrichtungen usw.) über lokale Netzwerke wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Low Power Wide Area Network(s) (LPWANs) wie LoRaWAN, SigFox usw. ermöglichen.
14B ist ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug 1400 aus 14A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die entsprechenden Sichtfelder stellen eine beispielhafte Ausführungsform dar und sind nicht als einschränkend aufzufassen. Zum Beispiel können zusätzliche und/oder alternative Kameras enthalten sein und/oder können sich die Kameras an unterschiedlichen Positionen am Fahrzeug 1400 befinden.
Die Kameratypen für die Kameras können Digitalkameras beinhalten, ohne darauf beschränkt zu sein, die zur Verwendung mit Komponenten und/oder Systemen des Fahrzeugs 1400 ausgelegt sind. Die Kamera(s) können mit dem Automobilsicherheitsintegritätslevel (automotive safety integrity level - ASIL) B und/oder mit einem anderen ASIL betrieben werden. Die Kameratypen können in Abhängigkeit von der Ausführungsform zu einer beliebigen Bildaufnahmerate in der Lage sein, wie z. B. 60 Bilder pro Sekunde (frames per second - fps), 120 fps, 240 fps usw. Die Kameras können in der Lage sein, Rollblendenverschlüsse, globale Blendenverschlüsse, eine andere Art von Blendenverschluss oder eine Kombination davon zu verwenden. In einigen Beispielen kann die Farbfilteranordnung eine Rot-Klar-Klar-Klar (red clear clear clear - RCCC)-Farbfilteranordnung, eine Rot-Klar-Klar-Blau (red clear clear blue - RCCB)-Farbfilteranordnung, eine Rot-Blau-Grün-Klar (red blue green clear - RBGC)-Farbfilteranordnung, eine Foveon-X3-Farbfilteranordnung, ein Bayer-Sensoren (RGGB)-Farbfilteranordnung, eine Monochrom-Sensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung beinhalten. In einigen Ausführungsformen können Klarpixelkameras, wie zum Beispiel Kameras mit einer RCCC-, einer RCCB- und/oder einer RBGC-Farbfilteranordnung, in einem Bestreben zur Erhöhung der Lichtempfindlichkeit verwendet werden.
In einigen Ausführungsformen können eine oder mehrere der Kamera(s) verwendet werden, um Funktionen der weiterentwickelten Fahrerassistenzsysteme (advanced driver assistance systems - ADAS) durchzuführen (z. B. als Teil einer redundanten oder ausfallsicheren Ausgestaltung). Zum Beispiel kann eine Multifunktions-Monokamera installiert sein, die Funktionen wie Spurverlassenswarnung, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitstellt. Eine oder mehrere der Kamera(s) (z. B. alle Kameras) können simultan Bilddaten (z. B. ein Video) aufnehmen und bereitstellen.
Eine oder mehrere der Kameras in einer Montagebaugruppe, z. B. einer kundenspezifisch entworfenen (3-D-gedruckten) Baugruppe, montiert sein, um Streulicht und Reflexionen aus dem Inneren des Autos (z. B. Reflexionen vom Armaturenbrett, die sich in den Windschutzscheibenspiegeln spiegeln) auszuschließen, welche die Bilddatenerfassungsfähigkeiten der Kamera beeinträchtigen können. Unter Bezugnahme auf Seitenspiegelmontagebaugruppen können die Seitenspiegelbaugruppen kundenspezifisch 3-D-gedruckt werden, sodass die Kameramontageplatte mit der Form des Seitenspiegels übereinstimmt. In einigen Beispielen kann die Kamera(s) in den Seitenspiegel integriert sein. Bei Seitensichtkameras können die Kamera(s) in den vier Säulen an jeder Ecke des Fahrerhauses integriert sein.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung vor dem Fahrzeug 1400 beinhaltet (z. B. nach vorn gerichtete Kameras), für die Rundumsicht verwendet werden, um dabei zu helfen, nach vorn gerichtete Pfade und Hindernisse zu identifizieren, sowie mit der Hilfe einer oder mehrerer Steuerungen 1436 und/oder Steuer-SoCs beim Bereitstellen von Informationen zu helfen, die für die Erzeugung eines Belegungsgitters und/oder die Bestimmung der bevorzugten Fahrzeugpfade entscheidend sind. Nach vorn gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LiDAR auszuführen, einschließlich, Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorn gerichtete Kameras können auch für ADAS-Funktionen und -Systeme verwendet werden, einschließlich, Spurverlassenswarnungen (Lane Departure Warning - „LDW“), autonome Geschwindigkeitssteuerung (Autonomous Cruise Control - „ACC“) und/oder andere Funktionen wie Verkehrszeichenerkennung.
Eine Vielfalt an Kameras kann in einer nach vorn gerichteten Konfiguration verwendet werden, einschließlich zum Beispiel einer monokularen Kameraplattform, die einen Farbbildsensor mit CMOS (complementary metal oxide semiconductor - komplementärer Metalloxid-Halbleiter) beinhaltet. Ein weiteres Beispiel kann/können eine Weitsichtkamera(s) 1470 sein, die verwendet werden kann/können, um Objekte wahrzunehmen, die aus der Peripherie ins Blickfeld kommen (z. B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl in 14B nur eine Weitwinkelkamera dargestellt ist, kann eine beliebige Anzahl von Weitwinkelkameras 1470 am Fahrzeug 1400 vorhanden sein. Zusätzlich können Langstreckenkamera(s) 1498 (z. B. ein Weitsichtstereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die noch kein neuronales Netzwerk trainiert wurde. Die Langstreckenkamera(s) 1498 können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
Eine oder mehrere Stereokameras 1468 können auch in einer nach vorne gerichteten Konfiguration beinhaltet sein. Die Stereokamera(s) 1468 können eine integrierte Steuereinheit beinhalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzelnen Chip bereitstellen kann. Mit einer solchen Einheit kann eine 3-D-Karte der Fahrzeugumgebung erstellt werden, die auch eine Entfernungsschätzung für alle Punkte im Bild beinhaltet. Eine oder mehrere alternative Stereokamera(s) 1468 können (einen) kompakte(n) Stereosichtsensor(en) beinhalten, die zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip beinhalten können, der den Abstand von dem Fahrzeug zu dem Zielobjekt messen und die erzeugten Informationen (z. B. Metadaten) verwenden kann, um autonome Notbrems- und Spurverlassenswarnfunktionen zu aktivieren. Andere Arten von Stereokamera(s) 1468 können zusätzlich oder alternativ zu den hierin beschriebenen verwendet werden.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung seitlich des Fahrzeugs 1400 beinhaltet (z. B. Seitensichtkameras), können für die Rundumsicht verwendet werden, wodurch Informationen bereitgestellt werden, die zum Erstellen und Aktualisieren des Belegungsgitters sowie zum Erzeugen von Seitenaufprallkollisionswarnungen verwendet werden. Zum Beispiel können die Umgebungskamera(s) 1474 (z. B. vier Umgebungskameras 1474, wie in 14B) auf dem Fahrzeug 1400 positioniert werden. Die Umgebungskamera(s) 1474 kann/können Weitwinkelkamera(s) 1470, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches beinhalten. So können beispielsweise vier Fischaugenkameras an der Vorderseite, am Heck und an den Seiten des Fahrzeugs angebracht werden. In einer alternativen Anordnung kann das Fahrzeug drei Rundumkamera(s) 1474 (z. B. links, rechts und hinten) verwenden und kann eine oder mehrere andere Kamera(s) (z. B. eine nach vorn gerichtete Kamera) als eine vierte Rundumsichtkamera nutzen.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung hinter dem Fahrzeug 1400 einschließt (z. B. Rückfahrkameras), können als Einparkhilfe, für die Rundumsicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsgitters verwendet werden. Eine Vielfalt von Kameras kann verwendet werden, einschließlich, aber nicht beschränkt auf, Kameras, die auch als nach vorn gerichtete Kamera(s) geeignet sind (z. B. Langstreckenkameras und/oder Mittelstreckenkamera(s) 1498, Stereokamera(s) 1468), Infrarotkamera(s) 1472 usw.), wie hierin beschrieben.
14C ist ein Blockdiagramm einer Beispiel-Systemarchitektur des beispielhaften autonomen Fahrzeugs 1400 von 14A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
Jede der Komponenten, Merkmale und Systeme des Fahrzeugs 1400 sind in 14C so dargestellt, dass sie über den Bus 1402 verbunden sind. Der Bus 1402 kann eine Controller Area Network (CAN)-Datenschnittstelle beinhalten (hier alternativ als „CAN-Bus“ bezeichnet). Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 1400 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 1400 verwendet wird, wie z. B. Betätigung der Bremsen, Beschleunigung, Bremsen, Lenkung, Scheibenwischer usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten aufweist, jeder mit seiner eigenen eindeutigen Kennung (z. B. eine CAN-ID). Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, Grundgeschwindigkeit, die Umdrehungen des Motors pro Minute (revolutions per minute - RPMs), Tastenpositionen und/oder andere Fahrzeugstatusindikatoren zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
Obwohl der Bus 1402 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können zusätzlich zu oder alternativ zu dem CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Obwohl der Bus 1402 mit einer einzigen Linie dargestellt wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel kann eine beliebige Anzahl von Bussen 1402 vorhanden sein, die einen oder mehr CAN-Busse, einen oder mehr FlexRay-Busse, einen oder mehr Ethernet-Busse und/oder einen oder mehr andere Arten von Bussen mit einem anderen Protokoll beinhalten können. In einigen Beispiel können zwei oder mehr Busse 1402 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder können sie zur Redundanz verwendet werden. Zum Beispiel kann ein erster Bus 1402 für die Kollisionsvermeidungsfunktionalität verwendet werden und kann ein zweiter Bus 1402 für die Antriebssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 1402 mit beliebigen Komponenten des Fahrzeugs 1400 kommunizieren und können zwei oder mehr Busse 1402 mit denselben Komponenten kommunizieren. In einigen Beispielen können jedes SoC 1404, jede Steuerung 1436 und/oder jeder Computer im Fahrzeug Zugriff auf dieselben Eingabedaten (z. B. Eingaben von Sensoren des Fahrzeugs 1400) haben und mit einem gemeinsamen Bus, wie z. B. dem CAN-Bus, verbunden sein.
Das Fahrzeug 1400 kann eine oder mehrere Steuerung(en) 1436 beinhalten, wie etwa diejenigen, die hierin in Bezug auf 14A. Die Steuerung(en) 1436 können für eine Vielfalt von Funktionen verwendet werden. Die Steuerung(en) 1436 können mit beliebigen der verschiedenen anderen Komponenten und Systemen des Fahrzeugs 1400 gekoppelt sein und können sie zur Steuerung des Fahrzeugs 1400, der künstlichen Intelligenz des Fahrzeugs 1400, des Infotainment für das Fahrzeug 1400 und/oder dergleichen verwendet werden.
Das Fahrzeug 1400 kann ein System (oder mehrere Systeme) auf einem Chip (SoC) 1404 beinhalten. Das SoC 1404 kann CPU(s) 1406, GPU(s) 1408, Prozessor(en) 1410, Cache(s) 1412, Beschleuniger 1414, Datenspeicher 1416 und/oder andere nicht dargestellte Komponenten und Funktionen beinalten. Das/die SoC(s) 1404 können zur Steuerung des Fahrzeugs 1400 in einer Vielfalt von Plattformen und Systemen verwendet werden. Beispielsweise können die SoC(s) 1404 in einem System (z. B. dem System des Fahrzeugs 1400) mit einer HD-Karte 1422 kombiniert werden, die über eine Netzwerkschnittstelle 1424 von einem oder mehreren Servern (z. B. dem/den Server(n) 1478 von 14D) Aktualisierungen der Karte erhalten kann.
Die CPU(s) 1406 können einen CPU-Cluster oder CPU-Komplex (hierin alternativ als „CCPLEX“ bezeichnet) beinhalten. Die CPU(s) 1406 können mehrere Kerne und/oder L2-Caches beinhalten. Zum Beispiel können in einigen Ausführungsformen die CPU(s) 1406 acht Kerne in einer kohärenten Mehrprozessorkonfiguration beinhalten. In einigen Ausführungsform können die CPU(s) 1406 vier Doppelkerncluster beinhalten, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z. B. einen L2-Cache mit 2 MB). Die CPU(s) 1406 (z. B. CCPLEX) können so konfiguriert sein, dass sie den simultanen Clusterbetrieb unterstützen, sodass eine beliebige Kombination von den Clustern von den CPU(s) 1406 zu einem beliebigen gegebenen Zeitpunkt aktiv sein kann.
Die CPU(s) 1406 können Leistungsverwaltungsfähigkeiten implementieren, die eines oder mehrere der folgenden Merkmale beinhalten: einzelne Hardwareblöcke können automatisch taktgesteuert werden, wenn sie inaktiv sind, um dynamische Leistung zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI-/WFE-Anweisungen keine Anweisungen aktiv ausführt; jeder Kern kann unabhängig leistungsgesteuert sein; jeder Kerncluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder leistungsgesteuert sind; und/oder jeder Kerncluster kann unabhängig leistungsgesteuert sein, wenn alle Kerne leistungsgesteuert sind. Die CPU(s) 1406 können ferner einen erweiterten Algorithmus zur Verwaltung von Leistungsstatus implementieren, bei dem zulässige Leistungsstatus und erwartete Aufwachzeiten spezifiziert werden und die Hardware/der Mikrocode den besten Leistungsstatus bestimmt, in den für den Kern, Cluster und CCPLEX einzutreten ist. Die Verarbeitungskerne können vereinfachte Leistungsstatus-Eintragssequenzen in der Software unterstützen, wobei die Arbeit in den Mikrocode ausgelagert wird.
Die GPU(s) 1408 können eine integrierte GPU (hierin alternativ als „iGPU“ bezeichnet) beinhalten. Die GPU(s) 1408 können programmierbar sein und für parallele Arbeitslasten effizient sein. Die GPU(s) 1408 können in einigen Beispielen einen erweiterten Tensor-Anweisungssatz verwenden. Die GPU(s) 1408 einen oder mehrere Streaming-Mikroprozessoren beinhalten, wobei jeder Streaming-Mikroprozessor einen L1-Cache beinhalten kann (z. B. einen L1-Cache mit einer Speicherkapazität von mindestens 96 KB), und zwei oder mehr der Streaming-Mikroprozessoren können einen L2-Cache gemeinsam nutzen (z. B. einen L2-Cache mit einer Speicherkapazität von 1412 KB). In einigen Ausführungsformen können die GPU(s) 1408 mindestens acht Streaming-Mikroprozessoren beinhalten. Die GPU(s) 1408 können (eine) Berechnungs-Anwendungsprogrammierschnittstelle(n) (API(s)) verwenden. Zusätzlich können die GPU(s) 1408 eine oder mehrere Parallelrechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
Die GPU(s) 1408 können für die beste Rechenleistung in Automobil- und eingebetteten Anwendungsfällen leistungsoptimiert sein. Die GPU(s) 1408 können zum Beispiel auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Dies ist jedoch nicht als Einschränkung zu verstehen, und die GPU(s) 1408 können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von Verarbeitungskernen mit gemischter Genauigkeit beinhalten, die in mehrere Blöcke partitioniert sind. Zum Beispiel, und ohne Einschränkung, könnten 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke partitioniert sein. In solch einem Beispiel könnten jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Genauigkeit für Deep-Learning-Matrixarithmetik, ein L0" Anweisungs-Cache, ein Warp-Planer, eine Verteilungseinheit und/oder eine Registerdatei mit 64 KB zugewiesen sein. Zusätzlich können Streaming-Mikroprozessoren unabhängige parallele Integer- und Fließkomma-Datenpfade beinhalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnung und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfunktion beinhalten, um eine feinkörnigere Synchronisation und Kooperation zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können eine Einheit aus kombiniertem L1-Daten-Cache und gemeinsam genutztem Speicher beinhalten, um die Performance zu verbessern, während die Programmierung vereinfacht wird.
Die GPU(s) 1408 können einen Speicher mit hoher Bandbreite (high bandwidth memory - HBM) und/oder ein 16-GB-HBM2-Speicherteilsystem beinhalten, um in einigen Beispielen eine Spitzenspeicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispiel kann zusätzlich oder alternativ zum HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher („SGRAM“) verwendet werden, z. B. ein synchroner Grafik-Double-Data-Rate-Typ-Fünf-Direktzugriffsspeicher („GDDR5“).
Die GPU(s) 1408 kann/können eine einheitliche Speichertechnologie mit Zugriffszählern beinhalten , die eine genauere Zuweisung von Speicherseiten an den Prozessor ermöglicht, der am häufigsten darauf zugreift, und so die Effizienz von Speicherbereichen verbessert, die von mehreren Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (address translation services - ATS) verwendet werden, um zu ermöglichen, dass die GPU(s) 1408 direkt auf die Seitentabellen von CPU(s) 1406 zugreifen. In derartigen Beispielen, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 1408 eine Auslassung erleidet, kann eine Adressübersetzungsanforderung an die CPU(s) 1406 übertragen werden. Als Reaktion darauf können die CPU(s) 1406 iin ihren Seitentabellen nach einer Virtuell-zu-Physisch-Zuordnung für die Adresse suchen und die Übersetzung zurück an die GPU(s) 1408 übertragen. Daher kann die einheitliche Speichertechnologie einen einzelnen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 1406 als auch der GPU(s) 1408 ermöglichen, wodurch die Programmierung der GPU(s) 1408 und die Portierung von Anwendungen auf die GPU(s) 1408 vereinfacht werden.
Zusätzlich können die GPU(s) 1408 einen Zugriffszähler beinhalten, der die Häufigkeit des Zugriffs der GPU(s) 1408 auf Speicher anderer Prozessoren nachverfolgen können. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher des Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
Die SoC(s) 1404 können eine beliebige Anzahl von Cache(s) 1412 beinhalten, einschließlich der hierin beschriebenen. Der/die Cache(s) 1412 kann/können beispielsweise einen L3-Cache beinhalten, der sowohl der/den CPU(s) 1406 als auch der/den GPU(s) 1408 zur Verfügung steht (z. B. der sowohl mit der/den CPU(s) 1406 als auch mit der/den GPU(s) 1408 verbunden ist). Der/die Cache(s) 1412 können einen Rückschreib-Cache beinhalten, der die Status von Zeilen verfolgen kann, wie z. B. durch die Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann in Abhängigkeit von der Ausführungsform 4 MB oder mehr beinhalten, obwohl auch kleinere Cache-Größen verwendet werden können.
Der/die SoC(s) 1404 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) beinhalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der vielen Aufgaben oder Operationen des Fahrzeugs 1400 - wie z. B. der Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus können die SoC(s) 1404 eine oder mehrere Gleitkommaeinheiten (floating point units - FPU(s)) - oder andere mathematische Coprozessoren oder numerische Coprozessoren - zur Durchführung mathematischer Operationen innerhalb des Systems beinhalten. Zum Beispiel können die SoC(s) 104 eine oder mehrere FPUs beinhalten, die als Ausführungseinheiten in einer oder mehreren CPU(s) 1406 und/oder GPU(s) 1408 integriert sind.
Die SoC(s) 1404 können einen oder mehrere Beschleuniger 1414 beinhalten (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Zum Beispiel können das/die SoC(s) 1404 einen Hardware-Beschleunigungscluster beinhalten, der optimierte Hardware-Beschleuniger und/oder einen großen chipinternen Speicher beinhalten kann. Der große chipinterne Speicher (z. B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster zum Beschleunigen neuronaler Netze und anderer Berechnungen ermöglichen. Der Hardware-Beschleunigungscluster kann verwendet werden, um die GPU(s) 1408 zu ergänzen und einige Tasks der GPU(s) 1408 auszulagern (um z. B. mehr Zyklen der GPU(s) 1408 für die Durchführung anderer Tasks freizumachen). Als Beispiel können der/die Beschleuniger 1414 für zielgerichtete Arbeitslasten (z. B. Wahrnehmung, neuronale Faltungsnetzwerke (CNNs usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der Begriff „CNN“, wie er hier verwendet wird, kann alle Arten von CNNs umfassen, einschließlich regionenbasierter oder regionaler neuronaler Faltungsnetzwerke (RCNNs) und Fast RCNNs (z. B. für die Objekterkennung).
Der/die Beschleuniger 1414 können (z. B. Hardware-Beschleunigungscluster) (einen) Deep-Learning-Beschleuniger (deep learning accelerator(s) - DLA(s)) beinhalten. Die DLA(s) können eine oder mehrere Tensor-Verarbeitungseinheiten (TPU(s)) beinhalten, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Vorgänge pro Sekunde für Deep-Learning-Anwendungen und -Ableitung bereitstellen. Die TPUs können Beschleuniger sein, die zum Durchführen von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Die DLA(s) können ferner für einen spezifischen Satz von Arten von neuronalen Netzwerken und Fließkommavorgängen sowie für die Ableitung optimiert sein. Das Design der DLA(s) kann mehr Performance pro Millimeter bereitstellen als eine typische Universal-GPU und übertrifft die Performance einer CPU bei weitem. Die TPU(s) können mehrere Funktionen durchführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datenarten sowohl für Merkmale als auch für Gewichtungen unterstützt, sowie Postprozessorfunktionen.
Die DLA(s) können neuronale Netzwerke, insbesondere CNNs, an verarbeiteten oder unverarbeiteten Daten für eine Vielfalt von Funktionen schnell und effizient ausführen, darunter zum Beispiel 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 und Erkennung von Einsatzfahrzeugen unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und Identifizierung von Fahrzeugbesitzern unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsrelevante Ereignisse.
Die DLA(s) können eine beliebige Funktion der GPU(s) 1408 durchführen und durch Verwenden eines Inferenzbeschleunigers kann ein Designer zum Beispiel entweder die DLA(s) oder die GPU(s) 1408 für eine beliebige Funktion anvisieren. Der Designer kann beispielsweise die Verarbeitung von CNNs und Fließkommavorgängen auf die DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 1408 und/oder anderen Beschleuniger(n) 1414 überlassen.
Der/die Beschleuniger 1414 (z. B. der Hardware-Beschleunigungscluster) können (einen) programmierbare(n) Sichtbeschleuniger (programmable vision accelerator - „PVA“) beinhalten, der hierin alternativ als ein Beschleuniger für maschinelles Sehen bezeichnet werden kann. Die PVA(s) können zur Beschleunigung von Algorithmen des maschinellen Sehens für weiterentwickelte Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented-Reality (AR)-Anwendungen und/oder Virtual-Reality (VR)-Anwendungen konstruiert und konfiguriert sein. Die PVA(s) können ein Gleichgewicht zwischen Performance und Flexibilität bereitstellen. Beispielswiese können alle PVA(s) und ohne Einschränkung eine beliebige Anzahl von Reduced-Instruction-Set-Computer (RISC)-Kerne, direkten Speicherzugriff (direct memory access - DMA) und/oder eine beliebige Anzahl von Vektorprozessoren beinhalten.
Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren einer beliebigen der hierin beschriebenen Kameras), Bildsignalprozessor(en) und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher beinhalten. Die RISC-Kerne können in Abhängigkeit von der Ausführungsform ein beliebiges von einer Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (real-time operating system - RTOS) ausführen. Die RISC-Kerne können unter Verwendung einer oder mehrerer Vorrichtungen für integrierte Schaltungen, anwendungsspezifischer integrierter Schaltungen (ASICs) und/oder Speichervorrichtungen implementiert sein. Die RISC-Kerne können beispielsweise einen Anweisungs-Cache und/oder einen eng gekoppelten RAM beinhalten.
Der DMA kann es den Komponenten des/der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 1406 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Merkmalen unterstützen, die zum Bereitstellen der Optimierung des PVA verwendet werden, einschließlich der Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung, ohne darauf beschränkt zu sein. In einigen Beispiel 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 beinhalten können.
Die Vektorprozessoren können programmierbare Prozessoren sein, die so ausgestaltet sein können, dass sie die Programmierung für Algorithmen des maschinellen Sehens effizient und flexibel ausführen und Signalverarbeitungsfähigkeiten bereitstellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungsteilsystempartitionen beinhalten. Der PVA-Kern kann ein Prozessorteilsystem, DMA-Engine(s) (z. B. zwei DMA-Engines) und/oder andere Peripheriegeräte beinhalten. Das Vektorverarbeitungsteilsystem kann als primäre Verarbeitungs-Engine des PVA arbeiten und kann eine Vektorverarbeitungseinheit (vector processing unit - VPU), einen Anweisungs-Cache und/oder einen Vektorspeicher (z. B. VMEM) beinhalten. Ein VPU-Kern kann einen digitalen Signalprozessor beinhalten, wie zum Beispiel einen digitalen Single-Instruction-Multiple-Data-(SIMD-)Very-Long-Instruction-Word-(VLIW-)Signalprozessor. Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
Jeder der Vektorprozessoren kann einen Anweisungs-Cache beinhalten und an dedizierten Speicher gekoppelt sein. Daher kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren ausgeführt wird. In anderen Beispielen können Vektorprozessoren, die in einem konkreten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität einsetzen. Zum Beispiel kann in einigen Ausführungsformen die Vielzahl von Vektorprozessoren, die in einem einzelnen PVA enthalten ist, denselben Algorithmus des maschinellen Sehens ausführen, jedoch an unterschiedlichen Regionen eines Bildes. In anderen Beispielen können die in einem konkreten PVA enthaltenen Vektorprozessoren simultan unterschiedliche Algorithmen des maschinellen Sehens an demselben Bild ausführen oder sogar unterschiedliche Algorithmen an sequentiellen Bildern oder Abschnitten eines Bildes ausführen. Unter anderem eine beliebige Anzahl von PVAs in dem Hardware-Beschleunigungscluster enthalten sein und kann eine beliebige Anzahl von Vektorprozessoren in jedem der PVAs enthalten sein. Zusätzlich können der/die PVA(s) einen zusätzlichen Fehlerkorrekturcode (ECC)-Speicher beinhalten, um die Gesamtsystemsicherheit zu erhöhen.
Der/die Beschleuniger 1414 (z. B. der Hardware-Beschleunigungscluster) können ein Netzwerk auf dem Chip für maschinelles Sehen und einen SRAM beinhalten, um einen SRAM mit hoher Bandbreite und niedriger Latenz für den/die Beschleuniger 1414 bereitzustellen. In einigen Beispielen kann der chipinterne Speicher mindestens 4 MB SRAM beinhalten, der z. B. und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine weiterentwickelte Peripheriebus (advanced peripheral bus - APB)-Schnittstelle, eine Konfigurationsschaltung, eine Steuerung und einen Multiplexer beinhalten. Es kann jede Art von Speicher verwendet werden. Der PVA und DLA können auf den Speicher über einen Backbone zugreifen, der dem PVA und DLA einen Hochgeschwindigkeitszugriff auf den Speicher bereitstellt. Der Backbone kann ein Netzwerk auf dem Chip für maschinelles Sehen beinhalten, das den PVA und DLA mit dem Speicher verbindet (z. B. unter Verwendung von dem APB).
Das Netzwerk kann auf dem Chip für maschinelles Sehen eine Schnittstelle beinhalten, die vor der Übertragung eines beliebigen Steuersignals/einer beliebigen Adresse/ beliebiger Daten bestimmt, dass sowohl der PVA als auch der DLA einsatzbereite und gültige Signale bereitstellen. Eine derartige Schnittstelle kann separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-artige Kommunikation für eine kontinuierliche Datenübertragung bereitstellen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, obwohl auch andere Normen und Protokolle verwendet werden können.
In einigen Beispielen können die SoC(s) 1404 einen Echtzeit-Raytracing-Hardware-Beschleuniger enthalten, wie er in der US-Patentanmeldung Nr. 16/101,232 , eingereicht am 10. August 2018, beschrieben ist. Der Echtzeitstrahlverfolgungs-Hardware-Beschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeitvisualisierungssimulationen 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 Zwecke der Lokalisierung und/oder für andere Funktionen und/oder für andere Anwendungen. In einigen Ausführungsformen können eine oder mehrere Tree Traversal Units (TTUs) für die Ausführung einer oder mehrerer Raytracingbezogener Operationen verwendet werden.
Der/die Beschleuniger 1414 (z. B. der Hardware-Beschleunigercluster) weisen ein breites Spektrum von Verwendungen für das autonome Fahren auf. Der PVA kann ein programmierbarer Sichtbeschleuniger sein, der für wichtige Verarbeitungsstufen im ADAS und in autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten des PVA sind eine gute Ergänzung für algorithmische Domänen, die eine vorhersagbare Verarbeitung bei niedriger Leistung und niedriger Latenz benötigen. Anders ausgedrückt zeigt der PVA eine gute Performance für halbdichte oder dichte reguläre Berechnungen, auch an kleinen Datensätzen, die vorhersagbare Laufzeiten mit niedriger Latenz und niedriger Leistung benötigen. Folglich sind die PVAs im Zusammenhang mit Plattformen für autonome Fahrzeuge für die Ausführung klassischer Algorithmen für maschinelles Sehen konstruiert, da diese effizient bei der Objekterkennung sind und mit Integer-Mathematik arbeiten.
Zum Beispiel wird gemäß einer Ausführungsform der Technologie der PVA verwendet, um maschinelles Stereo-Sehen durchzuführen. Ein auf semiglobalem Abgleich basierender Algorithmus kann verwendet werden, obwohl dies nicht als Einschränkung auszulegen ist. Viele Anwendungen für das autonome Fahren auf Level 3-5 erfordern Bewegungsschätzung/ Stereo-Abgleich spontan (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Der PVA kann eine Funktion des maschinellen Stereo-Sehens an Eingaben von zwei monokularen Kameras durchführen.
In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Gemäß der Verarbeitung von RADAR-Rohdaten (z. B. mit einer 4D-Fast-Fourier-Transformation) zur Bereitstellung von verarbeitetem RADAR. In anderen Beispielen wird der PVA für die Laufzeit-Tiefenverarbeitung verwendet, indem z. B. Laufzeit-Rohdaten verarbeitet werden, um verarbeitete Laufzeitdaten bereitzustellen.
Der DLA kann verwendet werden, um eine beliebige Art von Netzwerk auszuführen, um die Steuerung und Fahrsicherheit zu verbessern, einschließlich zum Beispiel ein neuronales Netzwerk, das ein Maß an Konfidenz für jede Objekterkennung ausgibt. Ein derartigre Konfidenzwert kann als eine Wahrscheinlichkeit interpretiert werden oder als Bereitstellung einer relativen „Gewichtung“ jeder Erkennung im Vergleich zu anderen Erkennungen. Der Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als richtig positive Erkennungen und nicht als falsch positive Erkennungen betrachtet werden sollten. Zum Beispiel kann das System einen Schwellenwert für die Konfidenz festlegen und nur Erkennungen, die den Schwellenwert überschreiten, als richtig positive Erkennungen betrachten. In einem automatischen Notbrems (automatic emergency braking - AEB)-System 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 Entdeckungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netzwerk zur Regression des Konfidenzwerts ausführen. Das neuronale Netzwerk kann als seine Eingabe mindestens eine Teilmenge von Parametern verwenden, wie z. B. die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Teilsystem) erhaltene Bodenebenenschätzung, die Ausgabe von Inertial Measurement Unit (IMU)-Sensor 1466, die mit der Ausrichtung des Fahrzeugs 1400 korreliert, den Abstand, die 3D-Positionsschätzungen des Objekts, die vom neuronalen Netzwerk und/oder anderen Sensoren (z. B. LiDAR-Sensor(en) 1464 oder RADAR-Sensor(en) 1460) erhalten werden, usw.
Der/die SoC(s) 1404 kann/können Datenspeicher 1416 (z. B. Speicher) enthalten. Bei den Datenspeicher(n) 1416 kann es sich um den chipinternen Speicher der SoC(s) 1404 handeln, der neuronale Netze speichern kann, die auf den GPU(s) und/oder dem DLA ausgeführt werden sollen. In einigen Beispiel kann die Kapazität des/der Datenspeicher(s) 1416 groß genug sein, um mehrere Instanzen von neuronalen Netzwerken zur Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 1412 können L2 oder L3 Cache(s) 1412 umfassen. Der Verweis auf den/die Datenspeicher 1416 kann einen Verweis auf den Speicher beinhalten, der dem PVA, DLA und/oder anderen Beschleunigern 1414 zugeordnet ist, wie hier beschrieben.
Der/die SoC(s) 1404 kann/können einen oder mehrere Prozessor(en) 1410 (z. B. eingebettete Prozessoren) enthalten. Der/die Prozessor(en) 1410 können einen Booting- und Leistungsverwaltungsprozessor beinhalten, der ein dedizierter Prozessor und ein Teilsystem sein kann, um die Booting-Leistungs- und - verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Booting- und Leistungsverwaltungsprozessor kann ein Teil der Booting-Sequenz des/der SoC(s) 1404 sein und Laufzeit-Leistungsverwaltungsdienste bereitstellen. Der Booting-Leistungs- und - verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Übergängen des Systems in einen Status mit niedriger Leistung, Verwaltung von Thermik und Temperatursensoren des/der SoC(s) 1404 und/oder Verwaltung von Leistungsstatus des/der SoC(s) 1404 bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und können das/die SoC(s) 1404 Ringoszillatoren verwenden, um Temperaturen von den CPU(s) 1406, GPU(s) 1408 und/oder Beschleuniger(n) 1414 zu erkennen. Wenn bestimmt wird, dass Temperaturen einen Schwellenwert überschreiten, kann der Booting- und Leistungsverwaltungsprozessor dann in eine Temperaturfehlerroutine eintreten und den/die SoC(s) 1404 in einen Status mit niedrigerer Leistung versetzen und/oder das Fahrzeug 1400 in einen Modus des Chauffierens zu einem sicheren Halt versetzen (z. B. das Fahrzeug 1400 zu einem sicheren Halt bringen).
Der/die Prozessor(en) 1410 können ferner einen Satz von eingebetteten Prozessoren beinhalten, die als eine Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audioteilsystem sein, 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) 1410 können ferner eine stets eingeschaltete Prozessor-Engine beinhalten, welche die notwendigen Hardware-Merkmale zur Unterstützung der Sensorverwaltung mit niedriger Leistung und der Aufwach-Anwendungsfälle bereitstellen kann. Die stets eingeschaltete Prozessor-Engine kann einen Prozessorkern, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Timer und Unterbrechungssteuerungen), verschiedene I/O-Steuerungsperipheriegeräte und Routing-Logik beinhalten.
Die Prozessor(en) 1410 können ferner eine Sicherheitscluster-Engine beinhalten, die ein dediziertes Prozessorteilsystem zum Handhaben der Sicherheitsverwaltung für Automobilanwendungen beinhaltet. Die Sicherheitscluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Timer, eine Unterbrechungssteuerung usw.) und/oder Routing-Logik beinhalten. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Gleichschrittmodus arbeiten und als ein einzelner Kern mit einer Vergleichslogik funktionieren, um beliebige Unterschiede zwischen ihren Vorgängen zu erkennen.
Der/die Prozessor(en) 1410 können ferner eine Echtzeitkamera-Engine beinhalten, die ein dediziertes Prozessorteilsystem zur Handhabung der Echtzeitkameraverwaltung beinhalten kann.
Der/die Prozessor(en) 1410 können ferner einen Signalprozessor mit hohem Dynamikbereich beinhalten, der einen Bildsignalprozessor beinhalten kann, der eine Hardware-Engine ist, die Teil einer Kameraverarbeitungspipeline ist.
Die Prozessor(en) 1410 können einen Videobildkompositor beinhalten, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachverarbeitungsfunktionen implementiert, die durch eine Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Fenster des Wiedergabeprogramms zu erzeugen. Der Videobildkompositor kann eine Linsenverzerrungskorrektur an der/den Weitsichtkamera(s) 1470, der/den Rundumkamera(s) 1474 und/oder an den kabineninternen Überwachungskamerasensoren durchführen. Der kabineninterne Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netzwerk überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein kabineninternes System kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, ein Ziel des Fahrzeugs zu ändern, ein Infotainmentsystem des Fahrzeugs und dessen Einstellungen zu aktivieren oder zu ändern oder sprachaktiviertes Surfen im Internet bereitzustellen. Dem Fahrer stehen bestimmte Funktionen nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
Der Videobildkompositor kann eine erweiterte zeitliche Rauschunterdrückung sowohl für die räumliche als auch für die zeitliche Rauschunterdrückung beinhalten. Wenn, zum Beispiel Bewegung in einem Video vorkommt, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend, indem sie die Gewichtung der Informationen, die von benachbarten Frames bereitgestellt werden, verringert. Wenn ein Bild oder ein Abschnitt eines Bildes keine Bewegung beinhaltet, kann die durch den Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus einem vorherigen Bild verwenden, um das Rauschen in einem derzeitigen Bild zu unterdrücken.
Der Videobildkompositor kann auch so konfiguriert sein, dass er eine Stereoentzerrung an den eingegebenen Stereolinsen-Frames durchführt. Der Videobildkompositor kann ferner für die Benutzerschnittstellenzusammensetzung verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 1408 nicht zum kontinuierlichen Rendern neuer Oberflächen benötigt werden. Sogar wenn die GPU(s) 1408 eingeschaltet sind und aktiv 3D-Rendering durchführen,kann der Videobildkompositor verwendet werden, um die GPU(s) 1408 zu entlasten, um die Performance und Reaktionsfähigkeit zu verbessern.
Das/die SoC(s) 1404 können ferner eine serielle Mobile-Industry-Processor-Interface (MIPI)-Kameraschnittstelle zum Empfangen von Videos und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock beinhalten, der für Kamera- und zugehörige Pixeleingabefunktionen verwendet werden kann. Das/die SoC(s) 1404 können ferner (eine) Eingabe/Ausgabe-Steuerung(en) beinhalten, die durch Software gesteuert werden können und für den Empfang von I/O-Signalen verwendet werden können, die keiner bestimmten Rolle zugewiesen sind.
Das/die SoC(s) 1404 können ferner eine breite Palette von Peripherieschnittstellen beinhalten, um die Kommunikation mit Peripheriegeräten, Audio-Codecs, Leistungsverwaltungs- und/oder anderen Vorrichtungen zu ermöglichen. Das/die SoC(s) 1404 kann/können verwendet werden, um Daten von Kameras (z. B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LiDAR-Sensor(en) 1464, RADAR-Sensor(en) 1460 usw., die über Ethernet verbunden sein können), Daten vom Bus 1402 (z. B. Geschwindigkeit des Fahrzeugs 1400, Lenkradposition usw.), Daten von GNSS-Sensor(en) 1458 (z. B. verbunden über Ethernet oder CAN-Bus) zu verarbeiten. Das/die SoC(s) 1404 kann/können außerdem dedizierte Hochleistungs-Massenspeicher-Controller enthalten, die ihre eigenen DMA-Engines enthalten können und die verwendet werden können, um die CPU(s) 1406 von Routineaufgaben der Datenverwaltung zu befreien.
Das/die SoC(s) 1404 können eine Ende-zu-Ende-Plattform mit einer flexiblen Architektur sein, welche die Automatisierungslevels 3-5 überspannt und dadurch eine umfassende funktionelle Sicherheitsarchitektur bereitstellt, die Techniken des maschinellen Sehens und des ADAS für Diversität und Redundanz nutzt und effizient einsetzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftwarestapel zusammen mit Deep-Learning-Werkzeugen bereitstellt. Das/die SoC(s) 1404 können schneller, zuverlässiger und sogar energieeffizienter und raumeffizienter sein als herkömmliche Systeme. Zum Beispiel können der/die Beschleuniger 1414, wenn sie mit der/den CPU(s) 1406, der/den GPU(s) 1408 und dem/den Datenspeicher(n) 1416 kombiniert sind, eine schnelle, effiziente Plattform für autonome Fahrzeuge der Levels 3-5 bereitstellen.
Die Technologie stellt somit Fähigkeiten und Funktionen bereit, die mit herkömmlichen Systemen nicht erreicht werden können. Zum Beispiel können Algorithmen des maschinellen Sehens auf CPUs ausgeführt werden, die unter Verwendung einer Programmiersprache auf hohem Level, wie z. B. der Programmiersprache C, konfiguriert werden können, um eine große Vielfalt von Verarbeitungsalgorithmen über eine große Vielfalt von visuellen Daten auszuführen. Die CPUs sind jedoch oft nicht in der Lage, die Performance-Anforderungen vieler Anwendungen des maschinellen Sehens zu erfüllen, wie z. B. in Bezug auf die Ausführungszeit und den Leistungsverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, die in fahrzeuginternen ADAS-Anwendungen und in praktischen autonomen Fahrzeugen der Levels 3-5 erforderlich sind.
Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungclusters die gleichzeitige und/oder sequentielle Ausführung mehrerer neuronaler Netze und die Kombination der Ergebnisse, um autonome Fahrfunktionen der Level 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder dGPU (z. B. GPU(s) 1420) ausgeführt wird, eine Text- und Worterkennung beinhalten, die es dem Supercomputer ermöglicht, Verkehrsschilder zu lesen und zu verstehen, einschließlich Schildern, für die das neuronale Netzwerk nicht speziell trainiert wurde. Der DLA kann ferner ein neuronales Netzwerk enthalten, das in der Lage ist, Zeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis davon bereitzustellen und dieses semantische Verständnis an den Pfadplanungsmodule weiterzugeben, die auf dem CPU-Komplex laufen.
Als weiteres Beispiel können mehrere neuronale Netze simultan ausgeführt werden, wie für das Fahren bei Level 3, 4 oder 5 erforderlich ist. Zum Beispiel kann ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Vereisung hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzwerken unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netzwerk (z. B. einem trainierten neuronalen Netzwerk) als Verkehrsschild identifiziert werden und kann der Text „Blinkende Lichter weisen auf Verweisung hin“ von einem zweiten eingesetzten neuronalen Netzwerk 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, Vereisungen vorliegen. Das blinkende Licht kann identifiziert werden, indem ein drittes eingesetztes neuronales Netz über mehrere Einzelbilder hinweg betrieben wird, das eine Pfadplanungssoftware des Fahrzeugs über das Vorhandensein (oder Nichtvorhandensein) von blinkenden Lichtern informiert. Alle drei neuronalen Netze können simultan laufen, wie etwa innerhalb des DLA und/oder auf den GPU(s) 1408.
In einigen Beispielen kann ein CNN zur Gesichtserkennung und Fahrzeugbesitzeridentifizierung Daten von Kamerasensoren verwenden, um das Vorhandensein eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 1400 zu identifizieren. Die stets eingeschaltete Sensorverarbeitungs-Engine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn sich der Besitzer der Fahrertür nähert und Lichter einschaltet, und um in dem Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise stellen das/die SoC(s) 1404 Sicherheit gegen Diebstahl und/oder Carjacking bereit.
In einem weiteren Beispiel kann ein CNN zur Detektion und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 1496 verwenden, um Sirenen von Einsatzfahrzeugen zu detektieren 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) 1404 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung von visuellen Daten. In einer bevorzugten Ausführungsform wird das CNN, das auf dem DLA läuft, dafür trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu identifizieren (z. B. durch Verwenden des Dopplereffekts). Das CNN kann auch dafür trainiert werden, Einsatzfahrzeuge zu identifizieren, die für das lokale Gebiet, in dem das Fahrzeug betrieben wird, spezifisch sind, wie durch den/die GNSS-Sensor(en) 1458. Folglich versucht das CNN zum Beispiel, wenn es in Europa betrieben wird, europäische Sirenen zu erkennen, und in den Vereinigten Staaten versucht das CNN, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Einsatzfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge auszuführen, um das Fahrzeug zu verlangsamen, an den Straßenrand zu fahren, das Fahrzeug zu parken und/oder das Fahrzeug im Leerlauf laufen zu lassen, und zwar mit der Hilfe der Ultraschallsensoren 1462, bis das/die Einsatzfahrzeug/e vorbeigefahren ist/sind.
Das Fahrzeug kann (eine) CPU(s) 1418 (z. B. diskrete CPU(s) oder dCPU(s)) beinhalten, die über eine Hochgeschwindigkeitszusammenschaltung (z. B. PCle) an die SoC(s) 1404 gekoppelt sein können. Die CPU(s) 1418 können zum Beispiel einen X86-Prozessor beinhalten. Die CPU(s) 1418 können dazu verwendet werden, eine beliebige einer Vielfalt von Funktionen durchzuführen, z. B. die Vermittlung potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und SoC(s) 1404 und/oder die Überwachung des Status und Zustands der Steuerung(en) 1436 und/oder Infotainment-SoC 1430.
Das Fahrzeug 1400 kann GPU(s) 1420 (z. B. diskrete GPU(s) oder dGPU(s)) beinhalten, die über eine Hochgeschwindigkeitszusammenschaltung (z. B. NVLINK von NVIDIA) mit dem/den SoC(s) 1404 gekoppelt sein können. Die GPU(s) 1420 können eine zusätzliche Funktionalität für künstliche Intelligenz bereitstellen, z. B. durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netzwerke, und können zum Trainieren und/oder Aktualisieren neuronaler Netzwerke verwendet werden, die auf Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 1400 basieren.
Das Fahrzeug 1400 kann ferner die Netzschnittstelle 1424 beinhalten, die eine oder mehrere drahtlose Antennen 1426 beinhalten kann (z. B. eine oder mehrere drahtlose Antennen für unterschiedliche Kommunikationsprotokolle, wie etwa eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzwerkschnittstelle 1424 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit (einem) Server(n) 1478 und/oder anderen Netzwerkvorrichtungen), mit anderen Fahrzeugen und/oder mit Rechenvorrichtungen (z. B. Client-Vorrichtungen von Fahrgästen) zu ermöglichen. Zum Kommunizieren mit anderen Fahrzeugen kann eine direkte Verknüpfung zwischen den zwei Fahrzeugen hergestellt werden und/oder eine indirekte Verknüpfung (z. B. über Netze und über das Internet) hergestellt werden. Direkte Verknüpfungen können unter Verwendung einer Fahrzeug-zu-Fahrzeug-Kommunikationsverknüpfung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverknüpfung kann dem Fahrzeug 1400 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 1400 bereitstellen (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 1400). Die vorgenannte Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitssteuerungsfunktionalität des Fahrzeugs 1400 sein.
Die Netzschnittstelle 1424 kann ein SoC beinhalten, das eine Modulations- und Demodulationsfunktionalität bereitstellt und es den Steuerung(en) 1436 ermöglicht, über drahtlose Netze zu kommunizieren. Die Netzwerkschnittstelle 1424 kann ein Hochfrequenz-Frontend für die Aufwärtskonvertierung vom Basisband auf die Hochfrequenz und die Abwärtskonvertierung von der Hochfrequenz auf das Basisband beinhalten. Die Frequenzkonvertierungen können durch hinreichend bekannte Prozesse und/oder unter Verwendung von Überlagerungsverfahren durchgeführt werden. In einigen Beispielen kann die Hochfrequenz-Frontend-Funktionalität durch einen separaten Chip bereitgestellt sein. Die Netzwerkschnittstelle kann eine drahtlose Funktionalität zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle beinhalten.
Das Fahrzeug 1400 kann ferner Datenspeicher 1428 beinhalten, die außerhalb des Chips (z. B. außerhalb der SoC(s) 1404) gespeichert sein können. Der/die Datenspeicher 1428 können ein oder mehrere Speicherelemente umfassen, darunter RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Vorrichtungen, die mindestens ein Datenbit speichern können.
Das Fahrzeug 1400 kann ferner GNSS-Sensor(en) 1458 beinhalten. Der/die GNSS-Sensor(en) 1458 (z. B. GPS, unterstützte GPS-Sensoren, Differential-GPS (DGPS)-Sensoren usw.), um bei der Kartierung, der Wahrnehmung, der Erstellung von Belegungsrastern und/oder der Pfadplanung zu helfen. Eine beliebige Anzahl von GNSS-Sensor(en) 1458 kann verwendet werden, zum Beispiel und ohne Einschränkung ein GPS unter Verwendung eines USB-Steckers mit einer Ethernet-zu-Seriell (RS-232)-Brücke.
Das Fahrzeug 1400 kann ferner RADAR-Sensor(en) 1460 beinhalten. Der/die RADAR-Sensor(en) 1460 können von dem Fahrzeug 1400 zur Fahrzeugerkennung mit großer Reichweite verwendet werden, auch bei Dunkelheit und/oder schlechten Wetterbedingungen. Die RADAR-Funktionssicherheitslevel ASIL B sein. Der/die RADAR-Sensor(en) 1460 können das CAN und/oder den Bus 1402 (z. B. zur Übertragung der von dem/den RADAR-Sensor(en) 1460 erzeugten Daten) zur Steuerung von und zum Zugriff auf Objektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugriff auf Rohdaten über Ethernet erfolgt. Eine große Vielfalt von RADAR-Sensorarten kann verwendet werden. Zum Beispiel und ohne Einschränkung können der/die RADAR-Sensor(en) 1460 für die Verwendung als Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensoren verwendet.
Der/die RADAR-Sensor(en) 1460 können unterschiedliche Konfigurationen beinhalten, z. B. mit großer Reichweite und schmalem Sichtfeld, mit geringer Reichweite und breitem Sichtfeld, mit seitlicher Abdeckung mit kurzer Reichweite usw. In einigen Beispielen kann das RADAR mit großer Reichweite für die adaptive Geschwindigkeitssteuerungsfunktionalität verwendet werden. Die RADAR-Systeme können mit großer Reichweite ein breites Sichtfeld bereitstellen, das durch zwei oder mehr unabhängige Scans realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 1460 können dabei helfen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und können von ADAS-Systemen für den Notbremsassistenten und die Vorwärtskollisionswarnung verwendet werden. RADAR-Sensoren mit großer Reichweite können ein monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle beinhalten. In einem Beispiel mit sechs Antennen können die vier zentrale Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu ausgestaltet ist, die Umgebung des Fahrzeugs 1400 bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den benachbarten Fahrspuren aufzuzeichnen. Die beiden anderen Antennen können das Sichtfeld erweitern, wodurch es möglich ist, Fahrzeuge, die in die Fahrspur des Fahrzeugs 1400 einfahren oder diese verlassen, schnell zu erkennen.
Die RADAR-Systeme mit mittlerer Reichweite können beispielsweise eine Reichweite von bis zu 1460 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 1450 Grad (hinten) beinhalten. RADAR-Systeme mit kurzer Reichweite können ohne Einschränkung RADAR-Sensoren beinhalten, die für die Installation an beiden Enden des hinteren Stoßfängers ausgestaltet sind. Wenn das RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers installiert ist, kann ein derartiges RADAR-Sensorsystem zwei Strahlen erzeugen, die den toten Winkel hinter und neben dem Fahrzeug konstant überwachen.
RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder zur Unterstützung beim Fahrspurwechsel verwendet werden.
Das Fahrzeug 1400 kann ferner Ultraschallsensor(en) 1462 beinhalten. Der/die Ultraschallsensor(en) 1462, die vorne, hinten und/oder an den Seiten des Fahrzeugs 1400 positioniert sein können, können als Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsgitters verwendet werden. Eine große Vielfalt von Ultraschallsensor(en) 1462 kann verwendet werden und können unterschiedliche Ultraschallsensor(en) 1462 können für unterschiedliche Erkennungsreichweiten (z. B. 2,5 m, 4 m) verwendet werden. Der/die Ultraschallsensor(en) 1462 können bei funktionellen Sicherheitslevels von ASIL B arbeiten.
Das Fahrzeug 1400 kann LiDAR-Sensor(en) 1464 beinhalten. Der/die LiDAR-Sensor(en) 1464 können zur Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LiDAR-Sensor(en) 1464 können dem funktionellen Sicherheitslevel ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 1400 mehrere LiDAR-Sensoren 1464 (z. B. zwei, vier, sechs usw.) beinhalten, die Ethernet verwenden können (um z. B. Daten für einen Gigabit-Ethernet-Switch bereitzustellen).
In einigen Beispielen können die LiDAR-Sensor(en) 1464 dazu in der Lage sein, eine Liste von Objekten und deren Abstände für ein 360-Grad-Sichtfeld bereitzustellen. Handelsübliche LiDAR-Sensor(en) 1464 können zum Beispiel eine beworbene Reichweite von ungefähr 1400 m aufweisen, mit einer Genauigkeit von 2 cm-3 cm und mit Unterstützung für eine 1400 Mbps-Ethernet-Verbindung. In einigen Beispielen können ein oder mehrere nicht vorstehende LiDAR-Sensoren 1464 verwendet werden. In einem solchen Beispiel können der/die LiDAR-Sensor(en) 1464 als eine kleine Vorrichtung implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 1400 eingebettet werden kann. Der/die LiDAR-Sensor(en) 1464 können in solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von bis zu 35 Grad mit einer Reichweite von 200 m selbst bei Objekten mit niedrigem Reflexionsvermögen bereitstellen. Der/die an der Front montierte(n) LiDAR-Sensor(en) 1464 können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert sein.
In einigen Beispielen können auch LiDAR-Technologien, wie z. B. 3D-Blitz-LiDAR, verwendet werden. 3D-Blitz-LiDAR verwendet einen Laserblitz als Sendequelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von ca. 200 m zu beleuchten. Eine Blitz-LiDAR-Einheit beinhaltet einen Rezeptor, der die Laserpuls-Laufzeit und das reflektierte Licht an jedem Pixel aufzeichnet, was wiederum der Reichweite vom Fahrzeug zu den Objekten entspricht. Blitz-LiDAR kann ermöglichen, dass mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung erzeugt werden. In einigen Beispielen können vier Blitz-LiDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 1400. Verfügbare 3D-Blitz-LiDAR-Systeme beinhalten eine Festkörper-3D-Staring-Array-LiDAR-Kamera ohne bewegliche Teile außer einem Lüfter (z. B. eine nicht scannende LiDAR-Vorrichtung). Die Blitz-LiDAR-Vorrichtung kann einen 5-Nanosekunden-Laserpuls der Klasse I (augensicher) pro Bild verwenden und kann das reflektierte Laserlicht in Form von den 3D-Reichweitenpunktwolken und gemeinsam registrierten Intensitätsdaten erfassen. Durch die Verwendung von Blitz-LiDAR und weil Blitz-LiDAR eine Festkörpervorrichtung ohne bewegliche Teile ist, ist der/die LiDAR-Sensor(en) 1464 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße.
Das Fahrzeug kann ferner IMU-Sensor(en) 1466 beinhalten. Der/die IMU-Sensor(en) 1466 kann/können sich in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 1400 befinden. Der/die IMU-Sensor(en) 1466 können zum Beispiel und ohne Einschränkung (einen) Beschleunigungsmesser, (ein) Magnetometer, (ein) Gyroskop(e), (einen) Magnetkompass(e) und/oder andere Sensorarten beinhalten. In einigen Beispielen, wie z. B. in sechsachsigen Anwendungen, kann der/die IMU-Sensor(en) 1466 Beschleunigungsmesser und Gyroskope beinhalten, während in neunachsigen Anwendungen der/die IMU-Sensor(en) 1466 Beschleunigungsmesser, Gyroskope und Magnetometer beinhalten kann/können.
In einigen Ausführungsformen können die IMU-Sensor(en) 1466 als miniaturisiertes GPS-gestütztes Trägheitsnavigationssystem (GPS-Aided Inertial Navigation System - GPS/INS) mit hoher Rechenleistung implementiert sein, das Trägheitssensoren von mikroelektromechanischen Systemen (micro-electromechanical systems - MEMS), einen hochempfindlichen GPS-Empfänger und weiterentwickelte Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage bereitzustellen. So können der/die IMU-Sensor(en) 1466 in einigen Beispiel es dem Fahrzeug 1400 ermöglichen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem vom GPS an den/die IMU-Sensor(en) 1466 Änderungen der Geschwindigkeit direkt beobachtet und korreliert werden. In einigen Beispielen können der/die IMU-Sensor(en) 1466 und GNSS-Sensor(en) 1458 in einer einzelnen integrierten Einheit kombiniert sein.
Das Fahrzeug kann Mikrofon(e) 1496 beinhalten, das/die in und/oder um das Fahrzeug 1400 herum angebracht sind. Das/die Mikrofon(e) 1496 können unter anderem zur Erkennung und Identifizierung von Einsatzfahrzeugen verwendet werden.
Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen beinhalten, darunter Stereokamera(s) 1468, Weitsichtkamera(s) 1470, Infrarotkamera(s) 1472, Rundumkamera(s) 1474, Langstrecken- und/oder Mittelstreckenkamera(s) 1498 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten um die gesamte Peripherie des Fahrzeugs 1400 herum zu erfassen. Die Art der verwendeten Kameras hängt von den Ausführungsformen und Anforderungen für das Fahrzeug 1400 ab, und es kann eine beliebige Kombination von Kameraarten verwendet werden, um die notwendige Abdeckung rund um das Fahrzeug 1400 zu gewährleisten. Zusätzlich kann die Anzahl der Kameras in Abhängigkeit von der Ausführungsform unterschiedlich sein. Zum Beispiel kann das Fahrzeug sechs Kameras,
sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras beinhalten. Die Kameras können zum Beispiel und ohne Einschränkung Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras wird hier in Bezug auf 14A und 14B.
Das Fahrzeug 1400 kann ferner Vibrationssensor(en) 1442 beinhalten. Der/die Vibrationssensor(en) 1442 können Vibrationen von Komponenten des Fahrzeugs, wie z. B. der der Achse(n), messen. Zum Beispiel können Änderungen der Vibrationen eine Änderung des Straßenbelags angeben. In einem weiteren Beispiel, wenn zwei oder mehr Vibrationssensoren 1442 verwendet werden, können die Unterschiede zwischen den Vibrationen verwendet werden, um die Reibung oder den Schlupf des Straßenbelags zu bestimmen (z. B., wenn der Unterschied der Vibration zwischen einer leistungsbetriebenen Achse und einer sich frei drehenden Achse besteht).
Das Fahrzeug 1400 kann ein ADAS-System 1438 beinhalten. Das ADAS-System 1438 kann in einigen Beispielen ein SoC beinhalten. Das ADAS-System 1438 kann autonome/adaptive/automatische Geschwindigkeitssteuerung (autonomous/adaptive/automatic cruise control - ACC), kooperative adaptive Geschwindigkeitssteuerung (cooperative adaptive cruise control - CACC), Vorwärtszusammenstoßwarnungen (forward crash warning - FCW), automatisches Notbremsen (AEB), Spurverlassenswarnungen (lane departure warning - LDW), Spurhalteassistenz (lane keep assist - LKA), Totwinkelwarnung (blind spot warning - BSW), Querverkehrswarnung (rear cross-traffic warning - RCTW), Kollisionswarn (collision warning - CWS)-Systeme, Spurzentrierung (lane centering - LC) und/oder andere Systeme, Merkmale und/oder Funktionen beinhalten.
Die ACC-Systeme können RADAR-Sensor(en) 1460, LiDAR-Sensor(en) 1464 und/oder eine Kamera(en) verwenden. Die ACC-Systeme können ACC in Längsrichtung und/oder ACC in Querrichtung beinhalten. Die Längs-ACC steuert den Abstand zum Fahrzeug, das sich unmittelbar vor dem Fahrzeug 1400 befindet, und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Die Quer-ACC führt eine Abstandshaltung durch und rät dem Fahrzeug 1400, die Fahrspuren zu wechseln, wenn dies erforderlich ist. Die Quer-ACC ist mit anderen ADAS-Anwendungen, wie zum Beispiel LCA und CWS, verbunden.
Eine CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzschnittstelle 1424 und/oder die drahtlose(n) Antenne(n) 1426 von anderen Fahrzeugen über eine drahtlose Verknüpfung oder indirekt über eine Netzverbindung (z. B. über das Internet) empfangen werden können. Direkte Verknüpfungen können durch eine Fahrzeug-zu-Fahrzeug (F-F)-Kommunikationsverknüpfung bereitgestellt werden, während indirekte Verknüpfungen durch eine Infrastruktur-zu-Fahrzeug (I-F)-Kommunikationsverknüpfung bereitgestellt werden können. Im Allgemeinen stellt das F-F-Kommunikationskonzept Informationen über unmittelbar vorausfahrende Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem und auf derselben Spur wie das Fahrzeug 1400 befinden) bereit, während das I-F-Kommunikationskonzept Informationen über den weiter entfernt vorausfahrenden Verkehr bereitstellt. CACC-Systeme können entweder eine oder beide der I-F- und F-F-Informationsquellen beinhalten. Angesichts der Informationen über die Fahrzeuge vor dem dem Fahrzeug 1400 kann die CACC zuverlässiger sein und hat das Potenzial, den Gleichmäßigkeit des Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
FCW-Systeme sind so ausgestaltet, dass es einen Fahrer vor einer Gefahr warnt, sodass der Fahrer eine korrigierende Maßnahme ergreifen kann. FCW-Systeme verwenden eine nach vorn gerichtete Kamera und/oder RADAR-Sensor(en) 1460, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente. Die FCW-Systeme können eine Warnung bereitstellen, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
AEB-System erkennen eine drohende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und kann automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines spezifizierten Zeit- oder Abstandsparameters eine korrigierende Handlung durchführt. AEB-Systeme können nach vorn gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1460 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn ein AEB-System eine Gefahr detektiert, warnt es typischerweise zuerst den Fahrer, um eine korrigierende Maßnahme zu ergreifen, um eine Kollision zu vermeiden, und falls der Fahrer keine korrigierende Maßnahme ergreift, kann das AEB-System automatisch die Bremsen in dem Bestreben betätigen, den Aufprall der vorhergesagten Kollision zu verhindern oder mindestens abzuschwächen. AEB-Systeme können Techniken, wie zum Beispiel dynamische Bremsunterstützung und/oder Bremsung aufgrund eines bevorstehenden Zusammenstoßes, beinhalten.
LDW-Systeme stellen optische, akustische und/oder taktile Warnungen bereit, wie z. B. Lenkrad- oder Sitzvibrationen, um den Fahrer zu warnen, wenn das Fahrzeug 1400 die Fahrspurmarkierungen überquert. Ein LDW-System wird nicht aktiviert, wenn der Fahrer ein absichtliches Verlassen der Fahrspur anzeigt, indem er den Blinker betätigt. LDW-Systeme können können nach vorne gerichtete Kameras verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
LKA-Systeme sind eine Variante der LDW-Systeme. LKA-Systeme stellen eine Lenkeingabe oder eine Bremsung bereit, um das Fahrzeug 1400 zu korrigieren, wenn das Fahrzeug 1400 beginnt, die Fahrspur zu verlassen.
BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen in einem toten Winkel eines Automobils. BSW-Systeme können einen optischen, akustischen und/oder taktilen Alarm bereitstellen, um anzugeben, dass Einfädeln in oder Wechseln der Fahrspuren unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker betätigt. BSW-Systeme können nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1460 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
RCTW-Systeme können eine optische, akustische und/oder taktile Benachrichtigung bereitstellen, wenn ein Objekt außerhalb der Reichweite der Heckkamera erkannt wird, wenn das Fahrzeug 1400 rückwärts fährt. Einige RCTW-Systeme beinhalten AEB, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Zusammenstoß zu vermeiden. Die RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensor(en) 1460 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
Herkömmliche ADAS-Systeme können anfällig für falsch positive Ergebnisse sein, die für den Fahrer ärgerlich und ablenkend sein können, aber typischerweise nicht katastrophal sind, da die ADAS-Systeme den Fahrer warnen und es dem Fahrer ermöglichen, zu entscheiden, ob wirklich eine Sicherheitsbedingung vorliegt, und entsprechend zu handeln. In einem autonomen Fahrzeug 1400 muss das Fahrzeug 1400 jedoch im Falle von widersprüchlichen Ergebnissen selbst entscheiden, ob das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. einer ersten Steuerung 1436 oder einer zweiten Steuerung 1436) zu beachten ist. In einigen Ausführungsformen kann das ADAS-System 1438 beispielsweise ein Backup- und/oder sekundärer Computer sein, der Wahrnehmungsinformationen für ein Rationalitätsmodul eines Backup-Computers bereitstellt. Der Rationalitätsmonitor des Backup-Computers kann eine redundante, diverse Software auf HardwareKomponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahr-Tasks zu erkennen. Die Ausgaben des ADAS-Systems 1438 können für eine Überwachungs-MCU bereitgestellt werden. Wenn die Ausgaben des primären und des sekundären Computers miteinander in Konflikt geraten, muss die übergeordnete MCU festlegen, wie der Konflikt gelöst werden kann, um einen sicheren Betrieb zu gewährleisten.
In einigen Beispielen kann der primäre Computer so konfiguriert sein, dass er der Überwachungs-MCU eine Konfidenzbewertung bereitstellt, die eine Konfidenz des primären Computers für das gewählte Ergebnis angibt. Falls die Konfidenzbewertung einen Schwellenwert überschreitet, kann diese Überwachungs-MCU der Führung des primären Computers folgen, unabhängig davon, ob dieser sekundäre Computer ein widersprüchliches oder inkonsistentes Ergebnis bereitstellt. Wenn die eine Konfidenzbewertung den Schwellenwert nicht erreicht und der primäre und der sekundäre Computer unterschiedliche Ergebnisse angeben (z. B. den Widerspruch), kann die Überwachungs-MCU zwischen den Computern vermitteln, um das zweckmäßige Resultat zu bestimmen.
Die Überwachungs-MCU kann so konfiguriert sein, dass sie neuronale(s) Netz(e) ausführt, die dafür trainiert und konfiguriert sind, mindestens auf Grundlage von Ausgaben aus dem primären Computer und dem sekundären Computer die Bedingungen zu bestimmen, unter denen der sekundäre Computer Fehlalarme bereitstellt. Folglich können das/die neuronale Netz(e) in der Überwachungs-MCU lernen, wann der Ausgabe eines sekundären Computers vertraut werden kann und wann nicht. Zum Beispiel können, wenn der sekundäre Computer ein RADAR-basiertes FCW-System ist, neuronale Netz(e) in der Überwachungs-MCU lernen, wann das FCW-System metallische Objekte identifiziert, die tatsächlich keine Gefahren sind, wie etwa ein Abflussgitter oder ein Gullydeckel, das/der einen Alarm auslöst. Wenn der sekundärer Computer ein kamerabasiertes LDW-System ist, kann ein neuronales Netz in der Überwachungs-MCU ähnlich lernen, die LDW zu überschreiben, wenn Fahrradfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, die (ein) neuronale(s) Netz(e) beinhalten, die auf der Überwachungs-MCU laufen, kann die Überwachungs-MCU mindestens einen DLA oder eine GPU beinhalten, der/die für die Ausführung von dem/den neuronalen Netzwerk(en) mit assoziiertem Speicher geeignet ist. In bevorzugten Ausführungsformen kann die Überwachungs-MCU eine Komponente eines oder mehrerer der SoC(s) 1404 umfassen und/oder als solche enthalten sein.
In anderen Beispielen kann das ADAS-System 1438 einen sekundären Computer beinhalten, der die ADAS-Funktionalität unter Verwendung der traditionellen Regeln des maschinellen Sehens durchführt. So kann der sekundäre Computer klassische Regeln des maschinellen Sehens (wenn-dann) verwenden und kann das Vorhandensein eines neuronalen Netzwerks/von neuronalen Netzwerken in der Überwachungs-MCU die Zuverlässigkeit, Sicherheit und Performance verbessern. Zum Beispiel macht die vielfältige Implementation und absichtliche Nicht-Identität das Gesamtsystem fehlertoleranter, insbesondere gegenüber Fehlern, die durch Software(oder Software-Hardware-Schnittstellen)-Funktionalität verursacht werden. Wenn zum Beispiel ein Software-Bug oder - Fehler in der auf dem primären Computer laufenden Software vorliegt und der nicht identische Software-Code, der auf dem sekundären Computer läuft, dasselbe Gesamtergebnis bereitstellt, kann die Überwachungs-MCU eine größere Konfidenz darin haben, dass das Gesamtergebnis korrekt ist und der Bug in der Software oder Hardware auf dem primären Computer keinen wesentlichen Fehler verursacht.
In einigen Beispielen kann die Ausgabe des ADAS-Systems 1438 in einen Wahrnehmungsblock des primären Computers und/oder in einen Block für dynamische Fahr-Tasks des primären Computers eingespeist werden. Wenn das ADAS-System 1438 z. B. eine Vorwärtszusammenstoßwarnung aufgrund eines unmittelbar vorausliegenden Objekts angibt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der sekundäre Computer über sein eigenes neuronales Netzwerk verfügen, das trainiert ist und somit das Risiko von falsch positiven Ergebnissen reduziert, wie hierin beschrieben.
Das Fahrzeug 1400 kann ferner das Infotainment-SoC 1430 (z. B. ein fahrzeuginternes Infotainment-System (in-vehicle infotainment system - IVI-System)) beinhalten. Obwohl als ein SoC veranschaulicht und beschrieben, kann das Infotainment-System kein SoC sein und kann zwei oder mehr diskrete Komponenten beinhalten. Das Infotainment-SoC 1430 kann eine Kombination aus Hardware und Software enthalten, die verwendet werden kann, um Audio (z. B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon (z. B. Freisprechen), Netzwerkkonnektivität (z. B. LTE, Wi-Fi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Rückwärtseinparkhilfe, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstofffüllstand, insgesamt zurückgelegte Gesamt Strecke, Bremskraftstofffüllstand, Ölfüllstand, Tür öffnen/schließen, Luftfilterinformationen usw.) für das Fahrzeug 1400 bereitzustellen. Das Infotainment-SoC 1430 kann beispielsweise Radios, Plattenspieler, Navigationssysteme, Videowiedergabevorrichtungen, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Audiosteuerungen am Lenkrad, eine Freisprech-Sprachsteuerung, eine Heads-up-Anzeige (heads-up display - HUD), eine HMI-Anzeige 1434, eine Telematikvorrichtung, ein Steuerfeld (z. B. zur Steuerung von und/oder Interaktion mit verschiedenen Komponenten, Merkmalen und/oder Systemen) und/oder andere Komponenten beinhalten. Das Infotainment-SoC 1430 kann ferner dazu verwendet werden, um einem Benutzer(n) des Fahrzeugs Informationen (z. B. optisch und/oder akustisch) bereitzustellen, wie z. B. Informationen vom ADAS-System 1438, Informationen zum autonomen Fahren, wie z. B. geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
Das Infotainment-SoC 1430 kann GPU-Funktionen beinhalten. Das Infotainment-SoC 1430 über den Bus 1402 (z. B. CAN-Bus, Ethernet usw.) mit anderen Vorrichtungen, Systemen und/oder Komponenten des Fahrzeugs 1400 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 1430 mit einer Überwachungs-MCU gekoppelt sein, sodass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primäre(n) Steuerung(en) 1436 (z. B. der primäre und/oder der Backup-Computer des Fahrzeugs 1400) ausfallen. In solch einem Beispiel kann das Infotainment-SoC 1430 das Fahrzeug 1400 in einen Modus des Chauffierens zu einem sicheren Halt versetzen, wie hierin beschrieben.
Das Fahrzeug 1400 kann ferner ein Kombiinstrument 1432 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) beinhalten. Das Kombiinstrument 1432 kann eine Steuerung und/oder einen Supercomputer (z. B. eine diskrete Steuerung oder einen diskreten Supercomputer) beinhalten. Das Kombiinstrument 1432 kann einen Satz von Messausrüstung beinhalten, wie z. B. Geschwindigkeitsmesser, Kraftstoffstand, Öldruck, Drehzahlmesser, Wegstreckenzähler, Blinker, Schaltknüppelpositionsangabe, Sicherheitsgurt-Warnleuchte(n), Feststellbremsen-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Informationen über Airbag (SRS)-Systeme,Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen usw. In einigen Beispielen können Informationen angezeigt und/oder vom Infotainment-SoC 1430 und dem Kombiinstrument 1432 gemeinsam genutzt werden. In anderen Worten kann das Kombiinstrument 1432 als Teil des Infotainment-SoC 1430 enthalten sein oder umgekehrt.
14D ist ein Systemdiagramm für die Kommunikation zwischen dem/den Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug 1400 aus 14A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System 1476 kann Server 1478, Netzwerk(e) 1490 und Fahrzeuge, einschließlich des Fahrzeugs 1400, beinhalten. Der/die Server 1478 können eine Vielzahl von GPUs 1484(A)-1484(H) (hierin kollektiv als GPUs 1484 bezeichnet), PCIe-Switches 1482(A)-1482(H) (hierin kollektiv als PCIe-Switches 1482 bezeichnet) und/oder CPUs 1480(A)-1480(B) (hierin kollektiv als CPUs 1480 bezeichnet) beinhalten. Die GPUs 1484, die CPUs 1480 und die PCIe-Switches können mit Hochgeschwindigkeitszusammenschaltungen miteinander verbunden sein, wie z. B. und ohne Einschränkung den von NVIDIA entwickelten NVLink-Schnittstellen 1488 und/oder PCIe-Verbindungen 1486. In einigen Beispielen sind die GPUs 1484 über ein NVLink- und/oder NVSwitch-SoC verbunden und die GPUs 1484 und die PCIe-Switches 1482 sind über PCIe-Zusammenschaltungen verbunden. Obwohl acht GPUs 1484, zwei CPUs 1480 und zwei PCIe-Switches veranschaulicht sind, soll dies nicht einschränkend sein. Je nach Ausführungsform kann jeder der Server 1478 eine beliebige Anzahl von GPUs 1484, CPUs 1480 und/oder PCIe-Switches beinhalten. Zum Beispiel können der/die Server 1478 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1484 beinhalten.
Der/die Server 1478 können über die Netz(e) 1490 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenbedingungen zeigen, wie etwa kürzlich begonnene Straßenarbeiten. Der/die Server 1478 können über das/die Netzwerk(e) 1490 und an die Fahrzeuge neuronale Netzwerke 1492, aktualisierte neuronale Netzwerke 1492 und/oder Karteninformationen 1494 übertragen, einschließlich Informationen über Verkehrs- und Straßenbedingungen. Die Aktualisierungen der Karteninformationen 1494 können Aktualisierungen für die HD-Karte 1422 beinhalten, wie z. B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In einigen Beispielen können die neuronalen Netzwerke 1492, die aktualisierten neuronalen Netzwerke 1492 und/oderdie Karteninformationen 1494 aus einem neuen Training und/oder Erfahrungen resultieren, das/die in Daten dargestellt wird/werden, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder basierend auf Training, das in einem Rechenzentrum (z. B. unter Verwendung von dem/den Server(n) 1478 und/oder anderen Servern) durchgeführt wurde.
Der/die Server 1478 können verwendet werden, um Modelle des maschinellen Lernens (z. B. neuronale Netzwerke) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen erzeugt werden und/oder können sie in einer Simulation (z. B. unter Verwendung einer Spiele-Engine) erzeugt werden. In einigen Beispielen werden die Trainingsdaten mit Tags versehen (z. B. wenn das neuronale Netzwerk von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B. wenn das neuronale Netzwerk kein überwachtes Lernen benötigt). 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, Selbstlernen, Verstärkungslernen, föderiertes Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraumlernen, vielfältiges Lernen, Repräsentationslernen (einschließlich Ersatzwörterbuchlernen), regelbasiertes maschinelles Lernen, Anomalieerkennung und alle Varianten oder Kombinationen davon. Sobald die Modelle des maschinellen Lernens trainiert sind, können die Modelle des maschinellen Lernens von den Fahrzeugen verwendet werden (z. B. über das/die Netzwerk(e) 1490 an die Fahrzeuge übertragen werden und/oder können die Modelle des maschinellen Lernens von dem/den Server(n) 1478 verwendet werden, um die Fahrzeuge aus der Ferne zu überwachen.
In einigen Beispielen kann der/können die Server 1478 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Echtzeit-Netze zum intelligenten Echtzeit-Inferenzieren anwenden. Der/die Server 1478 können Deep-Learning-Supercomputer und/oder dedizierte KI-Computer beinhalten, die von GPU(s) 1484 angetrieben werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen können der/die Server 1478 jedoch eine Deep-Learning-Infrastruktur beinhalten, die nur CPU-angetriebene Rechenzentren verwendet.
Die Deep-Learning-Infrastruktur des/der Server(s) 1478 kann zum schnellen Echtzeit-Inferenzieren in der Lage sein und diese Fähigkeit verwenden, um den Zustand von den Prozessoren, Software und/oder assoziierter Hardware in dem Fahrzeug 1400 zu bewerten und zu verifizieren. Zum Beispiel kann die Deep-Learning-Infrastruktur periodische Aktualisierungen vom Fahrzeug 1400 empfangen, wie z. B. eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 1400 in dieser Sequenz von Bildern lokalisiert hat (z. B. über maschinelles Sehen und/oder andere Objekt-Klassifizierungstechniken des maschinellen Lernens). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netzwerk laufen lassen, um die Objekte zu identifizieren und sie mit den Objekten zu vergleichen, die vom Fahrzeug 1400 identifiziert wurden, und wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 1400 eine Fehlfunktion aufweist, dann können der/die Server 1478 ein Signal an das Fahrzeug 1400 übertragen, das einen ausfallsicheren Computer des Fahrzeugs 1400 anweist, die Kontrolle zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
Zum Ableiten können der/die Server 1478 die GPU(s) 1484 und einen oder mehrere programmierbare Ableitungsbeschleuniger (z. B. TensorRT von NVIDIA) beinhalten. Die Kombination von GPU-angetriebenen Servern und Ableitungsbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, wenn z. B. die Performance weniger kritisch ist, können von CPUs, FPGAs und anderen Prozessoren angetriebene Server für die Ableitung verwendet werden.
BEISPIELHAFTE RECHENVORRICHTUNG
15 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung(en) 1500, die zur Verwendung beim Implementieren einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist/sind. Die Rechenvorrichtung 1500 kann ein Verschaltungssystem 1502 beinhalten, das die folgenden Vorrichtungen direkt oder indirekt koppelt: Speicher 1504, eine oder mehrere Zentraleinheiten (CPUs) 1506, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1508, eine Kommunikationsschnittstelle 1510, Eingabe-/Ausgabe-(I/O)-Anschlüsse 1512, Eingabe-/Ausgabekomponenten 1514, eine Stromversorgung 1516, eine oder mehrere Präsentationskomponenten 1518 (z. B. Anzeige(n)) und eine oder mehrere Logikeinheiten 1520. In mindestens einer Ausführungsform kann/können die Rechenvorrichtung(en) 1500 eine oder mehrere virtuelle Maschinen (VM) umfassen und/oder jede ihrer Komponenten kann aus virtuellen Komponenten bestehen (z. B. virtuelle Hardwarekomponenten). Nicht einschränkende Beispiele können eine oder mehrere GPUs 1508 eine oder mehrere vGPUs umfassen, eine oder mehrere CPUs 1506 können eine oder mehrere vCPUs umfassen und/oder eine oder mehrere Logikeinheiten 1520 können eine oder mehrere virtuelle Logikeinheiten umfassen. Die Rechenvorrichtung(en) 1500 kann (können) diskrete Komponenten (z. B. eine vollständigen, der Rechenvorrichtung 1500 zugeordneten GPU), virtuelle Komponenten (z. B. einen Teil einer der Rechenvorrichtung 1500 zugeordneten GPU) oder eine Kombination davon beinhalten.
Auch wenn die verschiedenen Blöcke von 15 als über das Verschaltungssystem 1502 mit Leitungen verbunden gezeigt sind, soll dies nicht einschränkend sein und dient nur der Klarheit. Zum Beispiel kann in einigen Ausführungsformen eine Präsentationskomponente 1518, wie etwa Anzeigevorrichtung, als I/O-Komponente 1514 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 1506 und/oder GPUs 1508 Speicher beinhalten (z. B. kann der Speicher 1504 repräsentativ für eine Speichervorrichtung zusätzlich zum Speicher der GPUs 1508, der CPUs 1506 und/oder anderen Komponenten sein). Mit anderen Worten dient die Rechenvorrichtung aus 15 lediglich der Veranschaulichung. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Vorrichtung“, „mobile Vorrichtung“, „Handheld-Vorrichtung“, „Spielekonsole“, „elektronische Steuereinheit (electronic control unit - ECU),“ „Virtual-Reality-System“ und/oder andere Vorrichtungs- oder Systemtypen unterschieden, da alle im Umfang der Rechenvorrichtung der 15 in Betracht gezogen werden.
Das Verschaltungssystem 1502 kann eine oder mehrere Verbindungen oder Busse darstellen, wie beispielsweise einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verschaltungssystem 1502 kann einen oder mehrere Bus- oder Verbindungstypen beinhalten, wie beispielsweise einen Bus mit Industriestandardarchitektur (industry standard architecture - ISA), einen Bus mit erweiterter Industriestandardarchitektur (extended industry standard architecture - EISA), einen Bus der Video Electronic Standards Association (VESA), einen Bus für Verschaltung einer Periphärkomponente (PCI), ein Bus für Expressverschaltung einer Periphärkomponente (PCle) und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen Komponenten. Als ein Beispiel kann die CPU 1506 direkt mit dem Speicher 1504 verbunden sein. Ferner kann die CPU 1506 direkt mit der GPU 1508 verbunden sein. Wo eine direkte oder Punkt-zu-Punkt-Verbindung zwischen Komponenten besteht, kann das Verschaltungssystem 1502 eine PCIe-Verbindung beinhalten, um die Verbindung auszuführen. In diesen Beispielen muss kein PCI-Bus in der Rechenvorrichtung 1500 beinhaltet sein.
Der Speicher 1504 kann eine beliebige Vielfalt computerlesbarer Medien beinhalten. Die computerlesbaren Medien können beliebige verfügbare Medien sein, auf welche die Rechenvorrichtung 1500 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entfernbare und nicht entfernbare Medien beinhalten. Beispielhaft und nicht einschränkend können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige und/oder entfernbare und nicht entfernbare Medien beinhalten, die in jedem beliebigen Verfahren oder jeder beliebigen Technologie zum Speichern von Informationen wie etwa computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder anderen Daten implementiert werden. Zum Beispiel kann der Speicher 1504 computerlesbare Anweisungen speichern (die z. B. ein Programm oder Programme und/oder ein oder mehrere Programmelemente darstellen, wie etwa ein Betriebssystem). Computerspeichermedien können RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium beinhalten, das verwendet werden kann, um die gewünschten Informationen zu speichern und auf das die Rechenvorrichtung 1500 zugreifen kann, sind aber nicht darauf beschränkt. Im hierin verwendeten Sinne umfassen Computerspeichermedien keine Signale an sich.
Die Computerspeichermedien können computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal wie etwa einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und beinhalten beliebige Informationsliefermedien. Der Begriff „moduliertes Datensignal“ kann ein Signal betreffen, das eine oder mehrere seiner Eigenschaften auf solch eine Weise verändert aufweist, dass Informationen in dem Signal kodiert werden. Zum Beispiel, und nicht als Einschränkung, können Computerspeichermedien verkabelte Medien beinhalten, wie beispielsweise ein verkabeltes Netzwerk oder eine drahtgebundene Verbindung, und drahtlose Medien, wie beispielsweise akustische, RF, infrarote und andere drahtlose Medien. Kombinationen von jeglichen der obigen sollten auch innerhalb des Umfangs der vorliegenden computerlesbaren Medien umfasst sein.
Die CPU(s) 1506 können konfiguriert sein, um mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1500 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Die CPU(s) 1506 können jeweils einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) beinhalten, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu handhaben. Die CPU(s) 1506 können eine beliebige Art von Prozessor beinhalten und können unterschiedliche Arten von Prozessoren beinhalten, abhängig von der Art der Rechenvorrichtung 1500 (z. B. Prozessoren mit weniger Kernen für mobile Vorrichtungen und Prozessoren mit mehr Kernen für Server). Zum Beispiel kann der Prozessor in Abhängigkeit von der Art der Rechenvorrichtung 1500 ein Advanced-RISC-Machines(ARM)-Prozessor sein, der unter Verwendung von Reduced Instruction Set Computing (RISC) implementiert ist, oder ein x86-Prozessor, der unter Verwendung von Complex Instruction Set Computing (CISC) implementiert ist. Die Rechenvorrichtung 1500 kann eine oder mehrere CPUs 1506 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Coprozessoren, wie etwa mathematischen Coprozessoren, beinhalten.
Zusätzlich oder alternativ zu den CPU(s) 1506 können die GPU(s) 1508 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Computervorrichtung 1500 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Eine oder mehrere der GPU(s) 1508 können eine integrierte GPU sein (z. B. mit einer oder mehreren der CPU(s) 1506) und/oder eine oder mehrere der GPU(s) 1508 können eine diskrete GPU sein. In Ausführungsformen können eine oder mehrere der GPU(s) 1508 ein Coprozessor einer oder mehrerer der CPU(s) 1506 sein. Die GPU(s) 1508 können durch die Computervorrichtung 1500 verwendet werden, um Grafiken (z. B. 3D-Grafiken) zu rendern oder Universalberechnungen durchzuführen. Zum Beispiel können die GPU(s) 1508 für Universalberechnungen auf GPUs (GPGPU) verwendet werden. Die GPU(s) 1508 können Hunderte oder Tausende von Kernen beinhalten, die in der Lage sind, Hunderte oder Tausende von Softwarethreads gleichzeitig zu handhaben. Die GPU(s) 1508 können Pixeldaten für Ausgabebilder als Reaktion auf das Rendern von Befehlen erzeugen (z. B. Rendern von Befehlen aus der/den CPU(s) 1506, die über eine Host-Schnittstelle empfangen werden). Die GPU(s) 1508 können Grafikspeicher beinhalten, wie etwa Anzeigespeicher, um Pixeldaten oder andere geeignete Daten zu speichern, wie etwa GPGPU-Daten. Der Anzeigespeicher kann als Teil des Speichers 1504 beinhaltet sein. Der/die GPU(s) 1508 können zwei oder mehrere GPUs beinhalten, die parallel arbeiten (z. B. über einen Link). Der Link kann die GPUs direkt verbinden (z. B. unter Verwendung von NVLINK) oder kann die GPUs über ein Switch verbinden (z. B. unter Verwendung von NVSwitch). Wenn sie miteinander kombiniert werden, kann jede GPU 1508 Pixeldaten oder GPGPU-Daten für verschiedene Abschnitte einer Ausgabe oder für verschiedene Ausgaben (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild) erzeugen. Jede GPU kann ihren eigenen Speicher beinhalten oder kann Speicher mit anderen GPUs teilen.
Zusätzlich oder alternativ zu den CPU(s) 1506 und/oder den GPU(s) 1508 kann/können die Logikeinheit(en) 1520 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1500 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. In Ausführungsformen können die CPU(s) 1506, die GPU(s) 1508 und/oder die Logikeinheit(en) 1520 einzeln oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 1520 kann/können Teil von und/oder integriert in eine oder mehrere der CPU(s) 1506 und/oder der GPU(s) 1508 sein und/oder eine oder mehrere der Logikeinheiten 1520 kann/können diskrete Komponenten oder anderweitig extern zu der/den CPU(s) 1506 und/oder der/den GPU(s) 1508 sein. In Ausführungsformen können eine oder mehrere der logischen Einheiten 1520 ein Coprozessor einer oder mehrerer der CPU(s) 1506 und/oder einer oder mehrerer der GPU(s) 1508 sein.
Beispiele der Logikeinheit(en) 1520 beinhalten einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie etwa Tensorkerne (Tensor Cores - TC), Tensor-Verarbeitungseinheiten (Tensor Processing Unit - TPU), visuelle Pixelkerne (Pixel Visual Cores - PVC), Bildverarbeitungseinheiten (Vision Processing Unit - VPU), Grafikverarbeitungscluster (Graphics Processing Cluster - GPC), Texturverarbeitungscluster (Texture Processing Cluster - TPC), Streaming-Multiprozessoren (SM), Baumdurchquerungseinheiten (Tree Traversal Unit - TTU), Beschleuniger für künstliche Intelligenz (Artificial Intelligence Accelerator - AIA), Deep-Learning-Beschleuniger (Deep Learning Accelerator - DLA), arithmetische Logikeinheiten (ALU), anwendungsspezifische integrierte Schaltungen (ASIC), Gleitkommaeinheiten (Floating Point Unit - FPU), Eingabe/Ausgabe (I/O)-Elemente, Elemente für Verschaltung von Periphärkomponenten (PCI) oder Expressverschaltung von Periphärkomponenten (peripheral component interconnect express - PCle) und/oder dergleichen.
Die Kommunikationsschnittstelle 1510 kann einen oder mehrere Empfänger, Sender und/oder Transceiver beinhalten, die es der Rechenvorrichtung 1500 ermöglichen, mit anderen Rechenvorrichtungen über ein elektronisches Kommunikationsnetz, einschließlich drahtgebundener und/oder drahtloser Kommunikation, zu kommunizieren. Die Kommunikationsschnittstelle 1510 kann Komponenten und Funktionalität beinhalten, um eine Kommunikation über eine Anzahl unterschiedlicher Netzwerke zu ermöglichen, wie etwa drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weiterverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet.
Die I/O-Anschlüsse 1512 können die Rechenvorrichtung 1500 dazu befähigen, logisch an andere Vorrichtungen gekoppelt zu werden, einschließlich der I/O-Komponenten 1514, der Präsentationskomponente(n) 1518 und/oder anderer Komponenten, von denen einige in die Rechenvorrichtung 1500 eingebaut (z. B. darin integriert) sein können. Veranschaulichende I/O-Komponenten 1514 beinhalten ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, eine drahtlose Vorrichtung usw. Die I/O-Komponenten 1514 können eine natürliche Benutzerschnittstelle (natural user interface - NUI) bereitstellen, die Luftgesten, Stimme oder andere physiologische Eingaben, die durch einen Benutzer generiert werden, verarbeitet. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten genauer beschrieben) implementieren, die einer Anzeige der Rechenvorrichtung 1500 zugeordnet sind. Die Rechenvorrichtung 1500 kann Tiefenkameras, wie etwa stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestendetektion und -erkennung beinhalten. Zusätzlich kann die Rechenvorrichtung 1500 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (intertia measurement unit - IMU)) beinhalten, die eine Bewegungsdetektion ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope durch die Rechenvorrichtung 1500 verwendet werden, um immersive augmentierte Realität oder virtuelle Realität zu rendern.
Die Stromversorgung 1516 kann auch eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon beinhalten. Die Stromversorgung 1516 kann der Rechenvorrichtung 1500 Strom bereitstellen, um den Komponenten der Rechenvorrichtung 1500 den Betrieb zu ermöglichen.
Die Präsentationskomponent(en) 1518 können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigearten oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten beinhalten. Die Präsentationskomponent(en) 1518 können Daten von anderen Komponenten (z. B. den GPU(s) 1508, den CPU(s) 1506 usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
BEISPIEL RECHENZENTRUM
16 zeigt ein Beispiel für ein Rechenzentrum 1600, das in mindestens einer Ausführungsform der vorliegenden Offenbarung verwendet werden kann. Das Rechenzentrum 1600 kann eine Rechenzentrumsinfrastrukturschicht 1610, eine Framework-Schicht 1620, eine Softwareschicht 1630 und/oder eine Anwendungsschicht 1640 beinhalten.
Wie in 16 gezeigt, kann die Rechenzentrumsinfrastrukturschicht 1610 einen Ressourcenorchestrierer 1612, gruppierte Berechnungsressourcen 1614 und Knotenberechnungsressourcen („Knoten-CRs“) 1616(1)-1616(N) beinhalten, wobei „N“ eine beliebige ganze positive Zahl darstellt. In mindestens einer Ausführungsform können die Knoten-C.R.s 1616(1)-1616(N) eine beliebige Anzahl von zentralen Verarbeitungseinheiten („CPUs“) oder anderen Prozessoren (einschließlich Beschleunigern, feldprogrammierbaren Gate-Anordnungen (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Arbeitsspeichervorrichtungen (z. B. dynamischer Festwertspeicher), Datenspeichervorrichtungen (z. B. Solid-State- oder Festplattenlaufwerke), Netzwerk-Eingabe-/Ausgabe(„NW-I/O“)-Vorrichtungen, Netzwerk-Switches, virtuellen Maschinen („VMs“), Leistungsmodulen und Kühlmodulen usw. beinhalten, sind aber nicht darauf beschränkt. In einigen Ausführungsformen können einer oder mehreren Knoten-C.R.s unter den Knoten-C.R.s 1616(1)-1616(N) einem Server entsprechen, der eine oder mehrere der vorstehend erwähnten Rechenressourcen aufweist. Darüber hinaus können die Knoten C.R.s 1616(1)-16161(N) in einigen Ausführungsformen eine oder mehrere virtuelle Komponenten beinhalten, wie z. B. vGPUs, vCPUs und/oder dergleichen, und/oder einer oder mehrere der Knoten C.R.s 1616(1)-1616(N) können einer virtuellen Maschine (VM) entsprechen.
In mindestens einer Ausführungsform können gruppierte Berechnungsressourcen 1614 getrennte Gruppierungen von Knoten-CR 1616 beinhalten, die in einem oder mehreren Racks (nicht gezeigt) untergebracht sind, oder vielen Racks, die in Rechenzentren an verschiedenen geografischen Standorten (ebenfalls nicht gezeigt) untergebracht sind. Getrennte Gruppierungen von Knoten-CR 1616 innerhalb gruppierter Rechenressourcen 1614 können gruppierte Rechen-, Netzwerk-, Arbeitsspeicher- oder Datenspeicherressourcen beinhalten, die konfiguriert oder zugewiesen sein können, um eine oder mehrere Rechenlasten zu unterstützen. In mindestens einer Ausführungsform können mehrere Knoten-CR 1616, die CPU, GPU und/oder Prozessoren beinhalten, in einem oder mehreren Racks gruppiert sein, um Rechenressourcen bereitzustellen, um eine oder mehrere Rechenlasten zu unterstützen. Das eine oder mehrere Racks können auch eine beliebige Anzahl von Leistungsmodulen, Kühlmodulen und Netz-Switches in beliebiger Kombination beinhalten.
Der Ressourcen-Orchestrator 1622 kann einen oder mehrere Knoten-CR 1616(1)-1616(N) und/oder gruppierte Rechenressourcen 1614 konfigurieren oder anderweitig steuern. In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 1622 eine Verwaltungseinheit für Software-Design-Infrastruktur („SDI“) für das Rechenzentrum 1600 beinhalten. Der Ressourcen-Orchestrator 1622 kann aus Hardware, Software oder einer Kombination davon bestehen.
In mindestens einer Ausführungsform, wie in 16 gezeigt, kann die Framework-Schicht 1620 einen Aufgabenplaner 1632, einen Konfigurations-Manager 1634, einen Ressourcen-Manager 1636 und ein verteiltes Dateisystem 1638 beinhalten. Die Framework-Schicht 1620 kann ein Framework zur Unterstützung von Software 1632 der Software-Schicht 1630 und/oder einer oder mehrerer Anwendung(en) 1642 der Anwendungsschicht 1640 beinhalten. Die Software 1632 bzw. die Anwendung(en) 1642 können webbasierte DienstSoftware oder -anwendungen beinhalten, wie sie beispielsweise von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. Die Framework-Schicht 1620 kann eine Art freies und quelloffenes Software-Webanwendungs-Framework wie Apache SparkTM (im nachfolgend „Spark“) sein, das ein verteiltes Dateisystem 1638 für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwenden kann, ohne darauf beschränkt zu sein. In mindestens einer Ausführungsform kann der Aufgabenplaner 1632 einen Spark-Treiber beinhalten, um die Planung von Arbeitslasten zu erleichtern, die durch verschiedene Schichten des Rechenzentrums 1600 unterstützt werden. Der Konfigurations-Manager 1634 kann in der Lage sein, unterschiedliche Schichten zu konfigurieren, z. B. die Software-Schicht 1630 und die Framework-Schicht 1620, einschließlich Spark und des verteilten Dateisystems 1638 zur Unterstützung der Verarbeitung großer Datenmengen. Der Ressourcen-Manager 1636 kann in der Lage sein, geclusterte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 1638 und des Aufgabenplaners 1632 zugeordnet oder zugewiesen sind. In mindestens einer Ausführungsform können geclusterte oder gruppierte Rechenressourcen die gruppierte Rechenressource 1614 auf der Rechenzentrumsinfrastrukturschicht 1610 beinhalten. Der Ressourcen-Manager 1036 und der Ressourcen-Orchestrator 1612 können sich aufeinander abstimmen, um diese zugeordneten oder zugewiesenen Rechenressourcen zu verwalten.
In mindestens einer Ausführungsform kann die in der Softwareschicht 1630 beinhaltete Software 1632 Software beinhalten, die durch mindestens Teile der Knoten-CR 1616(1)-1616(N), gruppierte Rechenressourcen 1614 und/oder das verteilte Dateisystem 1638 der Framework-Schicht 1620 verwendet werden. Eine oder mehrere Arten von Software können Internet-Webseiten-Suchsoftware, E-Mail-Virenscan-Software, Datenbanksoftware und Streaming-Videoinhalt-Software beinhalten, ohne darauf beschränkt zu sein.
In mindestens einer Ausführungsform kann/können die Anwendung(en) 1642, die in der Anwendungsschicht 1640 beinhaltet ist/sind, eine oder mehrere Arten von Anwendungen beinhalten, die durch mindestens Teile der Knoten-CR 1616(1)-1616(N), gruppierte Rechenressourcen 1614 und/oder das verteilte Dateisystem 1638 der Framework-Schicht 1620 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl einer Genomikanwendung, einer kognitiven Rechenanwendung und einer maschinellen Lernanwendung umfassen, die Trainings- oder Ableitungssoftware beinhaltet, Framework-Software des maschinellen Lernens (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere maschinelle Lernanwendungen beinhalten, ohne darauf beschränkt zu sein, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden.
In mindestens einer Ausführungsform können beliebige von dem Konfigurationsmanager 1634, Ressourcenmanager 1636 und Ressourcen-Orchestrator 1612 eine beliebige Anzahl und Art von selbstmodifizierenden Handlungen auf Grundlage einer beliebigen Menge und Art von Daten implementieren, die auf jede technisch machbare Weise erfasst werden. Selbstmodifizierende Handlungen können einen Rechenzentrumsbetreiber des Rechenzentrums 1600 dahingehend entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Abschnitte eines Rechenzentrums zu vermeiden.
Das Rechenzentrum 1600 kann Werkzeuge, Dienste, Software oder andere Ressourcen beinhalten, um ein oder mehrere Modelle des maschinellen Lernens zu trainieren oder Informationen unter Verwendung eines oder mehrerer Modelle des maschinellen Lernens gemäß einer oder mehreren in dieser Schrift beschriebenen Ausführungsformen vorherzusagen oder abzuleiten. Zum Beispiel kann/können ein Modell(e) für maschinelles Lernen trainiert werden, indem Gewichtungsparameter gemäß einer Architektur eines neuronalen Netzes unter Verwendung von Software und/oder Rechenressourcen berechnet werden, die vorstehend in Bezug auf das Rechenzentrum 1600 beschrieben sind. In mindestens einer Ausführungsform können trainierte oder eingesetzte Modelle für maschinelles Lernen, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um Informationen unter Verwendung der vorstehend in Bezug auf das Rechenzentrum 1600 beschriebenen Ressourcen zu inferenzieren oder vorherzusagen, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere hierin beschriebene Trainingstechniken berechnet werden, sind aber nicht darauf beschränkt.
In mindestens einer Ausführungsform kann das Rechenzentrum 1600 CPUs, anwendungsspezifische integrierte Schaltungen (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder die Inferenzierung mit den oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der oben beschriebenen Software- und/oder Hardwareressourcen als Dienst konfiguriert werden, der es dem Benutzer ermöglicht, Informationen zu trainieren oder zu inferieren, wie z.B. Bilderkennung, Spracherkennung oder andere Dienste künstlicher Intelligenz.
BEISPIELHAFTE NETZWERKUMGEBUNGEN
Netzwerkumgebungen, die für die Verwendung beim Implementieren von Ausführungsformen der Offenbarung geeignet sind, können ein oder mehrere Client-Vorrichtungen, Server, netzwerkverbundenen Speicher (network attached storage - NAS), andere Backend-Vorrichtungen und/oder andere Vorrichtungstypen beinhalten. Die Client-Vorrichtungen, -Server und/oder andere Vorrichtungsarten (z. B. jede Vorrichtung) können auf einer oder mehreren Instanzen der Rechenvorrichtung(en) 1500 von 15 implementiert werden - z. B. kann jede Vorrichtung ähnliche Komponenten, Merkmale und/oder Funktionen der Rechenvorrichtung(en) 1500 beinhalten. Wenn Backend-Vorrichtungen (z. B. Server, NAS usw.) implementiert werden, können die Backend-Vorrichtungen auch Teil eines Rechenzentrums 1600 sein, dessen Beispiel in 16 näher beschrieben wird.
Komponenten einer Netzwerkumgebung können miteinander über ein oder mehrere Netzwerke kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netzwerk kann mehrere Netzwerke oder ein Netzwerk von Netzwerken beinhalten. Beispielsweise kann das Netzwerk ein oder mehrere Weitverkehrsnetzwerke (WAN), ein oder mehrere lokale Netzwerke (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonvermittlungsnetz (publich switched telephone network - PSTN) und/oder ein oder mehrere private Netzwerke beinhalten. Wenn das Netzwerk ein drahtloses Telekommunikationsnetz beinhaltet, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Konnektivität bereitstellen.
Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebungen beinhalten - in diesem Fall kann ein Server nicht in einer Netzwerkumgebung beinhaltet sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung beinhaltet sein. In Peer-to-Peer-Netzwerkumgebungen kann die hierin in Bezug auf einen oder mehrere Server beschriebene Funktionalität auf einer beliebigen Anzahl von Client-Vorrichtungen implementiert sein.
In mindestens einer Ausführungsform kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. beinhalten. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Job-Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem beinhalten, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzwerkserver und/oder Edge-Server beinhalten können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Software-Schicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht beinhalten. Die Software oder Anwendung(en) können jeweils Web-basierte Dienstsoftware oder Anwendungen beinhalten. In Ausführungsformen können eine oder mehrere der Client-Vorrichtungen die Web-basierte Dienstsoftware oder Anwendungen verwenden (z. B. durch Zugreifen auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (API)). Bei der Framework-Schicht kann es sich um eine Art freies und quelloffenes Software-Webanwendungs-Framework handeln, das etwa ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwenden kann, ist aber nicht darauf beschränkt.
Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination von hierin 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 Rechenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Wenn eine Verbindung zu einem Benutzer (z. B. einer Client-Vorrichtung) relativ nahe bei einem oder mehreren Edge-Servern ist, können ein oder mehrere Core-Server dem oder den Edge-Servern mindestens einen Teil der Funktionalität zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat sein (z. B. auf eine einzelne Organisation beschränkt), kann öffentlich sein (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon sein (z. B. eine Hybrid-Cloud-Umgebung).
Die Client-Vorrichtung(en) können mindestens eine der Komponenten, Merkmale und Funktionalität der hierin in Bezug auf 15 beschrieben Rechenvorrichtung(en) 1500 beinhalten. Als Beispiel und nicht einschränkend kann eine Client-Vorrichtung als Personal Computer (PC), Laptop-Computer, mobile Vorrichtung, Smartphone, Tablet-Computer, Smartwatch, tragbarer Computer, Personal Digital Assistant (PDA), MP3-Player, Virtual-Reality-Headset, System oder Vorrichtung zur globalen Positionsbestimmung (GPS), Videoplayer, Videokamera, Überwachungsvorrichtung oder -system, Fahrzeug, Boot, Flugschiff, virtuelle Maschine, Drohne, Roboter, tragbare Kommunikationsvorrichtung, Vorrichtung in einem Krankenhaus, Spielgerät oder - system, Unterhaltungssystem, Fahrzeugcomputersystem, eingebetteter Systemcontroller, Fernbedienung, Haushaltsgerät, Unterhaltungselektronikgerät, Workstation, Edge-Vorrichtung, eine beliebige Kombination dieser skizzierten Vorrichtungen oder jede andere geeignete Vorrichtung verkörpert sein.
Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinenverwendbaren Anweisungen beschrieben werden, einschließlich computerausführbarer Anweisungen wie etwa Programmmodulen, die von einem Computer oder einer anderen Maschine wie etwa einem Personal Data Assistant 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 praktiziert werden, einschließlich Handheld-Vorrichtungen, Unterhaltungselektronik, Allzweckcomputern, spezielleren Rechenvorrichtungen usw. Die Offenbarung kann auch in verteilten Rechenumgebungen praktiziert werden, in denen Aufgaben von entfernten Verarbeitungsvorrichtungen, die über ein Kommunikationsnetz verbunden sind, durchgeführt werden.
Wie hierin verwendet, sollte eine Rezitation von „und/oder“ in Bezug auf zwei oder mehr Elemente so ausgelegt werden, dass sie nur ein Element oder eine Kombination von Elementen bedeutet. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder Elemente enthalten A, B und C. Außerdem kann „mindestens eines von Element A oder Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element umfassen B. Ferner kann „mindestens eines von Element A und Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B beinhalten.
Der Gegenstand der vorliegenden Offenbarung wird hierin spezifisch beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Erwägung gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um andere Schritte oder Kombinationen von Schritten ähnlich den in diesem Dokument beschriebenen in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien einzuschließen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden können, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sollten die Begriffe darüber hinaus nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge zwischen oder zwischen verschiedenen hierin offenbarten Schritten implizieren, es sei denn, die Reihenfolge ist der einzelnen Schritte ist explizit beschrieben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

JP 3016201806 [0070]
JP 3016201609 [0070]
US 16101232 B [0112]

Claims

Verfahren umfassend: Erfassen von Sensordaten, welche mit verschiedenen Typen von Sensoren erfasst werden; Zusammenstellen einer Menge von Annotationsszenen, wobei mindestens eine Annotationsszene in der Menge ein Bild der Sensordaten von jedem von zwei oder mehr der verschiedenen Sensortypen umfasst, wobei das Zusammenstellen mindestens auf einer Darstellung von einem oder mehreren zeitlichen Offsets basiert, welche die Sensordaten von zwei oder mehr der verschiedenen Sensortypen abgleichen; Erzeugen einer Darstellung einer Vielzahl von Annotationsaufgaben durch ein Kennzeichnungswerkzeug, um die Annotationsszenen mit Ground-Truth-Annotationen zu annotieren; Annehmen, unter Verwendung des Kennzeichnungswerkzeugs, einer Eingabe für mindestens eine Annotationsaufgabe aus der Vielzahl von Annotationsaufgaben, wobei die Eingabe eine oder mehrere Annotationsszenen aus der Menge von Annotationsszenen mit einer Menge von Ground-Truth-Annotationen annotiert, welche durch die mindestens eine Annotationsaufgabe definiert werden; und Exportieren einer Darstellung der Menge der Ground-Truth-Annotationen.
Verfahren nach Anspruch 1, wobei die verschiedenen Typen von Sensoren einen LiDAR-Sensor und eine Kamera umfassen, wobei die Darstellung des einen oder der mehreren zeitlichen Offsets eine Verzögerung relativ zu einem Beginn einer LiDAR-Drehung des LiDAR-Sensors umfasst, wenn sich die LiDAR-Drehung innerhalb eines Sichtfelds der Kamera befindet.
Verfahren nach Anspruch 1 oder 2, wobei die verschiedenen Typen von Sensoren einen LiDAR-Sensor und eine oder mehrere Kameras umfassen, und wobei die Vielzahl von Annotationsaufgaben umfasst: eine erste Annotationsaufgabe, welche eine Annotation von Kamerabildern in der Menge der Annotationsszenen umfasst; eine zweite Annotationsaufgabe, welche eine Annotation von LiDAR-Bildern in der Menge der Annotationsszenen im zweidimensionalen Raum umfasst; und eine dritte Annotationsaufgabe, welche ein Verknüpfen von Annotationen umfasst, welche in mehreren Annotationsszenen in der Menge der Annotationsszenen erscheinen.
Verfahren nach Anspruch 3, wobei die Vielzahl der Annotationsaufgaben darüber hinaus umfasst: eine vierte Annotationsaufgabe, welche eine Annotation der LiDAR-Bilder in der Menge der Annotationsszenen im dreidimensionalen Raum umfasst; und eine fünfte Annotationsaufgabe, welche ein Verknüpfen von Annotationen umfasst, welche sowohl in einem LiDAR-Bild als auch in einem Kamerabild in einer bestimmten Annotationsszene in der Menge der Annotationsszenen erscheinen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Vielzahl der Annotationssaufgaben Annotationen von verschiedenen Typen von Objekten oder verschiedenen Niveaus von Annotationsdetails in separate Annotationsaufgaben aufteilt.
Verfahren nach einem der vorhergehenden Ansprüche, welches darüber hinaus umfasst ein Initialisieren einer Menge von Annotationen für eine bestimmte Annotationsszene in der Menge von Annotationsszenen während einer bestimmten Annotationsaufgabe der Vielzahl von Annotationsaufgaben durch das Kennzeichnungswerkzeug mit einer vorhergehenden Menge von Annotationen einer vorhergehenden Annotationsszene in der Menge von Annotationsszenen während der bestimmten Annotationsaufgabe.
Verfahren nach einem der vorhergehenden Ansprüche, wobei eine bestimmte Annotationsszene in der Menge von Annotationsszenen ein erstes Bild der Sensordaten von einem ersten Sensortyp und ein zweites Bild der Sensordaten von einem zweiten Sensortyp umfasst, darüber hinaus umfassend, durch das Kennzeichnungswerkzeug: Identifizieren einer Zuordnung zwischen einem Abschnitt des ersten Bildes und einem Abschnitt des zweiten Bildes durch Projizieren einer Information von Koordinaten des Abschnitts des ersten Bildes in Koordinaten des Abschnitts des zweiten Bildes; und Veranlassen einer Darstellung einer Visualisierung der Zuordnung.
Verfahren nach einem der vorhergehenden Ansprüche, wobei eine bestimmte Annotationsszene in der Menge der Annotationsszenen ein erstes Bild der Sensordaten von einem ersten Sensortyp und ein zweites Bild der Sensordaten von einem zweiten Sensortyp umfasst, darüber hinaus umfassend, durch das Kennzeichnungswerkzeug: Bestimmen eines Abschnitts des ersten Bildes, welcher von einer Eingabeprobe identifiziert wird; Projizieren von Koordinaten des Abschnitts des ersten Bildes in Koordinaten eines entsprechenden Abschnitts des zweiten Bildes; und Veranlassen einer Visualisierung des entsprechenden Abschnitts des zweiten Bildes.
Verfahren nach einem der vorhergehenden Ansprüche, welches darüber hinaus durch das Kennzeichnungswerkzeug umfasst, Durchlaufen während der mindestens einen Annotationsaufgabe einer Prozedur pro Objekt, wobei die Prozedur pro Objekt für mindestens eine Annotation einer Annotationsszene aus der Menge der Annotationsszenen, welche während einer vorherigen Annotationsaufgabe der Vielzahl von Annotationsaufgaben empfangen wird, umfasst: Veranlassen einer Darstellung einer vergrößerten Ansicht der Annotation in der Annotationsszene; und Auffordern für eine und Annehmen einer Eingabe zum Anpassen oder Bestätigen der Annotation.
Verfahren nach einem der vorhergehenden Ansprüche, welches darüber hinaus durch das Kennzeichnungswerkzeug umfasst: Iterieren für die mindestens eine Annotationsaufgabe durch die Annotationsszenen in einer oder mehreren Annotationsschnittstellen des Kennzeichnungswerkzeugs; und für die mindestens eine Annotationsszene Auffordern für eine und Annehmen einer Eingabe, welche eine entsprechende Menge von Ground-Truth-Annotationen identifiziert, die durch die mindestens eine Annotationsaufgabe definiert sind, während eine Darstellung des Bildes der Sensordaten von jedem der zwei oder mehr der verschiedenen Sensortypen veranlasst wird.
Prozessor, welcher eine oder mehrere Schaltungen umfasst: um Sensordaten zu erfassen, welche während einer Aufnahmesitzung erfasst werden, wobei die Sensordaten LiDAR-Bilder von einem LiDAR-Sensor und Kamerabilder von mindestens einer Kamera aufweisen; um eine Menge von Annotationsszenen, wobei eine bestimmte Annotationsszene in der Menge von Annotationsszenen ein bestimmtes LiDAR-Bild der LiDAR-Bilder und ein bestimmtes Kamerabild der Kamerabilder umfasst, zumindest basierend auf einer Darstellung eines zeitlichen Offsets zwischen dem bestimmten LiDAR-Bild und dem bestimmten Kamerabild zusammenzustellen; um durch ein Kennzeichnungswerkzeug eine Darstellung einer Vielzahl von Annotationsaufgaben zu erzeugen, um die Annotationsszenen in der Menge von Annotationsszenen mit Ground-Truth-Annotationen zu annotieren; um mittels des Kennzeichnungswerkzeugs eine Eingabe für mindestens eine Annotationsaufgabe der Vielzahl von Annotationsaufgaben anzunehmen, wobei die Eingabe eine oder mehrere der Annotationsszenen in der Menge von Annotationsszenen mit einer Menge der Ground-Truth-Annotationen, welche durch die mindestens eine Annotationsaufgabe definiert sind, annotiert; und um eine Darstellung der Menge der Ground-Truth-Annotationen zu exportieren.
Prozessor nach Anspruch 11, wobei die Darstellung des zeitlichen Offsets eine Verzögerung relativ zu einem Beginn einer LiDAR-Drehung umfasst, wenn sich die LiDAR-Drehung innerhalb eines Sichtfeldes der mindestens einen Kamera befindet.
Prozessor nach Anspruch 11 oder 12, wobei die Vielzahl von Annotationsaufgaben umfasst: eine erste Annotationsaufgabe, welche eine Annotation einer Menge der Kamerabilder in der Menge von Annotationsszenen umfasst; eine zweite Annotationsaufgabe, welche eine Annotation einer Menge der LiDAR-Bilder in der Menge von Annotationsszenen im zweidimensionalen Raum umfasst; und eine dritte Annotationsaufgabe, welche ein Verknüpfen von Annotationen umfasst, welche in mehreren Annotationsszenen in der Menge der Annotationsszenen erscheinen.
Prozessor nach einem der Ansprüche 11 bis 13, wobei die eine oder die mehreren Schaltungen darüber hinaus vorhanden sind, um eine Menge von Annotationen für mindestens eine Annotationsszene in der Menge von Annotationsszenen während einer bestimmten Annotationsaufgabe der Vielzahl von Annotationsaufgaben mit einer vorhergehenden Menge von Annotationen einer vorhergehenden Annotationsszene in der Menge von Annotationsszenen während der bestimmten Annotationsaufgabe zu initialisieren.
Prozessor nach einem der Ansprüche 11 bis 14, wobei die eine oder die mehreren Schaltungen darüber hinaus vorhanden sind, um eine Zuordnung zwischen einem Abschnitt des bestimmten LiDAR-Bildes und einem Abschnitt des bestimmten Kamerabildes zu identifizieren, indem eine Information von Koordinaten des bestimmten LiDAR-Bildes in Koordinaten des bestimmten Kamerabildes projiziert werden; und um eine Darstellung einer Visualisierung der Zuordnung zu veranlassen.
Prozessor nach einem der Ansprüche 11 bis 15, wobei die eine oder die mehreren Schaltungen darüber hinaus vorhanden sind, um einen Abschnitt des bestimmten LiDAR-Bildes zu bestimmen, welcher von einer Eingabeprobe identifiziert wird; um Koordinaten des Abschnitts des bestimmten LiDAR-Bildes in Koordinaten eines entsprechenden Abschnitts des bestimmten Kamerabildes zu projizieren; und um eine Visualisierung des entsprechenden Abschnitts des bestimmten Kamerabildes zu veranlassen.
Prozessor nach einem der Ansprüche 11 bis 16, wobei die eine oder die mehreren Schaltungen darüber hinaus vorhanden sind, um während der mindestens einen Annotationsaufgabe durch eine Prozedur pro Objekt zu iterieren, wobei die Prozedur pro Objekt für mindestens eine Annotation einer Annotationsszene, welche während einer vorherigen Annotationsaufgabe der Vielzahl von Annotationsaufgaben empfangen wird, umfasst: Veranlassen einer Darstellung einer vergrößerten Ansicht der Annotation in der Annotationsszene; und Auffordern für eine und Annehmen einer Eingabe zum Anpassen oder Bestätigen der Annotation.
System umfassend: eine oder mehrere Verarbeitungseinheiten; und eine oder mehrere Speichereinheiten, welche Anweisungen speichern, welche, wenn sie von der einen oder den mehreren Verarbeitungseinheiten ausgeführt werden, die eine oder die mehreren Verarbeitungseinheiten veranlassen, Operationen auszuführen, welche umfassen: Erzeugen einer Darstellung einer Vielzahl von Annotationsaufgaben durch ein Kennzeichnungswerkzeug, um eine Menge von Annotationsszenen mit Ground-Truth-Annotationen zu annotieren, wobei mindestens eine Annotationsszene in der Menge von Annotationsszenen abgeglichene Bilder von Sensordaten von verschiedenen Sensortypen umfasst; Verwenden des Kennzeichnungswerkzeugs für mindestens eine Annotationsaufgabe aus der Vielzahl der Annotationsaufgaben: Iterieren durch die Menge von Annotationsszenen in einer oder mehreren Kennzeichnungsschnittstellen des Kennzeichnungswerkzeugs; und Annehmen einer Eingabe für die mindestens eine Annotationsszene, wobei die Eingabe eine Menge der Ground-Truth-Annotationen identifiziert, welche durch die mindestens eine Annotationsaufgabe definiert sind, während eine Darstellung einer Menge der abgeglichenen Bilder von Sensordaten von zwei oder mehr der verschiedenen Sensortypen veranlasst wird; und Exportieren einer Darstellung der Menge der Ground-Truth-Annotationen.
System nach Anspruch 18, wobei eine bestimmte Annotationsszene ein erstes Bild der Sensordaten eines ersten Sensortyps und ein zweites Bild der Sensordaten eines zweiten Sensortyps umfasst, wobei die Operationen darüber hinaus durch das Kennzeichnungswerkzeug umfassen: Identifizieren einer Zuordnung zwischen einem Abschnitt des ersten Bildes und einem Abschnitt des zweiten Bildes, indem eine Information von Koordinaten des Abschnitts des ersten Bildes in Koordinaten des Abschnitts des zweiten Bildes projiziert wird; und Veranlassen einer Darstellung einer Visualisierung der Zuordnung.
System nach Anspruch 18 oder 19, wobei das System mindestens eines umfasst von: ein Steuerungssystem für eine autonome oder halbautonome Maschine; ein Wahrnehmungssystem für eine autonome oder halbautonome Maschine; ein System zur Durchführung von Simulationsoperationen; ein System zur Durchführung von Deep-Learning-Operationen; ein System, welches unter Verwendung einer Edge-Einrichtung implementiert ist; ein unter Verwendung eines Roboters implementiertes System; ein System, welches eine oder mehrere virtuelle Maschinen (VMs) enthält; ein System, welches zumindest teilweise in einem Rechenzentrum implementiert ist; oder ein System, welches zumindest teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.