DE102018103107A1

DE102018103107A1 - Auf feedback beruhende erzeugung von steuermodellen für ein autonomes fahrzeug

Info

Publication number: DE102018103107A1
Application number: DE102018103107.6A
Authority: DE
Inventors: Zhen JIANG; Yan Fu; Yuzhou Li
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-02-15
Filing date: 2018-02-12
Publication date: 2018-08-16
Also published as: RU2018103736A; US20180229723A1; CN108423005A; GB2560439A; MX2018001705A; CN108423005B; GB201802284D0; US10449958B2

Abstract

Ein Computersystem empfängt Datensätze für ein Fahrmanöver an einem Ort, wie etwa Daten hinsichtlich eines Zustands eines Fahrzeugs, einer äußeren Umgebung, die durch Außensensoren angegeben wird, und Benutzerfeedback hinsichtlich des Fahrmanövers. Datensätze können von Benutzern erhoben werden, die verschiedene demografische Attribute und Verhaltensattribute aufweisen. Benutzer können unter Verwendung von Algorithmen zur Versuchsplanung (design of experiment - DOE) ausgewählt werden, um ein breites Spektrum an möglichen Kombinationen abzudecken. Ein stochastisches Antwortflächenmodell (stochastic response surface model - SRSM) wird erzeugt, das Sensordaten (Fahrzeugzustand und Umgebung) mit Benutzerfeedback hinsichtlich Sicherheit und Komfort in Beziehung setzt. Das SRSM kann unter Verwendung einer Gauß-Prozess-Regression (GPR) erzeugt werden, um Unsicherheit zu modellieren. Das SRSM wird dann dazu verwendet, ein Steuermodell unter Verwendung eines Algorithmus zur Optimierung unter Unsicherheit (optimization under uncertainty - OUU) zu erzeugen.

Description

HINTERGRUND
GEBIET DER ERFINDUNG
Diese Erfindung betrifft das Betreiben eines autonomen Fahrzeugs.
ALLGEMEINER STAND DER TECHNIK
Autonome Fahrzeuge werden immer relevanter und kommen tagtäglich immer mehr zum Einsatz. Bei einem autonomen Fahrzeug stützt sich eine Steuerung auf Sensoren, um umliegende Hindernisse und Straßenbeläge zu detektieren. Die Steuerung setzt Logik um, die der Steuerung das Lenken, Bremsen und Beschleunigen ermöglicht, um ein Ziel zu erreichen und Kollisionen zu vermeiden.
Das hier offenbarte System und Verfahren stellen einen verbesserten Ansatz zum Umsetzen von Steuerlogik für ein autonomes Fahrzeug bereit.
Figurenliste
Damit die Vorteile der Erfindung ohne Weiteres verstanden werden, erfolgt durch Bezugnahme auf konkrete Ausführungsformen, die in den beigefügten Zeichnungen veranschaulicht sind, eine genauere Beschreibung der vorstehend kurz beschriebenen Erfindung. Unter der Kenntnisnahme, dass diese Zeichnungen lediglich typische Ausführungsformen der Erfindung darstellen und daher nicht als den Umfang beschränkend aufzufassen sind, wird die Erfindung mit zusätzlicher Genauigkeit und Ausführlichkeit durch die Verwendung der beigefügten Zeichnungen beschrieben und erläutert, in denen Folgendes gilt:

1 ist ein schematisches Blockdiagramm von Komponenten zum Umsetzen eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung;
2 ist ein schematisches Blockdiagramm einer beispielhaften Rechenvorrichtung, die zum Umsetzen von Verfahren gemäß Ausführungsformen der Erfindung geeignet ist;
3 ist ein Prozessablaufdiagramm eines Verfahrens zum Erzeugen eines Steuermodells auf Grundlage von Fahrgastfeedback gemäß Ausführungsformen der vorliegenden Erfindung;
4 veranschaulicht eine Schnittstelle zum Empfangen von Fahrgastfeedback gemäß einer Ausführungsform der vorliegenden Erfindung;
5 ist ein Schaubild, das einen Versuchsplanungsprozess gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht;
6A und 6B sind Schaubilder, die eine stochastische Antwortflächenmodellierung (stochastic response surface modeling - SRSM) gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulichen;
7A und 7B sind Schaubilder, die eine Modellierung der Unsicherheit eines SRSM-Ansatzes gemäß einer Ausführungsform der vorliegenden Erfindung zeigen; und
8 ist ein Schaubild, das eine Gauß-Prozess-Regression gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht.

DETAILLIERTE BESCHREIBUNG
Unter Bezugnahme auf Fig. 1 können die hier offenbarten Verfahren unter Verwendung des veranschaulichten Systems 100 durchgeführt werden. Wie hier ausführlicher erörtert, kann eine Steuerung 102 autonome Navigation und Kollisionsvermeidung für ein Fahrzeug durchführen, in dem die Steuerung 102 untergebracht ist. Das Fahrzeug 100 kann alle Strukturen und Merkmale eines beliebigen fachbekannten Fahrzeugs aufweisen, darunter Räder, einen an die Räder gekoppelten Antriebsstrang, einen an den Antriebsstrang gekoppelten Motor, ein Lenksystem, ein Bremssystem und andere fachbekannte in ein Fahrzeug einzuschließende Systeme.
Die Steuerung 102 kann eine oder mehrere Ausgaben von einem oder mehreren Außensensoren 104 empfangen. Zum Beispiel können eine oder mehrere Kameras 106a an dem Fahrzeug 100 montiert sein und Bildströme an die Steuerung 102 ausgeben. Die Außensensoren 104 können Sensoren wie etwa einen Ultraschallsensor 106b, einen RADAR-Sensor (Radio Detection and Ranging sensor) 106c, einen LIDAR-Sensor (Light Detection and Ranging sensor) 106d, einen SONAR-Sensor (Sound Navigation and Ranging sensor) 106e und dergleichen beinhalten.
Die Steuerung 102 kann ein autonomes Steuermodul 108 ausführen, das die Ausgaben der Außensensoren 104 empfängt. Das autonome Steuermodul 108 kann ein Hindernisidentifikationsmodul 110a, ein Kollisionsvorhersagemodul 110b und ein Entscheidungsmodul 110c beinhalten. Das Hindernisidentifikationsmodul 110a analysiert die Ausgaben der Außensensoren und identifiziert potentielle Hindernisse, darunter Personen, Tiere, Fahrzeuge, Gebäude, Bordsteine und andere Objekte und Strukturen. Insbesondere kann das Hindernisidentifikationsmodul 110a Fahrzeugbilder in den Sensorausgaben identifizieren.
Das Kollisionsvorhersagemodul 110b sagt auf Grundlage seines gegenwärtigen Kurses oder gegenwärtig beabsichtigten Wegs vorher, welche Hindernisbilder wahrscheinlich mit dem Fahrzeug 100 kollidieren werden. Das Kollisionsvorhersagemodul 110b kann die Wahrscheinlichkeit einer Kollision mit durch das Hindernisidentifikationsmodul 110a identifizierten Objekten beurteilen. Das Entscheidungsmodul 110c kann eine Entscheidung zum Anhalten, Beschleunigen, Abbiegen etc. treffen, um Hindernissen auszuweichen. Die Art und Weise, auf die das Kollisionsvorhersagemodul 110b potentielle Kollisionen vorhersagt, und die Art und Weise, auf die das Entscheidungsmodul 110c Maßnahmen ergreift, um potentielle Kollisionen zu verhindern, können gemäß einem beliebigen auf dem Fachgebiet autonomer Fahrzeuge bekannten Verfahren oder System sein.
Das Entscheidungsmodul 110c kann den Kurs des Fahrzeugs steuern, um zu einem gewünschten Ziel zu navigieren, während Hindernissen ausgewichen wird. Zum Beispiel kann das Entscheidungsmodul 110c einen oder mehrere Aktoren 112 aktivieren, die die Richtung und Geschwindigkeit des Fahrzeugs 100 steuern. Zum Beispiel können die Aktoren 112 einen Lenkaktor 114a, einen Beschleunigungsaktor 114b und einen Bremsaktor 114c beinhalten. Die Auslegung der Aktoren 114a-114c kann gemäß einer beliebigen Umsetzung derartiger auf dem Fachgebiet autonomer Fahrzeuge bekannter Aktoren erfolgen.
In einigen Ausführungsformen können die durch das Entscheidungsmodul 110c getroffenen Steuerentscheidungen durch das Steuermodell 116 umgesetzt werden, das gemäß den hier beschriebenen Verfahren aktualisiert und/oder erzeugt wird. In einigen Ausführungsformen kann die vorstehend beschriebene Funktionalität des Hindernisidentifikationsmoduls 110a und Kollisionsvorhersagemoduls 110b zudem durch das Steuermodell 116 umgesetzt werden.
Die Steuerung 102 kann in Datenkommunikation mit einem Serversystem 118 stehen. Zum Beispiel kann die Steuerung 102 in Datenkommunikation mit einem oder mehreren Mobilfunkkommunikationsmasten 120 stehen, die mithilfe eines Netzwerks 122, wie etwa eines lokalen Netzwerks (local area network - LAN), Weitverkehrsnetzwerks (wide area network - WAN), des Internets oder jeder beliebigen anderen drahtlosen oder drahtgebundenen Netzwerkverbindung in Datenkommunikation mit dem Serversystem 118 stehen.
Das Serversystem 118 kann eine Datenbank 124 beherbergen oder auf diese zugreifen. Die Datenbank 124 kann Feedbackaufzeichnungen 126 speichern. Die Feedbackaufzeichnungen 126 können einem Fahrmanöver entsprechen, z. B. Abbiegen, Durchfahren eines Straßenabschnitts, autonomem Parken oder dergleichen. Jede Feedbackaufzeichnung 126 kann entweder einen bestimmten Benutzer beinhalten oder mit diesem assoziiert sein. Dementsprechend kann jede Feedbackaufzeichnung 126 ein oder mehrere Attribute 128a dieses Benutzers beinhalten oder damit assoziiert sein, zu denen eine Benutzerkennung, demographische Attribute (Alter, Geschlecht, Beruf etc.) sowie fahrspezifische Attribute (konservativ, abenteuerlustig etc.) gehören können. Diese Attribute können durch den Benutzer selbst angegeben und dem Serversystem 118 kommuniziert werden oder aus verfügbaren Daten gesammelt werden.
Die Feedbackaufzeichnung 126 kann Benutzerfeedback 128b beinhalten. Das Benutzerfeedback 128b kann in Form einer Bewertung (z. B. von 1 bis 5, wobei 5 die beste ist) erfolgen. Das Benutzerfeedback 128b gibt die Wahrnehmung des Fahrmanövers durch den Benutzer an. Falls sich der Benutzer zum Beispiel unwohl fühlte, wird eine niedrigere Bewertung gegeben. Das Benutzerfeedback 128b kann Feedback hinsichtlich mehrerer Faktoren beinhalten, wie etwa Feedback in Bezug auf Benutzerkomfort und Feedback in Bezug auf die Sicherheitswahmehmung des Benutzers.
Die Feedbackaufzeichnung 126 kann einen bestimmten Ort 128c aufzeichnen oder damit assoziiert werden, d. h. den Ort, an dem das Fahrmanöver, das den Gegenstand der Feedbackaufzeichnung darstellt, erfolgte. Der Ort kann ein Bereich von Orten sein, z. B. einen überquerten Straßenabschnitt definieren; die Einfahrt, der Scheitel und/oder die Ausfahrt einer Abbiegung; oder ein anderer Bereich von Orten. Auf diese Art und Weise kann Feedback von einem einzelnen Benutzer oder einer Gruppe von Benutzern, das ein bestimmtes Merkmal der Straße betrifft, gruppiert werden.
Die Feedbackaufzeichnung 126 kann Sensordaten 128d beinhalten oder damit assoziiert werden, die dem Fahrmanöver entsprechen, das den Gegenstand der Feedbackaufzeichnung 126 darstellt. Zu den Sensordaten 128d können Ausgaben von Sensoren während eines Zeitraums gehören, der das Fahrmanöver beinhaltet, z. B. nur während des Fahrmanövers oder in einem Fenster beiderseits von dem Fahrmanöver, wie etwa 1 bis 10 Sekunden, oder 5 bis 20 Fuß beiderseits von dem Ort oder Bereich von Orten 128c entsprechend.
Zu den Sensordaten 128d können Ausgaben der Außensensoren 104 während des Zeitraums gehören, die die Umgebung des Fahrzeugs während des Manövers angeben. Zu den Sensordaten 128d können Ausgaben anderer Fahrzeugsensoren während des Zeitraums gehören, wie etwa Sensoren, die den Zustand des Fahrzeugs angeben, wie etwa Beschleunigungsmesser, die Beschleunigung, Gierrate, Rollen oder dergleichen angeben. Dementsprechend können zu den Sensordaten Ausgaben eines Lenkradwinkelsensors, Raddrehzahlsensors, Fahrzeuggeschwindigkeitssensors, Motordrehzahlsensors, Motordrehmomentsensors, jedes beliebigen anderen Motorsensors oder jedes beliebigen anderen fachbekannten Sensors zum Erfassen des Zustands eines Fahrzeugs gehören.
Die Feedbackaufzeichnung 126 kann ferner Steuerdaten 128e für den Zeitraum beinhalten. Zu den Steuerdaten 128e können Daten gehören, die durch das Entscheidungsmodell 110c getroffene Steuerentscheidungen beschreiben, z. B. Bremssteuerausgänge (die sowohl Zeitpunkt als auch Ausmaß des Bremsens angeben können), Änderungen des Laufradwinkels während des Lenkens (die durch eine Änderung des Lenksäulenwinkels oder Änderung der Regelstangenposition dargestellt werden können), Beschleunigungssteuerausgängen (z. B. abnehmende oder zunehmende Drosselöffnung), Antriebsschlupf- und Fahrdynamiksteuerausgänge (Bremsmodulation, Drehmomentumverteilung unter den Rädern etc.) oder ein beliebiger anderer Steuereingang, der sich auf den Kurs und Betrieb des Fahrzeugs auswirkt, insbesondere diejenigen, die die Wahrnehmung eines Fahrmanövers durch den Benutzer beeinflussen können.
Die Datenbank 124 kann ferner ein Steuermodell 116 speichern. Das Steuermodell 116 kann ein Steuermodell 116 sein, das dem des Entscheidungsmoduls 110c entspricht. Das Steuermodell 116 kann gemäß den hier offenbarten Verfahren auf Grundlage der Feedbackaufzeichnungen 126 erzeugt und modifiziert werden. Das gemäß den hier beschriebenen Verfahren erzeugte oder aktualisierte Steuermodell 116 kann an verschiedene autonome Fahrzeuge übermittelt werden, die dann autonomes Fahren gemäß dem Steuermodell 116 durchführen können. In einigen Ausführungsformen kann das Steuermodell 116 einem bestimmten Fahrzeugfabrikat und -modell (z. B. Ford Escape) oder einer bestimmten Fahrzeugklasse (z. B. Softroader) entsprechen.
Wie hier nachstehend beschrieben, kann ein Benutzer Feedback mittels einer mobilen Vorrichtung 130 bereitstellen, wie etwa eines Mobiltelefons, Tablet-Computers oder am Körper tragbaren Computers. Die der mobilen Vorrichtung 130 hier zugeschriebenen Funktionen können zudem durch einen Schreibtisch- oder Laptop-Computer oder jede beliebige andere Art von Rechenvorrichtung durchgeführt werden. In einigen Ausführungsformen kann die mobile Vorrichtung 130 unmittelbar mit dem Server 118 oder mithilfe der Steuerung 102 oder einer anderen dazwischenliegenden Rechenvorrichtung kommunizieren. Alternativ kann Feedback durch die Steuerung 102 eingegeben werden. Zum Beispiel kann ein Touchscreen an die Steuerung 102 gekoppelt sein, durch das der Benutzer Feedback bereitstellt, wie etwa ein fahrzeuginternes Infotainmentsystem (in-vehicle infotainment - IVI - system). Alternativ kann jede beliebige andere Eingabevorrichtung verwendet werden, wie etwa Tasten, ein Mikrofon, das verbales Feedback detektiert, eine Tastatur, ein optischer Detektor oder dergleichen.
2 ist ein Blockdiagramm, das eine beispielhafte Rechenvorrichtung 200 veranschaulicht. Die Rechenvorrichtung 200 kann dazu verwendet werden, verschiedene Vorgänge auszuführen, wie etwa die hier erörterten. Die Steuerung 102, das Serversystem 118 und die mobile Vorrichtung 130 können einige oder alle der Attribute der Rechenvorrichtung 200 aufweisen.
Die Rechenvorrichtung 200 beinhaltet einen oder mehrere Prozessor(en) 202, eine oder mehrere Speichervorrichtung(en) 204, eine oder mehrere Schnittstelle(n) 206, eine oder mehrere Massenspeichervorrichtung(en) 208, eine oder mehrere Ein-/Ausgabe-(E/A-)Vorrichtung(en) 210 und eine Anzeigevorrichtung 230, die alle an einen Bus 212 gekoppelt sind. Der/Die Prozessor(en) 202 beinhaltet/beinhalten eine(n) oder mehrere Prozessoren oder Steuerungen, der/die in der/den Speichervorrichtung(en) 204 und/oder der/den Massenspeichervorrichtung(en) 208 gespeicherte Anweisungen ausführen. Der/Die Prozessor(en) 202 kann/können zudem verschiedene Arten von computerlesbaren Medien beinhalten, wie etwa Cache-Speicher.
Die Speichervorrichtung(en) 204 beinhaltet/beinhalten verschiedene computerlesbare Medien, wie etwa flüchtigen Speicher (z. B. Direktzugriffsspeicher (random access memory - RAM) 214) und/oder nichtflüchtigen Speicher (z. B. Festwertspeicher (read-only memory - ROM) 216). Die Speichervorrichtung(en) 204 kann/können zudem wiederbeschreibbaren ROM beinhalten, wie etwa Flash-Speicher.
Die Massenspeichervorrichtung(en) 208 beinhaltet/beinhalten verschiedene computerlesbare Medien, wie etwa Magnetbänder, Magnetplatten, optische Platten, Festkörperspeicher (z. B. Flash-Speicher) und so weiter. Wie in 2 gezeigt, ist eine besondere Massenspeichervorrichtung ein Festplattenlaufwerk 224. Zudem können verschiedene Laufwerke in der/den Massenspeichervorrichtung(en) 208 beinhaltet sein, um ein Auslesen aus und/oder Schreiben auf die verschiedenen computerlesbaren Medien zu ermöglichen. Die Massenspeichervorrichtung(en) 208 beinhaltet/beinhalten entfernbare Medien 226 und/oder nicht entfernbare Medien.
Die E/A-Vorrichtung(en) 210 beinhaltet/beinhalten verschiedene Vorrichtungen, die es ermöglichen, dass Daten und/oder andere Informationen in die Rechenvorrichtung 200 eingegeben oder daraus abgerufen werden. (Eine) Beispielhafte E/A-Vorrichtung(en) 210 beinhaltet/beinhalten Cursorsteuervorrichtungen, Tastaturen, Tastenfelder, Mikrofone, Monitore oder andere Anzeigevorrichtungen, Lautsprecher, Drucker, Netzwerkschnittstellenkarten, Modems, Linsen, CCDs oder andere Bilderfassungsvorrichtungen und dergleichen.
Die Anzeigevorrichtung 230 beinhaltet eine beliebige Art von Vorrichtung, die dazu in der Lage ist, einem oder mehreren Benutzern der Rechenvorrichtung 200 Informationen anzuzeigen. Zu Beispielen für eine Anzeigevorrichtung 230 gehören ein Monitor, ein Anzeigeendgerät, eine Videoprojektionsvorrichtung und dergleichen.
Die Schnittstelle(n) 206 beinhaltet/beinhalten verschiedene Schnittstellen, die es der Rechenvorrichtung 200 ermöglichen, mit anderen Systemen, Vorrichtungen oder Rechenumgebungen zu interagieren. Zu (einer) beispielhaften Schnittstelle(n) 206 gehören eine beliebige Anzahl von unterschiedlichen Netzwerkschnittstellen 220, wie etwa Schnittstellen zu lokalen Netzwerken (LANs), Weitverkehrsnetzwerken (WANs), drahtlosen Netzwerken und dem Internet. Zu (einer) andere(n) Schnittstelle(n) gehören eine Benutzerschnittstelle 218 und eine Peripherievorrichtungsschnittstelle 222. Zu der/den Schnittstelle(n) 206 können zudem eine oder mehrere Peripherieschnittstellen gehören, wie etwa Schnittstellen für Drucker, Zeigevorrichtungen (Mäuse, Trackpad etc.), Tastaturen und dergleichen.
Der Bus 212 ermöglicht dem/den Prozessor(en) 202, der/den Speichervorrichtung(en) 204, der/den Schnittstelle(n) 206, der/den Massenspeichervorrichtung(en) 208, der/den E/A-Vorrichtung(en) 210 und der Anzeigevorrichtung 230, miteinander sowie mit anderen Vorrichtungen oder Komponenten, die an den Bus 212 gekoppelt sind, zu kommunizieren. Der Bus 212 stellt eine oder mehrere von mehreren Arten von Busstrukturen dar, wie etwa einen Systembus, PCI-Bus, IEEE-1394-Bus, USB-Bus und so weiter.
Zum Zwecke der Veranschaulichung sind Programme und andere ausführbare Programmkomponenten hier als diskrete Blöcke gezeigt, auch wenn es sich versteht, dass sich derartige Programme und Komponenten zu verschiedenen Zeitpunkten in unterschiedlichen Speicherkomponenten der Rechenvorrichtung 200 befinden können, und werden durch den/die Prozessor(en) 202 ausgeführt. Alternativ können die hier beschriebenen Systeme und Vorgänge in Hardware oder einer Kombination aus Hardware, Software und/oder Firmware umgesetzt sein. Ein oder mehrere anwendungsspezifische integrierte Schaltkreise (application specific integrated circuits - ASICs) können zum Beispiel dazu programmiert sein, eines bzw. einen oder mehrere der hier beschriebenen Systeme und Vorgänge ausführen.
Unter Bezugnahme auf 3 kann das veranschaulichte Verfahren 300 durch das Serversystem 118 in Kooperation mit einer mobilen Vorrichtung 130 von einem oder mehreren Fahrgästen und den Steuerungen 102 von einem oder mehreren autonomen Fahrzeugen, in denen der eine oder die mehreren Fahrgäste gefahren sind oder fahren, ausgeführt werden.
Das Verfahren 300 kann Empfangen 302 von einer oder mehreren Entscheidungen bezüglich Umgebungen und Fahrgästen, die der Gegenstand des Tests sein sollen, beinhalten. Schritt 302 kann Empfangen dieser Entscheidungen von einem menschlichen Bediener beinhalten. Zum Beispiel kann ein Bediener wünschen, die Ausführungen von Abbiegungen durch autonome Fahrzeuge zu verbessern. Dementsprechend können die getesteten Umgebungen ausschließlich Abbiegungen oder eine große Anzahl von Abbiegungen beinhalten. Hinsichtlich der Fahrgäste kann ein Wertebereich für ein oder mehrere demografische Attribute (Alter, Geschlecht, Beruf, Einkommen etc.) festgelegt werden. Ebenso kann ein Bereich für Verhaltensattribute in Bezug auf das Fahren festgelegt werden, d. h. konservativ, risikoscheu, abenteuerlustig etc.
Das Verfahren 300 kann dann Auswählen eines Satzes von Fahrgästen und/oder Orten zur Beurteilung durch Durchführen 304 eines Versuchsplanungsalgorithmus (design-ofexperiment - DOE - algorithm) beinhalten. Es ist unmöglich, jede Kombination aus Ort, demografischen Attributen und Verhaltensattributen abzudecken. Dementsprechend ist beabsichtigt, dass Durchführen 304 der DOE eine vielfältige Erhebung von Testdaten sicherstellt. Das Verfahren, in dem Schritt 304 durchgeführt wird, ist nachstehend in Bezug auf 5 ausführlicher beschrieben.
Das Verfahren 300 kann ferner Erheben 306 von Daten zum Trainieren und Validieren des Steuermodells 116 beinhalten. Wie vorstehend angemerkt, kann dies Erheben von einigen oder allen der vorstehend in Bezug auf die Feedbackaufzeichnungen 126 beschriebenen Daten beinhalten. Wie vorstehend angemerkt, kann dies Erheben von Sensordaten sowie Benutzerfeedback beinhalten.
4 veranschaulicht eine beispielhafte Schnittstelle, durch die ein Benutzer Feedback bezüglich eines Fahrmanövers bereitstellen kann. Die Schnittstelle kann eine Karte 400 beinhalten, die Straßen, Orientierungspunkte, Beschriftungen von Straßen und Orientierungspunkten und beliebige andere Informationen, die wie fachbekannt in eine Karte eingeschlossen sein können, veranschaulicht. Die Karte kann wie fachbekannt über ein Satellitenbild des durch die Karte dargestellten Bereichs gelegt werden.
Die Schnittstelle kann ein Schnittstellenelement 404 beinhalten, das ein Benutzer auswählen kann, um eine Bewertung eines Fahrmanövers oder einer gesamten Fahrt bereitzustellen, z. B. eine positive oder negative Bewertung, eine Auswahl eines Werts von 1 bis N, wobei N keine Probleme angibt und 1 eine Fahrt von schlechter Qualität angibt. In einigen Ausführungsformen können mehrere Schnittstellenelemente 404 bereitgestellt sein, um Feedback bezüglich mehrerer Aspekte des Fahrmanövers, z. B. Komfort, Sicherheit, wahrgenommene Laufruhe etc., zu empfangen.
Die Schnittstelle kann ein Rendern 402 eines Wegs des Fahrzeugs während der Fahrt beinhalten, der über die Karte gelegt wird. Die Schnittstelle kann Benutzereingaben empfangen, die Orte 406, 408 mitteilen, an denen es während der Fahrt zu Anomalien kam. In einigen Ausführungsformen kann die Schnittstelle Fahrgastmitteilungen von Arten von Anomalien empfangen. Zum Beispiel kann es ein Schnittstellenelement 410 dem Fahrgast ermöglichen, einen Ort einer Fahrtanomalie zu markieren. Zum Beispiel kann im Anschluss an die Auswahl des Schnittstellenelements 410 eine anschließende Auswahl auf dem Weg 102 als Benutzermitteilung einer Fahrtanomalie interpretiert werden. Die Schnittstelle kann ferner eine Benutzermitteilung einer Art der Fahrtanomalie empfangen, d. h. einer autonomen Handlung des Fahrzeugs, die der Fahrgast als nicht gut ausgeführt empfindet, wie etwa ein Verlassen einer Spur, eine Abbiegung, die zu schnell genommen wurde oder von einem angemessenen Weg abwich, oder dergleichen.
Die Schnittstelle kann ein Schnittstellenelement 412 beinhalten, das es dem Fahrgast ermöglicht, mitzuteilen, dass ein ausgewählter Punkt auf der Wegkarte 400 einer Straßenanomalie entspricht, z. B. einem Schlagloch, einer gesperrten Spur, Straßenbauarbeiten, einer blockierten Straße, einem Unfall etc.
In einigen Ausführungsformen kann die Schnittstelle Feedback hinsichtlich konkreter Orte wie etwa bei Schritt 304 ausgewählter Orte zur Nachforschung anfordern. Dementsprechend kann die Karte 400 hervorgehobene Abschnitte beinhalten, die angeben, wo Feedback notwendig ist. Alternativ können Bilder von Kurven oder anderen Straßensegmenten gemeinsam mit einer Schnittstelle angezeigt werden, um Feedback hinsichtlich des Durchfahrens des veranschaulichten Segments zu empfangen.
Die Schnittstelle aus 4 kann dem Fahrgast nach der Fahrt oder während der gesamten Fahrt gezeigt werden. Zum Beispiel kann die Schnittstelle aus 4 unmittelbar im Anschluss an das Durchfahren eines Straßensegments, das ein relevanter Ort ist, bereitgestellt werden, um Feedback hinsichtlich der Leistung des autonomen Fahrzeugs in diesem Straßensegment von dem Benutzer anzufordern.
Wie vorstehend angemerkt, kann die Schnittstelle auf der mobilen Vorrichtung 130 des Benutzers oder auf einem Bildschirm, der in das autonome Fahrzeug integriert ist, wie etwa einem Touchscreen eines fahrzeuginternen Infotainmentsystems, angezeigt werden.
Unter erneuter Bezugnahme auf 3 kann das Verfahren 300 Aufbauen 308 von einem oder mehreren stochastischen Antwortflächenmodellen (stochastic respond surface model - SRSM) beinhalten. Das SRSM setzt eine gewünschte Ausgabe, positives Benutzerfeedback mit Eingaben wie etwa Sensordaten (Fahrzeugzustand und Umgebungsfaktoren) und durch das autonome Fahrzeug vorgenommenen Steuerhandlungen in Beziehung. Das Verfahren, in dem die SRSMs erzeugt werden, ist nachstehend in Bezug auf 6A und 6B sowie 7A und 7B beschrieben.
Das Verfahren 300 kann Beurteilen 310 der SRSMs gemäß Validierungsdaten beinhalten. Insbesondere können die SRSMs bei Schritt 308 unter Verwendung eines Teils der bei Schritt 306 erhobenen Daten erzeugt werden. Ein Teil der Daten aus Schritt 306, z. B. 10 Prozent oder ein anderer Teil der Feedbackaufzeichnungen 126, kann zurückgehalten und bei Schritt 310 zum Beurteilen der SRSMs verwendet werden. Insbesondere wird die Fähigkeit des SRSM zum Vorhersagen von Benutzerfeedback für einen gegebenen Satz von Eingaben beurteilt 310.
Falls befunden 312 wird, dass die Validierungsdaten angeben, dass die SRSMs beim Vorhersagen von Benutzerfeedback nicht ausreichend präzise sind, können die Schritte 306-312 wiederholt werden, d. h. es können mehr Daten erhoben 306 werden, um präzisere SRSMs zu erlangen. Was ausreichend präzise ist, kann gemäß menschlicher Einschätzung festgelegt werden. Zum Beispiel kann mehr als 90 % Präzision ausreichend sein. Falls die SRSMs zum Beispiel korrekt vorhersagen, dass Feedback bei mindestens 90 % der eingegebenen Datensätze in den Validierungsdaten (oder einem anderen prozentualen Schwellenwert) über oder unter einem Günstigkeitsschwellenwert liegt, z. B. 6 von 10, können die SRSMs als ausreichend präzise erachtet werden.
Falls befunden wird, dass die Validierungsdaten angeben, dass die SRSMs ausreichend präzise sind, kann das Verfahren 300 Erzeugen des Steuermodells 116 durch Durchführen 314 von Mehrzieloptimierung unter Unsicherheit beinhalten. Wie nachstehend in Bezug auf 8 beschrieben, kann Schritt 314 Erzeugen eines Steuermodells 116 beinhalten, um das Erreichen einer gewünschten Eigenschaft (z. B. positives Benutzerfeedback) angesichts der Unsicherheit bei den SRSMs zu optimieren, die zum Modellieren der Reaktion eines Benutzers auf einen gegebenen Zustand (z. B. Sensordaten, die den Fahrzeugzustand und Umgebungsfaktoren angeben) verwendet werden. Die Art und Weise, auf die Schritt 314 durchgeführt wird, ist nachstehend in Bezug auf 8 beschrieben.
Das Steuermodell, das das Ergebnis von Schritt 314 darstellt, kann dann in ein oder mehrere autonome Fahrzeuge hochgeladen 316 werden, die dann das Steuermodell dazu verwenden, die autonomen Fahrzeuge autonom zu steuern. Die autonomen Fahrzeuge, die das aktualisierte Steuermodell empfangen, können die gleichen autonomen Fahrzeuge beinhalten, von denen bei Schritt 306 Daten erhoben werden, und können zusätzlich oder alternativ andere autonome Fahrzeuge beinhalten.
Unter Bezugnahme auf 5 handelt es sich bei einheitlicher DOE (Versuchsplanung) um eine Klasse von Techniken, die es anstrebt, einheitliche Stichproben über den relevanten Bereich (der durch die obere und untere Grenze von Eingabefaktoren definiert werden) hinweg für physikalische Versuche zu erzeugen. Sie zielt darauf ab, so viele Informationen wie möglich über den gesamten relevanten Bereich hinweg unter Verwendung einer begrenzten Datenmenge zu sammeln, und sollte die folgenden Eigenschaften aufweisen:

• Die Stichprobenpunkte sollten einen breiten Bereich des durch die Eingabefaktoren gebildeten Raums abdecken.
• Die Stichprobenpunkte sollten gleichmäßige ohne offenkundige Clusterbildung über den Eingaberaum verteilt sein.
• Falls sie auf einen beliebigen Teilraum projiziert werden, der einen Teilsatz von Eingabefaktoren des Systems umfasst, sollten die Stichprobenpunkte weiterhin eine gleichmäßige Verteilung ohne Clusterbildung beibehalten.

In diesem Fall strebt Durchführen 304 von DOE an, Testdaten für ein großes Spektrum an Umgebungsbedingungen, ein großes Spektrum an Benutzertypen (z. B. demografische Attribute und Verhaltensattribute) und ein großes Spektrum an Steuerhandlungen (z. B. sowohl konservativ als auch aggressiv) zu erlangen.
Durchführen 304 von DOE kann Verwenden einer Kombination aus Latin-Hypercube-Stichprobennahme (Latin Hypercube sampling - LHS) und adaptiver Stichprobennahme (Adaptive Sampling - AS) beinhalten, um die Eingabeeinstellungen der Versuche zu entwerfen, z. B. Wetter, Straßenbedingungen, Attribute der Fahrgäste etc. 8 stellt ein veranschaulichendes Beispiel eines LHS-Entwurfs mit 16 Stichprobenpunkten über einen zweidimensionalen Eingaberaum {x₁, x₂} bereit. Die Stichprobenpunkte sind in dem Raum ohne Clusterbildung zerstreut, und sie bilden eine gleichmäßig beabstandete Verteilung, falls sie entweder auf die x₁-Achse oder die x₂-Achse projiziert werden. Andererseits können die durch LHS bereitgestellten Entwürfe in der Hinsicht zu eingeschränkt sein, dass sie unter Umständen zum Beispiel nicht unmittelbar aus dem Pool von potentiellen einzuladenden Fahrgästen verfügbar sind. Daher wird AS ebenfalls durchgeführt. Zum Beispiel kann die gemäß LHS bestimmte Verteilung so eingestellt werden, dass sie zu den Testfähigkeiten (z. B. dem Pool von verfügbaren Fahrgästen) passt, während die vorstehend umrissenen bevorzugten Eigenschaften von LHS (keine Clusterbildung, gleichmäßig beabstandete Verteilung etc.) beibehalten werden.
Zum Beispiel kann LHS verwendet werden, um eine anfängliche Verteilung von zu testenden Entwürfen (z. B. Kombination aus Parametern) bereitzustellen. Diejenigen, die undurchführbar sind, wie etwa aufgrund des begrenzten Pools von Fahrgästen, können dann herausgefiltert werden. AS kann dann auf Grundlage des Satzes von verbleibenden Entwürfen und verfügbaren Testfähigkeiten in einem iterativen Prozess durchgeführt werden, um neue Entwürfe zu finden, bis eine ausreichende Anzahl von Ausgestaltungen gefunden ist.
Wie vorstehend umrissen, kann Durchführen 304 von DOE umfassen, dass DOE über einen Bereich von Benutzerattributen (demografischen Attributen und Verhaltensattributen) und eine Vielzahl von Umgebungsfaktoren durchgeführt wird. Dementsprechend wird das zweidimensionale Raster mit dem gleichen Ziel, wie vorstehend umrissen eine Verteilung ohne Cluster zu erreichen, durch ein N-dimensionales Raster ersetzt, wobei N eine ganze Zahl ist, die größer als drei ist. In einigen Ausführungsformen kann ein bestimmter Punkt in dem DOE-Raster einmal oder wiederholt getestet werden. Wenn mehrere Tests durchgeführt werden, wird ein Einblick in Versuchsvariation erlangt.
Unter Bezugnahme auf 6A und 6B kann Aufbauen 308 der SRSMs unter Verwendung einer Methodik umgesetzt werden, die eine Beziehung zwischen den Eingabefaktoren x (z. B. den Sensordaten und während der Tests durch die Steuerung 102 vorgenommenen Steuerhandlungen) und der Ausgabereaktion y(x) (z. B. dem Benutzerfeedback und/oder der Steuereffizienz) auf Grundlage der erhobenen Daten {x_i, y_i: i=1,...,N}, wobei y_i = y(x_i), an einigen diskretisierten Stichprobenpunkten x_i (i=1,...,N) aufbaut. In diesem Fall kann jeder Stichprobenpunkt ein Fahrmanöver an einem gegebenen Ort sein. Aufbauen 308 der SRSMs strebt an, gewünschte Ausgaben wie etwa Fahrgastsicherheit S, Fahrgastkomfort C und Steuereffizienz E mit verschiedenen Eingaben einschließlich der Sensordaten 128d (die den Fahrzeugzustand und durch die Außensensoren 104 detektierte Umweltfaktoren widerspiegeln) und Steuerhandlungsdaten 128e in Beziehung zu setzen. Im Allgemeinen ist die Steuereffizienz E schwierig zu quantifizieren, es kann sich ihr jedoch durch einen Zeitraum, der zum Ausführen des Fahrmanövers erforderlich ist, angenähert werden. Dementsprechend kann das Benutzerfeedback 128b stellvertretend für einige oder alle der Werte S, C und E verwendet werden.
Diese erhobenen Daten werden als die Trainingsdaten bezeichnet. Techniken zur Antwortflächenmodellierung (response surface modeling - RSM) können im Allgemeinen als (strikte) Interpolation (siehe 6A) und Regression (siehe 6B) kategorisiert werden. Beide zielen darauf ab, eine funktionelle Reaktion y(x) als Annäherung von y(x) aufzubauen; das durch strikte Interpolation erstellte Modell durchläuft jedoch genau alle Trainingsdaten, während ein durch Regressionsverfahren erstelltes Modell gewöhnlich ein Gleichgewicht zwischen dem Anpassen der Trainingsdaten und erzeugen eines glatten RSM schafft.
Gemäß ihren unterschiedlichen Eigenschaften werden sie zu unterschiedlichen Zwecke verwendet: Interpolationsverfahren werden zum Erzeugen von RSMs von aufwändigen Computersimulationen verwendet (was zu einem „Metamodell“ führt, was „Modell eines Computermodells“ bedeutet), da Computersimulationen typischerweise mit keinerlei Rauschen und Variationen einhergehen; andererseits können Regressionsverfahren zum Aufbauen von RSMs für physikalische Versuche angewendet werden, die unweigerlich durch Testbedingungen, systematische Variabilität, menschliche Fehler etc. beeinflusst werden. Bei verrauschten Versuchsdaten ist es nicht mehr aussagekräftig (und praktisch schwierig), jeden einzelnen Trainingsdatenpunkt zu durchlaufen, da dies andernfalls zu einer hochgradig schwankenden („Zickzack-“) Funktion führt.
Ungeachtet der Kategorie hängt die Entwicklung von RSM-Techniken mit zwei zentralen Herausforderungen zusammen, wobei es sich bei der ersten um die Flexibilität bei der funktionalen Form und die Fähigkeit zum Anpassen an die Trainingsdaten handelt. Die meisten bestehenden Verfahren in der eher traditionellen Fachliteratur gehen von einer parametrischen funktionalen Form für die zugrundeliegende Funktion y(x) aus. Zum Beispiel nimmt die lineare Regression an, dass die Reaktion eine lineare Kombination aus den Eingabefaktoren ist, d. h. y = a^Tx + b, wobei a und b gemäß dem Prozess der linearen Regression bestimmte Faktoren sind, und die Polynomregression eine polynomische Beziehung zwischen y und x annimmt etc. Derartige Annahmen vereinfachen die Erstellung von RSMs stark, doch es mangelt ihnen andererseits auch an der Fähigkeit, sich auf technische Anwendungen in der Wirklichkeit einzustellen, die in vielen Fällen mit komplexen Reaktionen einhergehen, die nicht durch eine einfache funktionale Form beschrieben werden können.
Eine weitere Herausforderung, die in der bestehenden Fachliteratur äußerst selten thematisiert wird, ist die Fähigkeit zum Quantifizieren der Unsicherheit bei der Vorhersage. Die Unsicherheit geht aus dem Mangel an Wissen/Informationen hervor, zum Beispiel bei den simulierten Eingabeeinstellungen oder physikalischen Versuchen, die nicht durchgeführt worden sind; und aus der physikalischen Variabilität, zum Beispiel der Versuchsvariation, deren Niveau kaum genau bekannt sein kann. Bei Vorhandensein von Unsicherheit ist es für Ingenieure hilfreich zu verstehen, „wie falsch“ das erstellte y(x) des RSM sein kann und wie sehr die tatsächlichen Testdaten von der Vorhersage des Modells abweichen können. Dies können jedoch nur sehr wenige Verfahren bewerkstelligen. Ein RSM mit quantifizierter Unsicherheit gibt im Wesentlichen eine Reihe von Funktionen an, die womöglich die zugrundeliegende physikalische Funktion sein können, und wird hier als stochastisches RSM im Gegensatz zu einem deterministischen RSM, das nur eine einzelne Vorhersagefunktion y(x) bei einer bestimmten Eingabeeinstellung x (siehe 7A und 7B) bereitstellt, bezeichnet.
In einigen Ausführungsformen wird die Gauß-Prozess-Regression (GPR) als SRSM-Verfahren verwendet, da sie nicht auf konkrete funktionale Formen beschränkt ist und mit verrauschten Versuchsdaten umgehen kann. Sie weist zudem vorteilhaft ein angenehmes Merkmal auf, dass sie eine Vorhersageverteilung (die auch als Vorhersagevarianz, ein Vorhersageintervall etc. interpretiert werden kann) bereitstellt, die die Unsicherheit bei der Vorhersage quantifiziert. Es folgt eine ausführliche Beschreibung des Verfahrens.
Ein Gauß-Prozess (GP) ist eine spezifische Art von räumlichen Zufallsprozessen (spatial random processes - SRP), der als Sammlung von Zufallsvariablen betrachtet werden kann, die über einen räumlichen Eingaberaum x verteilt (d. h. durch diesen indexiert) sind. Die Versuchsreaktion y(x) kann folgendermaßen aufgelöst werden: $y (x) = y^{t} (x) + ε,$
wobei y^t(x) die zugrundeliegende „wahre“ Reaktion (ohne Einfluss der Versuchsvariabilität) bezeichnet und ε∼ N(0,λ) eine mittelwertfreie normalverteilte Zufallsvariable mit der Varianz λ (typischerweise angenommene Unbekannte) ist, die für die Versuchsvariabilität steht. Ein GP-Modell für y(x) wird durch Folgendes bezeichnet: $y^{t} (x) \sim G P (m (x), V (x, x')),$
wobei m(x) und V(x,x') die Mittelwertfunktion bzw. die Kovarianzfunktion des GP sind.
Eine häufig verwendete Form der Mittelwert- und Kovarianzfunktion lautet folgendermaßen: $m (x) = h {(x)}^{T} β,$
$V (x, x') = σ^{2} exp {- \sum_{k = 1}^{p} ω_{k} {(x_{k} - x_{k}^{'})}^{2}},$
wobei p die Größe von x ist, d. h. x=(x₁, x₂, ..., x_p)^T. h(x) ist ein Vektor von durch den Benutzer vordefinierten Polynomfunktionen, die zum Darstellen des vorherigen Mittelwerts verwendet werden. β ist der Vektor von mit h(x) assoziierten Koeffizienten zur Polynomregression des Mittelwerts, σ ist die vorherige Standardabweichung für eine einzelne Zufallsvariable in dem Zufallsprozess und ω=[ω₁, ω₂, ..., ω_p]^T ist der Vektor von Rauheitsparametern, die zum Erfassen der Nichtlinearität des Prozesses verwendet werden.
Die Erstellung des GP der Versuchsreaktion y(x) ist äquivalent zum Schätzen der unbekannten Parameter des GP, d. h. Φ = {β, σ, ω, λ} durch den Ansatz der Schätzung durch die maximale Wahrscheinlichkeit (maximum likelihood estimation - MLE), und kann somit unter Verwendung einer numerischen Optimierungsstrategie gelöst werden.
In der vorstehenden generischen Erörterung kann x als Kombination aus den Sensordaten und der Steuerhandlung bei dem Manöver interpretiert werden, und y ist das Benutzerfeedback. ε ist ein Zufallsterm, der die Variation beim Testen berücksichtigt (z. B. die große Vielfalt von Benutzerpräferenzen, die Testbedingungen, die nicht erfasst werden können...). Die anderen Variablen (zum Beispiel m, V, h) sind allesamt latente Variablen, die zum Erstellen der Beziehung zwischen y und x notwendig sind.
Unter Bezugnahme auf 8 ist, nachdem die wahrscheinlichsten Werte von ϕ bestimmt worden sind, der GP vollständig bestimmt und kann anschließend dazu verwendet werden, die Werte bei anderen Entwürfen vorherzusagen. Ein Vorteil der Verwendung der GPR besteht darin, dass sie die Interpolationsunsicherheit an den Orten, die noch nicht getestet worden sind, und die Versuchsvariabilität, die durch ein Vorhersageintervall dargestellt wird, das durch den schattierten Bereich in 8 dargestellt ist, quantifizieren kann.
Wenn die mit der Vorhersage von Ausgabereaktionen assoziierte Unsicherheit quantifiziert wird, ist es hilfreich, Unsicherheit in die Optimierungsformulierung von Schritt 314 in 3 einzubeziehen. Eine Forschungslinie zu fortgeschrittenen Ansätzen für OUU zielt auf die Verbesserung der Robustheit der Entwurfsleistung und Reduzierung ihrer Empfindlichkeit gegenüber der Unsicherheit ab, was als robuste Entwurfsoptimierung (robust design optimization - RDO) bekannt ist. Eine andere Kategorie der OUU ist die zuverlässigkeitsbasierte Entwurfsoptimierung (reliability-based design optimization - RBDO), die darauf abzielt, den Einschränkungen mit einem gewissen Konfidenzniveau zu genügen. Eine Kombination aus RDO und RBDO ist hier offenbart, wobei die erstere der Maximierung des Fahrgastkomforts C und der Steuereffizienz E (äquivalent dazu der Minimierung von -C und -E) dient und die letztere der Erfüllung der Anforderungen bezüglich der Sicherheit S dient. Die mathematische Formulierung lautet: $\begin{array}{l} min & - μ_{C} (x) + k_{C} σ_{C} (x), \\ min & - μ_{E} (x) + k_{E} σ_{E} (x), \\ s . t . & Pr [S (x) \geq S_{t a r g e t}] \geq α % \\ x^{L} \leq x \leq x^{U}, \end{array}$
wobei x, der Vektor der Eingabevariablen, innerhalb des relevanten Bereichs gerichtet ist, der durch die untere Grenze x^L und obere Grenze x^U begrenzt wird. µ und σ sind die mittlere Abweichung bzw. Standardabweichung ihrer tiefgestellten Angaben. S_target ist die Sicherheitsanforderung, a% ist das Konfidenzniveau, dass die Sicherheitsanforderung erfüllt würde, und k_C und k_E sind vordefinierte Gewichtungsfaktoren, die die relative Bedeutung der Reduzierung der Variabilität bei der Optimierung darstellen.
Im hier verwendeten Sinne bezieht sich Optimierung auf einen Verbesserungsprozess, der anstrebt, sich einer optimalen Lösung anzunähern, und der sich über mehrere Iterationen hinweg verbessert, obwohl es nicht erforderlich ist, dass die tatsächliche optimale Lösung erlangt wird, um den Vorteil des vorstehend offenbarten Ansatzes zu erlangen. Gleichermaßen bezieht sich die Formulierung aus (5) darauf, dass Minima angestrebt werden, die Einschränkungen unterliegen, sodass für mehrere Iterationen die Werte in den „min“-Ausdrücken abnehmen, obwohl die absolut möglichst minimalen Werte für die „min“-Ausdrücke nicht tatsächlich erreicht werden müssen, um den Vorteil des vorstehend offenbarten Ansatzes zu erlangen.
Die Gleichungen (1)-(4) legen dar, wie die Beziehung zwischen einer beliebigen Ausgabe y und Eingabe x unter Verwendung von GPR erstellt wird, d. h. sie sind nicht für eine bestimmte Anwendung spezifisch. Unter Anwendung dieses Verfahrens auf die Feedbackaufzeichnungen 126 können die Beziehungen zwischen dem Benutzerkomfort C (der in Gleichung (1)-(4) äquivalent zu y ist) und den Eingaben x erstellt werden. Gleichermaßen kann die Beziehung zwischen E (das in Gleichung 1-4 auch als y betrachtet werden kann) und x erhalten werden.
Nach der Anwendung des Verfahrens wird eine Beziehung erlangt, deren Form der des Graphen aus 8 ähnelt. Daher handelt es sich bei µ_C(x) und µ_E(x) um die „mittleren Vorhersagen“ von C und E in 8, und σ_C(x) und σ_E(x) sind eine Quantifizierung von C und E („Vorhersageintervall“ in 8).
Um eine Beziehung zwischen der Sicherheit S und der Eingabevariablen x zu erlangen, können Computersimulationen des Testzyklus durchgeführt werden (d. h. unter Verwendung der Sensordaten und Steuerhandlungen, die in den Feedbackaufzeichnungen 126 angegeben sind) und bestimmt werden, ob es zu unsicheren Bedingungen kam.
In der vorstehenden Offenbarung wurde auf die beigefügten Zeichnungen Bezug genommen, die einen Teil davon bilden und in denen zur Veranschaulichung konkrete Umsetzungen gezeigt sind, in denen die Offenbarung ausgeführt sein kann. Es versteht sich, dass andere Umsetzungen verwendet werden können und strukturelle Änderungen vorgenommen werden können, ohne vom Umfang der vorliegenden Offenbarung abzuweichen. Bezugnahmen in der Beschreibung auf „eine Ausführungsform“, „ein Ausführungsbeispiel“ etc. geben an, dass die beschriebene Ausführungsform ein(e) bestimmte(s) Merkmal, Struktur oder Eigenschaft beinhalten kann, doch es muss nicht notwendigerweise jede Ausführungsform diese(s) bestimmte Merkmal, Struktur oder Eigenschaft beinhalten. Darüber hinaus beziehen sich derartige Formulierungen nicht unbedingt auf dieselbe Ausführungsform. Ferner sei darauf hingewiesen, dass, wenn ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben wird, es im Bereich des Fachwissens des Fachmanns liegt, ein derartiges Merkmal, eine derartige Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen zu bewirken, ob dies nun ausdrücklich beschrieben ist oder nicht.
Umsetzungen der hier offenbarten Systeme, Vorrichtungen und Verfahren können einen Spezial- oder Universalcomputer umfassen oder verwenden, der Computerhardware beinhaltet, wie etwa zum Beispiel einen oder mehrere Prozessoren und einen oder mehrere Systemspeicher, wie hier erörtert. Umsetzungen innerhalb des Umfangs der vorliegenden Offenbarung können zudem physische Datenträger und andere computerlesbare Medien zum Transportieren oder Speichern von computerausführbaren Anweisungen und/oder Datenstrukturen einschließen. Bei derartigen computerlesbaren Medien kann es sich um beliebige verfügbare Medien handeln, auf die durch ein Universal- oder Spezialcomputersystem zugegriffen werden kann. Bei computerlesbaren Medien, auf denen computerausführbare Anweisungen gespeichert werden, handelt es sich um Computerspeichermedien (-vorrichtungen). Bei computerlesbaren Medien, die computerausführbare Anweisungen transportieren, handelt es sich um Übertragungsmedien. Daher können Umsetzungen der Offenbarung beispielsweise und nicht einschränkend mindestens zwei deutlich unterschiedliche Arten von computerlesbaren Medien umfassen: Computerspeichermedien (-vorrichtungen) und Übertragungsmedien.
Zu Computerspeichermedien (-vorrichtungen) gehören RAM, ROM, EEPROM, CD-ROM, Festkörperlaufwerke (solid state drives - SSDs) (z. B. basierend auf RAM), Flash-Speicher, Phasenänderungsspeicher (phase-change memory - PCM), andere Speicherarten, andere optische Plattenspeicher, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder ein beliebiges anderes Medium, das dazu verwendet werden kann, die gewünschten Programmcodemittel in Form von computerausführbaren Anweisungen oder Datenstrukturen zu speichern, und auf das durch einen Universal- oder Spezialcomputer zugegriffen werden kann.
Eine Umsetzung der hier offenbarten Vorrichtungen, Systeme und Verfahren kann über ein Computernetzwerk kommunizieren. Ein „Netzwerk“ ist als eine oder mehrere Datenverbindungen definiert, die den Transport elektronischer Daten zwischen Computersystemen und/oder Modulen und/oder anderen elektronischen Vorrichtungen ermöglichen. Wenn Informationen über ein Netzwerk oder eine andere (entweder festverdrahtete, drahtlose oder eine Kombination aus festverdrahteter oder drahtloser) Kommunikationsverbindung an einen Computer übertragen oder diesem bereitgestellt werden, sieht der Computer die Verbindung korrekt als Übertragungsmedium an. Übertragungsmedien können ein Netzwerk und/oder Datenverbindungen beinhalten, die dazu verwendet werden können, gewünschte Programmcodemittel in Form von computerausführbaren Anweisungen oder Datenstrukturen zu transportieren, und auf die durch einen Universal- oder Spezialcomputer zugegriffen werden kann. Kombinationen aus den Vorstehenden sollten ebenfalls im Umfang computerlesbarer Medien beinhaltet sein.
Computerausführbare Anweisungen umfassen zum Beispiel Anweisungen und Daten, die bei Ausführung an einem Prozessor einen Universalcomputer, Spezialcomputer oder eine Spezialverarbeitungsvorrichtung dazu veranlassen, eine bestimmte Funktion oder Gruppe von Funktionen auszuführen. Die computerausführbaren Anweisungen können zum Beispiel Binärdateien, Zwischenformatanweisungen, wie etwa Assemblersprache, oder auch Quellcode sein. Obwohl der Gegenstand in für Strukturmerkmale und/oder methodische Handlungen spezifischer Sprache beschrieben wurde, versteht es sich, dass der in den beigefügten Patentansprüchen definierte Gegenstand nicht notwendigerweise auf die vorstehend beschriebenen Merkmale oder Handlungen beschränkt ist. Die beschriebenen Merkmale und Handlungen werden vielmehr als beispielhafte Formen der Umsetzung der Patentansprüche offenbart.
Der Fachmann wird verstehen, dass die Offenbarung in Network-Computing-Umgebungen mit vielen Arten von Computersystemauslegungen angewendet werden kann, einschließlich eines Armaturenbrett-Fahrzeugcomputers, PCs, Desktop-Computern, Laptops, Nachrichtenprozessoren, Handvorrichtungen, Multiprozessorsystemen, Unterhaltungselektronik auf Mikroprozessorbasis oder programmierbarer Unterhaltungselektronik, Netzwerk-PCs, Minicomputern, Mainframe-Computern, Mobiltelefonen, PDAs, Tablets, Pagern, Routern, Switches, verschiedenen Speichervorrichtungen und dergleichen. Die Offenbarung kann zudem in Umgebungen mit verteilten Systemen angewendet werden, in denen sowohl lokale Computersysteme als auch Remotecomputersysteme, die durch ein Netzwerk (entweder durch festverdrahtete Datenverbindungen, drahtlose Datenverbindungen oder durch eine Kombination aus festverdrahteten und drahtlosen Datenverbindungen) verbunden sind, Aufgaben ausführen. In einer Umgebung mit verteilten Systemen können sich Programmmodule sowohl in lokalen Speichervorrichtungen als auch in Fernspeichervorrichtungen befinden.
Ferner können die hier beschriebenen Funktionen gegebenenfalls in einem oder mehreren der folgenden ausgeführt werden: Hardware, Software, Firmware, digitalen Komponenten oder analogen Komponenten. Ein oder mehrere anwendungsspezifische integrierte Schaltkreise (ASICs) können zum Beispiel dazu programmiert sein, eines bzw. einen oder mehrere der hier beschriebenen Systeme und Vorgänge ausführen. Bestimmte Ausdrücke werden in der gesamten Beschreibung und den Patentansprüchen verwendet, um auf bestimmte Systemkomponenten Bezug zu nehmen. Für den Fachmann versteht es sich, dass auf Komponenten durch unterschiedliche Bezeichnungen Bezug genommen werden kann. In dieser Schrift soll nicht zwischen Komponenten unterschieden werden, die sich dem Namen nach unterscheiden, nicht jedoch von der Funktion her.
Es ist anzumerken, dass die vorstehend erörterten Sensorausführungsformen Computerhardware, -software, -firmware oder eine beliebige Kombination daraus umfassen können, um mindestens einen Teil ihrer Funktionen auszuführen. Ein Sensor kann zum Beispiel Computercode beinhalten, der dazu ausgelegt ist, in einem oder mehreren Prozessoren ausgeführt zu werden, und kann eine Hardware-Logikschaltung/elektrische Schaltung beinhalten, die durch den Computercode gesteuert wird. Diese beispielhaften Vorrichtungen sind hier zum Zwecke der Veranschaulichung bereitgestellt und sollen nicht einschränkend sein. Ausführungsformen der vorliegenden Offenbarung können in weiteren Arten von Vorrichtungen umgesetzt werden, wie es dem einschlägigen Fachmann bekannt ist.
Mindestens einige Ausführungsformen der Offenbarung wurden Computerprogrammprodukten zugeführt, die eine solche Logik (z. B. in Form von Software) umfassen, die auf einem beliebigen computernutzbaren Medium gespeichert ist. Solche Software veranlasst bei Ausführung in einer oder mehreren Datenverarbeitungsvorrichtungen eine Vorrichtung dazu, wie hier beschrieben zu arbeiten.
Während vorstehend verschiedene Ausführungsformen der vorliegenden Offenbarung beschrieben wurden, versteht es sich, dass diese lediglich als Beispiele dienen und nicht als Einschränkung. Für den einschlägigen Fachmann wird ersichtlich, dass verschiedene Änderungen in Form und Detail daran vorgenommen werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen. Daher sollen die Breite und der Umfang der vorliegenden Offenbarung durch keine der vorstehend beschriebenen beispielhaften Ausführungsformen eingeschränkt werden, sondern sollen lediglich in Übereinstimmung mit den folgenden Patentansprüchen und ihren Äquivalenten definiert sein. Die vorstehende Beschreibung wurde zum Zwecke der Veranschaulichung und Beschreibung dargelegt. Sie erhebt keinerlei Anspruch auf Vollständigkeit und soll die Offenbarung nicht auf die konkrete offenbarte Form beschränken. Viele Modifikationen und Variationen sind in Anbetracht der vorstehenden Lehren möglich. Ferner ist anzumerken, dass beliebige oder alle der vorangehend genannten alternativen Umsetzungen in einer beliebigen gewünschten Kombination verwendet werden können, um zusätzliche Hybridumsetzungen der Offenbarung zu bilden.

Claims

Verfahren, das Folgendes durch ein Computersystem umfasst: Empfangen von Feedback von einem oder mehreren Fahrgästen eines oder mehrerer autonomer Fahrzeuge; Empfangen von Sensordaten und Steuerdaten von dem einen oder den mehreren autonomen Fahrzeugen; Erzeugen eines Verhaltensmodells gemäß dem Feedback, den Sensordaten und den Steuerdaten; Bestimmen der Unsicherheit für das Verhaltensmodell; und Erzeugen eines Steuermodells gemäß dem Verhaltensmodell und der Unsicherheit für das Verhaltensmodell.
Verfahren nach Anspruch 1, wobei das Feedback eine oder mehrere Fahrmanöverbewertungen beinhaltet, wobei jede Bewertung einen Ort beinhaltet.
Verfahren nach Anspruch 2, wobei Empfangen von Feedback Empfangen von Feedback von einer Vielzahl von Fahrgästen beinhaltet.
Verfahren nach Anspruch 3, ferner umfassend Auswählen der Vielzahl von Fahrgästen durch das Computersystem gemäß Versuchsplanungskriterien.
Verfahren nach Anspruch 3, ferner umfassend Auswählen der Vielzahl von Fahrgästen durch das Computersystem gemäß einem Versuchsplanungsalgorithmus, der potentielle Fahrgäste zur Auswahl gemäß demografischen Attributen der potentiellen Fahrgäste und Fahrpräferenzen der potentiellen Fahrgäste verarbeitet.
Verfahren nach Anspruch 1, wobei Erzeugen des Verhaltensmodells gemäß dem Feedback und den Sensordaten Erzeugen eines stochastischen Antwortflächenmodells (stochastic response surface model - SRSM) gemäß dem Feedback und den Sensordaten umfasst, wobei das SRSM das Feedback mit Umgebungsfaktoren, die durch die Sensordaten angegeben werden, dem Status des einen oder der mehreren autonomen Fahrzeuge, der in den Sensordaten angegeben wird, und durch das autonome Fahrzeug vorgenommenen Steuerhandlungen, die in den Steuerdaten angegeben werden, in Beziehung setzt.
Verfahren nach Anspruch 6, ferner umfassend: Beurteilen des SRSM durch das Computersystem gemäß einem Teil des Feedbacks, der Sensordaten und der Steuerdaten; Bestimmen durch das Computersystem, dass das SRSM nicht zufriedenstellend dem Teil des Feedbacks, der Sensordaten und der Steuerdaten entspricht; als Reaktion auf Bestimmen, dass die SRSMs nicht zufriedenstellend dem Teil des Feedbacks, der Sensordaten und der Steuerdaten entsprechen, Erheben von zusätzlichem Feedback, zusätzlichen Sensordaten und zusätzlichen Steuerdaten; und Erzeugen eines aktualisierten SRSM unter Verwendung des zusätzlichen Feedbacks, der zusätzlichen Sensordaten und der zusätzlichen Steuerdaten.
Verfahren nach Anspruch 1, wobei Erzeugen des Steuermodells gemäß dem Verhaltensmodell und der Unsicherheit für das Modell Ausführen eines Algorithmus zur Mehrzieloptimierung unter Unsicherheit (optimization under uncertainty - OUU) unter Verwendung des Verhaltensmodells und der Unsicherheit für das Verhaltensmodell umfasst.
Verfahren nach Anspruch 1, wobei die Sensordaten Ausgaben von mindestens einem von einem LIDAR-Sensor (light detection and ranging sensor), einem RADAR-Sensor (radio detection and ranging sensor) und einer oder mehreren Kameras beinhaltet.
Verfahren nach Anspruch 1, ferner umfassend: Hochladen des Steuermodells in ein autonomes Fahrzeug; Empfangen von Ausgaben von einem oder mehreren Sensoren durch eine Steuerung des autonomen Fahrzeugs; und autonomes Fahren des autonomen Fahrzeugs durch die Steuerung unter Verwendung der gemäß dem Steuermodell verarbeiteten Ausgaben.
System, umfassend eine oder mehrere Verarbeitungsvorrichtungen und eine oder mehrere Speichervorrichtungen, die an die eine oder mehreren Verarbeitungsvorrichtungen wirkgekoppelt sind, wobei die eine oder mehreren Speichervorrichtungen ausführbaren Code speichern, der dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Empfangen von Feedback von einer Vielzahl von Fahrgästen eines oder mehrerer autonomer Fahrzeuge; Empfangen von Sensordaten und Steuerdaten von dem einen oder den mehreren autonomen Fahrzeugen; Erzeugen eines Verhaltensmodells gemäß dem Feedback, den Sensordaten und den Steuerdaten; Bestimmen der Unsicherheit für das Verhaltensmodell; und Erzeugen eines Steuermodells gemäß dem Verhaltensmodell und der Unsicherheit für das Verhaltensmodell; wobei das Feedback eine oder mehrere Fahrmanöverbewertungen beinhaltet, wobei jede Bewertung einen Ort beinhaltet; wobei die Sensordaten Ausgaben von mindestens einem von einem LIDAR-Sensor, einem RADAR-Sensor und einer oder mehreren Kameras beinhaltet.
System nach Anspruch 11, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen dazu zu veranlassen, die Vielzahl von Fahrgästen gemäß Versuchsplanungskriterien auszuwählen; und wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen dazu zu veranlassen, die Vielzahl von Fahrgästen gemäß einem Versuchsplanungsalgorithmus auszuwählen, der potentielle Fahrgäste zur Auswahl gemäß demografischen Attributen der potentiellen Fahrgäste und Fahrpräferenzen der potentiellen Fahrgäste verarbeitet.
System nach Anspruch 11, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen dazu zu veranlassen, das Verhaltensmodell gemäß dem Feedback und den Sensordaten durch Erzeugen eines stochastischen Antwortflächenmodells (SRSM) gemäß dem Feedback und den Sensordaten zu erzeugen, wobei das SRSM das Feedback mit Umgebungsfaktoren, die durch die Sensordaten angegeben werden, dem Status des einen oder der mehreren autonomen Fahrzeuge, der in den Sensordaten angegeben wird, und durch das autonome Fahrzeug vorgenommenen Steuerhandlungen, die in den Steuerdaten angegeben werden, in Beziehung setzt.
System nach Anspruch 13, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen zu Folgendem zu veranlassen: Beurteilen des SRSM gemäß einem Teil des Feedbacks, der Sensordaten und der Steuerdaten; falls das SRSM nicht zufriedenstellend dem Teil des Feedbacks, der Sensordaten und der Steuerdaten entspricht, Erheben von zusätzlichem Feedback, zusätzlichen Sensordaten und zusätzlichen Steuerdaten; und Erzeugen eines aktualisierten SRSM unter Verwendung des zusätzlichen Feedbacks, der zusätzlichen Sensordaten und der zusätzlichen Steuerdaten.
System nach Anspruch 11, wobei der ausführbare Code ferner dazu wirksam ist, die eine oder mehreren Verarbeitungsvorrichtungen dazu zu veranlassen, das Steuermodell gemäß dem Verhaltensmodell und der Unsicherheit für das Modell durch Ausführen eines Algorithmus zur Mehrzieloptimierung unter Unsicherheit (OUU) unter Verwendung des Verhaltensmodells und der Unsicherheit für das Verhaltensmodell zu erzeugen.