DE102018121019A1

DE102018121019A1 - Erweitern von realen sensoraufzeichnungen mit simulierten sensordaten

Info

Publication number: DE102018121019A1
Application number: DE102018121019.1A
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: CN109425855A; US11455565B2; US20190065637A1

Abstract

Es werden ursprüngliche Sensordaten von einem oder mehreren Sensoren eines Fahrzeugs empfangen. Ein freier Raum um das Fahrzeug wird gemäß den Sensordaten identifiziert, wie etwa durch Identifizieren von Regionen, in denen Datenpunkte eine Höhe unter einem Schwellenwert aufweisen. Ein Standort für ein Objektmodell wird aus dem freien Raum ausgewählt. Eine Ebene wird an Sensordaten um den Standort angepasst und das Obj ektmodell 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, die durch das Objektmodell verdeckt worden wären, werden aus den ursprünglichen Sensordaten entfernt. Die erweiterten Sensordaten können verwendet werden, um einen Steueralgorithmus zu validieren oder ein Modell zum maschinellen Lernen zu trainieren.

Description

ALLGEMEINER STAND DER TECHNIK
VERWANDTE ANMELDUNGEN
Diese Anmeldung ist mit der US-Anmeldung Nr. 15/693.203 , eingereicht am 31. August 2017, verwandt, deren Offenbarung hierin vollumfänglich durch Bezugnahme aufgenommen ist.
GEBIET DER ERFINDUNG
Diese Erfindung betrifft Simulieren von Erfassen eines Szenarios unter Verwendung von einem oder mehreren elektronischen Sensoren.
ALLGEMEINER STAND DER TECHNIK
Die Herausforderung beim Prüfen und Validieren von Fahrerunterstützungstechnologien und autonomen Fahrzeugen besteht in der großen Anzahl an Prüffällen und sehr seltenen Grenzfällen. Während eine große Vielzahl von Fällen während einem Prüfen in der realen Welt auftritt, bestehen bestimmte Szenarien, die in der realen Welt sehr selten und zu riskant sind, um sie auf einem Versuchsgelände auszuführen. Es werden üblicherweise detaillierte Simulationen verwendet, um diese Szenarien auszuprobieren. Aufgrund von einem Mangel an perfekten Sensormodellen und Verkehrsmodellen sind die aus diesen Simulationen generierten Daten zwar sehr realistisch, spiegeln jedoch immernoch nicht alle Unzulänglichkeiten in der realen Welt wider.
Das System und die Verfahren in dieser Schrift stellen einen verbesserten Ansatz zum Generieren von Szenarien aus aufgezeichneten Sensordaten durch Erweitern von diesen 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:

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 Prozessablaufdiagramm eines Verfahrens zum Hinzufügen einer simulierten Sensorausgabe für ein Objektmodell zu tatsächlichen Sensordaten gemäß einer Ausführungsform der vorliegenden Erfindung;
4A und 4B sind schematische Blockdiagramme eines unter Verwendung von tatsächlichen Sensoren erfassten Szenarios;
5A und 5B veranschaulichen eine Erweiterung der Sensordaten für 4A und 4B gemäß einer Ausführungsform der vorliegenden Erfindung;
6 ist ein Prozessablaufdiagramm eines Verfahrens zum Erweitern von LIDAR-Daten gemäß einem Objektmodell gemäß einer Ausführungsform der vorliegenden Erfindung; und
7A bis 7C sind Abbildungen, die 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 hosten kann, in der Daten zur Verwendung gemäß den hierin offenbarten Verfahren gespeichert sind, oder auf diese zugreifen kann. Insbesondere können in der Datenbank 104 Sensordaten 106 gespeichert sein, die von Sensoren eines Fahrzeugs während des Fahrens in einer tatsächlichen Umgebung empfangen werden. Die Sensordaten können eines oder mehrere von Folgenden einschließen: visuelle Daten 108a (z. B. die Ausgabe von einer oder mehreren Kameras für sichtbares Licht oder Infrarotkameras), LIDAR-(Light-Detection-and-Ranging-)Daten 108b, die durch einen LIDAR-Sensor des Fahrzeugs ausgegeben werden, RADAR-(Radio-Detection-and-Ranging-)Daten 108c, die durch einen RADAR-Sensor ausgegeben werden. 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 Zurücklegens eines Weges durch das Fahrzeug ausgegeben werden.
In der Datenbank 104 können außerdem ein oder mehrere Sensormodelle 110 gespeichert sein. Die Sensormodelle 110 definieren Daten, die ausreichend sind, um eine simulierte Wahrnehmung eines dreidimensionalen (3D-)Modells durch einen tatsächlichen Sensor zu ermöglichen. Beispielsweise kann ein Kameramodell 112a Daten definieren, die eine Verzerrung, eine Farbtransformation, eine Frame-Rate, eine Auflösung, einen Zoom, ein Sichtfeld, eine Ausrichtung oder andere Artefakte einer Kamera definieren, die eine Wahrnehmung der Szene beeinflussen würden.
Ein LIDAR-Modell 112b kann eine Abtastrate, eine Punktdichte, eine Abtastlaserwellenlänge, Strahleneigenschaften, eine Detektorempfindlichkeit, ein Sichtfeld usw. definieren. Ein RADAR-Sensormodell 112c kann Begrenzungen und Attribute eines RADAR-Systems definieren, z. B. eine Wellenlänge, eine Signalamplitude, eine Winkelabtastgeschwindigkeit, eine Antennenverstärkung, ein Sichtfeld usw. Wenn andere Arten von Sensordaten 106 vorhanden sind, können andere Arten von Sensormodellen 110 für diese Arten von Sensoren definiert sein. Beispielsweise kann das Sensormodell 110 für ein Mikrofon eine Verstärkung, ein Signal-Rausch-Verhältnis, ein Empfindlichkeitsprofil (Empfindlichkeit gegenüber Frequenz) und dergleichen beinhalten.
Diese generierten Daten können zu verschiedenen Zwecken verwendet werden: Trainieren eines tiefen neuronalen Netzwerks (siehe Abschnitt 17), Prüfen und Verifizieren von Algorithmen für automatisiertes Fahren im Bereich Wahrnehmung, Szenenverständnis, Objekterfassung, Einsatzplanung, Wegplanung und Steuerung. Diese Prüfungen können als Tests mit offener oder geschlossener Schleife ausgebildet sein.
Die Datenbank 104 kann ferner Objektmodelle 114 beinhalten. Die Objektmodelle 114 können 3D-Modelle für Objekte einschließen, die wahrscheinlich durch ein Fahrzeug aufgefunden werden, wie etwa andere Fahrzeuge 116a, Fußgänger 116b und andere Objekte 116c, wie etwa Tiere, Verunreinigungen und dergleichen. Die Objektmodelle 114 können unter Verwendung eines beliebigen im Fachgebiet bekannten 3D-Modellbildungsformats definiert sein. In einigen Ausführungsformen können die Objektmodelle 114 als eine Punktwolke, ein Netz aus Dreiecken oder andere Darstellungen der Konturen des Objekts dargestellt sein. Das Objektmodell 114 kann ferner Materialeigenschaften definieren, die für die zu dem Objektmodell analoge Erfassung der realen Welt durch einen oder mehrere Arten von Sensoren relevant sind. Beispielsweise können Attribute, wie etwa Farbe, Struktur, Reflektivität und dergleichen, zur Modellbildungserfassung durch eine Kamera für Punkte auf der Oberfläche des Objektmodells 114 angegeben sein. Zur Modellbildungserfassung durch einen LIDAR-Sensor kann das Objektmodell 114 eine Reflektivität für Punkte auf der Oberfläche des Objektmodells definieren. Zur Modellbildungserfassung durch einen RADAR-Sensor können Eigenschaften eine Reflektivität bei einer Wellenlänge einschließen, die gemäß dem Modell 112c des RADAR-Sensors emittiert wird.
In der Datenbank 104 kann ferner ein Modell zum maschinellen Lernen 118 gespeichert sein, das unter Verwendung von simulierten Sensordaten trainiert wird, die gemäß den in dieser Schrift offenbarten Verfahren generiert werden. Das Modell zum maschinellen Lernen 118 kann für einen beliebigen Zweck trainiert werden. Beispielsweise kann das Modell zum maschinellen Lernen trainiert werden, um Hindernisse zu erfassen, insbesondere Hindernisse, für welche eine Erfassung gemäß den in dieser Schrift offenbarten Verfahren simuliert wird. Bei dem Modell zum maschinellen Lernen 118 kann es sich um ein tiefes neuronales Netzwerk, Bayessches Netzwerk oder eine andere Art von Modell zum maschinellen Lernen handeln.
In einem weiteren Beispiel kann ein Modell zum maschinellen Lernen 118 trainiert werden, um die Konturen eines Standorts ohne Objekte zu schätzen, wenn Objekte während der Erfassung der Szene vorhanden waren. Beispielsweise kann eine Straße unter Verwendung von LIDAR erfasst werden, ohne dass Fahrzeuge auf dieser fahren oder an dieser geparkt sind. Eine beispielhafte Anwendung kann Folgendes beinhalten: Erhalten von Sensordaten von einer leeren Straße, Simulieren von Erfassen von Modellen von Fahrzeugen zusammen mit der leeren Straße gemäß den in dieser Schrift beschriebenen Verfahren und dann Trainieren des Modells zum maschinellen Lernen 118, um durch Entfernen von Punkten, die den hinzugefügten Fahrzeugen entsprechen, eine Punktwolke zu generieren, die der leeren Straße entspricht.
Das Serversystem 102 kann eine Trainingengine 120 ausführen. Die Trainingengine 120 kann ein Lokalisatormodul 122a beinhalten. Das Lokalisatormodul 122a kann programmiert sein, um Koordinaten in einer Region von einem Raum zu identifizieren, einschließlich Sensordaten, die nicht aktuell durch ein Hindernis belegt werden. Wie nachfolgend erörtert, kann dies Identifizieren einer Bodenebene beinhalten, z. B. einer Straße, einer Seitenwand, eines Parkplatzes oder einer anderen Oberfläche.
Die Trainingengine 120 kann ein Einsetzmodul 122b beinhalten. Das Einsetzmodul 122b wählt Standorte für ein oder mehrere Objektmodelle 114 in einer oder mehreren der nicht belegten Regionen aus, die durch das Lokalisatormodul 122a identifiziert wurden. In einigen Ausführungsformen kann der Standort manuell durch einen Benutzer ausgewählt werden, um ein erwünschtes Szenario zu erzeugen. In anderen Ausführungsformen kann ein Standort in einer oder mehreren der nicht belegten Regionen zufällig durch das Einsetzmodul 122b ausgewählt werden. Ein nicht zufällig 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 eine Erfassung eines eingesetzten Objektmodells 114 als auch Einstellungen von Sensordaten, die mit Anwesenheit des Objektmodells 114 zu berücksichtigen sind. Wie nachfolgend erörtert, kann dies Entfernen von Sensordaten beinhalten, die verdeckt wären, wenn die zu dem Objektmodell 114 analoge reale Welt tatsächlich vorhanden wäre.
Die Trainingengine 120 kann ein Trainingsmodul 122d ausführen, das ein Modell zum maschinellen Lernen 118 unter Verwendung von Sensordaten trainiert, die gemäß den in dieser Schrift offenbarten Verfahren modifiziert sind. Wie im Fachgebiet bekannt, ist eine große Menge an Trainingsdaten erforderlich, um ein Modell zum maschinellen Lernen zu trainieren. Dementsprechend können viele Hunderte oder Tausende von Sätzen von Sensordaten modifiziert und verwendet werden, um das Modell zum maschinellen Lernen 118 zu trainieren.
Unter Bezugnahme auf 1B kann das Modell zum maschinellen Lernen 118 verwendet werden, um eine Hinderniserfassung in dem veranschaulichten System 124 durchzuführen, das in ein Fahrzeug integriert sein kann, wie etwa ein autonomes oder von einem Menschen bedienten Fahrzeug. Beispielsweise kann das System 124 eine Steuerung 126 beinhalten, die in einem Fahrzeug aufgenommen ist. Das Fahrzeug kann ein beliebiges im Fachgebiet bekanntes Fahrzeug einschließen. Das Fahrzeug kann alle Strukturen und Merkmale eines beliebigen im Fachgebiet bekannten Fahrzeugs aufweisen, wozu Räder, ein an die Räder gekoppelter Antriebsstrang, ein an den Antriebsstrang gekoppelter Motor, ein Lenksystem, ein Bremssystem und andere in ein Fahrzeug einzuschließende Systeme gehören, die im Fachgebiet bekannt sind.
Wie hierin ausführlicher erörtert, kann die Steuerung 126 autonome Navigation und Kollisionsvermeidung durchführen. Insbesondere können eines oder mehrere von LIDAR-Daten, Bilddaten, Radar-Daten und eine oder mehrere Arten von Sensordaten analysiert werden, um Hindernisse zu identifizieren.
Die Steuerung 126 kann einen oder mehrere Bildströme von einer oder mehreren Abbildungsvorrichtungen 128 empfangen. Beispielsweise können eine oder mehrere Kameras an dem Fahrzeug angebracht sein und durch die Steuerung 126 empfangene Bildströme ausgeben. Die Steuerung 126 kann einen oder mehrere Audioströme von einem oder mehreren Mikrofonen 130 empfangen. Beispielsweise können ein oder mehrere Mikrofone oder Mikrofonarrays an dem Fahrzeug angebracht sein und von der Steuerung 126 empfangene Audioströme ausgeben. Die Mikrofone 130 können Richtmikrofone mit einer Empfindlichkeit, die mit dem Winkel variiert, einschließen.
In einigen Ausführungsformen kann das System 124 andere Sensoren 132 beinhalten, die an die Steuerung 126 gekoppelt sind, wie etwa einen oder mehrere von LIDAR-, RADAR-, SONAR- und Ultraschallsensoren oder dergleichen. Die Standorte und Ausrichtungen der Erfassungsvorrichtungen 128, 130, 132 können denen entsprechen, die in den Sensormodellen 110 modelliert sind, die verwendet werden, um das Modell zum maschinellen Lernen 118 zu trainieren.
Die Steuerung 126 kann ein Kollisionsvermeidungsmodul 134 ausführen, das Ausgaben von den Erfassungsvorrichtungen 128, 130, 132 empfängt, Hindernisse in den Ausgaben erfasst und Maßnahmen ergreift, um diese zu vermeiden. Das Kollisionsvermeidungsmodul 134 kann das Modell zum maschinellen Lernen 118 beinhalten, das unter Verwendung von modifizierten Sensordaten trainiert ist, die gemäß den in dieser Schrift beschriebenen Verfahren generiert wurden, oder als dieses ausgebildet sein. Bei dem Kollisionsvermeidungsmodul 134 kann es sich ferner um ein programmiertes Steuersystem handeln, das unter Verwendung von erweiterten Sensordaten abgestimmt ist oder geprüft wurde, die gemäß dem in dieser Schrift offenbarten Verfahren generiert wurden.
Das Kollisionsvermeidungsmodul 134 kann ein Hindernisidentifikationsmodul 136a beinhalten, das Ausgaben von den Erfassungsvorrichtungen 128, 130, 132 empfängt und eine Schätzung bezüglich des Standorts 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 Weges wahrscheinlich mit dem Fahrzeug kollidieren. Das Kollisionsvorhersagemodul 136b kann die Wahrscheinlichkeit einer Kollision mit durch das Hindernisidentifikationsmodul 136a identifizierten Objekten evaluieren.
Ein Entscheidungsmodul 136c kann dann eine Entscheidung zum Anhalten, Beschleunigen, Abbiegen usw. treffen, um den 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 von einem oder mehrerer Aktoren 138 steuern, welche die Richtung und Geschwindigkeit des Fahrzeugs steuern. Beispielsweise können die Aktoren 138 einen Lenkaktor 140a, einen Beschleunigungsaktor 140b und einen Bremsaktor 140c einschließen. Die Konfiguration 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 verwendet werden, um 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 schließt/schließen eine(n) oder mehrere Prozessoren oder Steuerungen ein, 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 (random access memory- RAM) 214) und/oder nichtflüchtigen Speicher (z. B. Festwertspeicher (read-only memory - 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, handelt es sich bei einer bestimmten Massenspeichervorrichtung um ein Festplattenlaufwerk 224. Zudem können verschiedene Laufwerke in der/den Massenspeichervorrichtung(en) 208 enthalten 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 schließt/schließen verschiedene Schnittstellen ein, 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 (local area networks - LANs), Weitverkehrsnetzen (wide area networks - 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 usw.), Tastaturen und dergleichen.
Der Bus 212 ermöglicht es 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 diskrete 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 hierin 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 Prüfen und Validieren von Steueralgorithmen oder anderen Arten von Systemen oder Verfahren verwendet werden. In einem weiteren Beispiel können die erweiterten Sensordaten verwendet werden, um einen Erfassungsalgorithmus zum Erfassen von Objekten unter Verwendung von Sensordaten zu prüfen oder zu validieren. Der Erfassungsalgorithmus kann einzeln oder in Kombination mit einem Steueralgorithmus geprüft werden, der Entscheidungen auf Grundlage von Ausgaben von dem Erfassungsalgorithmus fällt. Das Verfahren 300 kann Empfangen 302 von ursprünglichen Sensordaten beinhalten. Die ursprünglichen Sensordaten können eine Reihe von Sensorausgaben über einen Zeitraum einschließen, die von tatsächlichen Sensoren eines Fahrzeugs empfangen werden, während dieses einen Kurs zurücklegt. Die Sensordaten schließen somit Daten ein, die eine Sensorwahrnehmung von häufig beobachteten Strukturen angeben, wie etwa einem oder mehreren von Straßen, Gebäuden, anderen Fahrzeugen, Fußgängern, Tieren, Verunreinigungen usw.
Die Ausgabe von jedem Sensor beinhaltet eine Reihe von Datensätzen, wobei jeder Datensatz in der Reihe Ausgaben von dem Sensor zu einem Zeitpunkt oder für einen Zeitraum der Aktualisierungsrate des Sensors darstellt. Wenn mehrere Sensoren verwendet werden, schließen die ursprünglichen Sensordaten eine Reihe von Datensätzen für jeden Sensor ein, welche dieselbe oder unterschiedliche Aktualisierungsraten oder Abtastraten aufweisen können.
Das Verfahren 300 kann Extrahieren 304 eines gefahrenen Kurses des Fahrzeugs beinhalten.
Dies kann Empfangen einer Reihe von Koordinaten des GPS (globalen Positioniersystems) von den ursprünglichen Sensordaten 302 beinhalten. Die GPS-Koordinaten können mit einem Zeitstempel versehen oder mit einer bekannten Abtastrate aufgezeichnet sein, sodass der jeder Koordinate zugeordnete Zeitpunkt bekannt ist und mit Ausgaben anderer Sensoren zu demselben Zeitpunkt in Bezug gesetzt werden kann (d. h. am nächsten an dem Zeitpunkt sind, zu dem die Abtast-/Aktualisierungsraten ungleich oder nicht ausgerichtet sind). Die Extraktion des Kurses kann außerdem durch einen Algorithmus definiert sein, der Daten von einem oder mehreren Sensoren im Zeitverlauf verwendet, um den gefahrenen Kurs zu definieren. Bekannte Konzepte für diesen Zweck sind z. B. Weg- und Geschwindigkeitsmessung, SLAM oder Structure from Motion.
Das Verfahren 300 kann ferner Extrahieren 306 eines verfügbaren Raums im Zeitverlauf beinhalten. Dies kann Identifizieren von Abschnitten einer Umgebung des Fahrzeugs beinhalten, welche die ursprünglichen Sensordaten erfasst haben, die nicht belegt sind. Beispielsweise können Punkte in einer Punktwolke für LIDAR-Daten in der Ausrichtung des Fahrzeugs sein oder dazu in Bezug gesetzt werden. Dementsprechend ist eine Höhe eines Punkts bezogen auf die vertikale Achse des Fahrzeugs bekannt. Diese Punkte, die über einer spezifischen Schwellenhöhe liegen, können als potentielle Höhe bestimmt werden; Punkte unter diesem Schwellenwert können jedoch als für eine Bodenebene wahrscheinlich bestimmt werden, z. B. einen Straßenbelag. Bereiche von Punkten unter dem Schwellenwert können dann identifiziert werden. Cluster zusammenhängender Punkte, die einen Bereich umfassen, der keine Punkte über dem Schwellenwert beinhaltet, können als nicht belegte Bereiche bestimmt werden. In weiteren Beispielen ist ein freier Raum nicht auf ein Bodenniveau eingeschränkt. Beispielweise könnte(n) ein Vogel, eine Drohne, ein überhängender Zweig, Fahrzeuge oder Menschen, die aufgrund eines Unfalls in Bewegung sind, oder eine andere Struktur in einem freiem Raum über dem Boden angeordnet sein. Dementsprechend kann ein verfügbarer Raum als ein Volumen von Raum ohne Punkte über dem Schwellenwert identifiziert werden. Der Schwellenwert kann anwendungsabhängig sein, z. B. höher sein, wenn 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 anstatt eine zu der Schwerkraftrichtung senkrechte Ebene definiert sein kann. Wenn das Fahrzeug auf einem Hügel positioniert ist, werden auf diese Weise Punkte auf dem Hügel nicht inkorrekt als über dem Schwellenwert liegend interpretiert.
Insofern als die Sensordaten einer Reihe von Datensätzen beinhalten, kann der verfügbare Raum aus einem einzelnen Datensatz oder einer Vielzahl von aufeinanderfolgenden Datensätzen extrahiert werden.
Im Fall von visuellen Daten können Farben und Strukturen eines Bildes analysiert werden, um den verfügbaren Raum zu identifizieren, wie etwa die Farbe und Struktur von Beton, Asphalt, Kies oder einer anderen Fahroberfläche, die als ein freier Raum identifiziert werden kann. Abschnitte eines Bildes, die Objekte beinhalten, 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-Abbildungssystem Bilder von mehreren Kameras verwenden kann, um ein 3D-Modell aus einem oder mehreren 2D-Bildern zu konstruieren, kann die 3D-Position dieser verfügbaren Räume aus dem 3D-Modell bestimmt werden. In einigen Ausführungsformen kann eine Sensorfusion verwendet werden, um Erkenntnisse von LIDAR-Punkten zu kombinieren, um eine tatsächliche 3D-Szene zu erzeugen, die mit dem Bildmaterial kombiniert wird. In solchen Ausführungsformen kann der freie Raum auf Grundlage der Farbe einer Region der 3D-Szene (Asphalt, Beton usw.) und der Höhe der Punkte in der Szene identifiziert werden, wie vorangehend in Bezug auf die LIDAR-Daten dargelegt.
Das Verfahren 300 kann Auswählen 308 eines verfügbaren Raums aus den bei Schritt 306 identifizierten beinhalten. Beispielsweise können die GPS-Koordinaten des Kurses dem Koordinatensystem einer Punktwolke eines LIDAR-Systems oder 3D-Abbildungssystem zugeordnet werden. Ein verfügbarer Raum kann aufgrund des Raums ausgewählt werden, der auf dem Kurs liegt. In vielen Anwendungen kann Schritt 308 manuell ausgeführt werden und kann einfach Empfangen einer Benutzerauswahl eines verfügbaren Raums beinhalten, der bei Schritt 306 identifiziert wurde. Beispielsweise können Sensordaten graphisch so dargestellt werden, dass die verfügbaren Räume hervorgehoben und Benutzerschnittstellenelementen zugeordnet sind, die ausgewählt werden können, um eine Benutzerauswahl eines verfügbaren Raums zu empfangen.
Das Verfahren 300 kann ferner Auswählen 310 eines Objektmodells beinhalten. Beispielsweise kann für den bei Schritt 308 ausgewählten Raum ein Objektmodell automatisch ausgewählt werden, das eine Grundfläche kleiner oder gleich dem Raum aufweist. Dementsprechend können die Objektmodelle 114 Abmessungen einer Grundfläche des Objektmodells beinhalten, um diesen Vergleich zu ermöglichen. Was Schritt 308 angeht, so kann Schritt 310 ebenfalls manuell durch Empfangen einer Benutzerauswahl eines Objektmodells 114 aus einer Sammlung von mehreren Objektmodellen 114 durchgeführt werden.
Schritt 312-318 können wiederholt für verschiedene Datensätze entsprechend verschiedenen Zeitschritten durchgeführt werden, um eine Reihe von erweiterten Datensätzen bereitzustellen, die verwendet werden können, um das Modell zum maschinellen Lernen zu trainieren. Schritt 312-318 können außerdem für Ausgaben mehrerer Sensoren durchgeführt werden.
Das Verfahren 300 kann ferner Ausrichten 312 des Objektmodells 114 in dem Koordinatensystem der ursprünglichen Sensordaten beinhalten. Beispielsweise kann für den bei Schritt 308 ausgewählten Bereich eine Ebene an die Punkte in dem Datensatz angepasst werden, in dem der ausgewählte Bereich identifiziert wurde. Das Objekt kann dann derart ausgerichtet werden, dass eine Basis des Objektmodells parallel zu dieser Ebene, z. B. der Unterseite der Reifen eines Fahrzeugs, dem Fuß eines Modells eines Fußgängers oder Tieres usw., ist und entsprechend angeordnet ist. Der Standort des Objektmodells 114 in dem ausgewählten Raum kann ausgewählt werden, um auf dem Kurs aus Schritt 304 zu liegen, sodass das Fahrzeug mit dem Objektmodell 114 zusammengestoßen wäre, wenn dieses tatsächlich vorhanden wäre.
Wie vorangehend angemerkt, können die ursprünglichen Sensordaten mehrere Datensätze an mehreren Zeitpunkten einschließen. Dementsprechend kann Schritt 312 für mehrere Datensätze durchgeführt werden, sodass das Objekt in Bezug auf das Koordinatensystem jedes Datensatzes auf konsistente Weise mit entweder einem stationären Objekt oder einem Objekt ausgerichtet 312 ist, das sich mit seiner zur realen Welt analogen Geschwindigkeit, z. B. Schrittgeschwindigkeit für einen Fußgänger, Fahrgeschwindigkeiten für ein Fahrzeug usw., konsistent bewegt. Beispielsweise kann das Koordinatensystem jedes Datensatzes wie vorangehend angemerkt mit den GPS-Koordinaten des Fahrzeugs in Bezug gesetzt werden. Dementsprechend kann die GPS-Koordinate des Fahrzeugs, die jedem Datensatz zeitlich am nächsten ist (oder für jeden Datensatz durch Interpolierung angenähert wird) verwendet werden, um die Ausrichtung des Objektmodells von einem Datensatz zu dem nächsten zu transformieren, um ein stationäres Objekt oder ein Objekt zu simulieren, das sich gemäß einem erwünschten Kurs bezogen auf den Kurs des Fahrzeugs bewegt.
Das Verfahren 300 kann dann Generieren 314 einer simulierten Sensorausgabe beinhalten, die eine Wahrnehmung des Objektmodells von einem Blickwinkel eines Sensors des Fahrzeugs simuliert. Dies kann Verwenden des entsprechenden Sensormodells 110 beinhalten, um eine Wahrnehmung des Objektmodells an dem Standort und der Ausrichtung aus Schritt 312 zu simulieren. Beispielsweise kann für LIDAR eine Punktwolke generiert werden, die der Oberfläche des Objektmodells entspricht, wobei die Dichte der Punkte und die Reflektivität gemäß dem Sensormodell 112b des LIDAR-Sensors bestimmt werden.
In einem weiteren Beispiel kann ein Rendern des Objektmodells an dessen Standort und Ausrichtung aus Schritt 312 generiert 314 werden. Die Technik, mit der dies durchgeführt wird, kann Verwenden einer beliebigen im Fachgebiet bekannten Computeranimationstechnik beinhalten, wie etwa die, die häufig zum Hinzufügen von computergenerierten Bildern für Film und Fernsehen herangezogen wird. Insbesondere kann die Beleuchtung der ursprünglichen Szene angenähert werden, um eine Beleuchtung des Objektmodells 114 zu simulieren und ein realistisches Rendern bereitzustellen. Außerdem kann die 3D-Umgebung (einschließlich lokaler Leuchten) verwendet werden, um klar definierte Schatten zu erzeugen. Beispielweise können 3D-Daten aus LIDAR-Punktwolken und Kameradaten verwendet werden, um Strukturen zu erfassen und Schatten zu berechnen, die durch solche Strukturen sowie das Objektmodell geworfen würden. Standorte von Leuchten und Strukturen, die Schatten werfen können, können außerdem aus vorbestehenden 3D-Karten einer Region erhalten werden.
In noch einem weiteren Beispiel kann eine Reflexion und Erfassung einer Funkwelle von 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 an 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 Hinzufügen der Punktwolke für das Objektmodell zu der Punktwolke eines gegebenen Datenframes beinhalten, d.h. des bei Schritt 306-312 analysierten Datenframes. Für RADAR können die Reflexionen von RADAR-Signalen, die bei Schritt 314 simuliert werden, zu Reflexionen der ursprünglichen Sensorausgabe für einen gegebenen Zeitschritt hinzugefügt werden. Für Bilddaten kann das Rendern des Objektmodells ein Bild überlagern oder zu einem 3D-Modell hinzugefügt werden, das von Bildern für einen gegebenen Zeitschritt erhalten wurde.
Das Verfahren 300 kann ferner Entfernen 318 von ursprünglichen Sensordaten beinhalten, die durch das Objektmodell verdeckt worden wären, wenn dieses vorhanden wäre. Ein Vorteil von RADAR besteht darin, dass die Wellen sogar „durch“ Objekte (z. B. zwischen den Boden und das untere Ende des Autos) geleitet werden können, sodass ein Objekt hinter einem anderen für eine RADAR-Vorrichtung nicht notwendigerweise verdeckt ist, wie dies für LIDAR oder eine Kamera der Fall wäre (auch wenn Fenster Sichtbarkeit durch Objekte bereitstellen können). Dementsprechend können diese Eigenschaften von RADAR-Wellen für RADAR-Daten beim Bestimmen, ob ursprüngliche Daten tatsächlich verdeckt sind, simuliert werden. In Fällen, in denen mehrere Objekte hinzugefügt werden, können die ursprünglichen Daten, die durch jedes verdeckt 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 bei Schritt 314 Simulieren von Erfassen eines hinzugefügten Objektmodells mit mehreren Objektmodellen durchgeführt werden, die ihre relative Ausrichtung und Positionierung aus Schritt 308 und 310 erhalten haben. Auf diese Weise kann jegliche Verdeckung bei der Simulation vom Erfassen der Gruppe von Objektmodellen berücksichtigt werden.
Dieser Prozess und die anderen Schritte des Verfahrens 300 können in Bezug auf 4A und 4B und 5A und 5B nachvollzogen werden. Die erweiterten Sensordaten mit den gemäß Schritt 318 entfernten Daten können dann ausgegeben und zu Trainingszwecken oder eine beliebige andere Anwendung verwendet werden, für die sie von Vorteil sein können.
Wie in 4A gezeigt, beinhaltet ein übliches 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 Prüffahrzeug 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, unter Verwendung von Sensoren, wie etwa Kameras 408a-408c, RADAR-Sensoren 410a-410b und eines LIDAR-Sensors 412. Andere Sensoren können ebenfalls verwendet werden, wie etwa Mikrofone, Ultraschallsensoren und dergleichen.
In Bezug auf 5A und 5B kann in dem veranschaulichten Beispiel ein Objektmodell 500 eines Motorradfahrers zu dem nicht belegten Bereich 404 hinzugefügt werden, der zwischen zwei Spuren fährt. Andere beispielhafte Positionen beinhalten vor dem Prüffahrzeug 406, sodass das Objektmodell 500 getroffen würde, wenn es tatsächlich vorhanden wäre. Eine simulierte Wahrnehmung des Objektmodells 500 durch einen oder mehrere der Sensoren 408a-408c, 410b, 412 kann dann auf Grundlage von Modellen dieser Sensoren und der Stellen dieser Sensoren an dem Prüffahrzeug 406 durchgeführt werden.
Wie in 5A und 5B ersichtlich, ist das Objektmodell 500 zwischen einigen der Sensoren 408a-408c, 410b, 412 und einem der anderen Fahrzeuge 402 eingefügt. Dementsprechend können Sensorausgaben, die dem verdeckten Fahrzeug entsprechen, auf die vorangehend beschriebene Weise aus den Sensorausgaben entfernt werden. In einigen Ausführungsformen können verdeckte Sensordaten in einem Kegel 502 evaluiert werden, der an einer Stelle eines Sensors (des LIDAR-Sensors 412 in dem veranschaulichten Beispiel) seinen Ursprung hat und das Objektmodell 500 begrenzt, um den Rechenaufwand 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 in dem Kegel 502 liegt. Beispielsweise kann der eingeschlossene Winkel des Kegels 502 derart ausgewählt werden, dass der Kegel 502 an einem oder mehreren Punkten tangential zu dem Objektmodell 500 ist, wobei keine Punkte des Objektmodells 500 außerhalb des Kegels 502 liegen.
Sensordaten, die Koordinaten in dem Kegel 502 aufweisen und die ungefähr hinter dem Objekt liegen, können dann evaluiert werden, um zu bestimmen, ob dieser Punkt mit dem vorhandenen Objektmodell 500 erfasst werden könnte. Beispielweise kann in einer Umsetzung zusätzlich zu dem Kegel 502 ein 3D-Zylinder um das Objekt definiert werden. Lediglich die Punkte, die sich entweder in dem Zylinder oder hinter diesem bezogen auf das Fahrzeug liegen, werden dann zum Entfernen evaluiert.
Wenn nicht, wird erkannt, dass ein Punkt nicht erfasst werden kann. Der Punkt kann dann aus den erweiterten Sensordaten entfernt werden. Wie nachfolgend beschrieben, kann das Objektmodell 500 als ein Satz von Dreiecken dargestellt werden. Ein Strahl, der von der Sensorstelle zu einem Punkt in den ursprünglichen Sensordaten verläuft, kann dann evaluiert werden, um zu bestimmen, ob der Strahl eines dieser Dreiecke schneidet. Wenn dies der Fall ist, kann der Punkt aus den erweiterten Sensordaten gelöscht werden. Dieser Ansatz ist für LIDAR-Daten und zum Bestimmen nützlich, welche Pixel zur Verwendung mit einem 3D-Bild abgedeckt werden müssen, das aus Bildern oder einer Kombination von einem oder mehreren Bildern und LIDAR-Daten generiert wurde. Für RADAR-Daten kann eine Simulation einer Ausbreitung von RADAR-Wellen um das eingesetzte Objektmodell durchgeführt werden, um zu bestimmen, ob Reflexionen von den ursprünglichen Sensordaten übertragene Wellen empfangen würden und ob Reflexionen dennoch den Sensor erreichen könnten.
Unter Bezugnahme auf 6 handelt es sich bei dem veranschaulichten Verfahren 600 um eine detailliertere Anwendung des Verfahrens 300, die für LIDAR-Sensordaten besonders geeignet ist. Das Verfahren 600 kann für jeden LIDAR-Datenframe über einen Zeitraum ausgeführt werden. Wie vorangehend beschrieben, kann der Standort eines Objektmodell für jede Iteration des Verfahrens 600 eingestellt werden, um ein stationäres Objekt zu simulieren oder um einen erwünschten Kurs für das Objektmodell zu simulieren.
Das Verfahren 600 kann Empfangen 602 einer ursprünglichen LIDAR-Sensorausgabe auf dieselbe Weise wie Schritt 302 des Verfahrens 300 beinhalten. Das Verfahren 600 kann ferner Auswählen einer 2D-Position eines Objektmodells mit erweiterter Realität (augmented reality - AR) beinhalten. In einem üblichen LIDAR System sind zwei der Koordinatenachsen (x, y) parallel zu der horizontalen Ebene des Fahrzeugs, z. B. parallel zu einer flachen Oberfläche, die das Fahrzeug stützt. Dementsprechend beinhaltet Schritt 604 Auswählen von x- und y-Koordinaten (dx, dy) zur Platzierung des AR-Objektmodells (Objektmodells mit erweiterter Realität). Wie vorangehend in Bezug auf Schritt 308 angemerkt, kann dieser Prozess automatisiert sein oder manuell durchgeführt werden. Beispielsweise können die Koordinaten dx, dy aus verfügbaren Räumen ausgewählt werden, die auf die vorangehend in Bezug auf Schritt 304-308 beschriebene Weise identifiziert wurden.
In Fällen, in denen das AR-Objektmodell nicht auf dem Boden platziert ist, können andere Parameter von einem Benutzer empfangen oder automatisch ausgewählt werden, wie etwa eine vertikale Position (dz) an der z-Achse und eine Ausrichtung, um z. B. ein Objekt in der Luft zu simulieren.
Das Verfahren 600 kann Berechnen 606 eines Bereichs unter dem AR-Objekt beinhalten. Dies kann beispielsweise Identifizieren von Abmessungen eines Rechtecks beinhalten, in die alle der x- und y-Koordinaten von Punkten an dem AR-Objekt passen. Das Verfahren 600 kann dann Evaluierten 608, ob dieser Bereich ausreichend Punkte beinhaltet, um eine Ebene zu definieren, beinhalten. Insbesondere, ob ausreichend Punkte in der LIDAR-Punktwolke vorhanden sind, die x- und y-Koordinaten in diesem Rechteck aufweisen, die zentriert auf der 2D-Position sind, die bei Schritt 604 ausgewählt wurde.
Die Anzahl an Punkten, die ausreichend ist, um eine Ebene zu definieren, kann ein vorbestimmter Wert sein, der durch einen Entwickler angegeben ist. Die ausreichende Anzahl ist von dem Ansatz abhängig, der verwendet wird, um die Ebene anzupassen. Ein beliebiger Ansatz zum Finden einer Ebene, um ein Punktearray anzunähern, kann verwendet werden, wie etwa der der kleinsten Quadrate, der RANSAC-(Random-Sample-Consensus-)Algorithmus, die Hough-Transformation oder ein anderer im Fachgebiet bekannter Ansatz. Beispielsweise sind drei Punkte ausreichend, um eine Ebene zu definieren. Ein Vielfaches dieser Anzahl kann jedoch erforderlich sein, um die Genauigkeit zu verbessern, wie etwa eine Anzahl zwischen 6 und 300.
Wenn die Anzahl an Punkten nicht ausreichend ist, kann der Bereich gemäß eines vorbestimmten Inkrementbetrags oder -anteils inkrementell vergrößert 610 werden, bis die Anzahl an Punkten als ausreichend befunden 608 wird, um die Ebene des Bereichs akkurat zu definieren.
Das Verfahren 600 kann dann Rotieren 612 des AR-Objektmodells beinhalten, sodass dieses in Bezug auf eine Ebene angemessen ausgerichtet ist, die unter Verwendung des bei Schritt 606-610 berechneten Bereichs unter Verwendung einer beliebigen der vorangehend dargelegten Ebenendefinierungstechniken angenähert wurde. Insbesondere kann das AR-Objektmodell ein lokales Koordinatensystem definieren, das eine horizontale Ebene definiert. Eine Transformation zu dem AR-Objektmodell kann angewendet werden, sodass die horizontale Ebene parallel zu der Ebene des Bereichs aus Schritt 606-610 ist. Das AR-Objektmodell kann einen Bezugspunkt definieren, wie etwa einen Mittelpunkt in der lokalen horizontalen Ebene des Modells oder einen anderen vordefinierten Punkt. Dieser Punkt kann bei Schritt 612 an der 2D-Position aus Schritt 604 positioniert werden.
Das Verfahren 600 kann ferner Definieren 614 einer simulierten Punktwolke für das AR-Objekt beinhalten, die an der Position aus Schritt 604 und in der Ausrichtung aus Schritt 614 bezogen auf das Fahrzeug angeordnet ist, wenn die ursprüngliche LIDAR-Sensorausgabe erfasst wurde. Dies kann Simulieren eines Abtastens des AR-Objektmodells unter Verwendung der Punktdichte, der Wellenlänge und von anderen Eigenschaften des LIDAR-Sensormodells 112b und der Reflektivität und Abmessungen des AR-Objektmodells (siehe vorangehende Beschreibung der Objektmodelle 114) beinhalten. Die Punkte der Punktwolke aus Schritt 614 können zu der ursprünglichen LIDAR-Sensorausgabe hinzugefügt 616 werden, um eine erweiterte Sensorausgabe zu erhalten.
Ein Dreiecksnetz kann ebenfalls für das AR-Objektmodell definiert 618 werden. Das Dreiecksnetz definiert Dreiecke, die Punkte auf der Oberfläche des AR-Objektmodells als Vertices haben. Bei diesen Punkten kann es sich um Punkte des eigentlichen AR-Objektmodells oder um Punkte der Punktwolke aus Schritt 616 handeln. Dieses Netz kann automatisch berechnet werden, wie etwa ein komplexer DGM-Triangulationsalgorithmus oder ein anderer auf dem Fachgebiet bekannter Ansatz.
Das Verfahren 600 kann ferner Berechnen 619 eines Schattenkegels des AR-Objektmodells beinhalten. Wie vorangehend in Bezug auf Verfahren 300 beschrieben, kann dies Definieren einer Kegelstumpfform beinhalten, die tangential zu Punkten des AR-Objektmodells ist, jedoch derart, dass keine Punkte des AR-Objektmodells außerhalb der Kegelstumpfform liegen. Für Punkte der ursprünglichen LIDAR-Sensorausgabe 602 in dem Schattenkegel kann das Verfahren Durchführen 620 eines Strahlendreiecksschnitttests beinhalten. Wenn eine Linie, die sich von einer Stelle eines Sensors zu einem Punkt erstreckt, eines der Dreiecke des AR-Objektmodells durchläuft, kann insbesondere dieser Punkt aus der erweiterten Sensorausgabe entfernt 622 werden.
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 die ursprüngliche LIDAR-Sensorausgabe überlagert. 7C veranschaulicht die endgültige erweiterte Sensorausgabe, in der eine simulierte Punktwolke für das Objektmodell 702 hinzugefügt 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 Schutzumfang der vorliegenden Offenbarung abzuweichen. Bezugnahmen in der Beschreibung auf „eine Ausführungsform“, „ein Ausführungsbeispiel“ usw. geben an, dass die beschriebene Ausführungsform ein(e) bestimmte(s) Merkmal, Struktur oder Eigenschaft beinhalten kann; jede Ausführungsform muss jedoch nicht notwendigerweise diese(s) bestimmte Merkmal, Struktur oder Eigenschaft beinhalten. Darüber hinaus beziehen sich solche Formulierungen nicht notwendigerweise 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 wird, es im Bereich des Fachwissens des Fachmanns liegt, diese(s) Merkmal, Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen umzusetzen, ob dies nun ausdrücklich beschrieben ist oder nicht.
Umsetzungen der hierin 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 Schutzumfangs der vorliegenden Offenbarung können zudem physische und andere computerlesbare Medien zum Transportieren oder Speichern von computerausführbaren Anweisungen und/oder Datenstrukturen beinhalten. 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 zumindest zwei deutlich unterschiedliche Arten von computerlesbaren Medien umfassen: Computerspeichermedien (-vorrichtungen) und Übertragungsmedien.
Zu Computerspeichermedien (-vorrichtungen) gehören RAM, ROM, EEPROM, CD-ROM, Festkörperlaufwerke (solid state drives - „SSDs“) (z. B. auf Grundlage von RAM), Flash-Speicher, Phasenänderungsspeicher (phase-change memory - „PCM“), andere Speicherarten, andere optische Plattenspeicher, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder ein beliebiges anderes Medium, das dazu verwendet werden kann, gewünschte 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 verdrahtete, drahtlose oder eine Kombination aus verdrahteter oder drahtloser) Kommunikationsverbindung einem Computer bereitgestellt oder auf diesen übertragen 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 Form von computerausführbaren Anweisungen oder Datenstrukturen zu transportieren und auf die durch einen Universal- oder Spezialcomputer zugegriffen werden kann. Kombinationen aus dem Vorstehenden sollten ebenfalls im Schutzumfang computerlesbarer Medien enthalten sein.
Computerausführbare Anweisungen umfassen zum Beispiel Anweisungen und Daten, die bei Ausführung auf 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 zum Beispiel Binärdateien, Zwischenformatanweisungen, wie etwa Assemblersprache, oder auch 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.
Für den Fachmann versteht es sich, dass die Offenbarung in Netzwerkcomputerumgebungen mithilfe vieler Arten von Computersystemkonfigurationen angewendet werden kann, die einen Armaturenbrett-Fahrzeugcomputer, PCs, Desktop-Computer, Laptops, Nachrichtenprozessoren, Handgeräte, Multiprozessorsysteme, Unterhaltungselektronik auf Mikroprozessorbasis oder programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputer, Großcomputer, Mobiltelefone, PDAs, Tablets, Pager, Router, Switches, verschiedene Speichervorrichtungen und dergleichen beinhalten. 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 verdrahteten und drahtlosen Datenverbindungen) verbunden sind, Aufgaben ausführen. In einer Umgebung mit verteilten Systemen können sich Programmmodule sowohl in lokalen Speichervorrichtungen als auch in Fernspeichervorrichtungen befinden.
Ferner können die hier beschriebenen Funktionen gegebenenfalls in einem oder mehreren der Folgenden ausgefü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 Begriffe werden in der gesamten Beschreibung und den Patentansprüchen verwendet, um auf bestimmte Systemkomponenten Bezug zu nehmen. Der Fachmann wird verstehen, 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 zumindest 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. Zumindest einige Ausführungsformen der Offenbarung wurden Computerprogrammprodukten zugeführt, die eine solche Logik (z. B. in Form von Software) umfassen, die auf einem beliebigen computernutzbaren Medium gespeichert ist. Derartige Software veranlasst bei Ausführung in einer oder mehreren Datenverarbeitungsvorrichtungen eine Vorrichtung dazu, wie hierin 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 kann bzw. 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, welche 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 Prozess herzustellen, sodass die Anweisungen, die auf dem Computer oder der anderen programmierbaren Einrichtung ausgeführt werden, Prozesse 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 Schutzumfang der Offenbarung abzuweichen. Daher sollen die Breite und der Schutzumfang 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.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 15693203 [0001]

Claims

Verfahren, das Folgendes durch eine Rechenvorrichtung umfasst: Empfangen einer ursprünglichen Punktwolke von einem LIDAR-(Light-Detection-And-Ranging-)Sensor einer Steuerung eines Fahrzeugs; Identifizieren eines verfügbaren Raums in der ursprünglichen Punktwolke; Platzieren eines Objektmodells an einem Standort in dem verfügbaren Raum; und Erhalten einer erweiterten Punktwolke durch Modellieren von Erfassen des Objektmodells durch den LIDAR-Sensor und Hinzufügen einer simulierten Punktwolke zu der ursprünglichen Punktwolke.
Verfahren nach Anspruch 1, ferner umfassend: Identifizieren von verdeckten Punkten der ursprünglichen Punktwolke durch die Rechenvorrichtung, sodass das Objektmodell zwischen den verdeckten Punkten und dem LIDAR-Sensor positioniert sein würde; und Entfernen der verdeckten Punkte aus der Punktwolke durch die Rechenvorrichtung.
Verfahren nach Anspruch 2, ferner umfassend: Definieren eines Schattenkegels des Objektmodells in Bezug auf eine Stelle des LIDAR-Sensors an dem Fahrzeug durch die Rechenvorrichtung; Definieren einer Dreiecksnetzversion des Objektmodells durch die Rechenvorrichtung; Suchen nach den verdeckten Punkten durch die Rechenvorrichtung lediglich in dem Schattenkegel; und Identifizieren der verdeckten Punkte durch die Rechenvorrichtung als derart angeordnet, dass ein Strahl, der sich von jedem Punkt der verdeckten Punkte zu der Stelle des LIDAR-Sensors erstreckt, zumindest ein Dreieck des Dreiecknetzes schneidet.
Verfahren nach Anspruch 1, ferner umfassend: Identifizieren eines zweidimensionalen Bereichs verfügbaren Raums um den relativen Standort durch die Rechenvorrichtung; Anpassen einer Ebene an Punkte der ursprünglichen Punktwolke in dem Bereich durch die Rechenvorrichtung; und Transformieren des Objektmodells gemäß einer Ausrichtung der Ebene durch die Rechenvorrichtung.
Verfahren nach Anspruch 4, ferner umfassend: Identifizieren des Bereichs als durch das Objektmodell abgedeckt; Bestimmen (a), dass der Bereich Punkte der ursprünglichen Punktwolke abdeckt, die nicht ausreichend sind, um die Ebene zu definieren; und Erweitern des Bereichs als Reaktion auf Bestimmen (a), bis der Bereich ausreichend Punkte der Punktwolke abdeckt, um der Ebene zu entsprechen.
Verfahren nach Anspruch 1, wobei das Identifizieren des verfügbaren Raums um das Fahrzeug in den Sensordaten Folgendes umfasst: Evaluieren einer Z-Koordinate von X-, Y- und X-Koordinaten, die jeden Punkt der ursprünglichen Punktwolke definieren; und Identifizieren derjenigen Regionen als den verfügbaren Raum, in denen die Z-Koordinate von Punkten in der ursprünglichen Punktwolke in den Regionen unter einer Schwellenhöhe liegen; wobei die Z-Koordinaten der ursprünglichen Punktwolke senkrecht zu einer horizontalen Ebene des Fahrzeugs gemessen werden.
Verfahren nach Anspruch 1, ferner umfassend Prüfen von zumindest einem von einem Steueralgorithmus und einem Erfassungsalgorithmus gemäß den erweiterten Sensordaten.
Verfahren nach Anspruch 1, ferner umfassend Verwenden der erweiterten Trainingsdaten durch die Rechenvorrichtung, um zumindest eines von Folgendem durchzuführen: Trainieren eines Modells zum maschinellen Lernen, um Hindernisse gemäß den erweiterten Trainingsdaten zu erfassen; Trainieren des Modells zum maschinellen Lernen, um Objekte gemäß den erweiterten Trainingsdaten aus den LIDAR-Sensordaten zu entfernen.
System, umfassend eine oder mehrere Verarbeitungsvorrichtungen und eine oder mehrere Speichervorrichtungen, die an der eine oder mehreren Verarbeitungsvorrichtungen wirkverbunden 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 einer ursprünglichen Punktwolke von einem LIDAR-(Light-Detection-And-Ranging-)Sensor einer Steuerung eines Fahrzeugs; Identifizieren eines verfügbaren Raums in der ursprünglichen Punktwolke; Platzieren eines Objektmodells an einem Standort in dem verfügbaren Raum; und Erhalten einer erweiterten Punktwolke durch Modellieren von Erfassen des Objektmodells durch den LIDAR-Sensor und Hinzufügen einer simulierten Punktwolke zu der ursprünglichen Punktwolke.
System nach Anspruch 9, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Identifizieren von verdeckten Punkten der ursprünglichen Punktwolke, sodass das Objektmodell zwischen den verdeckten Punkten und dem LIDAR-Sensor positioniert sein würde; und Entfernen der verdeckten Punkte aus der Punktwolke.
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 Stelle des LIDAR-Sensors an dem Fahrzeug; Definieren einer Dreiecksnetzversion des Objektmodells; Suchen nach den verdeckten Punkten lediglich in dem Schattenkegel; und Identifizieren der verdeckten Punkte als derart angeordnet, dass ein Strahl, der sich von jedem Punkt der verdeckten Punkte zu der Stelle des LIDAR-Sensors erstreckt, zumindest ein Dreieck des Dreiecknetzes schneidet.
System nach Anspruch 9, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Identifizieren eines zweidimensionalen Bereichs verfügbaren Raums um den relativen Standort; Anpassen einer Ebene an Punkte der ursprünglichen Punktwolke in dem Bereich; und Transformieren des Objektmodells gemäß einer Ausrichtung 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; Evaluieren (a), ob der Bereich nicht ausreichend Punkte der ursprünglichen Punktwolke abdeckt, um die Ebene zu definieren; und, wenn (a), Erweitern des Bereichs, bis der Bereich ausreichend Punkte der Punktwolke abdeckt, um der Ebene zu entsprechen.
System nach Anspruch 9, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen dazu zu veranlassen, den verfügbaren Raum um das Fahrzeug in den Sensordaten durch Folgendes zu identifizieren: Evaluieren einer Z-Koordinate von X-, Y- und X-Koordinaten, die jeden Punkt der ursprünglichen Punktwolke definieren; und, Identifizieren derjenigen Regionen als den verfügbaren Raum, in denen die Z-Koordinate von Punkten in der ursprünglichen Punktwolke in den Regionen unter einer Schwellenhöhe liegen; wobei die Z-Koordinaten der ursprünglichen Punktwolke senkrecht zu einer horizontalen Ebene des Fahrzeugs gemessen werden.
System nach Anspruch 9, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen dazu zu veranlassen, die erweiterten Sensordaten zum zumindest einem von Folgendem zu verwenden: Prüfen eines Steueralgorithmus; Prüfen eines Erfassungsalgorithmus; Trainieren eines Modells zum maschinellen Lernen, um eine Hinderniserfassung durchzuführen; und, Trainieren des Modells zum maschinellen Lernen, um Objekte gemäß den erweiterten Trainingsdaten aus den LIDAR-Sensordaten zu entfernen.