DE102016119129A1

DE102016119129A1 - Prüfstand zur Fahrspurgrenzenerfassung in virtueller Fahrumgebung

Info

Publication number: DE102016119129A1
Application number: DE102016119129.9A
Authority: DE
Inventors: Ashley Elizabeth Micks; Venkatapathi Raju Nallapa; Brielle Reiff; Vidya Nariyambut murali; Sneha Kadetotad
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-10-16
Filing date: 2016-10-07
Publication date: 2017-04-20
Also published as: US20170109458A1; RU2016140057A; GB2544634A; GB201617252D0; CN106598695A; MX2016013343A

Abstract

Verfahren und Gerät in Zusammenhang mit einem Prüfstand für Fahrspurgrenzenerfassung in einer virtuellen Fahrumgebung werden bereitgestellt. Ein Verfahren kann involvieren, dass durch ein Prozessor eine virtuelle Fahrumgebung erzeugt wird, die eine oder mehrere Fahrspuren, ein virtuelles Fahrzeug und einen oder mehrere virtuelle Sensoren, die auf dem virtuellen Fahrzeug installiert sind, die konfiguriert sind, um simulierte Daten zu erzeugen, während das virtuelle Fahrzeug innerhalb der virtuellen Umgebung durchquert, umfasst. Das Verfahren kann auch das Ausführen eines Algorithmus zum Verarbeiten der simulierten Daten involvieren, um die eine oder mehreren Fahrspuren zu erfassen. Das Verfahren kann ferner das Aufzeichnen einer Ausgabe des Algorithmus involvieren. Das Verfahren kann zusätzlich das Kommentieren der simulierten Daten mit der Ausgabe des Algorithmus involvieren.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung betrifft im Allgemeinen Fahrzeugsysteme und insbesondere einen Prüfstand zum Bereitstellen einer Test- und Prüfumgebung zum Entwickeln, Trainieren und Nachweisen von Algorithmen zum Erfassen von Fahrspurgrenzen in einer Fahrumgebung.
STAND DER TECHNIK
Im Allgemeinen ist es zwingend, über einen gut nachgewiesenen Algorithmus zu verfügen, um Sensordaten auszulegen, um Funktionalitäten, wie zum Beispiel Fahrerunterstützung, Steuerung von Fahrzeugdynamik und/oder autonomes Fahren bereitzustellen, ermöglichen oder anderswie zu unterstützen. Insbesondere sind Algorithmen zum Erfassen von Fahrspurgrenzen entscheidend. Derzeit verlässt man sich auf Real-World-Sensordaten und Ground-Truth-Daten zum Entwickeln, Trainieren, Testen und Nachweisen solcher Algorithmen. Es ist jedoch hinsichtlich der Zeit, der Kosten und Ressourcen aufwändig, eine nutzbringende Menge an Real-World-Daten und Ground-Truth-Daten zu erfassen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Nicht einschränkende und nicht erschöpfende Ausführungsformen der vorliegenden Offenbarung werden unter Bezugnahme auf die folgenden Figuren beschrieben, wobei gleiche Bezugszeichen auf gleiche Teile in den diversen Figuren verweisen, wenn nichts anderes angegeben ist.
1 ist eine Skizze, die eine beispielhafte Umgebung abbildet, in der beispielhafte Ausführungsformen der vorliegenden Offenbarung umgesetzt werden können.
2 ist ein Blockschaltbild, das ein beispielhaftes Gerät in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung abbildet.
3 ist eine Skizze, die eine Ausführungsform von Sensordaten zeigt, die mit einem oder mehreren Kommentaren in Übereinstimmung mit der vorliegenden Offenbarung gekennzeichnet sind.
4 ist ein Flussdiagramm eines beispielhaften Prozesses in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung.
5 ist ein Flussdiagramm eines anderen beispielhaften Prozesses in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung.
AUSFÜHRLICHE BESCHREIBUNG
In der folgenden ausführlichen Beschreibung wird auf die begleitenden Zeichnungen Bezug genommen, die fester Bestandteil der Beschreibung sind und in welchen beispielhaft spezifische Ausführungsformen gezeigt sind, in welchen die Offenbarung praktisch umgesetzt werden kann. Diese Ausführungsformen sind in ausführlichem Detail beschrieben, um es dem Fachmann zu erlauben, die hier offenbarten Konzepte umzusetzen, und es ist klar, dass Änderungen an den diversen offenbarten Ausführungsformen erfolgen und andere Ausführungsformen verwendet werden können, ohne vom Geltungsbereich der vorliegenden Offenbarung abzuweichen. Die folgende ausführliche Beschreibung darf daher nicht in einem einschränkenden Sinn gesehen werden.
Bei der Entwicklung von Algorithmen zur Fahrspurgrenzenerfassung, um Fahrspurgrenzen mit einer Vielfalt von Markierungen und ohne Markierungen zu erfassen, sind diverse Sätze von Sensordaten erforderlich, um Fahrspurgrenzen-Erfassungsalgorithmen und zusätzliche stromabwärtige Funktionen, die mit den Algorithmen assoziiert sind, zu trainieren, entwickeln, testen und nachzuweisen. Gewöhnlich sind jedoch beträchtliche Finanzen, Zeit und Ressourcen erforderlich, um Real-World-Sensordaten zu erfassen. Um zum Beispiel Real-World-Sensordaten zu erfassen, müssen Sensoren physisch auf ein Fahrzeug installiert werden und tatsächliche Fahrten müssen auf diversen Straßentypen und für diverse Verkehrsbedingungen ausgeführt werden, damit die Sensoren Sensordaten für jedes Szenario sammeln. Zusätzlich tendieren Umgebungsvariablen, wie zum Beispiel Wetter, Temperatur, Wind, Lichtverhältnisse und andere mit dem Wetter zusammenhängende Faktoren dazu, die Anzahl von Sensordatensätzen, die gesammelt werden muss, um mehrere Größenordnungen zu erhöhen. Im Allgemeinen benötigt man Sensordaten von Tausenden Meilen Straße, um einen Fahrspurgrenzen-Erfassungsalgorithmus zu entwickeln, und daher sind beträchtliche Mengen an Zeit, Geld und Ressourcen erforderlich, um solche Daten zu erfassen.
Die Szenarien werden ferner komplizierter gemacht und die zu sammelnden Sensordaten noch umfassender, wenn unterschiedliche Fahrzeugtypen (wie zum Beispiel unterschiedliche Marken/Modelle) mit unterschiedlichen Arten von Sensoren, die an unterschiedlichen Lagen des Fahrzeugs vorgesehen sind, in Betracht gezogen werden. Ferner können sich Merkmale eines bestimmten Fahrzeugs sowie Merkmale der diversen Sensoren, die darauf installiert sind, ändern oder mit der Zeit unter anderem aufgrund von Faktoren wie Altern oder Ansammeln von zurückgelegten Kilometern abweichen. Mit anderen Worten kann ein Fahrspurgrenzen-Erfassungsalgorithmus, der für ein neues Fahrzeug mit niedrigem Kilometerstand entwickelt und trainiert wird, nicht so effektiv oder präzis sein, nachdem das Fahrzeug einige Jahre in Betrieb war.
Ferner ergeben nicht alle Arten von Sensoren Daten in gegenseitig kompatiblen Formaten. Signifikante Bemühungen sind folglich für das Post-Processing der massiven Menge Real-World-Sensordaten nach dem Erfassen in ein Format, das von einem Fahrspurgrenzen-Erfassungsalgorithmus verwendet werden kann, erforderlich. Zusätzlich ist es beim Entwickeln von Algorithmen, die eingebettete überwachte integrierte Lernfunktionen haben, erforderlich, einen solchen Algorithmus mit tatsächlichen Fahrspurgrenzeninformationen zu versorgen, die hier „Ground-Truth-Daten“ genannt werden, so dass der Algorithmus seine eigene Fahrspurgrenzenbezeichnung mit wahren oder als richtig bekannten Fahrspurgrenzenlagen vergleichen kann, wodurch die Erfassungsfähigkeit des Algorithmus durch maschinelles Lernen verbessert wird. Dieses Erfordernis, die Ground-Truth-Daten zu erhalten, verschlimmert die Last des Verwendens von Real-World-Daten zum Entwickeln von Fahrspurgrenzen-Erfassungsalgorithmen.
Die vorliegende Offenbarung stellt eine Lösung zum Bewältigen der Schwierigkeiten und Verringern der Kosten des Erfassens von Sensordaten bereit, die für einen Fahrspurgrenzen-Erfassungsalgorithmus erforderlich sind, indem die Sensordaten unter Verwenden einer virtuellen Umgebung erzeugt werden. Die Lösung ermöglicht das Erzeugen von Ground-Truth-Daten mit relativer Einfachheit zum Selbsttraining des Algorithmus. Beim Erfassen von Sensordaten können diverse Szenarien, Bedingungen und Parameter, wie oben erwähnt, leicht virtuell in der virtuellen Umgebung eingerichtet werden, und ein virtuelles Fahrzeug, das mit virtuellen Sensoren ausgestattet ist, kann die virtuelle Umgebung bei einer Simulation durchqueren oder in ihr fahren und virtuell die Sensordaten sammeln (das heißt durch Simulation erzeugen), die für den Fahrspurgrenzen-Erfassungsalgorithmus erforderlich sind. Die virtuelle Umgebung, das virtuelle Fahrzeug und die virtuellen Sensoren werden modelliert, um der Real-World-Umgebung, dem Real-World-Fahrzeug und den Real-World-Sensoren weitgehend zu entsprechen, so dass die durch Simulation erzeugten virtuellen Sensordaten im Wesentlichen dieselben Informationen darstellen, wie die von dem Real-World-Sensor in der Real-World-Umgebung gesammelten. Ground-Truth-Fahrspurgrenzendaten sind leicht verfügbar, da sie als Teil der virtuellen Umgebung definiert sind.
1 veranschaulicht eine beispielhafte Umgebung 100, die eine virtuelle Umgebung ist, in der beispielhafte Ausführungsformen der vorliegenden Offenbarung umgesetzt werden können. In der beispielhaften Umgebung 100 kann eine Straßenoberfläche 105 konzipiert sein, um entweder Einbahn- oder Kraftfahrzeuggegenverkehr darauf zu erlauben. Der Verkehr in jede Richtung kann eine oder mehrere Fahrspuren 115 haben. Die Straßenoberfläche 105 kann mit einer oder mehreren Linien, wie zum Beispiel mit einer Linie 110 und einer Linie 120, als Fahrspurmarkierungen versehen sein, um eine Fahrspur 115 auf einer Straßenoberfläche 105 zu identifizieren oder anderswie zu bezeichnen. Bei einigen Ausführungsformen kann die Straßenoberfläche 105 andere Markierungen als Fahrspurmarkierungen aufweisen, wie zum Beispiel eine Mehrzahl von Oberflächenreflektoren 130. Die Linie 110 und/oder 120 können durchgehend, unterbrochen oder in einem anderen Muster vorliegen und können aus irgendeiner Farbe und irgendeiner Textur bestehen. Zu veranschaulichendem Zweck und ohne Einschränkung des Geltungsbereichs der vorliegenden Offenbarung ist in 1 die Linie 110 als eine durchgehende Linie gezeigt und die Linie 120 ist als eine unterbrochene Linie gezeigt. Bei einigen Ausführungsformen kann die Straßenoberfläche 105 andere Arten von Markierungen haben, wie zum Beispiel ein Pfeilzeichen 140 oder andere Symbole oder anderen Text, die/der auf die Straßenoberfläche 105 gemalt oder auf ihr angeordnet sind/ist. Bei einigen Ausführungsformen können eine oder mehrere oder alle Arten von Markierungen und Linien, die oben erwähnt sind, auf der Straßenoberfläche 105 fehlen, um bestimmte Arten von Straßenoberflächen zu simulieren, wie zum Beispiel Landstraßen, Schotterstraßen, ungepflasterte Straßen, Privatstraßen und Straßen, die mit Schutt, Schlamm oder Schnee bedeckt sind.
Bei einigen Ausführungsformen kann die Straßenoberfläche 105 mit einer oder mehreren Straßenstrukturen versehen sein, wie zum Beispiel mit Verkehrstrennelementen, die eine Fahrspur von einer anderen Fahrspur trennen. Bei einigen Ausführungsformen können eine oder mehrere Strukturen am Straßenrand, wie zum Beispiel Straßenrandstreifen, Schutzschienen oder Kurvenschutzschienen 150, entlang der Straßenoberfläche 105 in eine Richtung parallel zu dem Kraftfahrzeugverkehr auf einer oder beiden Seiten der Straßenoberfläche 105 vorgesehen sein. Bei einigen Ausführungsformen können Objekte, wie zum Beispiel Verkehrsschilder 160, kommerzielle Schilder oder Reklametafeln, ebenfalls entlang der Straßenoberfläche 105 in einer Richtung parallel zu dem Kraftfahrzeugverkehr vorgesehen sein. Verkehrsschilder oder andere Schilder können auch oberhalb der Straßenoberfläche 105 vorgesehen sein, wo der Kraftfahrzeugverkehr nicht beeinflusst wird.
Bei einigen Ausführungsformen können Gegenstände, wie zum Beispiel Büsche, Bäume oder andere Pflanzen 170, und andere Strukturen, wie zum Beispiel Lampenständer, Leitungsmasten, Strommasten oder Gebäude, entlang der Straßenoberfläche 105 in eine Richtung parallel zu dem Kraftfahrzeugverkehr vorgesehen sein.
Ein virtuelles Fahrzeug mit einem oder mehreren virtuellen Sensoren darauf installiert kann in der Umgebung 100 zum Erzeugen von Sensordaten verwendet werden. Ein Fahrzeug 190, wie in 1 veranschaulicht, kann zum Beispiel die Umgebung 100 durch Fahren auf der Straßenoberfläche 105 innerhalb der Fahrspur 115 durchqueren. Ein oder mehrere Sensoren, wie zum Beispiel die Sensoren 191, 192 und 193, können auf das Fahrzeug 190 installiert sein und verwendet werden, während das Fahrzeug 190 auf der Straßenoberfläche 105 durchquert, um die Umgebung 100 durch Erzeugen bestimmter Sensordaten gemäß spezifischen Merkmalen jedes der Sensoren 191, 192 und 193 zu erzeugen. Die Sensordaten können aufgezeichnet und später beim Entwickeln eines Fahrspurgrenzen-Erfassungsalgorithmus, einer Software-Vorgehensweise, die programmiert wird, um Fahrspurgrenzen der einen oder mehreren Fahrspuren 115 innerhalb der Umgebung 100 zu identifizieren oder anderswie zu bestimmen, verwendet werden. Die Sensoren 191, 192 und 193, die auf dem Fahrzeug 190 installiert sind, können zum Beispiel die Umgebung 100 durch Identifizieren und/oder Aufzeichnen bestimmter Merkmale einiger oder aller Objekte, Strukturen, Markierungen und Linien, die in der Umgebung 100 wie oben erwähnt vorhanden sind, darunter die Linie 110 und 120, Oberflächenreflektoren 130, Markierungen oder Text 140, Straßenrandstreifen oder Schutzschienen 150, Schilder 160 sowie Bäume oder andere Pflanzen 170, charakterisieren. Zusätzlich können die Sensoren 191, 192 und 193, die auf dem Fahrzeug 190 installiert sind, auch andere Fahrzeuge, die in der Umgebung 100 gegenwärtig sind, die sich entweder in dieselbe oder in die entgegengesetzte Richtung des Fahrzeugs 190 bewegen, wie zum Beispiel die Fahrzeuge 181, 182 und 183, wie in 1 veranschaulicht, charakterisieren und aufzeichnen. Sensordaten, die der Charakterisierung anderer Fahrzeuge, wie zum Beispiel der Fahrzeuge 181, 182 und 183, entsprechen, können von dem Fahrspurgrenzen-Erfassungsalgorithmus verwendet werden, um beim Identifizieren oder anderswie Bestimmen der Fahrspurgrenzen zu helfen.
Der Ansatz, den die vorliegende Offenbarung heranzieht, um eine kostengünstige und effiziente Lösung zum Erfassen von Sensordaten auszuführen, erfolgt im Wesentlichen durch Umwandeln von Real-World-Elementen und Objekten, die in 1 veranschaulicht sind, in Elemente und Objekte eines virtuellen Raums, sowie das Durchqueren des Sensoren tragenden Fahrzeugs und die Charakterisierung der Umgebung. Jedes Element, das in 1 abgebildet ist, wird nämlich modelliert, um ein tatsächliches Objekt in der realen Welt darzustellen, und kann auch ein virtuelles Objekt in einem virtuellen Raum darstellen. Im Allgemeinen wird ein solches System, das die Umwandlung von realer Welt zu virtuellem Raum sowie die Erzeugung virtueller Sensordaten ausführt, durch Verwenden einer Rechenvorrichtung oder eines oder mehrerer Prozessoren verwirklicht.
2 veranschaulicht einen beispielhaften Fahrspurgrenzen-Erfassungsprüfstand 200, in dem beispielhafte Ausführungsformen der vorliegenden Offenbarung umgesetzt werden können. Der Fahrspurgrenzen-Erfassungsprüfstand 200 kann eine oder mehrere Simulationen ausführen, um Sensordaten 250 zu erzeugen, die zum Entwickeln, Testen und/oder Training diverser Fahrspurgrenzen-Erfassungsalgorithmen geeignet sind. Der Fahrspurgrenzen-Erfassungsprüfstand 200 kann auf irgendeine geeignete Art konfiguriert werden, um einen solchen Zweck zu erfüllen. Der Fahrspurgrenzen-Erfassungsprüfstand 200 kann zum Beispiel als Hardware, Software oder irgendeine Kombination davon verkörpert werden.
Bei einigen Ausführungsformen kann der Fahrspurgrenzen-Erfassungsprüfstand 200 Computerhardware und Computersoftware aufweisen. Die Computerhardware des Fahrspurgrenzen-Erfassungsprüfstands 200 kann einen oder mehrere Prozessoren 202, Speicher 290, eine Benutzeroberfläche 204, andere Hardware 206, wie zum Beispiel ein feldprogrammierbares Gate-Array (FPGA) oder eine Grafikverarbeitungseinheit (GPU) oder dergleichen, oder eine Kombination oder Subkombination davon aufweisen. Der Speicher 290 kann betrieblich mit dem einen oder den mehreren Prozessoren 202 verbunden oder anderswie zugänglich sein und kann konfiguriert sein, um die Computersoftware zur Ausführung durch den einen oder die mehreren Prozessoren 202 zu speichern.
Bei einigen Ausführungsformen können der eine oder die mehreren Prozessoren 202 einen Fahrspurgrenzen-Erfassungsalgorithmus 270 ausführen, um Algorithmusausgabe 280 zu erzeugen. Der Fahrspurgrenzen-Erfassungsalgorithmus 270 kann den einen oder die mehreren Prozessoren 202 befähigen, einen „wahrscheinlichsten“ oder „voraussichtlichsten“ Ort zu bestimmen, an dem eine Fahrspurgrenze sein kann, durch Empfangen und Analysieren von Sensordaten 250, die durch virtuelle Sensormodelle 220, die einen oder mehrere Real-World-Sensoren von Interesse modellieren, erzeugt werden.
Die Benutzeroberfläche 204 kann es einem Benutzer, zum Beispiel einem Ingenieur, Techniker oder dergleichen, ermöglichen, mit diversen Aspekten des Fahrspurgrenzen-Erfassungsprüfstands 200 zu interagieren, diesen zu betätigen, anzupassen oder seine diversen Aspekte zu steuern. Bei einigen Ausführungsformen kann die Benutzeroberfläche 204 ein oder mehrere Tastenfelder, Tastaturen, Touchscreens, Zeigevorrichtungen oder dergleichen oder eine Kombination oder Subkombination dieser aufweisen.
Bei einigen Ausführungsformen kann der Speicher 290 Daten, Codes und/oder Anweisungen in Zusammenhang mit einer oder mehreren virtuellen Fahrumgebungen 210 oder zur Definition dieser speichern. Die eine oder die mehreren virtuellen Fahrumgebungen 210 können diverse virtuelle Objekte, Strukturen und Markierungen, wie in 1 gezeigt, enthalten. Der Speicher 290 kann auch ein oder mehrere Sensormodelle 220, ein oder mehrere Fahrzeugmodelle 230, ein Simulationsmodul 240, Sensordaten 250, Algorithmusausgabe 280, andere Daten oder Software 260 (wie zum Beispiel „Ground-Truth-Daten“, die aus der virtuellen Fahrumgebung 210 extrahiert sind, oder Codes, die programmiert sind, um Sensordaten 250 durch die Benutzeroberfläche 204 visuell anzuzeigen) oder dergleichen oder Kombinationen oder Subkombinationen dieser speichern.
Bei einigen Ausführungsformen kann die virtuelle Fahrumgebung 210 ein dreidimensionales Netz aufweisen, das in einem virtuellen Raum Lagen, Ausrichtungen, Größen, Formen, Farben, Oberflächenreflexivität oder andere Merkmale einiger oder aller der stationären Objekte, Strukturen, Markierungen und Linien, die in der Umgebung 100, wie in 1 veranschaulicht, vorhanden sind, darunter die Linie 110 und 120, Oberflächenreflektoren 130, Markierungen oder Text 140, Straßenrandstreifen oder Schutzschienen 150, Schilder 160 sowie Bäume oder andere Pflanzen 170, definiert. Bei einigen Ausführungsformen kann die virtuelle Fahrumgebung 210 auch Merkmale anderer sich bewegender Objekte definieren, wie zum Beispiel Fahrzeuge 181, 182 und 183, wie in 1 veranschaulicht, darunter, ohne darauf beschränkt zu sein, Geschwindigkeit, Bewegungsrichtung, Beschleunigung/Verlangsamung und Wenden jedes der anderen sich bewegenden Objekte.
Bei einigen Ausführungsformen kann jedes Sensormodell 220 ein Softwaremodell sein, das für bestimmte Situationen oder Ansichten die Ausgabe eines entsprechenden Real-World-Sensors definiert oder vorhersagt. Bei bestimmten Ausführungsformen kann jedes Sensormodell 220 mit Informationen versehen sein (zum Beispiel Daten von einer virtuellen Fahrumgebung 210), die diverse Ansichten einer Straßenoberfläche, zum Beispiel der Straßenoberfläche 105, charakterisieren. Mit diesen Informationen kann jedes Sensormodell 220 vorhersagen, was ein tatsächlicher Sensor, dem in der realen Welt diese Ansichten präsentiert werden, ausgeben würde.
Bei einigen Ausführungsformen können die Real-World-Sensoren von Interesse Transducer aufweisen, die einige Merkmale einer Umgebung erfassen oder detektieren und eine entsprechende Ausgabe (zum Beispiel ein elektrisches oder optisches Signal oder ein Bild), die das Merkmal definiert, bereitstellen. Ein oder mehrere Real-World-Sensoren von Interesse können zum Beispiel Beschleunigungsmesser sein, die ein elektrisches Signal ausgeben, das für die Eigenbeschleunigung, die dabei erfahren wird, charakteristisch ist. Solche Beschleunigungsmesser können verwendet werden, um die Ausrichtung, Beschleunigung, Geschwindigkeit und/oder Entfernung, die ein Fahrzeug zurücklegt, zu bestimmen. Andere Real-World-Sensoren von Interesse können Kameras, Laserscanner, Light-Detection-And-Ranging(LIDAR)-Scanner, Ultraschalltransducer, Radargeräte, Gyroskope, Trägheitsmesseinheiten, Drehzahlzähler oder -sensoren, Dehnungsmessstreifen, Temperatursensoren oder dergleichen aufweisen.
Jedes Sensormodell 220 kann verwendet werden, um die Ausgabe zu modellieren, die von einem Real-World-Sensor von Interesse ausgegeben wird. Das Sensormodell 220 kann zum Beispiel verwendet werden, um die Sensoren 191, 192 und 193, die auf dem Fahrzeug 190 installiert sind, wie in 1 veranschaulicht, zu modellieren. Obwohl die Ausgaben für unterschiedliche Real-World-Sensoren unterschiedlich sein können, kann folglich bei einigen Ausführungsformen ein gegebenes Sensormodell 220 einem spezifischen Typ eines Real-World-Sensors entsprechen. Ein Sensormodell 220 kann zum Beispiel geeignet sein, um die Ausgabe eines besonderen Sensortyps zu modellieren (zum Beispiel einer besonderen Art von Kamera), während ein anderes Sensormodell 220 geeignet sein kann, um die Ausgabe eines anderen Sensortyps zu modellieren (zum Beispiel eines besonderen Radarscanners).
Jedes Sensormodell 220 kann eine Ausgabe in irgendeinem geeigneten Format erzeugen. Bei einigen Ausführungsformen kann zum Beispiel ein Sensormodell 220 ein analoges Signal ausgeben, das ein entsprechender Real-World-Sensor erzeugen würde. Alternativ kann ein Sensormodell 220 ein verarbeitetes Signal ausgeben, wie zum Beispiel eine digitalisierte und gefilterte Version eines analogen Signals. Ein Sensormodell 220 kann zum Beispiel ein verarbeitetes Signal wie das ausgeben, das von einem Datenerfassungssystem ausgegeben wird. Bei einigen Ausführungsformen kann die Ausgabe eines Sensormodells 220 folglich eine aufbereitete, digitale Version des Signals sein, das ein entsprechender Real-World-Sensor erzeugen würde.
Jedes des einen oder der mehreren Fahrzeugmodelle 230 ist konfiguriert, um ein jeweiliges Fahrzeug mit installiertem Sensor zu modellieren, das auf einer Straßenoberfläche in einer Fahrumgebung durchquert, wie zum Beispiel das Fahrzeug 190 der 1. Ähnlich den Sensormodellen 220, können die Fahrzeugmodelle 230 von unterschiedlichen Typen von Real-World-Fahrzeugen unterschiedlich sein (zum Beispiel unterschiedliche Marke/unterschiedliches Modell eines Kraftfahrzeugs). Eine spezifische Marke/ein spezifisches Modell eines Fahrzeugs (zum Beispiel ein besonderes Sportauto) kann durch ein jeweiliges Fahrzeugmodell 230 modelliert werden, das sich von einem anderen Fahrzeugmodell 230 unterscheidet, das verwendet wird, um ein anderes Fahrzeug einer anderen Marke/eines anderen Modells zu modellieren (zum Beispiel ein besonderer Pick-up Truck).
Im Allgemeinen kann ein Fahrzeugmodell 230 zwei Submodelle aufweisen: ein Modell 232 mit stationärem Fahrzeug und ein Modell 234 mit dynamischem Fahrzeug. Mit den zwei Submodellen kann das Durchqueren eines Fahrzeugs innerhalb der virtuellen Fahrumgebung 210 in einem vernünftig präzisen Ausmaß modelliert werden. Das Modell 232 mit stationärem Fahrzeug kann ein Softwaremodell sein, das bestimmte stationäre Merkmale eines entsprechenden Fahrzeugtyps modelliert. Bei einigen Ausführungsformen kann ein Satz von Parametern verwendet werden, um Maße des entsprechenden Fahrzeugtyps aufzuzeichnen. Der Parametersatz kann auch Informationen in Zusammenhang mit geplanten Lagen eines oder mehrerer Sensoren aufweisen, die auf dem entsprechenden Fahrzeugtyp installiert sind. Das Modell 234 mit dynamischem Fahrzeug kann ein Softwaremodell sein, das bestimmte dynamische Merkmale eines entsprechenden Fahrzeugtyps als Reaktion auf externe Kräfte oder Aufpralle definiert. Bei einigen Ausführungsformen kann das Modell 234 mit dynamischem Fahrzeug Merkmale von Chassis- und/oder Federungsdynamik eines entsprechenden Fahrzeugtyps mit einer bestimmten Treue aufweisen.
Bei einigen Ausführungsformen kann das Modell 234 mit dynamischem Fahrzeug mit einer oder mehreren Fahrereingaben (zum Beispiel ein oder mehrere Werte, die Parameter, wie zum Beispiel Geschwindigkeit, Antriebsdrehmoment, Bremsenbetätigung, Lenkeingabe oder dergleichen oder Kombinationen oder Subkombinationen davon, charakterisieren) und Informationen (zum Beispiel Daten aus einer virtuellen Fahrumgebung 210), die eine Straßenoberfläche charakterisieren, versehen werden. Mit diesen Eingaben und Informationen kann das Modell 234 mit dynamischem Fahrzeug Bewegungszustände der Karosserie eines entsprechenden Fahrzeugtyps vorhersagen.
Die Parameter des Modells 234 mit dynamischem Fahrzeug können auf irgendeine geeignete Art bestimmt oder spezifiziert werden. Bei einigen Ausführungsformen können bestimmte Parameter des Modells 234 mit dynamischem Fahrzeug aus vorhergehender Kenntnis der mechanischen Eigenschaften (zum Beispiel Geometrien, Trägheit, Steifigkeit, Dämpfungskoeffizienten usw.) eines entsprechenden Real-World-Fahrzeugs abgeleitet werden. Die Parameter können für unterschiedliche Fahrzeugtypen unterschiedlich sein.
Das Simulationsmodul 240 kann programmiert sein, um den einen oder die mehreren Prozessoren 202 zu veranlassen, eine virtuelle Fahrumgebung 210, ein oder mehrere Sensormodelle 220 und ein Fahrzeugmodell 230 als Eingaben zu nehmen und anschließend eine Ausgabe zu erzeugen, die eine Real-World-Ausgabe modelliert, die von einem oder mehreren Real-World-Sensoren, die auf einem entsprechenden Real-World-Fahrzeug installiert sind (zum Beispiel das Fahrzeug, das durch das Fahrzeugmodell 230 modelliert wird), das eine Real-World-Fahrumgebung durchquert, die durch die virtuelle Fahrumgebung 210 modelliert wird (zum Beispiel im Wesentlichen oder genau übereinstimmend), erzeugt werden. Bei einigen Ausführungsformen kann mindestens ein Abschnitt der Ausgabe, die durch das Simulationsmodul 240 erzeugt wird, in dem Speicher 290 als Sensordaten 250 gespeichert werden. Wie oben erwähnt, kann die Fahrumgebung 100 eine oder mehrere Fahrspurmarkierungen aufweisen, wie zum Beispiel eine durchgehende Linie 110, eine unterbrochene Linie 120 und Oberflächenreflektoren 130. In diesem Fall können die Sensordaten 250 Daten aufweisen, die Lagen von Fahrspurgrenzen direkt charakterisieren. Alternativ kann die Fahrumgebung 100 bei einigen Ausführungsformen keine oder einige der Fahrspurmarkierungen aufweisen. In diesem Fall können die Sensordaten 250 Daten aufweisen, die andere virtuelle Objekte, die in der virtuellen Fahrumgebung 210 definiert sind, charakterisieren, die entweder stationär oder beweglich sind, wie zum Beispiel Text 140, Straßenrandstreifen oder Schutzschienen 150, Schilder 160, Bäume oder andere Pflanzen 170 sowie andere Fahrzeuge 181, 182 und 183. Daten dieser virtuellen Objekte, die als Sensordaten 250 gespeichert sind, können, wenn auch indirekt, noch von dem einen oder den mehreren Prozessoren 202 verwendet werden, um Lagen von Fahrspurgrenzen durch Ausführen des Fahrspurgrenzen-Erfassungsalgorithmus 270 abzuleiten.
Bei einigen Ausführungsformen kann der Fahrspurgrenzen-Erfassungsprüfstand 200 in dem Simulationsmodul 240 ein oder mehrere Einflussmodule 242 aufweisen. Der Zweck eines Einflussmoduls 242 ist es, Sekundäreffekte zu berücksichtigen, wie zum Beispiel Witterungsbedingungen, Tageszeit, Altern von Sensor und Fahrzeug. Bei Real-World-Szenarien behält ein Sensor eventuell nicht dieselben Merkmale oder dieselbe Leistung während einer unendlich langen Zeitspanne. Real-World-Sensoren können sehr wahrscheinlich bestimmte Alterungseffekte erfahren, und ihre Merkmale können sich mit der Zeit ändern oder abweichen. Eine ähnliche Situation kann bei Real-World-Fahrzeugen auftreten. Ein Einflussmodul 242, das in dem Simulationsmodul 240 enthalten ist, kann programmiert sein, um solche Effekte zu berücksichtigen, die auf Witterungsbedingungen, Tageszeit, Altern von Sensor und Fahrzeug zurückzuführen sind, indem der eine oder die mehreren Prozessoren 202 veranlasst werden, entweder die Ausgabe anzupassen, die von dem Simulationsmodul 240 erzeugt wird, oder die gespeicherten Sensordaten 250 gemäß einem Satz von Einflussparametern anzupassen. Bei einigen Ausführungsformen kann ein Einflussmodul 242 programmiert werden, um diverse Witterungsbedingungen zu berücksichtigen. Bei einigen Ausführungsformen kann ein Einflussmodul 242 programmiert werden, um Lichtverhältnisse zu berücksichtigen, die sich vom Morgengrauen bis zur Dämmerung in Abhängigkeit von verschiedenen Tageszeiten ändern können. Bei einigen Ausführungsformen kann ein Einflussmodul 242 den einen oder die mehreren Prozessoren 202 veranlassen, ein oder mehrere Sensormodelle 220 anzupassen oder „zu beeinflussen“, um solche sekundären Effekte zu berücksichtigen.
Eine beispielhafte Umsetzung eines Einflussmoduls 242 kann ferner durch die folgenden Beispiele veranschaulicht werden. Bei einigen Ausführungsformen kann ein Sensormodell 220 eine virtuelle Kamera sein, die eine visuelle Real-World-Kamera modelliert, und die entsprechenden Sensordaten 250 können daher ein oder mehrere visuelle Bilder sein. Falls die virtuellen Witterungsbedingungen Regen sind, würde das Bild, das von der virtuellen Kamera wahrgenommen wird, aufgrund von Regen verschwommen werden und kann durch die Bewegung von Scheibenwischern im Vergleich zu einem klaren Bild, das ansonsten bei einer normalen Witterungsbedingung wahrgenommen wird, gestört sein. Als ein anderes Beispiel könnte das Bild, das unter einem hellen Sonnenschein wahrgenommen wird, weniger Kontrast haben und daher einen „White out“-Effekt im Vergleich zu einem klaren Bild bei normaler Tageslichtbedingung haben. Diese visuellen Effekte auf den Bildern (zum Beispiel Sensordaten 250), die durch das Simulationsmodul 240 erzeugt werden, können von einem oder mehreren Einflussmodulen 242 erzeugt werden. Kurz gesagt berücksichtigen das eine oder die mehreren Einflussmodule 242 nicht nur diverse Sekundäreffekte, sie erleichtern auch das Erzeugen einer großen Menge von Sensordaten 250 unter diversen Bedingungen auf effiziente und kostengünstige Art.
3 veranschaulicht eine Ausführungsform von Sensordaten, die mit einem oder mehreren Kommentaren in Übereinstimmung mit der vorliegenden Offenbarung gekennzeichnet sind. Unter Bezugnahme auf 1 und 2 als ein Beispiel, während ein virtuelles Fahrzeug 190 die virtuelle Fahrumgebung 100 (oder gleichwertig die virtuelle Fahrumgebung 210) durchquert, kann der Fahrspurgrenzen-Erfassungsprüfstand 200 für jeden virtuellen Sensor 191, 192 und 193 Sensordaten 250 für jeden simulierten Augenblick während einer simulierten Zeitspanne erzeugen. Ebenfalls unter Bezugnahme auf 3 kann das Simulationsmodul 240 während eines ersten simulierten Augenblicks zum Beispiel Sensordaten 250a erzeugen, die die virtuelle Fahrumgebung 100 charakterisieren, wie sie von einem besonderen virtuellen Sensor 191 in diesem ersten Augenblick wahrgenommen wird. Anschließend kann das Simulationsmodul 240 für einen zweiten simulierten Augenblick Sensordaten 250b erzeugen, die die virtuelle Fahrumgebung 210, wie sie von dem virtuellen Sensor 191 in diesem zweiten Augenblick wahrgenommen wird, charakterisieren. Dieser Prozess kann während eines dritten simulierten Augenblicks wiederholt werden (und Sensordaten 250c erzeugen), während eines vierten simulierten Augenblicks (und Sensordaten 250d erzeugen) usw. Folglich kann durch Fortschreiten von einem Augenblick zum nächsten das Simulationsmodul 240 einen Datenstrom 391 erzeugen, der die virtuelle Fahrumgebung 210 so charakterisiert, wie sie von dem virtuellen Sensor 191 während dieser simulierten Zeitspanne wahrgenommen wird. Dieser Simulationsprozess kann für alle virtuellen Sensoren (zum Beispiel für die Sensoren 191, 192 und 193), die auf einem besonderen virtuellen Fahrzeug (zum Beispiel auf dem Fahrzeug 190) installiert sind, wiederholt werden. Für das besondere virtuelle Fahrzeug 190 und die virtuelle Fahrumgebung 100, die es durchquert hat, können somit Sensordaten 250, die einen oder mehrere Datenströme (zum Beispiel die Datenströme 391, 392 und 393) umfassen, erzeugt werden.
Bei dem in 3 gezeigten Beispiel können unterschiedliche Datenströme 391, 392 und 393 die Ausgaben unterschiedlicher virtueller Sensoren 191, 192 und 193 darstellen. Ein erster Datenstrom 391 kann daher die Ausgabe einer ersten virtuellen Kamera 191, die auf der vorderen linken Ecke des virtuellen Fahrzeugs 190 installiert ist, darstellen, ein zweiter Datenstrom 392 kann die Ausgabe einer zweiten virtuellen Kamera 192, die auf der vorderen Mitte des virtuellen Fahrzeugs 190 installiert ist, darstellen und ein dritter Datenstrom 393 kann die Ausgabe einer dritten virtuellen Kamera 193, die auf der vorderen rechten Ecke des virtuellen Fahrzeugs 190 installiert ist, darstellen. Gemeinsam können die diversen Datenströme 391, 392 und 393, die die Sensordaten 250 für eine besondere Fahrt bilden (zum Beispiel eine besondere virtuelle Durchquerung eines besonderen virtuellen Fahrzeugs 190 durch eine besondere virtuelle Fahrumgebung 210), einige oder alle Eingaben darstellen oder berücksichtigen, die ein besonderer Algorithmus (das heißt der Algorithmus, der entwickelt oder getestet wird) in der realen Welt verwenden würde.
Bei einigen Ausführungsformen kann das Simulationsmodul 240 ein Ground-Truth-Kommentarmodul 244 aufweisen, das programmiert ist, um den einen oder die mehreren Prozessoren 202 zu veranlassen, die Sensordaten 250 mit einem oder mehreren Kommentaren einer ersten Art zu koppeln. Der Kommentar 350a und der Kommentar 350b, die in 3 gezeigt sind, können zum Beispiel solche Kommentare der ersten Art aufweisen. Jeder solche Kommentar kann „Ground-Truth-Daten“, die der virtuellen Fahrumgebung 210 entsprechen, kommentieren. Bei einigen Ausführungsformen weisen Ground-Truth-Daten tatsächliche räumliche Lage von Fahrspurgrenzen, wie sie innerhalb der virtuellen Fahrumgebung 210 definiert sind, auf. Während solches Ground-Truth durch die virtuelle Fahrumgebung 210 modelliert wird, sind solche Informationen leicht für den Fahrspurgrenzen-Erfassungsprüfstand 200 verfügbar. Bei einigen Ausführungsformen können die Ground-Truth-Daten, die in einem oder mehreren Kommentaren enthalten sind, verwendet werden, um die Leistung des Fahrspurgrenzen-Erfassungsalgorithmus 270 zu quantifizieren oder zu bewerten, wenn kommentierte Sensordaten 250 von dem Algorithmus in einem überwachten Lernansatz verwendet werden.
Ein oder mehrere Kommentare, darunter die Kommentare 350a und 350b, können „wahre Lagen“ der Grenzen der Fahrspur 115, innerhalb welcher das virtuelle Fahrzeug 190 für eine besondere Fahrt gefahren wird, bereitstellen. Die wahren Lagen der Fahrspurgrenzen werden gemäß der Raumdefinition der Fahrspur 115 innerhalb der virtuellen Fahrumgebung 100 definiert. Die Kommentare 350a und 350b können mit besonderen Abschnitten der Datenströme 391, 392 und 393 verknüpft, verbunden, überlagert oder anderswie assoziiert werden. Die Ground-Truth-Daten, die einer besonderen Fahrspur 115 entsprechen, können folglich mit dem Abschnitt von Datenströmen 391, 392 und 393, der die Wahrnehmung der virtuellen Sensoren 191, 192 und 193 dieser Grenzen der Fahrspur 115 wiedergibt, verknüpft werden. Bei einigen Ausführungsformen können nicht alle Datenströme 391, 392 und 393 Ground-Truth-Daten haben, die an denselben zeitlichen Abschnitten kommentiert sind.
Bei einigen Ausführungsformen kann das Simulationsmodul 240 ein Fahrspurgrenzen-Kommentarmodul 246 aufweisen, das programmiert ist, um den Prozessor 202 zu veranlassen, die Sensordaten 250 mit einem oder mehreren Kommentaren einer zweiten Art zu koppeln. Der Kommentar 350a und der Kommentar 350b, die in 3 gezeigt sind, können zum Beispiel solche Kommentare der zweiten Art aufweisen. Jeder solche Kommentar kann Sensordaten 250 mit Algorithmusausgabe 280 kommentieren, das heißt die Lagen der Fahrspurgrenzen, wie sie von dem Fahrspurgrenzen-Erfassungsalgorithmus 270 bestimmt werden. Bei einigen Ausführungsformen können die Sensordaten 250 virtuelle Bilder sein, wie sie von einem virtuellen Kameramodell durch ein jeweiliges Sensormodell 220 wahrgenommen werden, und der Kommentar 350a und der Kommentar 350b können Linien oder Kurven oder andere Markierungen sein, die auf den virtuellen Bildern überlagert sind, die die Algorithmusausgabe 280 angeben. Die Algorithmusausgabe 280 kann Lagen aufweisen, die von dem Prozessor 202 (durch Ausführen des Fahrspurgrenzen-Erfassungsalgorithmus 270) bezeichnet werden, wo Fahrspurgrenzen in etwa angesichts der virtuellen Bilder (das heißt Sensordaten 250), die von dem Simulationsmodul 240 erzeugt werden, liegen.
4 veranschaulicht einen beispielhaften Prozess 400 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung. Der beispielhafte Prozess 400 kann einen oder mehrere Vorgänge, Aktionen oder Funktionen, die als Blöcke gezeigt sind, wie zum Beispiel 410, 420, 430, 440, 450, 460 und 470, aufweisen. Obwohl sie als gesonderte Blöcke veranschaulicht sind, können diverse Blöcke in Abhängigkeit von der gewünschten Umsetzung in zusätzliche Blöcke unterteilt sein, in weniger Blöcke kombiniert sein oder eliminiert werden. Der beispielhafte Prozess 400 kann in einer beispielhaften Umgebung 100 und/oder dem beispielhaften Fahrspurgrenzen-Erfassungsprüfstand 200 umgesetzt werden. Zur Vereinfachung der Beschreibung und um ihren Geltungsbereich nicht einzuschränken, wird der beispielhafte Prozess 400 unten in dem Kontext des beispielhaften Fahrspurgrenzen-Erfassungsprüfstands 200 beschrieben.
Bei 410 kann der beispielhafte Prozess 400 involvieren, dass der Prozessor 202 die virtuelle Fahrumgebung 210 gemäß diversen virtuellen Objekten (zum Beispiel als Text 140, Straßenrandstreifen oder Schutzschienen 150, Schilder 160, Bäume oder andere Pflanzen 170 sowie als andere Fahrzeuge 181, 182 und 183), Fahrspurmarkierungen (zum Beispiel durchgehende Linie 110, unterbrochene Linie 120 und Oberflächenreflektoren 130) und virtuelle Sensoren (zum Beispiel Sensoren 191, 192 und 193), die in 1 gezeigt sind, einrichtet. Auf Block 410 kann Block 420 folgen.
Bei 420 kann der beispielhafte Prozess 400 involvieren, dass der Prozessor 202 bestimmt, ob eine Durchquerung einen vorbestimmten Zielort erreicht hat. Nach dem Erzeugen der virtuellen Fahrumgebung 210, kann der Prozessor 202 zum Beispiel bestimmen, ob ein Durchqueren einen vorbestimmten Zielort erreicht hat oder nicht. Einerseits, wenn bestimmt wird, dass das Durchqueren den vorbestimmten Zielort noch nicht erreicht hat, kann der Prozessor 202 bestimmen, virtuelle Sensoren zu einer nächsten Lage innerhalb der virtuellen Fahrumgebung durchqueren zu lassen, und der beispielhafte Prozess 400 kann zu 430 weitergehen. Andererseits, wenn bestimmt wird, dass das Durchqueren den vorbestimmten Zielort erreicht hat, kann der Prozessor 202 bestimmen, zu 470 weiter zu gehen.
Bei 430 kann der beispielhafte Prozess 400 als Reaktion auf eine Bestimmung, dass das Durchqueren den vorbestimmten Zielort noch nicht erreicht hat, involvieren, dass die virtuellen Sensoren zu einer nächsten Lage unter Verwenden eines Modells 234 mit dynamischem Fahrzeug eines Fahrzeugmodells 230 durchqueren. Auf Block 430 kann Block 440 folgen.
Bei 470, als Reaktion auf eine Bestimmung, dass das Durchqueren den vorbestimmten Zielort erreicht hat, kann der beispielhafte Prozess 400 das Analysieren (durch den Prozessor 202, der den Fahrspurgrenzen-Erfassungsalgorithmus 270 ausführt) von Sensordaten 250 und anschließend das Bestimmen (ebenfalls durch den Prozessor 202, der den Fahrspurgrenzen-Erfassungsalgorithmus 270 ausführt) von Fahrspurgrenzenlagen in der virtuellen Fahrumgebung 210 involvieren. Bei 470 kann der beispielhafte Prozess 400 auch das Kommentieren von Sensordaten 250 mit der erfassten Fahrspurgrenze involvieren. Der beispielhafte Prozess 400 kann nach 470 enden.
Bei 440 kann der beispielhafte Prozess 400 involvieren, dass der Prozessor 202 Sensordaten 250 aufzeichnet, die durch das Simulationsmodul 240 erzeugt werden, die die virtuelle Fahrumgebung 210, wie sie von einem virtuellen Sensor wahrgenommen wird, der von einem Sensormodell 220 modelliert wird, charakterisieren. Auf Block 440 kann Block 450 folgen.
Bei 450 kann der beispielhafte Prozess 400 involvieren, dass das Ground-Truth-Kommentarmodul 244 des Simulationsmoduls 240 Sensordaten 250 mit Ground-Truth-Daten kommentiert, wie zum Beispiel mit Lagen von Fahrspurgrenzen, wie sie in der virtuellen Fahrumgebung 210 an diversen Zeitabschnitten der Sensordaten 250 definiert sind. Auf Block 450 kann Block 460 folgen.
Bei 460 kann der beispielhafte Prozess 400 involvieren, dass der Prozessor 202 als Reaktion auf das Aufzeichnen kommentierter Daten, die die virtuelle Fahrumgebung 210, wie sie von einem virtuellen Sensor wahrgenommen wird, charakterisieren, bestimmt, ob der virtuelle Sensor der letzte der virtuellen Sensoren ist, die die virtuelle Fahrumgebung 210 erfassen, dessen Wahrnehmungen aufgezeichnet werden müssen. Einerseits, falls bestimmt wird, dass der virtuelle Sensor nicht der letzte der virtuellen Sensoren ist, die die virtuelle Fahrumgebung 210 erfassen, dessen Wahrnehmungen aufgezeichnet werden müssen, kann der Prozessor 202 zu 440 weitergehen, um kommentierte Daten aufzuzeichnen, die die virtuelle Fahrumgebung 210, wie sie von einem nächsten virtuellen Sensor wahrgenommen wird, charakterisieren. Andererseits, falls bestimmt wird, dass der virtuelle Sensor bereits der letzte der virtuellen Sensoren ist, die die virtuelle Fahrumgebung 210 erfassen, dessen Wahrnehmungen aufgezeichnet werden müssen, kann der Prozessor 202 zu 420 weitergehen, um wieder zu prüfen, ob das Durchqueren den vorbestimmten Zielort erreicht hat.
5 veranschaulicht einen anderen beispielhaften Prozess 500 in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung. Der beispielhafte Prozess 500 kann einen oder mehrere Vorgänge, Aktionen oder Funktionen, die als Blöcke gezeigt sind, wie zum Beispiel 510, 520, 530, 540, 550, 560 und 570, aufweisen. Obwohl sie als gesonderte Blöcke veranschaulicht sind, können diverse Blöcke in Abhängigkeit von der gewünschten Umsetzung in zusätzliche Blöcke unterteilt sein, in weniger Blöcke kombiniert sein oder eliminiert werden. Der beispielhafte Prozess 500 kann in einer beispielhaften Umgebung 100 und/oder dem beispielhaften Fahrspurgrenzen-Erfassungsprüfstand 200 umgesetzt werden. Zur Vereinfachung der Beschreibung und um ihren Geltungsbereich nicht einzuschränken, wird der beispielhafte Prozess 500 unten in dem Kontext des beispielhaften Fahrspurgrenzen-Erfassungsprüfstands 200 beschrieben. Der beispielhafte Prozess 500 kann mit Block 510 beginnen.
Bei 510 kann der beispielhafte Prozessor 500 involvieren, dass ein oder mehrere Prozessoren 202 eine virtuelle Fahrumgebung 100 erzeugen, die eine oder mehrere Fahrspuren 105, ein virtuelles Fahrzeug 190 und virtuelle Sensoren 191, 192 und 193 aufweist. Die virtuellen Sensoren 191, 192 und 193 sind auf dem virtuellen Fahrzeug 190 installiert.
Bei 520 kann der beispielhafte Prozess 500 einen oder mehrere Prozessoren 202 involvieren, die virtuelle Sensoren 191, 192 und 193, wie sie auf dem virtuellen Fahrzeug 190 installiert sind, innerhalb der virtuellen Fahrumgebung 100 durchqueren lassen, um simulierte Sensordaten 250 zu erzeugen. Auf Block 520 kann Block 530 folgen.
Bei 530 kann der beispielhafte Prozess involvieren, dass ein oder mehrere Prozessoren 202 einen oder mehrere Fahrspurgrenzen-Erfassungsalgorithmen 270 ausführen, um simulierte Sensordaten 250 zu verarbeiten, um eine oder mehrere Fahrspuren 105 zu erfassen, die Lagen von Grenzen einer oder mehrerer Fahrspuren 105 als Algorithmusausgabe 280 bezeichnen. Auf Block 530 kann Block 540 folgen.
Bei 540 kann der beispielhafte Prozess 500 involvieren, dass ein oder mehrere Prozessoren 202 die Algorithmusausgabe 280 aufzeichnen. Auf Block 540 kann Block 550 folgen.
Bei 550 kann der beispielhafte Prozess 500 involvieren, dass ein oder mehrere Prozessoren 202 durch das Fahrspurgrenzen-Kommentarmodul 246 die simulierten Sensordaten 250 mit Algorithmusausgabe 280 kommentieren. Auf Block 550 kann Block 560 folgen.
Bei 560 kann der beispielhafte Prozess 500 involvieren, dass ein oder mehrere Prozessoren 202 Ground-Truth-Daten für die mindestens eine der einen oder mehreren Fahrspuren 105 erzeugen. Die Ground-Truth-Daten können eine oder mehrere tatsächliche Lagen der einen oder mehreren Grenzen der mindestens einen der einen oder mehreren Fahrspuren 105 innerhalb der virtuellen Fahrumgebung 100 darstellen. Zusätzlich kann der beispielhafte Prozess 500 involvieren, dass ein oder mehrere Prozessoren 202 einen Unterschied zwischen den Ground-Truth-Daten und der Ausgabe des Algorithmus 280 aufzeichnen. Alternativ oder zusätzlich kann der beispielhafte Prozess 500 involvieren, dass ein oder mehrere Prozessoren 202 die simulierten Sensordaten 250 mit den Ground-Truth-Daten kommentieren. Auf Block 560 kann Block 570 folgen.
Bei 570 kann der beispielhafte Prozess 500 involvieren, dass ein oder mehrere Prozessoren 202 durch das Ground-Truth-Kommentarmodul 244 die simulierten Sensordaten 250 mit Ground-Truth-Daten einer oder mehrerer Fahrspuren 105 kommentieren.
Bei einigen Ausführungsformen kann die virtuelle Fahrumgebung 100 auch eine Mehrzahl von Fahrspurmarkierungen aufweisen, die der einen oder den mehreren Fahrspuren 105 entsprechen, wie zum Beispiel Linie 110, eine Linie 120, Oberflächenreflektoren 130 und Markierungen oder Text 140. Bei einigen Ausführungsformen kann die virtuelle Fahrumgebung 100 auch eine Mehrzahl virtueller Objekte aufweisen, die entweder stationär oder in Bezug zu der virtuellen Fahrumgebung beweglich sind, wie zum Beispiel Straßenrandstreifen oder Schutzschienen 150, Schilder 160, Bäume oder andere Pflanzen 170 sowie andere Fahrzeuge 181, 182 und 183. Der eine oder die mehreren virtuellen Sensoren, wie zum Beispiel die Sensoren 191, 192 und 193, die auf dem virtuellen Fahrzeug 190 installiert sind, können jede der Fahrspurmarkierungen und jedes der virtuellen Objekte erfassen. Bei einigen Ausführungsformen können die simulierten Sensordaten 250 die virtuelle Fahrumgebung 100, wie sie von einem oder mehreren virtuellen Sensoren 191, 192 und 193, die die Mehrzahl von Fahrspurmarkierungen und virtuellen Objekte erfassen, wahrgenommen werden, charakterisieren.
Bei einigen Ausführungsformen können die virtuellen Sensoren 191, 192 und 193 eine virtuelle Kamera aufweisen, und die simulierten Sensordaten 250 können ein oder mehrere virtuelle Bilder der virtuellen Fahrumgebung 100, wie sie von der virtuellen Kamera wahrgenommen wird, aufweisen. Bei einigen Ausführungsformen kann der beispielhafte Prozess 500 auch das Anzeigen einer Mehrzahl überlagerter Markierungen auf dem einen oder den mehreren virtuellen Bildern involvieren. Die Mehrzahl überlagerter Markierungen kann eine oder mehrere Lagen einer oder mehrerer Grenzen mindestens einer der einen oder mehreren Fahrspuren 105 angeben.
Bei einigen Ausführungsformen kann die Algorithmusausgabe 280 eine oder mehrere Lagen einer oder mehrerer Grenzen der mindestens einen der einen oder mehreren Fahrspuren, die durch den Fahrspurgrenzen-Erfassungsalgorithmus 270 als „wahrscheinlichere“ Lagen von Grenzen einer oder mehrerer Fahrspuren 105 bezeichnet werden, aufweisen. Bei einigen Ausführungsformen können die eine oder mehreren Lagen der einen oder mehreren Grenzen der mindestens einen der einen oder mehreren Fahrspuren eine Mehrzahl von Punkten jeweils mit einer jeweiligen räumlichen Koordinate innerhalb der virtuellen Fahrumgebung 100 aufweisen. Die Mehrzahl von Punkten kann gemeinsam der einen oder den mehreren Lagen der einen oder mehreren Grenzen der mindestens einen der einen oder mehreren Fahrspuren entsprechen. Zusätzlich kann der beispielhafte Prozess 500 auch das Kommentieren der simulierten Sensordaten 250 mit den räumlichen Koordinaten der Mehrzahl von Punkten involvieren.
Bei einigen Ausführungsformen kann der beispielhafte Prozess 500 beim Aufzeichnen der Algorithmusausgabe 280 das Aufzeichnen eines Zeitstempels der Ausgabe des Algorithmus 280 involvieren.
Bei einigen Ausführungsformen können virtuelle Sensoren 191, 192 und 193 auf dem virtuellen Fahrzeug 190 gemäß dem Modell 232 mit stationärem Fahrzeug, das eine Lage der virtuellen Sensoren 191, 192 und 193 in Bezug zu dem virtuellen Fahrzeug 190 modelliert, installiert sein. Bei einigen Ausführungsformen kann das virtuelle Fahrzeug 190 innerhalb der virtuellen Umgebung 100 gemäß dem Modell 234 mit dynamischem Fahrzeug, das Bewegungen des virtuellen Fahrzeugs 190 modelliert, durchqueren.
Die Artikel „ein” und „eine“ werden hier verwendet, um auf eines oder mehr als eines (das heißt mindestens eines) des grammatischen Objekts des Artikels zu verweisen. Beispielhaft bedeutet „ein Benutzer“ ein Benutzer oder mehr als ein Benutzer. In dieser Patentschrift bedeutet der Verweis auf „eine Ausführungsform“ oder „ein Beispiel“, dass ein besonderes Merkmal, eine Struktur oder Charakteristik, die in Zusammenhang mit der Ausführungsform beschrieben ist, in mindestens einer Ausführungsform der vorliegenden Offenbarung enthalten ist. Das Erscheinen der Sätze „in einer Ausführungsform“ oder „ein Beispiel“ an verschiedenen Stellen in dieser Patentschrift bezieht sich nicht notwendigerweise auf dieselbe Ausführungsform oder dasselbe Beispiel. Ferner können die besonderen Merkmale, Strukturen, Datenbanken oder Charakteristiken in irgendwelchen geeigneten Kombinationen und/oder Subkombinationen in einer oder mehreren Ausführungsformen oder in einem oder mehreren Beispielen kombiniert werden. Zusätzlich ist klar, dass die Figuren, die hier bereitgestellt werden, erklärenden Zweck für den Durchschnittsfachmann haben, und dass die Zeichnungen nicht notwendigerweise maßstabgerecht sind.
Ausführungsformen in Übereinstimmung mit der vorliegenden Offenbarung können als ein Gerät, Verfahren oder Computerprogrammprodukt verkörpert werden. Aspekte der vorliegenden Offenbarung können folglich die Form einer ausschließlichen Hardware-Ausführungsform, einer ausschließlichen Software-Ausführungsform (inklusive Firmware, residente Software, Microcode oder dergleichen) oder einer Ausführungsform, die Software- und Hardwareaspekte kombiniert, die hier allgemein eine „Schaltung“, ein „Modul“ oder ein „System“ genannt werden, annehmen. Ferner können Ausführungsformen der vorliegenden Offenbarung die Form eines Computerprogrammprodukts annehmen, das in irgendeinem konkreten Ausdrucksmedium, das einen von einem Computer nutzbaren Programmcode in dem Medium verkörpert hat, verkörpert ist.
Die Flussdiagramme und die Blockschaltbilder in den anliegenden Figuren veranschaulichen die Architektur, Funktionalität und den Betrieb möglicher Umsetzungen des Systems, der Verfahren und Computerprogrammprodukte gemäß unterschiedlichen Ausführungsformen der vorliegenden Offenbarung. In diesem Hinblick kann jeder Block in den Flussdiagrammen oder in den Blockschaltbildern ein Modul, Segment oder einen Codeabschnitt darstellen, das/der eine oder mehrere ausführbare Anweisungen zum Umsetzen der spezifizierten logischen Funktion(en) umfasst. Ferner ist zu bemerken, dass jeder Block der Blockschaltbilder und/Flussdiagramme sowie Kombinationen von Blöcken in den Blockschaltbildern und/oder den Flussdiagrammen durch auf Hardware basierende Systeme mit speziellem Zweck umgesetzt werden können, die die spezifizierten Funktionen oder Aktionen oder Kombinationen von Hardware mit speziellem Zweck und Computeranweisungen ausführen. Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert sein, das einen Computer oder ein anderes programmierbares Datenverarbeitungsgerät steuern kann, um auf eine besondere Art zu arbeiten, so dass die in dem computerlesbaren Medium gespeicherten Anweisungen einen Artikel der Herstellung herstellen, darunter Anweisungsmittel, die die Funktion/Aktion, die in dem Flussdiagramm und/oder Blockdiagrammblock oder den Blockdiagrammblöcken spezifiziert ist, umsetzen.
Obwohl die vorliegende Offenbarung in Form bestimmter Ausführungsformen beschrieben ist, sind dem Durchschnittsfachmann andere Ausführungsformen dank dieser Offenbarung klar, darunter Ausführungsformen, die nicht alle Vorteile und Merkmale, die hier dargelegt sind, bereitstellen, die ebenfalls in den Geltungsbereich dieser Offenbarung fallen. Man muss verstehen, dass andere Ausführungsformen verwendet werden können, ohne vom Geltungsbereich der vorliegenden Offenbarung abzuweichen.

Claims

Verfahren, das Folgendes umfasst: Erzeugen durch einen Prozessor einer virtuellen Fahrumgebung, die eine oder mehrere Fahrspuren, ein virtuelles Fahrzeug und einen oder mehrere virtuelle Sensoren, die auf dem virtuellen Fahrzeug installiert sind, die konfiguriert sind, um simulierte Daten zu erzeugen, während das virtuelle Fahrzeug innerhalb der virtuellen Umgebung durchquert, umfasst, Ausführen durch den Prozessor eines Algorithmus zum Verarbeiten der simulierten Daten, um die eine oder mehreren Fahrspuren zu erfassen, und Aufzeichnen durch den Prozessor einer Ausgabe des Algorithmus.
Verfahren nach Anspruch 1, das ferner Folgendes umfasst: Kommentieren der simulierten Daten mit der Ausgabe des Algorithmus.
Verfahren nach Anspruch 1, wobei die virtuelle Fahrumgebung ferner eine Mehrzahl von Fahrspurenmarkierungen umfasst, die der einen oder den mehreren Fahrspuren entsprechen, und eine Mehrzahl virtueller Objekte, die entweder stationär oder in Bezug zu der virtuellen Fahrumgebung beweglich sind, wobei der eine oder die mehreren virtuellen Sensoren jede der Mehrzahl von Fahrspurmarkierungen und jedes der Mehrzahl virtueller Objekte erfassen kann und wobei die simulierten Daten die virtuelle Fahrumgebung, wie sie von dem einen oder den mehreren virtuellen Sensoren, die die Mehrzahl von Fahrspurmarkierungen und die Mehrzahl virtueller Objekte erfassen, wahrgenommen werden, charakterisieren.
Verfahren nach Anspruch 1, wobei der eine oder die mehreren virtuellen Sensoren eine virtuelle Kamera umfassen und wobei die simulierten Daten ein oder mehrere virtuelle Bilder der virtuellen Fahrumgebung, wie sie von der virtuellen Kamera wahrgenommen wird, umfassen.
Verfahren nach Anspruch 4, das ferner Folgendes umfasst: Kommentieren der simulierten Daten mit der Ausgabe des Algorithmus, und Anzeigen auf dem einen oder den mehreren virtuellen Bildern einer Mehrzahl überlagerter Markierungen, wobei die Mehrzahl überlagerter Markierungen eine oder mehrere Lagen einer oder mehrerer Grenzen der mindestens einen der einen oder mehreren Fahrspuren angeben.
Verfahren nach Anspruch 1, wobei die Ausgabe des Algorithmus eine oder mehrere Lagen der einen oder mehreren Grenzen der mindestens einen der einen oder mehreren Fahrspuren umfasst.
Verfahren nach Anspruch 6, wobei die eine oder mehreren Lagen der einen oder mehreren Grenzen der mindestens einen der einen oder mehreren Fahrspuren eine Mehrzahl von Punkten jeweils mit einer jeweiligen räumlichen Koordinate innerhalb der virtuellen Fahrumgebung umfassen, wobei die Mehrzahl von Punkten gemeinsam der einen oder den mehreren Lagen der einen oder mehreren Grenzen der mindestens einen der einen oder mehreren Fahrspuren entspricht.
Verfahren nach Anspruch 7, das ferner Folgendes umfasst: Kommentieren der simulierten Daten mit den räumlichen Koordinaten der Mehrzahl von Punkten.
Verfahren nach Anspruch 6, das ferner Folgendes umfasst: Erzeugen von Ground-Truth-Daten für die mindestens eine der einen oder mehreren Fahrspuren, wobei die Ground-Truth-Daten eine oder mehrere tatsächliche Lagen der einen oder mehreren Grenzen der mindestens einen der einen oder mehreren Fahrspuren innerhalb der virtuellen Fahrumgebung darstellen.
Verfahren nach Anspruch 9, das ferner Folgendes umfasst: Aufzeichnen eines Unterschieds zwischen den Ground-Truth-Daten und der Ausgabe des Algorithmus.
Verfahren nach Anspruch 9, das ferner Folgendes umfasst: Kommentieren der simulierten Daten mit den Ground-Truth-Daten.
Verfahren nach Anspruch 1, wobei das Aufzeichnen das Aufzeichnen eines Zeitstempels der Ausgabe des Algorithmus umfasst.
Verfahren nach Anspruch 1, wobei der eine oder die mehreren virtuellen Sensoren auf dem virtuellen Fahrzeug gemäß einem Modell mit stationärem Fahrzeug, das eine Lage des einen oder der mehreren virtuellen Sensoren in Bezug zu dem virtuellen Fahrzeug modelliert, installiert sind und wobei das virtuelle Fahrzeug innerhalb der virtuellen Umgebung gemäß einem Modell mit dynamischem Fahrzeug, das Bewegungen des virtuellen Fahrzeugs modelliert, durchquert.
Fahrspurgrenzen-Erfassungsprüfstand, der Folgendes umfasst: einen oder mehrere Prozessoren, die konfiguriert sind, um einen Fahrspurgrenzen-Erfassungsalgorithmus auszuführen, und einen Speicher, der betrieblich mit dem einen oder den mehreren Prozessoren verbunden ist, wobei der Speicher eine Mehrzahl von Codes speichert, die durch den einen oder die mehreren Prozessoren ausführbar sind, wobei die Mehrzahl von Codes Folgendes umfasst: ein virtuelles Fahrumgebungsmodul, das programmiert ist, um eine virtuelle Fahrumgebung zu erzeugen, die eine Definition einer oder mehrerer Fahrspuren, eine Mehrzahl von Fahrspurmarkierungen, die mit der einen oder den mehreren Fahrspuren assoziiert sind, und eine Mehrzahl virtueller Objekte umfasst, ein erstes Softwaremodell, das programmiert ist, um einen Sensor zu modellieren, ein zweites Softwaremodell, das programmiert ist, um stationäre Merkmale eines Fahrzeugs, das den Sensor trägt, zu modellieren, ein drittes Softwaremodell, das programmiert ist, um dynamische Merkmale des Fahrzeugs, das den Sensor trägt, zu modellieren, und ein Simulationsmodul, das programmiert ist, um den einen oder die mehreren Prozessoren zu veranlassen, das virtuelle Fahrumgebungsmodul, das erste Softwaremodell, das zweite Softwaremodell und das dritte Softwaremodell zu verwenden, um Daten zu erzeugen, die eine Ausgabe des Sensors in einem Real-World-Szenario modellieren, in dem der Sensor auf dem Fahrzeug installiert ist, wenn das Fahrzeug in einer tatsächlichen Fahrumgebung, die der virtuellen Fahrumgebung ähnlich ist oder mit ihr übereinstimmt, gefahren wird, wobei der Fahrspurgrenzen-Erfassungsalgorithmus programmiert ist, um beim Ausführen durch den einen oder die mehreren Prozessoren den einen oder die mehreren Prozessoren zu veranlassen, eine oder mehrere Lagen einer oder mehrerer Grenzen der einen oder mehreren Fahrspuren zu bestimmen.
Fahrspurgrenzen-Erfassungsprüfstand nach Anspruch 14, wobei das Simulationsmodul ferner programmiert ist, um den einen oder die mehreren Prozessoren zu veranlassen, die Daten mit der einen oder den mehreren Lagen der einen oder mehreren Grenzen der einen oder mehreren Fahrspuren zu kommentieren.
Fahrspurgrenzen-Erfassungsprüfstand nach Anspruch 14, wobei das Simulationsmodul ferner programmiert ist, um den einen oder die mehreren Prozessoren zu veranlassen, die Daten mit Ground-Truth-Daten, die eine Lage der einen oder mehreren Fahrspuren charakterisieren, gemäß der Definition der einen oder mehreren Fahrspuren zu kommentieren.
Fahrspurgrenzen-Erfassungsprüfstand nach Anspruch 14, wobei das Simulationsmodul einen Satz von Einflussparametern umfasst, die programmiert sind, um den einen oder die mehreren Prozessoren zu veranlassen, die Daten zu beeinflussen, um mindestens eine Witterungsbedingung, eine Tageszeit, das Altern des Sensors und des Fahrzeugs zu berücksichtigen.
Fahrspurgrenzen-Erfassungsprüfstand nach Anspruch 14, wobei der Sensor eine virtuelle Kamera umfasst und wobei die Daten ein oder mehrere virtuelle Bilder der virtuellen Fahrumgebung, wie sie von der virtuellen Kamera wahrgenommen wird, umfassen.
Fahrspurgrenzen-Erfassungsprüfstand nach Anspruch 14, wobei der Sensor ein virtuelles Light-Detection-And-Ranging(LIDAR)-Gerät umfasst und wobei die Daten Informationen umfassen, die für die eine oder mehreren Fahrspurgrenzen, wie sie von dem virtuellen LIDAR-Gerät wahrgenommen werden, repräsentativ sind.
Fahrspurgrenzen-Erfassungsprüfstand nach Anspruch 14, wobei der Speicher ferner die Daten und die eine oder mehreren Lagen der einen oder mehreren Grenzen der einen oder mehreren Fahrspuren mit einem Zeitstempel speichert.