DE102016100492A1

DE102016100492A1 - Virtueller autonomer Antwortprüfstand

Info

Publication number: DE102016100492A1
Application number: DE102016100492.8A
Authority: DE
Inventors: Arthur Alaniz; Ashley Elizabeth Micks; Vidya Nariyambut murali; Sneha Kadetotad; Harpreetsingh Banvait; Jinesh J. Jain
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-01-21
Filing date: 2016-01-13
Publication date: 2016-07-21
Also published as: GB201601126D0; GB2536549A; RU2015156117A; US20160210383A1; CN105809103A; MX2016000873A

Abstract

Eine Computervorrichtung beinhaltet eine Prozessorschaltung und ein Datenspeichermedium und ist programmiert zum Empfangen einer Benutzereingabe, die eine Fahrzeugsteueraktion darstellt, die mit Betrieb eines virtuellen Fahrzeugs in einer virtuellen Umwelt assoziiert ist, zum virtuellen Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt gemäß der Fahrzeugsteueraktion, zum Sammeln von Daten virtueller Sensoren und zum Verarbeiten der gesammelten Daten virtueller Sensoren.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung mit der Serien-Nr. 62/106,074 mit dem Titel “VIRTUAL SENSOR TESTBED”, eingereicht am 21. Januar 2015, deren Inhalt hiermit durch Bezugnahme in seiner Gesamtheit aufgenommen wird. Diese Anmeldung bezieht sich auf die US-Ser.-Nr. 14/945,744 mit dem Titel “AUTONOMOUS DRIVING IN REFINED VIRTUAL ENVIRONMENTS”, eingereicht am 19. November 2015 und die US-Ser.-Nr. 14/945,791 mit dem Titel “VIRTUAL SENSOR TESTBED”, eingereicht am 19. November 2015.
HINTERGRUND
Von autonomen Fahrzeugen wird erwartet, dass sie gewisse Schilder entlang des Straßenrandes interpretieren. Zum Beispiel wird erwartet, dass autonome Fahrzeuge an Stopp-Schildern anhalten. Eine Möglichkeit für autonome Fahrzeuge, Schilder zu interpretieren, ist es, die autonomen Fahrzeuge durch Sammeln von Daten realexistierender Sensoren zu "lehren", wie ein bestimmtes Schild aussieht. Sammeln von Daten realexistierender Sensoren beinhaltet das Aufsetzen physischer Tests oder das Herumfahren mit Sensoren, um relevante Daten zu sammeln. Im Zusammenhang mit dem Identifizieren von Straßenbeschilderung kann das Sammeln von Sensordaten das Sammeln von tausenden von Bildern verschiedener Straßenbeschilderungen beinhalten. Gemäß dem "Manual on Uniform Traffic Control Devices" gibt es mehr als 500 US-weit zugelassene Verkehrsschilder.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 veranschaulicht ein autonomes Beispielfahrzeug mit einem System, das zum Empfangen und Verarbeiten von Daten virtueller Sensoren programmiert ist.
2 ist ein Blockschaltbild von Beispielkomponenten des autonomen Fahrzeugs.
3A veranschaulicht eine Beispielansicht einer virtuellen Umwelt, die dafür programmiert ist, Daten virtueller Sensoren zu erzeugen.
3B veranschaulicht eine weitere Beispielansicht einer virtuellen Umwelt, die dafür programmiert ist, Daten virtueller Sensoren zu erzeugen.
4 ist ein Prozess-Flussdiagramm eines Beispielprozesses, der implementiert sein kann, um ein oder mehr virtuelle Fahrzeug-Subsysteme in einer virtuellen Umwelt zu testen und/oder zu trainieren.
AUSFÜHRLICHE BESCHREIBUNG
Die Entwicklung eines autonomen Fahrzeugs beinhaltet das Testen autonomer Prozesse relativ zu der Fahrumwelt. Diverse Testszenarien werden verwendet, um die autonomen Prozesse sorgfältig zu validieren. Eine virtuelle Umwelt wird als eine Alternative zum Testen in der realexistierenden Welt offenbart. Die offenbarte virtuelle Umwelt kann ein virtuelles Testbett für autonome Fahrprozesse beinhalten. Sensormodelle und Bildverarbeitungs-Software können mit virtuellen Umwelten und dynamischen, interaktiven Fahrszenarien zusammenschalten. Virtuelle Tests können eine breitgefächerte und sogfältige Validierung von Fahrprozessen liefern, um das Testen mit realen Fahrzeugen zu ergänzen und vorzubereiten. Verglichen mit Tests in der realexistierenden Welt können virtuelle Tests hinsichtlich Zeit, Geld und Ressourcen billiger sein. Bei simulierten Fahrszenarien können damit minimale Risiken verbunden sein, die in Tests in der real existierenden Welt gefährlich oder schwer zu simulieren sein würden, was es leichter macht, in einer großen Bandbreite und einer großen Anzahl von Szenarien zu testen und dieses früh im Prozess des Entwickelns autonomer Steuerungen durchzuführen. Das Werkzeug kann während der Entwicklung von Sensorfusionsprozessen für autonomes Fahren durch Integrieren von Kameras mit Lidar-, Radar- und Ultraschall-Sensoren und dem Bestimmen der Fahrzeugreaktion auf die interpretierten Sensordaten verwendet werden.
Die Prozesse können Sensordaten aufnehmen und Schlüsselelemente der virtuellen Fahrzeugumgebung identifizieren, die unter Verwendung der Probedaten entworfen und verfeinert werden müssen. Zum Beispiel können Klassifizierer, die Straßenbeschilderung identifizieren, unter Verwendung von Bildern dieser Schilder trainiert werden müssen, einschließlich einer großen und breitgefächerten Menge von Bildern, um Datensatzbeeinflussung zu vermeiden und richtige Detektion unter einer Bandbreite von Bedingungen zu fördern. In der virtuellen Umwelt können tausende von simulierten Kamerabildern in Sekunden erstellt werden, was diesen Ansatz zu einem effektiven Verfahren des Minimierens von Beeinflussung und des Optimierens von Klassifizierer-Leistung macht. Es würde auch möglich sein, eine Datenbank zu erstellen, die alle Verkehrsschilder in den USA repräsentiert.
Ein Kaskaden-Klassifizierer, der in der OpenCV-C++-Bibliothek gefunden werden kann, kann dazu verwendet werden, eine Vielzahl von Straßenbeschilderungen zu identifizieren. Bilder dieser Schilder können in der virtuellen Umwelt mit zufälliger Orientierung, zufälligem Abstand von der Kamera, zufälligen Beschattungs- und Beleuchtungsbedingungen und teilweiser Verdeckung erzeugt werden. Ein maschineller Lernprozess kann diese Bilder zusammen mit der Position und der Umrahmung der Verkehrszeichen in ihnen als Eingaben aufnehmen, unter Verwendung von Bildverarbeitungstechniken Merkmale erzeugen und Klassifizierer trainieren, jeden Schildertyp zu erkennen. Ähnliche Prozesse können implementiert werden, um Detektions- und Erkennungsprozesse für andere Sensortypen zu entwickeln.
Die gezeigten Elemente können viele verschiedene Formen annehmen und mehrere und/oder alternative Komponenten und Ausstattungen beinhalten. Die veranschaulichten Beispielkomponenten sind nicht dafür gedacht, beschränkend zu sein. Tatsächlich können zusätzliche oder alternative Komponenten und/oder Implementierungen verwendet werden.
Wie in 1 veranschaulicht, beinhaltet das autonome Fahrzeug 100 ein Fahrzeugsystem 105, das dafür programmiert ist, Daten virtueller Sensoren zu empfangen, die von einer Computervorrichtung 110 in einer virtuellen Umwelt erzeugt werden. Die Computervorrichtung 110 kann dafür programmiert sein, die virtuelle Umwelt zu simulieren. Die virtuelle Umwelt kann mehrere Fahrszenarien präsentieren. Jedes Fahrszenario kann eine Straße mit verschiedenen Objekten auf der Straße oder entlang der Straßenränder beinhalten. Zum Beispiel kann das Fahrszenario andere Fahrzeuge, bewegend oder geparkt, Straßenschilder, Bäume, Büsche, Gebäude, Fußgänger oder dergleichen beinhalten. Die verschiedenen Fahrszenarien können ferner verschiedene Wetterbedingungen wie etwa Regen, Schnee, Nebel usw. beinhalten. Darüber hinaus können die Fahrszenarien verschiedene Typen von Straßen oder Gelände definieren. Beispiele dafür können Autobahnen, ebenerdige Straßen, Bergstraßen oder dergleichen beinhalten.
Die Computervorrichtung 110, die ein Datenspeichermedium 110A und eine Prozessorschaltung 110B enthalten kann, kann dafür programmiert sein, ein virtuelles Fahrzeug zu simulieren, das durch die virtuelle Umwelt fährt. Die Simulation kann virtuelle Sensoren beinhalten, die Daten virtueller Sensoren sammeln, die auf den in der virtuellen Umwelt präsentierten Bedingungen basieren. Die Computervorrichtung 110 kann dafür programmiert sein, die Daten virtueller Sensoren zu sammeln, so als würden sie in einem echten Fahrzeug gesammelt. Beispielsweise kann die Computervorrichtung 110 den virtuellen Sensor mit einer Ansicht der virtuellen Umwelt simulieren, als sei der virtuelle Sensor auf einem echten Fahrzeug. Somit können die Daten virtueller Sensoren Bedingungen der realexistierenden Welt relativ zum Detektieren von z.B. Schildern reflektieren. Unter Bedingungen der realexistierenden Welt kann die Sicht eines Fahrzeugsensors auf ein Schild zum Beispiel teilweise oder vollständig von einem Objekt, wie etwa einem anderen Fahrzeug oder einem Baum blockiert werden. Durch Simulieren der virtuellen Sensoren mit der Sicht als wären sie auf einem echten Fahrzeug kann der virtuelle Sensor virtuelle Daten sammeln, gemäß der Sicht, die der Sensor unter realexistierenden Bedingungen haben würde.
Die Ausgabe der Computervorrichtung 110 kann Daten virtueller Sensoren beinhalten, die für Testzwecke, Trainingszwecke oder beides verwendet werden können und kann die Sensordaten repräsentieren, die von virtuellen Sensoren als Ergebnis virtuellen Fahrens eines virtuellen Fahrzeugs durch die virtuelle Umwelt gesammelt werden. Die Daten virtueller Sensoren können letztendlich dafür verwendet werden, Kalibrierungsdaten zu erzeugen, die dann zu dem Fahrzeugsystem 105 hochgeladen werden können, so dass ein oder mehr Subsysteme des autonomen Fahrzeugs 100 (ein realexistierendes Fahrzeug) gemäß den Daten virtueller Sensoren kalibriert werden können, die während des Testens oder Trainierens gesammelt werden, wenn das virtuelle Fahrzeug durch die virtuelle Umwelt gefahren wird. Die Kalibrierungsdaten können von derselben oder einer anderen Computervorrichtung 110 erzeugt werden und können von mehreren Sätzen von Daten virtueller Sensoren erzeugt werden. Darüber hinaus können die während mehreren Simulationen erzeugten Daten virtueller Sensoren zusammengefasst und verarbeitet werden, um die Kalibrierungsdaten zu erzeugen. Daher muss die Computervorrichtung 110 nicht sofort nach dem Sammeln der Daten virtueller Sensoren irgendwelche Kalibrierungsdaten ausgeben. Mit den Kalibrierungsdaten können die realexistierenden Fahrzeug-Subsysteme "trainiert" werden, um gewisse Szenarien zu identifizieren, gemäß den in der virtuellen Umwelt simulierten Szenarien, wie sie durch die Daten virtueller Sensoren repräsentiert werden.
Obwohl als eine Limousine veranschaulicht, kann das Fahrzeug 100 jedwedes Personen- oder Nutzfahrzeug beinhalten, wie etwa ein Auto, einen Laster, einen SUV, ein Crossover-Fahrzeug, einen Transporter, einen Kleintransporter, ein Taxi, einen Bus usw. Ferner kann das autonome Fahrzeug 100 dafür ausgelegt sein, in einem vollautonomen (z.B. fahrerlosen) Modus oder einem teilautonomen Modus zu arbeiten.
2 veranschaulicht Beispielkomponenten des autonomen Fahrzeugs 100. Wie gezeigt beinhaltet das autonome Fahrzeug 100 eine Benutzerschnittstellen-Vorrichtung 115, ein Navigationssystem 120, eine Kommunikations-Schnittstelle 125, Autonom-Fahr-Sensoren 130, eine Autonom-Modus-Steuerung 135 und eine Verarbeitungsvorrichtung 140.
Die Benutzerschnittstellen-Vorrichtung 115 kann dafür ausgelegt oder programmiert sein, einem Benutzer, wie etwa einem Fahrer, während des Betriebs des autonomen Fahrzeugs 100, Informationen zu präsentieren. Darüber hinaus kann die Benutzerschnittstellen-Vorrichtung 115 dafür ausgelegt oder programmiert sein, Benutzereingaben zu empfangen. Somit kann die Benutzerschnittstellen-Vorrichtung 115 im Passagierabteil des autonomen Fahrzeugs 100 positioniert sein. Bei manchen möglichen Ansätzen kann die Benutzerschnittstellen-Vorrichtung 115 einen berührungsempfindlichen Anzeigebildschirm beinhalten.
Das Navigationssystem 120 kann dafür ausgelegt oder programmiert sein, eine Position des autonomen Fahrzeugs 100 zu bestimmen. Das Navigationssystem 120 kann einen Global-Positoning-System(GPS)-Empfänger beinhalten, der dafür ausgelegt oder programmiert ist, die Position des autonomen Fahrzeugs 100 relativ zu Satelliten oder erdbasierten Sendemasten zu triangulieren. Das Navigationssystem 120 kann deshalb für drahtlose Kommunikation ausgelegt oder programmiert sein. Das Navigationssystem 120 kann ferner dafür ausgelegt oder programmiert sein, Routen von einem aktuellen Standort zu einem ausgewählten Ziel zu entwickeln sowie ein Landkarte anzuzeigen und Fahranweisungen zu dem ausgewählten Ziel zu präsentieren, z.B. über die Benutzerschnittstellen-Vorrichtung 115. In manchen Fällen kann das Navigationssystem 120 die Route nach einer Benutzerpräferenz entwickeln. Beispiele für Benutzerpräferenzen können das Maximieren der Kraftstoffwirtschaftlichkeit, das Verkürzen der Reisezeit, das Fahren der kürzesten Entfernung oder dergleichen umfassen.
Die Kommunikations-Schnittstelle 125 kann dafür ausgelegt oder programmiert sein, drahtgebundene und/oder drahtlose Kommunikation zwischen den Komponenten des autonomen Fahrzeugs 100 und anderen Vorrichtungen, wie etwa einem Fernserver oder sogar einem anderen Fahrzeug zu erleichtern, wenn z.B. ein Fahrzeug-zu-Fahrzeug Kommunikationsprotokoll verwendet wird. Die Kommunikations-Schnittstelle 125 kann dafür ausgelegt oder programmiert sein, Nachrichten zu empfangen von einem und Nachrichten zu senden an einen Mast eines Mobilfunkanbieters und von dem/an das Telematik-Dienstliefernetz (SDN), das mit dem Fahrzeug assoziiert ist, das wiederum eine Kommunikation mit einer mobilen Vorrichtung eines Benutzers herstellt, wie etwa einem Mobiltelefon, einem Tablet-Computer, einem Laptop-Computer, einer Fernbedienung oder irgendeiner anderen elektronischen Vorrichtung, die für drahtlose Kommunikation über einen Zweit- oder denselben Mobilfunkanbieter ausgelegt ist. Mobilfunkkommunikation zu dem Telematik-Transceiver über das SDN kann auch von einer mit dem Internet verbundenen Vorrichtung, wie etwa einem PC, einem Laptop, einem Notebook oder einem über WiFi verbundenen Telefon, aufgebaut werden. Die Kommunikations-Schnittstelle 125 kann auch dafür ausgelegt oder programmiert sein, direkt von dem autonomen Fahrzeug 100 mit der Fernvorrichtung des Benutzers oder irgendeiner anderen Vorrichtung zu kommunizieren, die irgendeine Anzahl von Kommunikationsprotokollen, wie etwa Bluetooth^®, Niederenergie-Bluetooth^® oder WiFi verwendet. Ein Beispiel für ein Fahrzeug-zu-Fahrzeug Kommunikationsprotokoll kann z.B. das dedizierte Kurzreichweiten-Kommunikations(DSRC)-Protokoll beinhalten. Dementsprechend kann die Kommunikations-Schnittstelle 125 dafür ausgelegt oder programmiert sein, Nachrichten von einem/an einen Fernserver und/oder von anderen/an andere Fahrzeuge zu empfangen und/oder zu senden.
Die Autonom-Fahr-Sensoren 130 können eine beliebige Anzahl von Vorrichtungen beinhalten, die dafür ausgelegt oder programmiert sind, Signale zu erzeugen, die dem autonomen Fahrzeug 100 helfen, während das autonome Fahrzeug 100 in dem autonomen (d.h. fahrerlosen) Modus betrieben wird. Beispiele für Autonom-Fahr-Sensoren 130 können einen Radar-Sensor, einen Lidar-Sensor, einen visuellen Sensor oder dergleichen beinhalten. Die Autonom-Fahr-Sensoren 130 helfen dem autonomen Fahrzeug 100 die Straße und die Fahrzeugumgebung zu "sehen" und/oder verschiedene Hindernisse anzugehen, während das Fahrzeug in dem autonomen Modus betrieben wird. In einer möglichen Implementierung können die Autonom-Fahr-Sensoren 130 gemäß den virtuellen Fahrdatenausgaben von der Rechenvorrichtung 110 als ein Ergebnis der von den vis-à-vis der virtuellen Umwelt durchgeführten Simulationen kalibriert werden.
Die Autonom-Modus-Steuerung 135 kann dafür ausgelegt oder programmiert sein, ein oder mehr Subsysteme 145 zu steuern, während das Fahrzeug in dem autonomen Modus betrieben wird. Beispiele für Subsysteme 145, die von der Autonom-Modus-Steuerung 135 gesteuert werden, können ein Bremsen-Subsystem, ein Fahrwerk-Subsystem, ein Lenkungs-Subsystem und ein Antriebsstrang-Subsystem beinhalten. Die Autonom-Modus-Steuerung 135 kann ein oder mehr beliebige dieser Subsysteme 145 durch Ausgeben von Signalen steuern, um mit diesen Subsystemen 145 assoziierte Einheiten zu steuern. Die Autonom-Modus-Steuerung 135 kann die Subsysteme 145 zumindest teilweise basierend auf Signalen steuern, die von den Autonom-Fahr-Sensoren 130 erzeugt werden. In einem möglichen Ansatz kann die Autonom-Modus-Steuerung 135 gemäß den virtuellen Fahrdatenausgaben von der Rechenvorrichtung 110 als ein Ergebnis der von den vis-à-vis der virtuellen Umwelt durchgeführten Simulationen kalibriert werden.
Die Verarbeitungsvorrichtung 140 kann dafür programmiert sein, die virtuellen Datensignale, die von der Computervorrichtung 110 erzeugt werden, zu empfangen und zu verarbeiten. Verarbeiten der virtuellen Datensignale kann z.B. das Erzeugen von Kalibrierungs-Einstellungen für die Autonom-Fahr-Sensoren 130, die Autonom-Modus-Steuerung 135 oder beide beinhalten. Die Kalibrierungs-Einstellungen können die Autonom-Fahr-Sensoren 130 und die Autonom-Modus-Steuerung 135 "lehren", die Umwelt um das autonome Fahrzeug 100 besser zu interpretieren.
3A–3B veranschaulichen Beispielansichten einer virtuellen Umwelt 150, die dafür programmiert ist, Daten virtueller Sensoren zu erzeugen. 3A zeigt eine virtuelle Ansicht eines Bord-Sensors, wie etwa einer Kamera. Mit anderen Worten gesagt, zeigt 3A wie die Kamera die virtuelle Umwelt 150 "sehen" würde. Dagegen zeigt 3B eine mögliche „Experimentator“-Ansicht. Die „Experimentator"-Ansicht ermöglicht es der Kamera oder einem anderen Sensor, außerhalb des virtuellen Fahrzeugs, im Fahrersitz des virtuellen Fahrzeugs oder sonst irgendwo relativ zu dem virtuellen Fahrzeug positioniert zu sein.
Mit den in der virtuellen Umwelt 150 präsentierten interaktiven virtuellen Szenarien kann der Benutzer das virtuelle Fahrzeug durch die virtuelle Umwelt 150 fahren, um Schilder- und Hindernis-Detektionsprozesse zu testen, autonome Fahrprozessleistung zu beobachten oder mit dem Umschalten zwischen autonomen und manuellen Fahrmodi zu experimentieren. Die virtuelle Umwelt 150 kann, wie in 3A gezeigt in Echtzeit die Ausgabe z.B. des Verkehrsschild-Detektionsklassifizierers präsentieren, die den Standort und den Durchmesser von jedem detektierten Schild anzeigt.
Die Computervorrichtung 110 integriert eine virtuelle Fahrumwelt, die unter Verwendung von drei-dimensionalen Modellierungs- und Animationswerkzeugen erschaffen wird, mit Sensormodellen, um die Daten virtueller Sensoren in einer relativ kurzen Zeitdauer in großen Mengen zu erstellen. Relevante Parameter, wie etwa Beleuchtung und Verkehrsschild-Orientierung, im Falle einer Schilder-Detektion, können in den aufgezeichneten Daten zufällig angeordnet werden, um eine breitgefächerte Datenmenge mit minimaler Beeinflussung sicherzustellen. Ferner können gewisse Systeme der virtuellen Fahrzeuge innerhalb der virtuellen Umwelt gesteuert werden. Zum Beispiel können die Drosselklappe, die Bremse, die Lenkung des virtuellen Fahrzeugs und andere Fahrereingaben gesteuert werden. Dadurch kann die Computervorrichtung 110 testen wie ein real existierendes autonomes Fahrzeug auf die verschiedenen Bedingungen reagieren kann, die über die virtuelle Umwelt präsentiert werden. Mit anderen Worten gesagt, kann die Rechenvorrichtung 110 unter Verwendung des virtuellen Fahrzeugs in der virtuellen Umwelt simulieren, wie ein realexistierendes Fahrzeug reagieren würde, wenn ihm Sensordaten präsentiert würden, die z.B. den oben erörterten Daten virtueller Sensoren ähnlich sind.
Verglichen mit dem Sammeln von Daten einer realexistierenden Welt kann das Sammeln virtueller Daten hinsichtlich Zeit, Geld und Ressourcen günstiger sein. In nur wenigen Minuten können tausende von virtuellen Bildern eines gegebenen Verkehrszeichentyps empfangen und analysiert werden. Das Sammeln einer vergleichbaren Anzahl von Daten der realexistierenden Welt würde Stunden benötigen.
4 ist ein Prozessflussdiagramm eines Beispielprozesses 400 zum Testen und/oder Trainieren von einem oder mehr Autonom-Fahr-Sensoren 130 gemäß den Daten virtueller Sensoren, die während des Befahrens der virtuellen Umwelt gesammelt werden.
Bei Block 405 kann die Computervorrichtung 110 die Simulation der virtuellen Umwelt laden. Die Simulation der virtuellen Umwelt kann Elemente beinhalten, die für ein autonomes Fahrzeug während Betriebs in einer realexistierenden Welt sichtbar sein würden. Beispielsweise kann die virtuelle Umwelt virtuelle Straßen, Bäume, Schilder, Verkehrssteuerungs-Vorrichtungen (wie Ampeln), Brücken und andere Infrastruktur-Vorrichtungen beinhalten, wie etwa Straßenbeleuchtung, andere Fahrzeuge, Fußgänger, Gebäude, Gehwege, Bordsteine usw. Darüber hinaus kann die virtuelle Umwelt dafür programmiert sein, unterschiedliche Straßen und Strukturen zu präsentieren. Beispielsweise können die verschiedenen Straßen eine Kreuzung, eine Landstraße, eine Wohnstraße mit geparkten Autos, ein städtisches Gebiet, ein ländliches Gebiet, eine Autobahn, eine Auffahrspur, eine Abfahrspur, einen Tunnel, eine Brücke, eine unbefestigte oder Schotterstraße, Straßen mit verschiedenen Krümmungen und Straßenordnungen, ebene Straßen, Straßen mit Schlaglöchern, eine Straße, die über Schienen führt usw. beinhalten. Ferner kann die virtuelle Umwelt verschiedene Wetter- und Beleuchtungsbedingungen simulieren. Beispielsweise kann die virtuelle Umwelt Regen, Schnee, Eis usw. simulieren sowie Lichtverhältnisse bei Morgendämmerung, Tageszeit, Abend, Abenddämmerung und Nacht.
Bei Block 410 kann die Computervorrichtung 110 Benutzereingaben empfangen, die verschiedene Testparameter auswählen. Die Testparameter können z.B. eine Benutzereingabe enthalten, die den Typ von Fahrbedingungen auswählt. Die Benutzereingabe kann demnach eine Auswahl der Wetterbedingungen, der Beleuchtungsbedingungen oder von beiden (z.B. Regen in der Abenddämmerung) beinhalten sowie eine Auswahl beliebiger anderer Faktoren, einschließlich des Straßen- oder Gebietstyps (z.B. Kreuzung, Landstraße, städtisches Gebiet, ländliches Gebiet usw.).
Bei Block 415 kann die Computervorrichtung 110 die virtuelle Umwelt gemäß den bei Block 410 empfangenen Benutzereingaben erzeugen. Die virtuelle Umwelt kann auf einem Anzeigebildschirm 155 präsentiert werden. Die virtuelle Umwelt kann gemäß der oben erörterten „Experimentator“-Ansicht oder der Ansicht von einem oder mehr der Autonom-Fahrzeug-Sensoren 130 präsentiert werden, wie etwa einer Bordkamera. Darüber hinaus kann der Anzeigebildschirm die virtuelle Umwelt mit verschiedenen Bedingungen präsentieren, die bei Block 405 ausgewählt wurden, einschließlich Wetterbedingungen, Beleuchtungsbedingungen oder dergleichen. Bei manchen möglichen Ansätzen kann das Erzeugen der virtuellen Umwelt das Erzeugen zufälliger Testparameter beinhalten. Beispiel für zufällige Testparameter können z.B. eine zufällige Beleuchtungsbedingung, eine zufällige Wetterbedingung, eine zufällige Schilderplatzierung, eine zufällige Schilderausrichtung usw. beinhalten.
Bei Block 420 kann die Computervorrichtung 110 das virtuelle Fahrzeug durch die virtuelle Umwelt fahren. Das Fahren durch die virtuelle Umwelt kann das Bestimmen eines Endpunktes, über z.B. eine Benutzereingabe, und das Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt zu dem Endpunkt beinhalten. Der autonome Betrieb des virtuellen Fahrzeugs kann auf den Sensoreingaben basieren, so als ob das virtuelle Fahrzeug ein autonomes Fahrzeug wäre, das in einer realexistierenden Umwelt fährt, die von der Computervorrichtung 110 simuliert wird. Alternativ kann das Fahren in der virtuellen Umwelt das Anzeigen der virtuellen Umwelt, wie sie einem oder mehreren Autonom-Fahr-Sensoren 130 erscheinen würde, umfassen. So kann, statt dem Zeigen des virtuellen Fahrzeugs wie es durch die virtuelle Umwelt fährt oder der Sicht des virtuellen Fahrers, ein Benutzer einfach verschiedene Sichten der Autonom-Fahr-Sensoren 130 sehen.
In einer möglichen Implementierung kann die Computervorrichtung 110 bei Block 420 das virtuelle Fahrzeug, als Reaktion auf eine Benutzereingabe, die eine Fahrzeugsteueraktion repräsentiert, durch die virtuelle Umwelt fahren. Die Fahrzeugsteueraktion kann Befehle beinhalten, die bestimmte virtuelle Systeme in dem virtuellen Fahrzeug steuern. Beispiele derartiger Systeme können ein virtuelles Drosselklappensystem, ein virtuelles Bremssystem, ein virtuelles Lenksystem oder dergleichen beinhalten. Somit können die virtuellen Fahrzeug-Befehle dafür verwendet werden, das virtuelle Fahrzeug in Echtzeit virtuell durch die virtuelle Umwelt zu fahren.
Bei Block 425 kann die Computervorrichtung 110 Daten virtueller Sensoren erzeugen, die die Daten repräsentieren, die von den virtuellen Sensoren gesammelt wurden. Die Daten virtueller Sensoren können demnach die Daten repräsentieren, die von realexistierenden Autonom-Fahrzeug-Sensoren 130 beim Fahren durch eine realexistierende Umwelt gesammelt würden, die mit der simulierten Umwelt identisch ist. Beispielsweise können die Daten virtueller Sensoren angeben, ob der Autonom-Fahrzeug-Sensor 130 z.B. ein Stopp-Schild erkannt haben würde, das teilweise versteckt ist, wie etwa teilweise von einem Baum verdeckt oder bei schlechten Beleuchtungsbedingungen (z.B. in der Abenddämmerung oder bei Nacht, ohne nahegelegene Straßenbeleuchtung). Bei einem möglichen Ansatz beinhaltet das Erzeugen der Daten virtueller Sensoren das Aufnehmen von Kamerabilddaten oder von Sensordaten mit Ray-Tracing, abhängig vom Sensortyp, und Speichern der aufgenommenen Kamerabilddaten oder der Sensordaten mit Ray-Tracing in einer Speichervorrichtung, wo auf sie zugegriffen werden kann und wo sie gemäß einem Signalverarbeitungscode verarbeitet werden können. Die Daten können, bevor sie z.B. an ein Objektdetektionsmodul ausgegeben werden, auf eine Weise verarbeitet werden, die die Grenzen realexistierender Sensoren widerspiegeln. Das Objektdetektionsmodul kann die simulierten Sensordaten verarbeiten und Informationen ausgeben, die relative Position, Größe und Objekttyp über irgendwelche detektierte Objekte beinhalten. Detektierte Objekte können unter Verwendung von Markierungen und Beschriftungen angezeigt werden, die über ein Simulationsfenster (z.B. den Anzeigebildschirm 155) gelegt werden, das die Sicht von jedem Sensor aus zeigt. Die Ausgabe der Rechenvorrichtung kann zeitgestempelt und für späteres Studieren oder spätere Verwendung in eine Datei geschrieben werden.
Bei Block 430 kann die Computervorrichtung 110 die Daten virtueller Sensoren verarbeiten, um Ausgangsdaten zu erzeugen, die Testdaten, Lerndaten oder beides enthalten können. Die Ausgangsdaten können auf den Daten virtueller Sensoren basieren, die bei Block 425 erzeugt wurden. Das bedeutet, dass Ausgangsdaten helfen können, bestimmte Einstellungen für die Autonom-Fahr-Sensoren 130 zu identifizieren, um Straßenbeschilderung, Fußgänger, Spurmarkierungen, andere Fahrzeuge usw. unter den bei Block 410 ausgewählten Umständen geeignet zu identifizieren. In einigen Fällen können die Ausgangsdaten Trends in den Daten virtueller Sensoren repräsentieren, die Einstellungen beinhalten, die mit dem Identifizieren der größten Anzahl von Objekten unter dem größten Satz von Umständen assoziiert sind. In anderen Fällen können die Ausgangsdaten spezifisch für einen Satz von Umständen sein, wobei in diesem Fall mehrere Sätze von Ausgangsdaten für letztendliche Verwendung in dem autonomen Fahrzeug 100 erzeugt werden. Letztendlich können die Ausgangsdaten, oder eine Zusammenfassung von Ausgangsdaten, in das Fahrzeugsystem 105 geladen werden, z.B. als Kalibrierungsdaten, die in einem realexistierenden autonomen Fahrzeug 100 betrieben werden. Wenn die Kalibrierungsdaten in das Fahrzeugsystem 105 geladen werden, können die Autonom-Fahr-Sensoren 130 die geeigneten Einstellungen anwenden, um Objekte unter den bei Block 410 ausgewählten Umständen richtig zu identifizieren.
Im Allgemeinen können die beschriebenen Computersysteme und/oder -vorrichtungen ein beliebiges einer Reihe von Computerbetriebssystemen einsetzen, einschließlich, jedoch auf keinen Fall eingeschränkt auf, Versionen und/oder Varianten des Ford Sync^® Betriebssystems, des Microsoft Windows^®-Betriebssystems, des Unix-Betriebssystems (z. B. das Solaris^®-Betriebssystem, das von der Oracle Corporation in Redwood Shores, Kalifornien, USA, vertrieben wird), des AIX-UNIX-Betriebssystems, das von International Business Machines in Armonk, New York, USA, vertrieben wird, des Linux-Betriebssystems, der MacOSX- und -iOS-Betriebssysteme, die von der Apple Inc. in Cupertino, Kalifornien, USA, vertrieben werden, des BlackBerry OS, das von der Blackberry, Ltd. in Waterloo, Kanada vertrieben wird, und des Android-Betriebssystems, das von der Google, Inc. und der Open Handset Alliance entwickelt wird. Beispiele für Rechenvorrichtungen beinhalten unter anderem einen Fahrzeug-Bordcomputer, eine Computer-Workstation, einen Server, einen Tisch-, Notebook-, Laptop- oder Hand-Computer oder ein(e) sonstige(s) andere(s) Rechensystem und/oder -Vorrichtung.
Computervorrichtungen beinhalten allgemein computer-ausführbare Anweisungen, wobei die Anweisungen von einer oder mehreren wie den oben aufgelisteten Rechenvorrichtungen ausgeführbar sein können. Computer-ausführbare Anweisungen können aus Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung vielfältiger Programmiersprachen und/oder -technologien erstellt werden, darunter, aber ohne Beschränkung und entweder alleine oder in Kombination, Java^TM, C, C++, Visual Basic, Java Script, Perl usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen z. B. aus einem Speicher, einem computer-lesbaren Medium usw. und führt diese Anweisungen aus, um dadurch einen oder mehrere Prozesse, einschließlich eines oder mehrerer der hier beschriebenen Prozesse, auszuführen. Solche Anweisungen und andere Daten können unter Verwendung vielfältiger computer-lesbarer Medien gespeichert und übertragen werden.
Ein computerlesbares Medium (auch als ein prozessorlesbares Medium bezeichnet) beinhaltet ein beliebiges nicht-vergängliches (z. B. physisches) Medium, das an einer Bereitstellung von Daten (z.B. Anweisungen) teilhat, die von einem Computer gelesen werden können (z.B. von einem Prozessor eines Computers). Ein solches Medium kann viele Formen annehmen, darunter, aber ohne Beschränkung darauf, nicht-flüchtige Medien und flüchtige Medien. Nicht-flüchtige Medien können zum Beispiel optische oder magnetische Datenträger und andere persistente Speicher beinhalten. Flüchtige Medien können zum Beispiel einen dynamischen Direktzugriffsspeicher (DRAM), der typischerweise einen Hauptspeicher bildet, beinhalten. Derartige Anweisungen können von einem oder mehreren Übertragungsmedien, einschließlich Koaxialkabeln, Kupferdraht und Glasfasern, einschließlich denen, die einen Systembus umfassen, der mit einem Prozessor eines Computers gekoppelt ist, übertragen werden. Übliche Formen von computer-lesbaren Medien umfassen zum Beispiel eine Floppy-Disk, eine Diskette, eine Festplatte, ein Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, eine DVD, ein beliebiges anderes optisches Medium, Lochkarten, Papierband, ein beliebiges anderes physisches Medium mit einem Muster von Löchern, einen RAM, einen PROM, einen EPROM, einen Flash-EEPROM, einen beliebigen anderen Speicherchip oder eine Speicherkassette oder ein beliebiges anderes Medium, woraus ein Computer lesen kann.
Zu Datenbanken, Datensammlungen oder anderen Datenspeichern, die hierin beschrieben sind, können verschiedene Arten von Mechanismen zum Speichern und Abrufen verschiedener Arten von Daten sowie Zugreifen auf diese zählen, einschließlich einer hierarchischen Datenbank, eines Dateisatzes in einem Dateisystem, einer Anwendungsdatenbank in einem proprietären Format, eines relationalen Datenbankverwaltungssystems (relational database management system, RDBMS) usw. Jeder derartige Datenspeicher ist allgemein in einer Rechenvorrichtung enthalten, die ein Computerbetriebssystem einsetzt, wie eines der oben erwähnten, und auf ihn wird mittels eines Netzes auf eine beliebige oder beliebige mehrere einer Vielfalt von Methoden zugegriffen. Ein Dateisystem kann von einem Computerbetriebssystem zugreifbar sein und kann Dateien beinhalten, die in vielfältigen Formaten gespeichert sein können. Ein RDBMS wendet allgemein die Structured Query Language (SQL) an, zusätzlich zu einer Sprache zum Schaffen, Speichern, Bearbeiten und Ausführen gespeicherter Prozeduren, wie etwa die oben erwähnte PL/SQL-Sprache.
In einigen Beispielen sind Systemelemente möglicherweise als computerlesbare Anweisungen (z.B. Software) auf einer oder mehreren Rechenvorrichtungen (z. B. Server, PCs usw.) implementiert, auf damit assoziierten computerlesbaren Medien (z.B. Platten, Speicher usw.) gespeichert. Ein Computerprogrammprodukt kann derartige auf computerlesbaren Medien gespeicherte Anweisungen zum Ausführen der hier beschriebenen Funktionen umfassen.
Mit Bezug auf die hier beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht sich, dass, obwohl die Schritte solcher Prozesse usw. als gemäß einer bestimmten geordneten Abfolge auftretend beschrieben wurden, solche Prozesse mit in einer anderen als der hier beschriebenen Reihenfolge ausgeführten beschriebenen Schritten ausgeübt werden könnten. Ferner versteht sich, dass bestimmte Schritte gleichzeitig ausgeführt werden könnten, dass andere Schritte hinzugefügt werden könnten oder dass bestimmte hier beschriebene Schritte weggelassen werden könnten. Mit anderen Worten werden die Beschreibungen von Prozessen hierin zum Zwecke der Veranschaulichung bestimmter Ausführungsformen bereitgestellt und sollten in keiner Weise als Beschränkung der Ansprüche aufgefasst werden.
Dementsprechend versteht sich, dass die obige Beschreibung nicht einschränkend, sondern veranschaulichend sein soll. Bei Durchsicht der obigen Beschreibung würden viele andere Ausführungsformen und Anwendungen als die gegebenen Beispiele offensichtlich werden. Der Schutzumfang soll nicht unter Bezugnahme auf die obige Beschreibung bestimmt werden, sondern stattdessen unter Bezugnahme auf die beiliegenden Ansprüche zusammen mit dem vollen Umfang von Äquivalenten, zu denen diese Ansprüche berechtigt sind. Es wird erwartet und beabsichtigt, dass zukünftige Entwicklungen in den hier besprochenen Technologien auftreten werden und dass die offenbarten Systeme und Verfahren in solche zukünftigen Ausführungsformen integriert werden. Zusammengefasst versteht sich, dass die Anmeldung modifiziert und abgewandelt werden kann.
Alle in den Ansprüchen verwendeten Begriffe sind dafür beabsichtigt, ihre gewöhnliche Bedeutung zu erhalten, wie sie von in den hier beschriebenen Technologien bewanderten Fachleuten verstanden wird, es sei denn, dass hier ein expliziter Hinweis auf das Gegenteil gemacht wird. Insbesondere ist die Verwendung der Artikel im Singular wie „ein“, „einer“, „eine“, „der“, „die“, „das“ usw. als Angabe eines oder mehrerer der aufgezeigten Elemente zu verstehen, sofern ein Anspruch nicht ausdrücklich eine gegensätzliche Einschränkung angibt.
Die Zusammenfassung wird bereitgestellt, um dem Leser zu ermöglichen, schnell die Natur der technischen Offenbarung festzustellen. Sie wird mit dem Verständnis eingereicht, dass sie nicht dazu verwendet werden soll, den Schutzumfang oder die Bedeutung der Ansprüche zu interpretieren oder zu beschränken. Zusätzlich kann in der vorangehenden Ausführlichen Beschreibung gesehen werden, dass verschiedene Merkmale in verschiedenen Ausführungsformen für den Zweck der Übersichtlichkeit der Offenbarung gruppiert werden. Diese Vorgehensweise der Offenbarung ist nicht als eine Absicht wiedergebend zu interpretieren, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern als ausdrücklich in jedem Anspruch dargelegt ist. Vielmehr liegt der Erfindungsgegenstand in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform, wie es die folgenden Ansprüche wiedergeben. Somit werden die folgenden Ansprüche hiermit in die Ausführliche Beschreibung aufgenommen, wobei jeder Anspruch für sich als ein eigenständig beanspruchter Gegenstand steht.
Zeichenerklärung

Fig. 1

110

Computing Device

Computervorrichtung

Fig. 2

115	User Interface Device	Benutzerschnittstellen-Vorrichtung
120	Navigation System	Navigationssystem
125	Communication Interface	Kommunikations-Schnittstelle
130	Autonomous Driving Sensors	Autonom-Fahr-Sensoren
135	Autonomous Mode Controller	Autonom-Modus-Steuerung
140	Processing Device	Verarbeitungsvorrichtung
145	Vehicle Subsystems	Fahrzeug-Subsysteme

Fig. 4

405	Load Simulation	Simulation Laden
410	Receive User Inputs	Benutzereingaben erhalten
415	Generate Virtual Environment	Virtuelle Umwelt erzeugen
420	Navigate Virtual Vehicle Through Virtual Environment	Virtuelles Fahrzeug durch die virtuelle Umwelt fahren
425	Generate Virtual Sensor Data	Daten virtueller Sensoren erzeugen
430	Generate Testing/Training Data	Test-/Trainingsdaten erzeugen

Claims

Computervorrichtung, die eine Verarbeitungsschaltung und ein Datenspeichermedium umfasst, wobei die Rechenvorrichtung programmiert ist zum: Empfangen einer Benutzereingabe, die eine Fahrzeugsteueraktion darstellt, die mit Betrieb eines virtuellen Fahrzeugs in einer virtuellen Umwelt assoziiert ist; virtuellen Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt gemäß der Fahrzeugsteueraktion; Sammeln von Daten virtueller Sensoren; und Verarbeiten der gesammelten Daten virtueller Sensoren.
Computervorrichtung nach Anspruch 1, wobei die Rechenvorrichtung dafür programmiert ist, die Daten virtueller Sensoren mindestens teilweise basierend auf dem virtuellen Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt zu erzeugen.
Computervorrichtung nach Anspruch 1, wobei die Rechenvorrichtung dafür programmiert ist, Kalibrierungsdaten aus den Daten virtueller Sensoren zu erzeugen und wobei Kalibrierungsdaten zu einem autonomen Fahrzeug hochgeladen werden.
Computervorrichtung nach Anspruch 1, wobei die Rechenvorrichtung dafür programmiert ist, das virtuelle Fahrzeug virtuell durch die virtuelle Umwelt in Echtzeit zu fahren.
Computervorrichtung nach Anspruch 4, wobei die virtuellen Sensoren mindestens teilweise auf in einem autonomen Fahrzeug eingebauten Autonom-Fahr-Sensoren basieren.
Computervorrichtung nach Anspruch 1, wobei die Fahrzeugsteueraktion das Steuern eines virtuellen Drosselklappensystems und/oder eines virtuellen Bremssystems und/oder eines virtuellen Lenksystems beinhaltet.
Computervorrichtung nach Anspruch 1, wobei das Erzeugen der virtuellen Umwelt das Erzeugen der virtuellen Umwelt mit zufälligen Testparametern beinhaltet.
Computervorrichtung nach Anspruch 7, wobei das Erzeugen der virtuellen Umwelt mit zufälligen Testparametern das Erzeugen der virtuellen Umwelt beinhaltet, um mindestens eines der Folgenden zu simulieren: eine zufällige Beleuchtungsbedingung, eine zufällige Wetterbedingung, eine zufällige Schilderplatzierung und eine zufällige Schilderausrichtung.
Verfahren, umfassend: Empfangen einer Benutzereingabe, die mindestens einen Testparameter auswählt, der mit autonomem Betrieb eines virtuellen Fahrzeugs in einer virtuellen Umwelt assoziiert ist; Simulieren der virtuellen Umwelt, die den mindestens einen Testparameter umfasst; virtuelles Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt; Sammeln von Daten virtueller Sensoren; und Verarbeiten der gesammelten Daten virtueller Sensoren.
Verfahren nach Anspruch 9, das ferner das Erzeugen der Daten virtueller Sensoren umfasst, mindestens teilweise basierend auf dem virtuellen Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt.
Verfahren nach Anspruch 9, das ferner das Erzeugen von Kalibrierungsdaten aus den Daten virtueller Sensoren zum Hochladen zu einem autonomen Fahrzeug umfasst.
Verfahren nach Anspruch 9, wobei das virtuelle Fahrzeug virtuell durch die virtuelle Umwelt gefahren wird, zumindest teilweise basierend auf in dem virtuellen Fahrzeug eingebauten virtuellen Sensoren.
Verfahren nach Anspruch 12, wobei die virtuellen Sensoren mindestens teilweise auf in einem autonomen Fahrzeug eingebauten Autonom-Fahr-Sensoren basieren.
Verfahren nach Anspruch 9, das ferner das Erzeugen der virtuellen Umwelt mindestens teilweise basierend auf der Benutzereingabe umfasst.
Verfahren nach Anspruch 14, wobei das Erzeugen der virtuellen Umwelt das Erzeugen der virtuellen Umwelt beinhaltet, um eine Wetterbedingung zu simulieren.
Verfahren nach Anspruch 14, wobei das Erzeugen der virtuellen Umwelt das Erzeugen der virtuellen Umwelt beinhaltet, um eine Beleuchtungsbedingung zu simulieren.
Computersystem, umfassend: einen Anzeigebildschirm; und eine Computervorrichtung, die eine Prozessorschaltung und ein Datenspeichermedium umfasst, wobei die Computervorrichtung programmiert ist zum: Empfangen einer Benutzereingabe, die mindestens einen Testparameter auswählt, der mit autonomem Betrieb eines virtuellen Fahrzeugs in einer virtuellen Umwelt assoziiert ist; Simulieren der virtuellen Umwelt, die den mindestens einen Testparameter umfasst; virtuellen Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt; Sammeln von Daten virtueller Sensoren; und Verarbeiten der gesammelten Daten virtueller Sensoren; wobei das virtuelle Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt auf dem Anzeigebildschirm präsentiert wird.
Computersystem nach Anspruch 17, wobei die Computervorrichtung dafür programmiert ist, die Daten virtueller Sensoren mindestens teilweise basierend auf dem virtuellen Fahren des virtuellen Fahrzeugs durch die virtuelle Umwelt zu erzeugen und die Daten der virtuellen Sensoren über den Anzeigebildschirm auszugeben.
Computersystem nach Anspruch 17, wobei die Computervorrichtung dafür programmiert ist, die virtuelle Umwelt mindestens teilweise basierend auf der Benutzereingabe zu erzeugen, wobei das Erzeugen der virtuellen Umwelt das Erzeugen der virtuellen Umwelt beinhaltet, um eine Wetterbedingung und/oder eine Beleuchtungsbedingung zu simulieren.
Computersystem nach Anspruch 17, wobei die Präsentation der virtuellen Umwelt auf der Benutzer-Anzeigevorrichtung eine graphische Darstellung der Wetterbedingung und/oder der Beleuchtungsbedingung beinhaltet.