DE102018121018A1

DE102018121018A1 - Erweitern von realen sensoraufnahmen mit simuliertem sensordatenhintergrund

Info

Publication number: DE102018121018A1
Application number: DE102018121018.3A
Authority: DE
Inventors: Daniel Bogdoll; Shreyasha Paudel; Tejaswi Koduri
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-08-31
Filing date: 2018-08-28
Publication date: 2019-02-28
Also published as: US20190065933A1; CN109427214A; US11487988B2

Abstract

Ursprüngliche Sensordaten werden von einem oder mehreren Sensoren eines Fahrzeugs empfangen. Freier Raum um das Fahrzeug wird gemäß den Sensordaten identifiziert, wie etwa durch Identifizieren von Regionen, in welchen Datenpunkte eine Höhe unter einem Schwellenwert aufweisen. Ein Standort für ein Objektmodell wird aus dem freien Raum ausgewählt. Eine Ebene wird gemäß Sensordaten um den Standort eingefügt und das Objektmodell wird gemäß einer Ausrichtung der Ebene ausgerichtet. Erfassen des Objektmodells durch einen Sensor des Fahrzeugs wird simuliert, um simulierte Daten zu erhalten, die dann zu den ursprünglichen Sensordaten hinzugefügt werden. Sensordaten, die Objekten entsprechen, welche durch das Objektmodell verborgen worden wären, werden aus den ursprünglichen Sensordaten entfernt. Erweiterte Sensordaten können verwendet werden, um einen Steuerungsalgorithmus zu validieren oder ein Modell zum Maschinenlernen zu trainieren.

Description

GEBIET DER ERFINDUNG
Diese Erfindung betrifft das Simulieren von einem Szenario unter Verwendung von einem oder mehreren elektronischen Sensoren.
ALLGEMEINER STAND DER TECHNIK
Die Herausforderung beim Testen und Validieren von Fahrerassistenztechnologien und autonomen Fahrzeugen entsteht aus der großen Anzahl von Testfällen und sehr seltenen Grenzfällen. Während eine Vielfalt von Fällen bei Praxistests auftreten, gibt es bestimmte Szenarien, die in der Praxis sehr selten sind und die zu gefährlich sind, um sie auf einem Testgelände auszuführen. Detaillierte Simulationen werden herkömmlicherweise verwendet, um Versuche dieser Szenarien durchzuführen. Aufgrund von Fehlen perfekter Sensormodelle und Verkehrsmodelle sind die aus diesen Simulationen generierten Daten sehr realistisch, imitieren jedoch nicht alle Mängel der Praxis.
Das hierin offenbarte System und die hierin offenbarten Verfahren stellen einen verbesserten Ansatz zum Generieren von Szenarien aus aufgenommenen Sensordaten durch Erweitern dieser mit simulierten Sensordaten bereit.
Figurenliste
Damit die Vorteile der Erfindung ohne Weiteres verstanden werden, erfolgt durch Bezugnahme auf konkrete Ausführungsformen, die in den beigefügten Zeichnungen veranschaulicht sind, eine genauere Beschreibung der vorstehend kurz beschriebenen Erfindung. Unter der Annahme, dass diese Zeichnungen lediglich typische Ausführungsformen der Erfindung darstellen und daher nicht als den Umfang beschränkend aufzufassen sind, wird die Erfindung mit zusätzlicher Genauigkeit und Ausführlichkeit durch Verwendung der beigefügten Zeichnungen beschrieben und erläutert, in denen Folgendes gilt:

Die 1A und 1B sind schematische Blockdiagramme eines Systems zum Umsetzen von Ausführungsformen der Erfindung;
2 ist ein schematisches Blockdiagramm einer beispielhaften Rechenvorrichtung, die zum Umsetzen von Verfahren gemäß Ausführungsformen der Erfindung geeignet ist;
3 ist ein Prozessflussdiagramm eines Verfahrens zum Hinzufügen von simulierter Sensorausgabe für ein Objektmodell zu tatsächlichen Sensordaten gemäß einer Ausführungsform der vorliegenden Erfindung;
Die 4A und 4B sind schematische Blockdiagramme eines Szenarios, das unter Verwendung tatsächlicher Sensoren erfasst wurde;
Die 5A und 5B veranschaulichen die Erweiterung der Sensordaten für die 4A und 4B gemäß einer Ausführungsform der vorliegenden Erfindung;
6 ist ein Prozessflussdiagramm eines Verfahrens zur Erweiterung von LIDAR-Daten gemäß einem Objektmodell gemäß einer Ausführungsform der vorliegenden Erfindung; und
Die 7A bis 7C sind Bilder, welche das Erweitern von LIDAR-Daten gemäß dem Verfahren aus 6 veranschaulichen.

DETAILLIERTE BESCHREIBUNG
Unter Bezugnahme auf 1 kann eine Rechenumgebung 100 ein Serversystem 102 beinhalten, das eine Datenbank 104, die Daten zur Verwendung gemäß den hier offenbarten Verfahren speichert, hostet oder darauf zugreifen kann. Insbesondere kann die Datenbank 104 Sensordaten 106 speichern, die von Sensoren eines Fahrzeugs empfangen werden, während das Fahrzeug in einer tatsächlichen Umgebung fährt. Die Sensordaten können einen oder mehrere von visuellen Daten 108a (z. B. die Ausgabe von einer oder mehreren Kameras im sichtbaren Lichtbereich oder Infrarotkameras), LIDAR- (light detection and ranging) Daten 108b, die durch einen LIDAR-Sensor des Fahrzeugs ausgegeben sind, RADAR. (radio detection and ranging) Daten 108c, die durch einen RADAR-Sensor ausgegeben sind, beinhalten. Andere Arten von Sensordaten 106 können ebenfalls gespeichert sein, wie etwa Ausgaben von Mikrofonen, Ultraschallsensoren oder anderen Arten von Sensoren. Die Sensordaten 108a-108c für jeden Sensor können eine Reihe von Datensätzen beinhalten, die über einen Zeitraum während des Fahrens auf einem Verlauf durch das Fahrzeug ausgegeben wurden.
Die Datenbank 104 kann ferner ein oder mehrere Sensormodelle 110 speichern. Die Sensormodelle 110 definieren Daten, die ausreichen, um eine simulierte Wahrnehmung eines dreidimensionalen (3D-) Modells durch einen tatsächlichen Sensor zu ermöglichen. Zum Beispiel kann ein Kameramodell 112a Daten definieren, welche Verzerrung, Farbänderung, Bildwechselfrequenz, Resolution, Zoom, Sichtfeld, Ausrichtung oder andere Artefakte einer Kamera definieren kann, die die Wahrnehmung einer Szene beeinträchtigen könnten.
Ein LIDAR-Modell 112b kann eine Abtastrate, Punktdichte, Abtastlaserwellenlänge, Strahleneigenschaften, Detektorempfindlichkeit, Sichtfeld usw. definieren. Ein RADAR-Sensormodell 112c kann Einschränkungen und Attribute eines RADAR-Systems definieren, z. B. Wellenlänge, Signalamplitude, Winkelabtastgeschwindigkeit, Antennenverstärkung, Sichtfeld usw. Wo andere Arten von Sensordaten 106 vorhanden sind, können andere Arten von Sensormodellen 110 für diese Arten von Sensoren definiert sein. Bei einem Mikrofon kann das Sensormodell 110 zum Beispiel die Verstärkung, das Signal-Rausch-Verhältnis, das Empfindlichkeitsprofil (Empfindlichkeit gegenüber Frequenz) und dergleichen beinhalten.
Diese generierten Daten können zu mehreren Zwecken verwendet werden: Trainieren eines tiefen neuronalen Netzwerks (ihr habt das in Abschnitt 17 besprochen), Testen und Überprüfen von automatisierten Fahralgorithmen in den Gebieten der Wahrnehmung, Szenenverständnis, Objektdetektion, Missionsplanung, Verlaufsplanung und Steuerung. Diese Tests können als Tests mit offenem oder geschlossenem Regelkreis ausgestaltet sein.
Die Datenbank 104 kann ferner Objektmodelle 114 beinhalten. Die Objektmodelle 114 können 3D-Modelle von Objekten beinhalten, die Fahrzeuge antreffen können, wie etwa andere Fahrzeuge 116a, Fußgänger 116b und andere Objekte 116c wie etwa Tiere, Fremdkörper und dergleichen. Die Objektmodelle 114 können unter Verwendung eines beliebigen fachbekannten 3D-Modellierungsformats definiert werden. In einigen Ausführungsformen können die Objektmodelle 114 als eine Punktwolke, ein Netz von Dreiecken oder anderen Darstellungen der Konturen des Objekts dargestellt sein. Das Objektmodell 114 kann ferner Materialeigenschaften definieren, die für die Detektion des Praxisgegenstücks des Objektmodells durch einen oder mehrere Arten von Sensoren relevant sind. Zum Beispiel können für Modellierungsdetektion durch eine Kamera Attribute wie etwa Farbe, Textur, Reflexionsvermögen und dergleichen für Punkte auf der Fläche des Objektmodells 114 vorgegeben werden. Zur Modellierungsdetektion durch einen LIDAR-Sensor kann das Objektmodell 114 Reflexionsvermögen für Punkte auf der Fläche des Objektmodells definieren. Zur Modellierungsdetektion durch einen RADAR-Sensor, können Eigenschaften Reflexionsvermögen bei einer Wellenlänge beinhalten, die gemäß dem Modell 112c des RADAR-Sensors emittiert werden.
Die Datenbank 104 kann ferner ein Modell zum Maschinenlernen 118 speichern, das unter Verwendung von simulierten Sensordaten trainiert wird, die gemäß den hierin offenbarten Verfahren generiert werden. Das Modell zum Maschinenlernen 118 kann für einen beliebigen Zweck trainiert sein. Zum Beispiel kann das Modell zum Maschinenlernen dazu trainiert sein, Hindernisse zu detektieren, insbesondere Hindernisse für die Detektion gemäß den hierin offenbarten Verfahren simuliert ist. Das Modell zum Maschinenlernen 118 kann ein tiefes neuronales Netzwerk, Bayessches Netzwerk oder ein anderer Typ eines Modells zum Maschinenlernen sein.
In einem anderen Beispiel kann ein Modell zum Maschinenlernen 118 dazu trainiert werden, die Konturen eines Standorts ohne Objekte zu schätzen, wenn Objekte während des Detektierens der Szene vorhanden waren. Zum Beispiel kann eine Straße unter Verwendung von LIDAR ohne entlang fahrende oder geparkte Fahrzeuge detektiert werden. Ein beispielhafte Anwendung kann Folgendes beinhalten: das Erhalten von Sensordaten von einer leeren Straße, das Simulieren von Erfassen von Modellen von Fahrzeugen zusammen mit der leeren Straße gemäß den hierin beschriebenen Verfahren und dann das Trainieren des Modells zum Maschinenlernen 118, um durch Entfernen der Punkte, die den hinzugefügten Fahrzeugen entsprechen, eine Punktwolke, die der leeren Straße entspricht, zu generieren.
Das Serversystem 102 kann eine Trainingengine 120 ausführen. Die Trainingengine 120 kann ein Lokalisatormodul 122a beinhalten. Das Lokalisatormodul 122a kann dazu programmiert sein, Koordinaten in einer Raumregion zu identifizieren, einschließlich Sensordaten, die gegenwärtig nicht durch ein Hindernis belegt sind. Wie nachstehend besprochen kann dies das Identifizieren einer Bodenebene, z. B. einer Straße, einer Seitenwand, eines Parkplatzes oder einer anderen Fläche, beinhalten.
Die Trainingengine 120 kann ein Einsetzmodul 122b beinhalten. Das Einsetzmodul 122b wählt Standorte für ein oder mehrere Objektmodelle 114 innerhalb einer oder mehrerer der unbelegten Regionen, die durch das Lokalisatormodul 122a identifiziert wurden, aus. In einigen Ausführungsformen kann der Standort manuell durch einen Benutzer vorgegeben werden, um ein gewünschtes Szenario zu erzeugen. In anderen Ausführungsformen kann ein Standort zufällig innerhalb einer oder mehrerer nicht belegten Regionen durch das Einsetzmodul 122b ausgewählt sein. Ein nicht zufällig automatisch ausgewählter Standort (z. B. mit einem umgesetzten Modell eines Fahrzeugfahrers) ist ebenfalls möglich.
Die Trainingengine 120 kann ein Simulationsmodul 122c beinhalten. Das Simulationsmodul 122c simuliert sowohl die Detektion eines eingesetzten Objektmodells 114 als auch Einstellungen von Sensordaten, damit sie der Anwesenheit des Objektmodells 114 entsprechen. Wie nachstehend besprochen kann dies das Entfernen von Sensordaten beinhalten, die verborgen werden würden, wenn das Praxisgegenstück des Objektmodells 114 tatsächlich vorhanden wäre.
Die Trainingengine 120 kann ein Trainingsmodul 122d ausführen, das ein Modell zum Maschinenlernen 118 unter Verwendung von Sensordaten trainiert, die gemäß den hierin offenbarten Verfahren modifiziert wurden. Wie auf dem Fachgebiet bekannt, ist eine große Menge an Trainingsdaten erforderlich, um ein Modell zum Maschinenlernen zu trainieren. Dementsprechend können viele Hunderte oder Tausende der Sensordatensätze modifiziert und verwendet werden, um das Modell zum Maschinenlernen 118 zu trainieren.
Unter Bezugnahme auf 1B kann das Modell zum Maschinenlernen 118 verwendet werden, um eine Hindernisdetektion in dem veranschaulichten System 124 durchzuführen, welches in einem Fahrzeug integriert sein kann, wie etwa einem autonomen oder von einem Menschen bedienten Fahrzeug. Zum Beispiel kann das System 124 eine Steuerung 126 beinhalten, die in einem Fahrzeug untergebracht ist. Das Fahrzeug kann ein beliebiges fachbekanntes Fahrzeug beinhalten. Das Fahrzeug kann alle Strukturen und Merkmale eines beliebigen fachbekannten Fahrzeugs aufweisen, wozu Räder, ein an die Räder gekoppelter Antriebsstrang, ein an den Antriebsstrang gekoppelter Motor, ein Lenksystem, ein Bremssystem und andere fachbekannte in ein Fahrzeug einzuschließende Systeme gehören.
Wie hier ausführlicher erörtert, kann die Steuerung 126 autonome Navigation und Kollisionsvermeidung durchführen. Insbesondere können eines oder mehrere von LIDAR-Daten, Bilddaten, Radardaten und eine oder mehrere Arten von Sensordaten analysiert werden, um Hindernisse zu identifizieren.
Die Steuerung 126 kann ein oder mehrere Bildströme von einer oder mehreren Abbildungsvorrichtungen 128 empfangen. Zum Beispiel können eine oder mehrere Kameras an dem Fahrzeug montiert sein und durch die Steuerung 126 empfangene Bildströme ausgeben. Die Steuerung 126 kann ein oder mehrere Audioströme von einem oder mehreren Mikrofonen 130 empfangen. Zum Beispiel kann/können eine oder mehrere Mikrofone oder Mikrofonarrays am Fahrzeug montiert sein und von der Steuerung 126 empfangene Audioströme ausgeben. Die Mikrofone 130 können Richtmikrofone mit einer Empfindlichkeit, die mit dem Winkel variiert, beinhalten.
In einigen Ausführungsformen kann das System 124 andere Sensoren 132 beinhalten, die an die Steuerung 126 gekoppelt sind, wie etwa einer oder mehrere von LIDAR, RADAR, SONAR und Ultraschallsensor oder dergleichen. Die Standorte und Ausrichtungen der Erfassungsvorrichtungen 128, 130, 132 können denen entsprechen, die in den Sensormodellen 110 modelliert sind, welche verwendet werden, um das Modell zum Maschinenlernen 118 zu trainieren.
Die Steuerung 126 kann ein Kollisionsvermeidungsmodul 134 ausführen, das Ausgaben von Erfassungsvorrichtungen 128, 130, 132 empfängt, Hindernisse in den Ausgaben detektiert und Maßnahmen ergreift, um sie zu vermeiden. Das Kollisionsvermeidungsmodul 134 kann ferner das Modul zum Maschinenlernen 118 beinhalten oder verkörpern, das unter Verwendung von modifizierten Sensordaten, die gemäß den hierin offenbarten Verfahren generiert sind, trainiert ist. Das Kollisionsvermeidungsmodul 134 kann ebenfalls ein programmiertes Steuerungssystem sein, das unter Verwendung von erweiterten Sensordaten, die gemäß den hierin offenbarten Verfahren generiert sind, abgestimmt oder getestet wird.
Das Kollisionsvermeidungsmodul 134 kann ein Hindernisidentifikationsmodul 136a beinhalten, das das Ausgaben von den Erfassungsvorrichtungen 128, 130, 132 empfängt und eine Schätzung zu dem Standort eines Hindernisses und möglicherweise eine Klassifizierung des Hindernisses (Fahrzeug, Fußgänger, Struktur, Tier usw.) ausgibt.
Das Kollisionsvermeidungsmodul 134 kann ferner ein Kollisionsvorhersagemodul 136b ausführen, das vorhersagt, welche Hindernisbilder auf Grundlage seines gegenwärtigen Kurses oder gegenwärtig beabsichtigten Verlaufs wahrscheinlich mit dem Fahrzeug kollidieren. Das Kollisionsvorhersagemodul 136b kann die Wahrscheinlichkeit einer Kollision mit durch das Hindernisidentifikationsmodul 136a identifizierten Objekten beurteilen.
Ein Entscheidungsmodul 136c kann dann eine Entscheidung zum Anhalten, Beschleunigen, Abbiegen usw. treffen, um Hindernissen auszuweichen. Die Art und Weise, auf die das Kollisionsvorhersagemodul 132c potentielle Kollisionen vorhersagt, und die Art und Weise, auf die das Entscheidungsmodul 132d Maßnahmen ergreift, um potentielle Kollisionen zu vermeiden, können gemäß einem beliebigen auf dem Fachgebiet autonomer Fahrzeuge bekannten Verfahren oder System sein.
Das Entscheidungsmodul 136c kann den Kurs des Fahrzeugs durch Betätigen eines oder mehrerer Aktoren 138 steuern, welche die Richtung und Geschwindigkeit des Fahrzeugs steuern. Zum Beispiel können die Aktoren 138 einen Lenkaktor 140a, einen Beschleunigungsaktor 140b und einen Bremsaktor 140c beinhalten. Die Auslegung der Aktoren 140a-140c kann gemäß einer beliebigen Umsetzung derartiger auf dem Fachgebiet autonomer Fahrzeuge bekannter Aktoren erfolgen.
2 ist ein Blockdiagramm, das eine beispielhafte Rechenvorrichtung 200 veranschaulicht. Die Rechenvorrichtung 200 kann dazu verwendet werden, verschiedene Vorgänge durchzuführen, wie etwa die hier erörterten. Das Serversystem 102 und die Steuerung 126 können einige oder alle der Attribute der Rechenvorrichtung 200 aufweisen.
Die Rechenvorrichtung 200 beinhaltet einen oder mehrere Prozessor(en) 202, eine oder mehrere Speichervorrichtung(en) 204, eine oder mehrere Schnittstelle(n) 206, eine oder mehrere Massenspeichervorrichtung(en) 208, eine oder mehrere Ein-/Ausgabe-(E/A-)Vorrichtung(en) 210 und eine Anzeigevorrichtung 230, die alle an einen Bus 212 gekoppelt sind. Der/Die Prozessor(en) 202 beinhaltet/beinhalten eine(n) oder mehrere Prozessoren oder Steuerungen, der/die in der/den Speichervorrichtung(en) 204 und/oder der/den Massenspeichervorrichtung(en) 208 gespeicherte Anweisungen ausführen. Der/Die Prozessor(en) 202 kann/können zudem verschiedene Arten von computerlesbaren Medien beinhalten, wie etwa Zwischenspeicher.
Die Speichervorrichtung(en) 204 beinhaltet/beinhalten verschiedene computerlesbare Medien, wie etwa flüchtigen Speicher (z. B. Direktzugriffsspeicher (RAM) 214) und/oder nichtflüchtigen Speicher (z. B. Festwertspeicher (ROM) 216). Die Speichervorrichtung(en) 204 kann/können zudem wiederbeschreibbaren ROM beinhalten, wie etwa Flash-Speicher.
Die Massenspeichervorrichtung(en) 208 beinhaltet/beinhalten verschiedene computerlesbare Medien, wie etwa Magnetbänder, Magnetplatten, optische Platten, Festkörperspeicher (z. B. Flash-Speicher) und so weiter. Wie in 2 gezeigt, ist eine besondere Massenspeichervorrichtung ein Festplattenlaufwerk 224. Zudem können verschiedene Laufwerke in der/den Massenspeichervorrichtung(en) 208 beinhaltet sein, um ein Auslesen aus und/oder Schreiben auf die verschiedenen computerlesbaren Medien zu ermöglichen. Die Massenspeichervorrichtung(en) 208 beinhaltet/beinhalten entfernbare Medien 226 und/oder nicht entfernbare Medien.
Die E/A-Vorrichtung(en) 210 beinhaltet/beinhalten verschiedene Vorrichtungen, die es ermöglichen, dass Daten und/oder andere Informationen in die Rechenvorrichtung 200 eingegeben oder daraus abgerufen werden. (Eine) Beispielhafte E/A-Vorrichtung(en) 210 beinhaltet/beinhalten Cursorsteuervorrichtungen, Tastaturen, Tastenfelder, Mikrofone, Monitore oder andere Anzeigevorrichtungen, Lautsprecher, Drucker, Netzwerkschnittstellenkarten, Modems, Linsen, CCDs oder andere Bilderfassungsvorrichtungen und dergleichen.
Die Anzeigevorrichtung 230 beinhaltet eine beliebige Art von Vorrichtung, die dazu in der Lage ist, einem oder mehreren Benutzern der Rechenvorrichtung 200 Informationen anzuzeigen. Zu Beispielen für eine Anzeigevorrichtung 230 gehören ein Monitor, ein Anzeigeendgerät, eine Videoprojektionsvorrichtung und dergleichen.
Die Schnittstelle(n) 206 beinhaltet/beinhalten verschiedene Schnittstellen, die es der Rechenvorrichtung 200 ermöglichen, mit anderen Systemen, Vorrichtungen oder Rechenumgebungen zu interagieren. Zu (einer) beispielhaften Schnittstelle(n) 206 gehören eine beliebige Anzahl von unterschiedlichen Netzwerkschnittstellen 220, wie etwa Schnittstellen zu lokalen Netzen (LANs), Weitverkehrsnetzen (WANs), drahtlosen Netzen und dem Internet. Zu (einer) andere(n) Schnittstelle(n) gehören eine Benutzerschnittstelle 218 und eine Peripherievorrichtungsschnittstelle 222. Zu der/den Schnittstelle(n) 206 können zudem eine oder mehrere Peripherieschnittstellen gehören, wie etwa Schnittstellen für Drucker, Zeigevorrichtungen (Mäuse, Trackpad etc.), Tastaturen und dergleichen.
Der Bus 212 ermöglicht dem/den Prozessor(en) 202, der/den Speichervorrichtung(en) 204, der/den Schnittstelle(n) 206, der/den Massenspeichervorrichtung(en) 208, der/den E/A-Vorrichtung(en) 210 und der Anzeigevorrichtung 230, miteinander sowie mit anderen Vorrichtungen oder Komponenten, die an den Bus 212 gekoppelt sind, zu kommunizieren. Der Bus 212 stellt eine oder mehrere von mehreren Arten von Busstrukturen dar, wie etwa einen Systembus, PCI-Bus, IEEE-1394-Bus, USB-Bus und so weiter.
Zum Zwecke der Veranschaulichung sind Programme und andere ausführbare Programmkomponenten hier als getrennte Blöcke gezeigt, auch wenn es sich versteht, dass sich derartige Programme und Komponenten zu verschiedenen Zeitpunkten in unterschiedlichen Speicherkomponenten der Rechenvorrichtung 200 befinden können, und werden durch den/die Prozessor(en) 202 ausgeführt. Alternativ können die hier beschriebenen Systeme und Vorgänge in Hardware oder einer Kombination aus Hardware, Software und/oder Firmware umgesetzt sein. Ein oder mehrere anwendungsspezifische integrierte Schaltkreise (application specific integrated circuits - ASICs) können zum Beispiel so programmiert sein, dass sie eines bzw. einen oder mehrere der hier beschriebenen Systeme und Vorgänge ausführen.
Unter Bezugnahme auf 3 kann das veranschaulichte Verfahren 300 durch das Serversystem 102 ausgeführt werden, um simulierte Sensordaten zu Trainingszwecken zu generieren. Erweiterte Sensordaten können ebenfalls zum Testen und Validieren von Steuerungsalgorithmen oder anderen Arten von Systemen oder Verfahren verwendet werden. In einem anderen Beispiel können die erweiterten Sensordaten verwendet werden, um einen Detektionsalgorithmus zum Erfassen von Objekten unter Verwendung von Sensordaten zu testen oder zu validieren. Der Detektionsalgorithmus kann alleine oder in Kombination mit einem Steuerungsalgorithmus getestet werden, der Entscheidungen auf Grundlage von Ausgaben des Detektionsalgorithmus trifft. Das Verfahren 300 kann das Empfangen 302 von ursprünglichen Sensordaten beinhalten. Die ursprünglichen Sensordaten können eine Reihe von Sensorausgaben über einen Zeitraum beinhalten, die von tatsächlichen Sensoren eines Fahrzeugs empfangen werden, während dieses einen Kurs zurücklegt. Die Sensordaten beinhalten daher Daten, welche Sensorwahrnehmung von häufig angetroffenen Strukturen angeben, wie etwa einem oder mehreren von Straßen, Gebäuden, anderen Fahrzeugen, Fußgängern, Tieren, Fremdkörpern usw.
Die Ausgabe von jedem Sensor beinhaltet eine Reihe von Datensätzen, wobei jeder Datensatz in der Reihe Ausgaben des Sensors zu einem Zeitpunkt oder während eines Zeitraums der Aktualisierungsrate des Sensors darstellt. Wenn mehrere Sensoren verwendet werden, beinhalten die ursprünglichen Sensordaten eine Reihe von Datensätzen für jeden Sensor, welche dieselben oder unterschiedliche Aktualisierungsraten oder Abtastraten aufweisen können.
Das Verfahren 300 kann Extrahieren 304 eines gefahrenen Kurses des Fahrzeugs beinhalten. Dies kann das Empfangen einer Reihe von GPS- (globales Positionierungssystem) Koordinaten aus den ursprünglichen Sensordaten 302 beinhalten. Die GPS-Koordinaten können mit einem Zeitstempel versehen sein oder mit einer bekannten Abtastrate aufgenommen sein, sodass die Zeit, die mit jeder Koordinate zusammenhängt, bekannt ist und auf Ausgaben von anderen Sensoren zu demselben Zeitpunkt (d. h. am nächsten an dem Zeitpunkt, zu dem die Abtast-/Aktualisierungsraten ungleich oder nicht ausgerichtet sind) bezogen werden. Das Extrahieren des Kurses kann ebenfalls durch einen Algorithmus definiert sein, der Daten von einem oder mehreren Sensoren im Laufe der Zeit verwendet, um den gefahrenen Kurs zu definieren. Bekannte Konzepte zu diesem Zweck sind z. B. Odometrie, SLAM oder Structure from Motion.
Das Verfahren 300 kann ferner das Extrahieren 306 von verfügbaren Raum im Laufe der Zeit beinhalten. Dies kann identifizierende Abschnitte einer Umgebung des Fahrzeugs beinhalten, welches die ursprünglichen Sensordaten erfasste, die nicht belegt sind. Zum Beispiel können bei LIDAR-Daten Punkte in einer Punktwolke in der Ausrichtung des Fahrzeugs sein oder dazu in Bezug stehen. Dementsprechend ist eine Höhe eines Punkts relativ zu der vertikalen Achse des Fahrzeugs bekannt. Diese Punkte liegen über einer vorgegebenen Schwellenwerthöhe und können als mögliche Höhe bestimmt sein, Punkte unter diesem Schwellenwert können jedoch als wahrscheinlich eine Bodenebene, z. B. Straßenbelag, bestimmt sein. Bereiche von Punkten unter dem Schwellenwert können dann identifiziert werden. Cluster von durchgehenden Punkten, die einen Bereich umschließen, der keinen der Punkte über dem Schwellenwert beinhaltet, können als nicht belegte Bereiche bestimmt werden. In anderen Beispielen ist freier Raum nicht auf ein Bodenniveau beschränkt. Zum Beispiel könnten ein Vogel, eine Drohne, ein überhängender Ast, Fahrzeuge oder Menschen, die aufgrund eines Unfalls in Bewegung sind, oder eine andere Struktur in dem freien Raum über dem Boden positioniert sein. Dementsprechend kann verfügbarer Raum als ein Volumen von Raum ohne Punkte über dem Schwellenwert identifiziert werden. Der Schwellenwert kann von einer Anwendung abhängig sein, z. B. höher sein, wo das hinzuzufügende Objekt nicht auf dem Boden ruht.
Es ist anzumerken, dass die vertikale Höhe von Punkten über einer horizontalen Ebene in Bezug auf die horizontale Ebene des Fahrzeugs, statt einer Ebene, die senkrecht zur Schwerkraftrichtung verläuft, definiert sein kann. Auf diese Weise, wenn das Fahrzeug auf einem Hügel positioniert ist, werden Punkte auf dem Hügel nicht fälschlicherweise als über dem Schwellenwert liegend interpretiert.
Insofern als die Sensordaten eine Reihe von Datensätzen beinhalten, kann verfügbarer Raum aus einem einzelnen Datensatz oder einer Vielzahl von aufeinanderfolgenden Datensätzen extrahiert werden.
Im Fall von visuellen Daten, können Farben und Texturen eines Bildes analysiert werden, um verfügbaren Raum zu identifizieren, sodass die Farbe und Textur von Beton, Asphalt, Kies oder einer anderen Fahrfläche als freier Raum identifiziert werden können. Abschnitte eines Bilds, einschließlich Objekten, die als Fahrzeuge, Gebäude, Fußgänger, Tiere usw. identifiziert werden können, können von den verfügbaren Räumen ausgeschlossen werden. Wenn ein 3D-Bildsystem Bilder von mehreren Kameras verwenden kann, um ein 3D-Modell aus einem oder mehreren 2D-Bildern zu bilden, kann die 3D-Position dieser verfügbaren Räume aus dem 3D-Modell bestimmt werden. In einigen Ausführungsformen kann Sensorfusion verwendet werden, um Erkenntnisse aus LIDAR-Punkten zu kombinieren, um eine tatsächliche 3D-Szene in Kombination mit dem Bildmaterial zu erzeugen. In derartigen Ausführungsformen kann der freie Raum auf Grundlage der Farbe einer Region der 3D-Szene (Asphalt, Beton usw.) und die Höhe der Punkte in der Szene wie vorstehend in Bezug auf LIDAR-Daten dargelegt, identifiziert werden.
Das Verfahren 300 kann das Auswählen 308 eines verfügbaren Raums aus denen bei Schritt 306 identifizierten beinhalten. Zum Beispiel können die GPS-Koordinaten des Kurses in dem Koordinatensystem einer Punktwolke eines LIDAR-Systems oder 3D-Bildgebungssystem kartiert sein. Ein verfügbarer Raum kann aufgrund des Raums, der auf dem Kurs liegt, ausgewählt werden. In vielen Anwendungen kann Schritt 308 manuell durchgeführt werden und kann einfach das Empfangen einer Benutzerauswahl eines verfügbaren Raums, der in Schritt 306 identifiziert wurde, beinhalten. Zum Beispiel können Sensordaten grafisch derart dargestellt werden, dass die verfügbaren Räume hervorgehoben sind und mit Benutzerschnittstellenelementen zusammenhängen, die auswählbar sind, um eine Benutzerauswahl eines verfügbaren Raums zu empfangen.
Das Verfahren 300 kann ferner das Auswählen 310 eines Objektmodells beinhalten. Zum Beispiel kann ein Objektmodell automatisch für den bei Schritt 308 ausgewählten Raum ausgewählt werden, das eine Grundfläche aufweist, die kleiner als oder gleich ist wie der Raum. Dementsprechend können die Objektmodelle 114 Abmessungen einer Grundfläche des Objektmodells beinhalten, um diesen Vergleich zu ermöglichen. In Bezug auf Schritt 308 kann Schritt 310 ebenfalls manuell durchgeführt werden, durch Empfangen einer Benutzerauswahl eines Objektmodells 114 aus einer Sammlung von mehreren Objektmodellen 114.
Die Schritte 312-318 können wiederholt für unterschiedliche Datensätze durchgeführt werden, die unterschiedlichen Zeitschritten entsprechen, um eine Reihe von erweiterten Datensätzen bereitzustellen, die zum Trainieren des maschinellen Lernmodells verwendet werden können. Die Schritte 312-318 können ebenfalls für Ausgaben von mehreren Sensoren durchgeführt werden.
Das Verfahren 300 kann ferner das Ausrichten 312 des Objektmodells 114 innerhalb des Koordinatensystems der ursprünglichen Sensordaten beinhalten. Zum Beispiel, für den bei Schritt 308 ausgewählten Bereich kann eine Ebene zu den Punkten in dem Datensatz eingefügt werden, in welchem der ausgewählte Bereich identifiziert wurde. Das Objekt kann dann derart ausgerichtet sein, dass eine Basis des Objektmodells parallel zu und entsprechend mit dieser Ebene angeordnet ist, z. B. die Unterseite der Reifen eines Fahrzeugs, die Füße eines Modells eines Fußgängers oder Tieres, usw. Der Standort des Objektmodells 114 innerhalb des ausgewählten Raums kann derart ausgewählt sein, dass er derart auf dem Kurs von Schritt 304 liegt, dass das Fahrzeug mit dem Objektmodell 114 kollidiert wäre, wenn es tatsächlich vorhanden wäre.
Wie vorstehend angemerkt können ursprüngliche Sensordaten mehrere Datensätze zu mehreren Zeitpunkten beinhalten. Dementsprechend kann Schritt 312 für mehrere Datensätze derart durchgeführt werden, dass das Objekt in Bezug auf das Koordinatensystem von jedem Datensatz auf eine einheitliche Weise mit entweder einem stationären Objekt oder einem Objekt ausgerichtet ist, das sich wie sein entsprechendes Praxisgegenstück bewegt, z. B. Schrittgeschwindigkeit für einen Fußgänger, Fahrgeschwindigkeit für ein Fahrzeug usw. Zum Beispiel, wie vorstehend angemerkt, kann das Koordinatensystem von jedem Datensatz in Bezug zu den GPS-Koordinaten des Fahrzeugs stehen. Dementsprechend können die GPS-Koordinaten des Fahrzeugs, das jedem Datensatz zeitlich am nächsten ist (oder ungefähr für jeden Datensatz der durch Interpolation eingestellt ist) verwendet werden, um die Ausrichtung des Objektmodells von einem Datensatz zu dem nächsten zu ändern, um ein stationäres Objekt oder ein Objekt, das sich gemäß einem gewünschten Kurs relativ zu dem Kurs des Fahrzeugs bewegt, zu simulieren.
Das Verfahren 300 kann dann das Generieren 314 einer simulierten Sensorausgabe beinhalten, die die Wahrnehmung des Objektmodells aus einem Sichtpunkt eines Sensors des Fahrzeugs simuliert. Dies kann das Verwenden des entsprechenden Sensormodells 110 beinhalten, um die Wahrnehmung des Objektmodells an dem Standort und der Ausrichtung aus Schritt 312 zu simulieren. Zum Beispiel kann für LIDAR eine Punktwolke generiert werden, welche der Fläche des Objektmodells entspricht, wobei die Dichte der Punkte und das Reflexionsvermögen gemäß dem Sensormodell 112b des LIDAR-Sensors bestimmt werden.
In einem anderen Beispiel kann eine Wiedergabe des Objektmodells an seinem Standort und seiner Ausrichtung aus Schritt 312 generiert 314 werden. Die Technik, durch die dies durchgeführt wird, kann das Verwenden einer beliebigen fachbekannten Computeranimationstechnik beinhalten, wie etwa die, die oft beim Hinzufügen von computergenerierten Bildern für Filme und Fernsehen eingesetzt werden. Insbesondere kann die Beleuchtung der Originalszene angenähert werden, um eine Beleuchtung des Objektmodells 114 zu simulieren und eine realistische Wiedergabe bereitzustellen. Die 3D-Umgebung (einschließlich lokalen Lampen) kann verwendet werden, um hochentwickelte Schatten zu erzeugen. Zum Beispiel können 3D-Daten aus LIDAR-Punktwolken und Kameradaten verwendet werden, um Strukturen zu detektieren und Schatten zu berechnen, die durch derartige Strukturen sowie das Objektmodell geworfen würden. Standorte von Lampen und Strukturen, die Schatten werfen können, können ebenfalls aus bereits bestehenden 3D-Karten einer Region erhalten werden.
In noch einem anderen Beispiel können Reflexion und Detektion einer Radiowelle aus einem RADAR-Sensor für das Objektmodell an der Position und Ausrichtung aus Schritt 312 gemäß dem RADAR-Sensormodell 112c simuliert werden.
Das Verfahren 300 kann dann Hinzufügen 316 der simulierten Sensordaten zu den ursprünglichen Sensordaten 302 beinhalten, um erweiterte Sensordaten zu erhalten. Es ist anzumerken, dass eine beliebige Anzahl von Objekten in ein Szenario eingefügt werden kann und entsprechende Sensordaten zu den ursprünglichen Sensordaten hinzugefügt werden können. Für LIDAR kann dies das Hinzufügen der Punktwolke für das Objektmodell zu der Punktwolke eines bestimmten Datenrahmens beinhalten, d. h. den Rahmen von Daten, die bei Schritten 306-312 analysiert wurden. Für RADAR können die Reflexionen von RADAR-Signalen, die bei Schritt 314 simuliert wurden, zu Reflexionen in der ursprünglichen Sensorausgabe für einen bestimmten Zeitschritt hinzugefügt werden. Für Bilddaten kann die Wiedergabe des Objektmodells über ein Bild überlagert oder zu einem 3D-Modell hinzugefügt werden, das aus Bildern für einen bestimmten Zeitschritt erhalten wurde.
Das Verfahren 300 kann ferner das Entfernen 318 von ursprünglichen Sensordaten beinhalten, die durch das Objektmodell verdeckt worden wären, wenn es vorhanden wäre. Ein Vorteil von RADAR ist, dass die Wellen sogar „durch“ Objekte (z. B. zwischen dem Boden und dem unteren Ende des Autos) hindurchlaufen können, sodass ein Objekt hinter einem anderen für eine RADAR-Vorrichtung nicht unbedingt verdeckt ist, wenn es für einen LIDAR oder eine Kamera verdeckt wäre (obwohl Fenster Sichtbarkeit durch Objekte bereitstellen können). Dementsprechend können diese Eigenschaften von RADAR-Wellen für RADAR-Daten simuliert werden, wenn bestimmt wird, ob ursprüngliche Daten tatsächlich verdeckt sind. In Fällen, wo mehrere Objekte hinzugefügt werden, können die ursprünglichen Daten, die durch jedes davon blockiert werden, bestimmt werden. Abschnitte von simulierten Daten für Objektmodelle, die durch andere hinzugefügte Objektmodelle verdeckt sind, können ebenfalls berechnet und entfernt werden. Alternativ kann das Simulieren des Erfassens eines hinzugefügten Objektmodells bei Schritt 314 mit mehreren Objektmodellen durchgeführt werden, deren relative Ausrichtung und Positionierung aus den Schritten 308 und 310 stammt. Auf diese Weise wird ein beliebiges Verdecken beim Simulieren des Erfassens der Gruppe von Objektmodellen in Betracht gezogen.
Dieser Prozess und die anderen Schritte des Verfahrens 300 können unter Bezugnahme auf die 4A und 4B und die 5A und 5B verstanden werden. Die erweiterten Sensordaten mit den gemäß Schritt 318 entfernten Daten können dann ausgegeben und zu Trainingszwecken oder für eine beliebige andere Anwendung, für die es vorteilhaft wäre, verwendet werden.
Wie in 4A gezeigt, beinhaltet ein typisches Fahrszenario eine Straße 400 mit einer Vielzahl von Fahrzeugen 402, die Regionen der Straße 400 belegen, und einen oder mehrere Bereiche 404 die nicht belegt sind. Ein Subjektfahrzeug 406, d. h. das Fahrzeug, welches das Szenario erfasst, befindet sich auf der Straße 400 und erfasst das Szenario, einschließlich der anderen Fahrzeuge 402, welche Sensoren, wie etwa Kameras 408a-408c, RADAR-Sensoren 410a-410b und einen LIDAR-Sensor 412 verwenden. Andere Sensoren, wie etwa Mikrofone, Ultraschallsensoren und dergleichen können ebenfalls verwendet werden.
In Bezug auf 5A und 5B kann ein Objektmodell 500 eines Motorradfahrers, der zwischen den Spuren fährt, zu dem nicht belegten Bereich 404 hinzugefügt werden. Andere beispielhafte Positionen beinhalten vor dem Subjektfahrzeug 406, sodass das Objektmodell 500 getroffen würde, falls es tatsächlich vorhanden wäre. Die simulierte Wahrnehmung eines Objektmodells 500 durch einen oder mehrere der Sensoren 408a-408c, 410b, 412 kann dann auf Grundlage von Modellen dieser Sensoren und den Stellen dieser Sensoren an dem Subjektfahrzeug 406 beruhen.
Wie in den 5A und 5B ersichtlich, ist das Objektmodell 500 zwischen einigen der Sensoren 408a-408c, 410b, 412 und einem der anderen Fahrzeuge 402 eingeschoben. Dementsprechend können Sensorausgaben, die dem verdeckten Fahrzeug entsprechen, auf die vorstehend beschriebene Weise aus den Sensorausgaben entfernt werden. In einigen Ausführungsformen können verdeckte Sensordaten innerhalb eines Kegels 502, der von einer Stelle eines Sensors (LIDAR-Sensor 412 in dem veranschaulichten Beispiel) ausgeht und das Objektmodell 500 begrenzt, ausgewertet werden, um Rechenanforderungen zu reduzieren. Wie in 5A gezeigt, kann der Kegel kegelförmig oder kegelstumpfförmig sein und kann derart bemessen sein, dass das Objektmodell 500 vollständig innerhalb des Kegels 502 liegt. Zum Beispiel kann der beinhaltete Winkel des Kegels 502 derart ausgewählt sein, dass der Kegel 502 das Objektmodell 500 an einem oder mehreren Punkten berührt, ohne dass Punkte des Objektmodells 500 außerhalb des Kegels 502 liegen.
Sensordaten, die Koordinaten innerhalb des Kegels 502 aufweisen und die ungefähr hinter dem Objekt liegen, können dann bewertet werden, um zu bestimmen, ob dieser Punkt bei vorhandenem Objektmodell 500 detektierbar wäre. Zum Beispiel kann in einer Ausführung zusätzlich zu dem Kegel 502 ein 3D-Zylinder um das Objekt definiert werden. Nur die Punkte, welche sich entweder innerhalb des Zylinders oder dahinter relativ zu dem Fahrzeug befinden, werden dann zur Entfernung ausgewertet.
Falls nicht, wird ein Punkt als nicht detektierbar befunden. Der Punkt kann dann aus den erweiterten Sensordaten entfernt werden. Wie nachstehend beschrieben kann das Objektmodell 500 als ein Satz von Dreiecken dargestellt sein. Ein Strahl, der von der Sensorstelle ausgeht zu einem Punkt in den Originalsensordaten, kann ausgewertet werden, um zu bestimmen, ob sich der Strahl mit einem dieser Dreiecke schneidet. Falls ja, kann der Punkt aus den erweiterten Sensordaten entfernt werden. Dieser Ansatz ist für LIDAR-Daten und zum Bestimmen nützlich, welche Pixel zur Verwendung mit einem 3D-Bild abgedeckt werden sollen, das aus Bildern oder einer Kombination aus einem oder mehreren Bildern und LIDAR-Daten generiert ist. Für RADAR-Daten kann eine Simulation einer Ausbreitung von RADAR-Wellen um das eingefügte Objektmodell durchgeführt werden, um zu bestimmen, ob Reflexionen aus den ursprünglichen Sensordaten übertragene Wellen empfangen würden und ob Reflexionen immer noch den Sensor erreichen könnten.
Unter Bezugnahme auf 6 ist das veranschaulichte Verfahren 600 eine detaillierte Anwendung des Verfahrens 300, die besonders für LIDAR-Sensordaten geeignet ist. Das Verfahren 600 kann für jeden LIDAR-Datenframe über einen Zeitraum ausgeführt werden. Wie vorstehend beschrieben kann der Standort eines Objektmodells für jede Wiederholung des Verfahrens 600 eingestellt werden, um ein stationäres Objekt zu simulieren oder um einen gewünschten Kurs für das Objektmodell zu simulieren.
Das Verfahren 600 kann das Empfangen 602 einer ursprünglichen LIDAR-Sensorausgabe auf dieselbe Weise beinhalten wie Schritt 302 des Verfahrens 300. Das Verfahren 600 kann ferner das Auswählen einer 2D-Position eines Objektmodells erweiterter Realität (augmented reality - AR) beinhalten. In einem typischen LIDAR-System sind zwei der Koordinatenachsen (X, Y) parallel zu der horizontalen Ebene des Fahrzeugs, z. B. eine Parallele zu einer flachen Fläche, die das Fahrzeug stützt. Dementsprechend beinhaltet Schritt 604 das Auswählen von X- und Y-Koordinaten (dx, dy) zum Platzieren des AR- (erweiterte Realität) Objektmodells. Wie vorstehend in Bezug auf den Schritt 308 angemerkt, kann dieser Prozess automatisiert werden oder manuell durchgeführt werden. Zum Beispiel können die Koordinaten dx, dy aus verfügbaren Räumen ausgewählt werden, die auf vorstehend in Bezug auf die Schritte 304-308 beschriebene Weise identifiziert wurden.
In Fällen, in denen das AR-Objektmodell nicht auf dem Boden platziert ist, können andere Parameter, wie etwa eine vertikale Position (dz) entlang der Z-Achse, und eine Ausrichtung von einem Benutzer empfangen oder automatisch ausgewählt werden, z. B. um ein fliegendes Objekt zu simulieren.
Das Verfahren 600 kann das Berechnen 606 eines Bereichs unter dem AR-Objekt beinhalten. Zum Beispiel kann dies das Identifizieren von Abmessungen eines Rechtecks beinhalten, innerhalb das alle der X- und Y-Koordinaten von Punkten auf dem AR-Objekt passen. Das Verfahren 600 kann dann das Bewerten 608 beinhalten, ob dieser Bereich ausreichend Punkte beinhaltet, um eine Ebene zu definieren. Konkreter, ob es ausreichend Punkte in der LIDAR-Punktwolke gibt, die X- und Y-Koordinaten innerhalb dieses Rechtecks aufweisen, das auf der 2D-Position zentriert ist, die bei Schritt 604 ausgewählt wurde.
Die Anzahl von Punkten, die ausreicht, um eine Ebene zu definieren, kann ein vorbestimmter Wert sein, der durch einen Entwickler vorgegeben ist. Die Anzahl, die ausreicht, ist von dem Ansatz abhängig, der verwendet wird, um die Ebene einzufügen. Ein beliebiger Ansatz zum Finden einer Ebene, um ein Punktearray anzunähern, kann verwendet werden, wie etwa der der wenigsten Quadrate, der RANSAC- (random sample consensus) Algorithmus, die Hough-Transformation oder ein anderer fachbekannter Ansatz. Zum Beispiel reichen drei Punkte aus, um eine Ebene zu definieren. Jedoch kann das Vielfache dieser Anzahl erforderlich sein, um Genauigkeit zu verbessern, wie etwa eine Anzahl von 6 bis 300.
Falls die Anzahl von Punkten nicht ausreicht, kann der Bereich schrittweise gemäß einer vorbestimmten Schrittgröße oder eines vorbestimmten Prozentsatzes vergrößert 610 werden, bis die Anzahl von Punkten als zum genauen Definieren der Ebene des Bereichs ausreichend befunden 608 wird.
Das Verfahren 600 kann dann das Drehen 612 des AR-Objektmodells derart beinhalten, dass es in Bezug auf die Ebene richtig ausgerichtet ist, die unter Verwendung des Bereichs, der bei Schritten 606-610 unter Verwendung einer beliebigen der vorstehend dargelegten Ebenendefinierungstechniken berechnet wurde, angenähert wurde. Insbesondere kann das AR-Objektmodell ein lokales Koordinatensystem definieren, das eine horizontale Ebene definiert. Eine Transformation des AR-Objektmodells kann derart angewendet werden, dass die horizontale Ebene parallel zu der Ebene des Bereichs aus Schritten 606-610 ist. Das AR-Objektmodell kann einen Bezugspunkt definieren, wie etwa einen Mittelpunkt in der lokalen horizontalen Ebene des Modells oder einen anderen vorbestimmten Punkt. Dieser Punkt kann bei Schritt 612 an der 2D-Position aus Schritt 604 positioniert werden.
Das Verfahren 600 kann ferner das Definieren 614 einer simulierten Punktwolke für das AR-Objekt beinhalten, das sich an der Position aus Schritt 604 und in der Ausrichtung aus Schritt 614 relativ zu dem Fahrzeug befindet, wenn die ursprüngliche LIDAR-Sensorausgabe erfasst wurde. Dies kann das Simulieren des Abtastens des AR-Objektmodells unter Verwendung der Punktdichte, Wellenlänge und anderen Eigenschaften des LIDAR-Sensormodells 112b und des Reflexionsvermögens und der Abmessungen des AR-Objektmodells (siehe vorstehende Beschreibung der Objektmodelle 114) beinhalten. Die Punkte auf der Punktewolke aus Schritt 614 können zu der ursprünglichen LIDAR-Sensorausgabe hinzugefügt 616 werden, um eine erweiterte Sensorausgabe zu erhalten.
Ein Dreiecknetz kann ebenfalls für das AR-Objektmodell definiert 618 werden. Das Dreiecknetz definiert Dreiecke, die als Eckpunkte Punkte auf der Fläche des AR-Objektmodells aufweisen. Diese Punkte können Punkte des eigentlichen AR-Objektmodells oder Punkte der Punktwolke aus Schritt 616 sein. Dieses Netz kann automatisch berechnet werden, wie etwa über einen Greedy-Flächentriangulationsalgorithmus oder einen anderen fachbekannten Ansatz.
Das Verfahren 600 kann ferner das Berechnen 619 eines Schattenkegels des AR-Objektmodells beinhalten. Wie vorstehend in Bezug auf das Verfahren 300 beschrieben kann dies das Definieren einer kegelstumpfförmigen Form beinhalten, die Punkte des AR-Objektmodells berührt, jedoch derart, dass keine Punkte des AR-Objektmodells außerhalb der kegelstumpfförmigen Form liegen. Bei Punkten der ursprünglichen LIDAR-Sensorausgabe 602 innerhalb des Schattenkegels kann das Verfahren das Durchführen 620 eines Strahl/Dreieck-Schnittpunkttests beinhalten. Konkreter, falls eine Linie, die sich von einer Stelle eines Sensors zu einem Punkt erstreckt, durch eines der Dreiecke des AR-Objektmodells verläuft, wird dieser Punkt aus der erweiterten Sensorausgabe entfernt 622.
Die 7A bis 7C veranschaulichen eine beispielhafte Verwendung des Verfahrens 600. 7A veranschaulicht die ursprüngliche LIDAR-Sensorausgabe. 7B veranschaulicht den Schattenkegel 700 eines AR-Objektmodells 702, der über die ursprünglichen LIDAR-Sensorausgabe überlagert ist. 7C veranschaulicht die letzte erweiterte Sensorausgabe in welcher eine simulierte Punktwolke für das Objektmodell 702 hinzugefügt wurde und Punkte in dem Schattenkegel 700 entfernt wurden.
In der vorstehenden Offenbarung wurde auf die beigefügten Zeichnungen Bezug genommen, die einen Teil davon bilden und in denen zur Veranschaulichung konkrete Umsetzungen gezeigt sind, in denen die Offenbarung ausgeführt sein kann. Es versteht sich, dass andere Umsetzungen verwendet werden können und strukturelle Änderungen vorgenommen werden können, ohne vom Umfang der vorliegenden Offenbarung abzuweichen. Bezugnahmen in der Beschreibung auf „eine Ausführungsform“, „ein Ausführungsbeispiel“ etc. geben an, dass die beschriebene Ausführungsform ein(e) bestimmte(s) Merkmal, Struktur oder Eigenschaft beinhalten kann, doch es muss nicht notwendigerweise jede Ausführungsform diese(s) bestimmte Merkmal, Struktur oder Eigenschaft beinhalten. Darüber hinaus beziehen sich derartige Formulierungen nicht unbedingt auf dieselbe Ausführungsform. Ferner sei darauf hingewiesen, dass, wenn ein(e) bestimmte(s) Merkmal, Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben ist, es im Bereich des Fachwissens des Fachmanns liegt, ein(e) derartige(s) Merkmal, Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen umzusetzen, ob dies nun ausdrücklich beschrieben ist oder nicht.
Umsetzungen der hier offenbarten Systeme, Vorrichtungen und Verfahren können einen Spezial- oder Universalcomputer umfassen oder verwenden, der Computerhardware beinhaltet, wie zum Beispiel einen oder mehrere Prozessoren und Systemspeicher, wie sie hier erörtert sind. Umsetzungen innerhalb des Umfangs der vorliegenden Offenbarung können zudem physische Datenträger und andere computerlesbare Medien zum Transportieren oder Speichern von computerausführbaren Anweisungen und/oder Datenstrukturen einschließen. Bei derartigen computerlesbaren Medien kann es sich um beliebige verfügbare Medien handeln, auf die durch ein Universal- oder Spezialcomputersystem zugegriffen werden kann. Bei computerlesbaren Medien, auf denen computerausführbare Anweisungen gespeichert werden, handelt es sich um Computerspeichermedien (-vorrichtungen). Bei computerlesbaren Medien, die computerausführbare Anweisungen transportieren, handelt es sich um Übertragungsmedien. Daher können Umsetzungen der Offenbarung beispielsweise und nicht einschränkend mindestens zwei deutlich unterschiedliche Arten von computerlesbaren Medien umfassen: Computerspeichermedien (-vorrichtungen) und Übertragungsmedien.
Computerspeichermedien (-vorrichtungen) beinhalten RAM, ROM, EEPROM, CD-ROM, Festkörperlaufwerke („SSDs“) (z. B. basierend auf RAM), Flash-Speicher, Phasenänderungsspeicher („PCM“), andere Speichertypen, andere optische Plattenspeicher, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder ein beliebiges anderes Medium, das verwendet werden kann, um die gewünschten Programmcodemittel in Form von computerausführbaren Anweisungen oder Datenstrukturen zu speichern, und auf das durch einen Universal- oder Spezialcomputer zugegriffen werden kann.
Eine Umsetzung der hier offenbarten Vorrichtungen, Systeme und Verfahren kann über ein Computernetzwerk kommunizieren. Ein „Netzwerk“ ist als eine oder mehrere Datenverbindungen definiert, die den Transport elektronischer Daten zwischen Computersystemen und/oder Modulen und/oder anderen elektronischen Vorrichtungen ermöglichen. Wenn Informationen über ein Netzwerk oder eine andere (entweder festverdrahtete, drahtlose oder eine Kombination aus festverdrahteter oder drahtloser) Kommunikationsverbindung an einen Computer übertragen oder diesem bereitgestellt werden, sieht der Computer die Verbindung korrekt als Übertragungsmedium an. Übertragungsmedien können ein Netzwerk und/oder Datenverbindungen beinhalten, die verwendet werden können, um gewünschte Programmcodemittel in der Form von computerausführbaren Anweisungen oder Datenstrukturen zu übertragen und auf die durch einen Universal- oder Spezialcomputer zugegriffen werden kann. Kombinationen aus den Vorstehenden sollten ebenfalls im Umfang computerlesbarer Medien beinhaltet sein.
Computerausführbare Anweisungen umfassen beispielsweise Anweisungen und Daten, die bei Ausführung an einem Prozessor einen Universalcomputer, Spezialcomputer oder eine Spezialverarbeitungsvorrichtung dazu veranlassen, eine bestimmte Funktion oder Gruppe von Funktionen durchzuführen. Die computerausführbaren Anweisungen können beispielsweise Binärdateien, Zwischenformatanweisungen, wie etwa Assemblersprache, oder sogar Quellcode sein. Obwohl der Gegenstand in für Strukturmerkmale und/oder methodische Handlungen spezifischer Sprache beschrieben wurde, versteht es sich, dass der in den beigefügten Patentansprüchen definierte Gegenstand nicht notwendigerweise auf die vorstehend beschriebenen Merkmale oder Handlungen beschränkt ist. Die beschriebenen Merkmale und Handlungen werden vielmehr als beispielhafte Formen der Umsetzung der Patentansprüche offenbart.
Der Fachmann wird verstehen, dass die Offenbarung in Network-Computing-Umgebungen mit vielen Arten von Computersystemauslegungen angewendet werden kann, einschließlich eines Armaturenbrett-Fahrzeugcomputers, PCs, Desktop-Computern, Laptops, Nachrichtenprozessoren, Handvorrichtungen, Multiprozessorsystemen, Unterhaltungselektronik auf Mikroprozessorbasis oder programmierbarer Unterhaltungselektronik, Netzwerk-PCs, Minicomputern, Mainframe-Computern, Mobiltelefonen, PDAs, Tablets, Pagern, Routern, Switches, verschiedenen Speichervorrichtungen und dergleichen. Die Offenbarung kann zudem in verteilten Systemumgebungen umgesetzt werden, in denen sowohl lokale Computersysteme als auch Remote-Computersysteme, die durch ein Netzwerk (entweder durch festverdrahtete Datenverbindungen, drahtlose Datenverbindungen oder durch eine Kombination aus festverdrahteten und drahtlosen Datenverbindungen) verbunden sind, Aufgaben ausführen. In einer verteilten Systemumgebung können sich Programmmodule sowohl in lokalen Speichervorrichtungen als auch in Remote-Speichervorrichtungen befinden.
Ferner können die hier beschriebenen Funktionen gegebenenfalls in einem oder mehreren des Folgenden durchgeführt werden: Hardware, Software, Firmware, digitalen Komponenten oder analogen Komponenten. Ein oder mehrere anwendungsspezifische integrierte Schaltkreise (application specific integrated circuits - ASICs) können zum Beispiel so programmiert sein, dass sie eines bzw. einen oder mehrere der hier beschriebenen Systeme und Vorgänge ausführen. Bestimmte Ausdrücke werden in der gesamten Beschreibung und den Patentansprüchen verwendet, um auf bestimmte Systemkomponenten Bezug zu nehmen. Der Fachmann wird zu schätzen wissen, dass auf Komponenten durch unterschiedliche Bezeichnungen Bezug genommen werden kann. In dieser Schrift soll nicht zwischen Komponenten unterschieden werden, die sich dem Namen nach unterscheiden, nicht jedoch von der Funktion her.
Es ist anzumerken, dass die vorstehend erörterten Sensorausführungsformen Computerhardware, -software, -firmware oder eine beliebige Kombination daraus umfassen können, um mindestens einen Teil ihrer Funktionen auszuführen. Ein Sensor kann zum Beispiel Computercode beinhalten, der dazu konfiguriert ist, in einem oder mehreren Prozessoren ausgeführt zu werden, und kann eine Hardware-Logikschaltung/elektrische Schaltung beinhalten, die durch den Computercode gesteuert wird. Diese beispielhaften Vorrichtungen sind hier zum Zwecke der Veranschaulichung bereitgestellt und sollen nicht einschränkend sein. Ausführungsformen der vorliegenden Offenbarung können in weiteren Arten von Vorrichtungen umgesetzt werden, wie es dem einschlägigen Fachmann bekannt ist. Mindestens einige Ausführungsformen der Offenbarung sind Computerprogrammprodukten zugeführt worden, die eine derartige Logik (z. B. in Form von Software) umfassen, die auf einem beliebigen computernutzbaren Medium gespeichert ist. Solche Software veranlasst bei Ausführung in einer oder mehreren Datenverarbeitungsvorrichtungen eine Vorrichtung dazu, wie hier beschrieben zu arbeiten.
Computerprogrammcode zum Ausführen von Vorgängen der vorliegenden Erfindung kann in jeder beliebigen Kombination aus einer oder mehreren Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie etwa Java, Smalltalk, C++ oder dergleichen, und herkömmlicher prozeduraler Programmiersprachen, wie etwa der „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben sein. Der Programmcode kann gänzlich auf einem Computersystem als eigenständiges Softwarepaket, auf einer eigenständigen Hardware-Einheit, teilweise auf einem Remote-Computer, der sich in einigem Abstand von dem Computer befindet, oder gänzlich auf einem Remote-Computer oder -Server ausgeführt werden. In letztgenanntem Fall kann der Remote-Computer durch eine beliebige Art von Netz mit dem Computer verbunden sein, einschließlich eines lokalen Netzes (local area network - LAN) oder eines Weitverkehrsnetzes (wide area network - WAN), oder die Verbindung kann mit einem externen Computer erfolgen (zum Beispiel durch das Internet unter Verwendung eines Internetdienstanbieters).
Die vorliegende Erfindung ist vorstehend unter Bezugnahme auf Veranschaulichungen durch Ablaufdiagramme und/oder Blockdiagramme von Verfahren, Einrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Veranschaulichungen durch Ablaufdiagramme und/oder Blockdiagramme und Kombinationen von Blöcken in den Veranschaulichungen durch Ablaufdiagramme und/oder Blockdiagrammen durch Computerprogrammanweisungen oder Code umgesetzt sein können. Diese Computerprogrammanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungseinrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die Anweisungen, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungseinrichtung ausgeführt werden, Mittel zum Umsetzen der Funktionen/Handlungen, die in dem Block oder den Blöcken des Ablaufdiagramms und/oder Blockdiagramms vorgegeben sind, erzeugen.
Diese Computerprogrammanweisungen können zudem in einem nichtflüchtigen computerlesbaren Medium gespeichert sein, das einen Computer oder eine andere programmierbare Datenverarbeitungseinrichtung dazu anleiten kann, auf bestimmte Art und Weise zu funktionieren, sodass die in dem computerlesbaren Medium gespeicherten Anweisungen einen Fertigungsartikel herstellen, der Anweisungsmittel beinhaltet, die die Funktion/Handlung, die in dem Block oder den Blöcken des Ablaufdiagramms und/oder Blockdiagramms vorgegeben ist, umsetzen.
Die Computerprogrammanweisungen können zudem auf einen Computer oder eine andere programmierbare Datenverarbeitungseinrichtung geladen sein, um zu veranlassen, dass eine Reihe von Verfahrensschritten auf dem Computer oder der anderen programmierbaren Einrichtung durchgeführt wird, um einen computerimplementierten Vorgang herzustellen, sodass die Anweisungen, die auf dem Computer oder der anderen programmierbaren Einrichtung ausgeführt werden, Vorgänge zum Umsetzen der Funktionen/Handlungen, die in dem Block oder den Blöcken des Ablaufdiagramms und/oder Blockdiagramms vorgegeben sind, bereitstellen.
Während vorstehend verschiedene Ausführungsformen der vorliegenden Offenbarung beschrieben wurden, versteht es sich, dass diese lediglich als Beispiele dienen und nicht als Einschränkung. Für den einschlägigen Fachmann ist ersichtlich, dass verschiedene Änderungen in Form und Detail daran vorgenommen werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen. Daher sollen die Breite und der Umfang der vorliegenden Offenbarung durch keine der vorstehend beschriebenen beispielhaften Ausführungsformen eingeschränkt werden, sondern sollen lediglich gemäß den folgenden Patentansprüchen und ihren Äquivalenten definiert sein. Die vorstehende Beschreibung wurde zum Zwecke der Veranschaulichung und Beschreibung dargelegt. Sie erhebt keinerlei Anspruch auf Vollständigkeit und soll die Offenbarung nicht auf die konkrete offenbarte Form beschränken. Viele Modifikationen und Variationen sind in Anbetracht der vorstehenden Lehren möglich. Ferner ist anzumerken, dass beliebige oder alle der vorangehend genannten alternativen Umsetzungen in einer beliebigen gewünschten Kombination verwendet werden können, um zusätzliche Hybridumsetzungen der Offenbarung zu bilden.

Claims

Verfahren, das Folgendes durch eine Rechenvorrichtung umfasst: Empfangen von Sensordaten von einer Steuerung eines Fahrzeugs; Identifizieren von verfügbarem Raum um das Fahrzeug in den Sensordaten; Platzieren eines Objektmodells an einer Stelle relativ zu dem Fahrzeug; Simulieren des Erfassens des Objektmodells, um simulierte Sensordaten zu erhalten; und Hinzufügen der simulierten Sensordaten zu den Sensordaten, um erweiterte Sensordaten zu erhalten.
Verfahren nach Anspruch 1, das Folgendes umfasst: Identifizieren, durch die Rechenvorrichtung, eines Abschnitts der Sensordaten, die aufgrund der Platzierung des Objektmodells an der relativen Stelle nicht detektierbar wären; und Entfernen, durch die Rechenvorrichtung, des Abschnitts der Sensordaten aus den erweiterten Sensordaten.
Verfahren nach Anspruch 2, das ferner Folgendes umfasst: Definieren, durch die Rechenvorrichtung, eines Schattenkegels des Objektmodells in Bezug auf eine Sensorstelle auf dem Fahrzeug; und Suchen, durch die Rechenvorrichtung, nach dem Abschnitt der Sensordaten, die nicht innerhalb des Schattenkegels detektierbar wären.
Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Identifizieren, durch die Rechenvorrichtung, eines Bereichs von verfügbarem Raum um die relative Stelle; Einfügen, durch die Rechenvorrichtung, einer Ebene in den Bereich; und Transformieren, durch die Rechenvorrichtung, des Objektmodells gemäß einer Orientierung der Ebene.
Verfahren nach Anspruch 4, das ferner Folgendes umfasst: Identifizieren, durch die Rechenvorrichtung, des Bereichs als durch das Objektmodell abgedeckt; Bestimmen, durch die Rechenvorrichtung, (a) dass der Bereich nicht genügend Datenpunkte der Sensordaten abdeckt, um die Ebene zu definieren; und als Reaktion auf das Bestimmen (a) das Ausdehnen, durch die Rechenvorrichtung, des Bereichs, bis der Bereich genügend Datenpunkte abdeckt, um die Ebene einzufügen.
Verfahren nach Anspruch 1, wobei das Identifizieren des verfügbaren Raums um das Fahrzeug in den Sensordaten Folgendes umfasst: Auswerten, durch die Rechenvorrichtung, einer Höhe, die mit Datenpunkten in den Sensordaten zusammenhängt; und Identifizieren, durch die Rechenvorrichtung, von Regionen, in welchen die Höhe, welche mit Datenpunkten zusammenhängt, niedriger ist als eine Schwellenwerthöhe, als der verfügbare Raum; wobei das Auswerten der Höhe, die mit Datenpunkten in den Sensordaten zusammenhängt, das Definieren, durch die Rechenvorrichtung, der Höhe in Bezug auf eine horizontale Ebene des Fahrzeugs umfasst.
Verfahren nach Anspruch 1, wobei die Sensordaten mindestens eines von LIDAR (light detection and ranging), RADAR (radio detection and ranging) und Bilddaten beinhaltet.
Verfahren nach Anspruch 1, das ferner das Verwenden der erweiterten Trainingsdaten umfasst, um mindestens eines der Folgenden durchzuführen: Testen, durch die Rechenvorrichtung, eines Detektionsalgorithmus; Testen, durch die Rechenvorrichtung, eines Steuerungsalgorithmus; Trainieren, durch die Rechenvorrichtung, eines maschinellen Lernmodells dazu, Hindernisse zu detektieren; und Trainieren, durch die Rechenvorrichtung, des maschinellen Lernmodells dazu, Objekte aus den Sensorausgaben zu entfernen
System, das eine oder mehrere Verarbeitungsvorrichtungen und eine oder mehrere Speichervorrichtungen umfasst, die an die eine oder mehreren Verarbeitungsvorrichtungen wirkgekoppelt sind, wobei die eine oder mehreren Speichervorrichtungen ausführbaren Code speichern, der dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Empfangen von Sensordaten von einer Steuerung eines Fahrzeugs, wobei die Sensordaten mindestens eines von LIDAR (light detection and ranging), RADAR (radio detection and ranging) und Bilddaten beinhalten; Identifizieren von verfügbarem Raum um das Fahrzeug in den Sensordaten; Platzieren eines Objektmodells an einer Stelle relativ zu dem Fahrzeug; Simulieren des Erfassens des Objektmodells, um simulierte Sensordaten zu erhalten; und Hinzufügen der simulierten Sensordaten zu den Sensordaten, um erweiterte Sensordaten zu erhalten.
System nach Anspruch 9, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Identifizieren eines Abschnitts der Sensordaten, die aufgrund der Platzierung des Objektmodells an der relativen Stelle nicht detektierbar wären; und Entfernen des Abschnitts der Sensordaten aus den erweiterten Sensordaten.
System nach Anspruch 10, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Definieren eines Schattenkegels des Objektmodells in Bezug auf eine Sensorstelle auf dem Fahrzeug; und Suchen nach dem Abschnitt der Sensordaten, die nicht innerhalb des Schattenkegels detektierbar wären.
System nach Anspruch 9, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Identifizieren eines Bereichs von verfügbarem Raum um die relative Stelle; Einfügen einer Ebene in den Bereich; und Transformieren des Objektmodells gemäß einer Orientierung der Ebene.
System nach Anspruch 12, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Identifizieren des Bereichs als durch das Objektmodell abgedeckt; Bestimmen (a) dass der Bereich nicht genügend Datenpunkte der Sensordaten abdeckt, um die Ebene zu definieren; und falls (a), Ausdehnen des Bereichs, bis der Bereich genügend Datenpunkte abdeckt, um die Ebene einzufügen.
System nach Anspruch 9, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Auswerten einer Höhe, die mit Datenpunkten in den Sensordaten zusammenhängt; und Identifizieren von Regionen, in welchen die Höhe, welche mit Datenpunkten zusammenhängt, niedriger ist als eine Schwellenwerthöhe, als der verfügbare Raum; wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zum Auswerten der Höhe, die mit Datenpunkten in den Sensordaten zusammenhängt, durch das Definieren der Höhe in Bezug auf eine horizontale Ebene des Fahrzeugs, zu veranlassen.
System nach Anspruch 9, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen dazu zu veranlassen, die erweiterten Sensordaten zu verwenden, um eines der Folgenden durchzuführen: Testen eines Detektionsalgorithmus; Testen eines Steuerungsalgorithmus; Trainieren eines maschinellen Lernmodells zum Detektieren von Hindernissen; und Trainieren des maschinellen Lernmodells zum Entfernen von Objekten aus den Sensorausgaben.