DE112021000216T5

DE112021000216T5 - Verhaltensplanung für autonome Fahrzeuge

Info

Publication number: DE112021000216T5
Application number: DE112021000216.3T
Authority: DE
Inventors: David Nister; Yizhou Wang; Julia Ng; Rotem Aviv; Seungho Lee; Joshua John Bialkowski; Hon Leung Lee; Hermes Lanker; Raul Correal Tezanos; Zhenyi Znang; Nikolai Smolyanskiy; Alexey Kamenev; Ollin Boer Bohan; Anton Vorontsov; Miguel Sainz Serra; Birgit Henke
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2020-02-19
Filing date: 2021-02-18
Publication date: 2022-11-03
Also published as: US20240239374A1; US11981349B2; WO2021168058A1; JP2023514905A; US20210253128A1; CN115175841A

Abstract

Ausführungsformen der vorliegenden Offenbarung beziehen sich auf die Verhaltensplanung für autonome Fahrzeuge. Das hier beschriebene Verfahren wählt eine bevorzugte Trajektorie für ein autonomes Fahrzeug auf der Grundlage einer Bewertung mehrerer hypothetischer Trajektorien durch verschiedene Komponenten innerhalb eines Planungssystems aus. Die verschiedenen Komponenten geben für jede Trajektorie eine Optimierungsbewertung entsprechend den Prioritäten der jeweiligen Komponente ab, und Bewertungen mehrerer Komponenten können eine endgültige Optimierungsbewertung bilden. Dieses Bewertungssystem ermöglicht es, die konkurrierenden Prioritäten (z.B. Komfort, minimale Fahrzeit, Kraftstoffverbrauch) der verschiedenen Komponenten gemeinsam zu berücksichtigen. In Beispielen kann die Route mit der besten kombinierten Bewertung für die Umsetzung ausgewählt werden. So kann ein iterativer Ansatz, der verschiedene Faktoren bewertet, verwendet werden, um eine optimale oder bevorzugte Trajektorie für ein autonomes Fahrzeug bei der Navigation durch eine Umgebung zu ermitteln.

Description

HINTERGRUND DER ERFINDUNG
Die Entwicklung eines Systems zum autonomen und sicheren Fahren eines Fahrzeugs ohne Aufsicht ist enorm schwierig. Ein autonomes Fahrzeug sollte zumindest in der Lage sein, als funktionales Äquivalent eines aufmerksamen Fahrers zu fungieren - der auf ein Wahrnehmungs- und Handlungssystem zurückgreift, das eine unglaubliche Fähigkeit besitzt, bewegliche und statische Hindernisse in einer komplexen Umgebung zu erkennen und darauf zu reagieren, um Kollisionen mit anderen Objekten oder Strukturen entlang des Pfades bzw. Weges des Fahrzeugs zu vermeiden. Daher ist die Fähigkeit, Hindernisse, Wege, Wartebedingungen, Straßen- oder Fahrbahngeometrie und/oder andere Informationen über die Umgebung zu erkennen, für Wahrnehmungssysteme zum autonomen Fahren oft entscheidend.
Die Erkenntnisse der Wahrnehmungssysteme zum autonomen Fahren können für die Verhaltensplanung verwendet werden, z. B. für die Bestimmung einer oder mehrerer Trajektorien entlang einer Route des Fahrzeugs. Die Verhaltensplanung für autonome Fahrzeuge ist eine anspruchsvolle, aber kritische Aufgabe, insbesondere in komplexen städtischen Szenarien. Damit ein autonomes Fahrzeug zum Beispiel seine Umgebung verstehen kann, um sichere und effektive Verhaltensentscheidungen zu treffen, müssen die autonomen Fahrzeuge diese verschiedenen Umgebungsdaten zusammen mit der aktuellen Fahrzeugtrajektorie und den Routeninformationen verarbeiten, um eine fortlaufende oder zukünftige Trajektorie für das Fahrzeug zu berechnen. Herkömmliche Systeme zur Verhaltensplanung beruhen jedoch häufig auf unflexiblen Entscheidungen, die die sich ständig ändernden Variablen in der Umgebung nicht berücksichtigen. Konventionelle Verfahren wählen beispielsweise eine Route mit der geringsten Fahrzeit aus und legen dann einen Fahrbahnplan fest, der dieser Route folgt. Diese starre Planung erlaubt es einem Planungssystem jedoch nicht, die Trajektorie optimal an die sich ändernden Umweltbedingungen anzupassen. Wenn beispielsweise das Verhalten des Fahrzeugs unabhängig von anderen Faktoren - wie der Kollisionsvermeidung - bestimmt wird, können die Anpassungen eines aktuellen Plans eher reaktiv als proaktiv erfolgen. So kann im Beispiel der Kollisionsvermeidung eine Steuerungsentscheidung unter Verwendung der Ausgaben eines Verhaltensplaners bestimmt werden, und wenn festgestellt wird, dass eine Kollision möglich ist, kann eine Kollisionsvermeidungsfunktion eine aktualisierte Steuerungsentscheidung erzeugen. Folglich wird die Trajektorie des Fahrzeugs nicht unter Berücksichtigung der Kollisionsvermeidung bestimmt, sondern von der Kollisionsvermeidungsfunktion des Fahrzeugs überschrieben. Diese konventionellen Systeme bestimmen somit ein suboptimales Verhalten des Fahrzeugs, das die dynamischen Eingaben der verschiedenen Fahrzeugfunktionen - wie Kollisionsvermeidung oder Fahrbahnplanung - nicht berücksichtigt.
ZUSAMMENFASSUNG DER ERFINDUNG
Ausführungsformen der vorliegenden Offenbarung beziehen sich auf die Verhaltensplanung für autonome Fahrzeuge. Es werden Systeme und Verfahren zur Planung einer Trajektorie für ein autonomes Fahrzeug offenbart, die mehrere Vorteile gegenüber bisherigen Verfahren zur Planung der Trajektorien aufweisen. Zum Beispiel ermöglicht das hier beschriebene Verfahren im Gegensatz zu herkömmlichen Verfahren die gleichzeitige Auswertung mehrerer hypothetischer Trajektorien durch verschiedene Komponenten innerhalb eines Planungssystems. Jede dieser verschiedenen Komponenten - z. B. für Kollisionsvermeidung, Fahrzeugmanövertypen, Routenplanung, Fahrbahnplanung, Ausweichinformationen usw. - kann für jede Trajektorie eine Optimierungsbewertung entsprechend den Prioritäten der jeweiligen Komponente abgeben. So können die Bewertungen bzw. Ergebnisse mehrerer Komponenten eine endgültige Optimierungsbewertung bilden, und die Trajektorie mit der besten kombinierten Bewertung kann zur Umsetzung ausgewählt werden. Mit diesem Bewertungssystem können die konkurrierenden Prioritäten (z. B. Komfort, minimale Fahrzeit, Kraftstoffverbrauch, Sicherheit usw.) verschiedener Komponenten gemeinsam berücksichtigt werden.
Wie es oben beschrieben ist, ermöglicht das hier beschriebene Verfahren darüber hinaus eine sicherere und effizientere Planung, indem es Informationen bereitstellt, die von mehreren Systemkomponenten genutzt werden können, um die Folgen zu quantifizieren, die sich ergeben, wenn ein derzeit bevorzugter oder ausgewählter Fahrbahnplan oder eine Route nicht eingehalten wird. Während herkömmliche Ansätze beispielsweise erkennen, dass ein nicht erfolgter Fahrbahnwechsel innerhalb der nächsten fünf Sekunden dazu führen könnte, dass eine Route verpasst wird, können diese herkömmlichen Ansätze diesen Fehler nicht quantifizieren oder kodieren, wenn sie potenzielle zukünftige Trajektorien für das Fahrzeug erzeugen. Durch die Quantifizierung dieses Fehlers kann gemäß der vorliegenden Offenbarung eine bevorzugte oder optimale Route generiert und vom Planungssystem bei der Bestimmung einer zu verfolgenden Trajektorie verwendet werden. Infolgedessen kann das Verhaltensplanungssystem der vorliegenden Offenbarung Informationen von verschiedenen Systemkomponenten verwenden, um potenzielle Trajektorien für das Fahrzeug zu bestimmen, und kann die potenziellen Trajektorien - z. B. im Hinblick auf jedes dieser verschiedenen Systeme - bei jeder Iteration oder jedem Zeitschritt aktualisieren, um die dynamische Natur von Umgebungsvariablen, Routenplanungsinformationen und/oder Fahrbahnplanungsinformationen widerzuspiegeln.
Figurenliste
Die vorliegenden Systeme und Verfahren zur Verhaltensplanung für autonome Fahrzeuge werden im Folgenden unter Bezugnahme auf die beigefügten Figuren im Detail beschrieben, wobei:

1 ist eine Illustration einer beispielhaften Verhaltensplanungsarchitektur für autonome Fahrzeuge, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
2 ist eine Illustration von beispielhaften Bahnplänen und entsprechenden Geschwindigkeitsberechnungen gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
3 ist eine Illustration von beispielhaften Umgebungsbedingungen um ein autonomes Fahrzeug herum gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
4 ist eine Illustration von beispielhaften Bahnplänen und entsprechenden Geschwindigkeitsberechnungen, wenn sie gemäß einigen Ausführungsformen der vorliegenden Offenbarung an die Umgebungsbedingungen angepasst werden;
5 ist ein Flussdiagramm, das ein Verfahren zur Auswahl einer Trajektorie für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
6 ist ein Flussdiagramm, das ein Verfahren zur Auswahl einer Trajektorie für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
7 ist ein Flussdiagramm, das ein Verfahren zur Auswahl einer Trajektorie für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
8A ist eine Illustration eines Beispiels für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8B ist ein Beispiel für Kamerapositionen und Sichtfelder für das beispielhafte autonome Fahrzeug von 8A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8D ist ein Systemdiagramm für die Kommunikation zwischen einem oder mehreren Cloud-basierten Servern und dem beispielhaften autonomen Fahrzeug aus 8A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
9 ist ein Blockdiagramm einer beispielhaften Recheneinrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
10 ist ein Blockdiagramm eines beispielhaften Rechenzentrums, das für die Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es werden Systeme und Verfahren offenbart, die sich auf die Planung einer Trajektorie für ein autonomes Fahrzeug oder eine andere Art von autonomen Maschinen beziehen, wie z. B. aber nicht beschränkt auf die hier beschriebenen. Obwohl die vorliegende Offenbarung in Bezug auf ein Beispiel für ein autonomes Fahrzeug 800 (hier alternativ als „Fahrzeug 800“ oder „Ego-Fahrzeug 800“ bezeichnet, wovon ein Beispiel hier in Bezug auf die 8A-8D beschrieben wird) beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Beispielsweise können die hier beschriebenen Systeme und Verfahren von nichtautonomen Fahrzeugen, halbautonomen Fahrzeugen (z. B. in einem oder mehreren fortschrittlichen Fahrerassistenzsystemen (ADAS)), Robotern und Roboterplattformen, Lagerfahrzeugen, Geländewagen, fliegenden Luftschiffen, Booten und/oder anderen Fahrzeugtypen verwendet werden. Auch wenn die vorliegende Offenbarung in Bezug auf das autonome Fahren beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Beispielsweise können die hier beschriebenen Systeme und Verfahren in der Robotik (z. B. Verhaltensplanung für die Robotik), in Luftfahrtsystemen (z. B. Verhaltensplanung für eine Drohne oder ein anderes Luftfahrzeug), in Bootssystemen (z. B. Verhaltensplanung für Wasserfahrzeuge), in Simulationsumgebungen (z. B. zum Testen oder Validieren von Verhaltensplanungssystemen virtueller Fahrzeuge innerhalb einer virtuellen Simulationsumgebung) und/oder in anderen Technologiebereichen eingesetzt werden, wie z. B. für die Routenplanung, die Fahrbahnplanung, die Verhaltensplanung und/oder Steuerungsentscheidungen.
Die hier beschriebene Technologie kann eine Architektur verwenden, die es jeder Planungskomponente erlaubt, minimale Rechenressourcen zu verwenden. Bei einigen Ausführungsformen kann das hier beschriebene Trajektorienplanungssystem drei verschiedene Planungskomponenten verwenden, die jeweils einen unterschiedlichen Planungshorizont haben. Dadurch kann die Recheneffizienz verbessert werden, indem jede Planungskomponente mit Planungsinformationen versorgt wird, die gerade detailliert genug sind, um die erforderliche Aufgabe für den jeweiligen Planungshorizont zu erfüllen. Bei mindestens einer Ausführungsform weisen die drei verschiedenen Planungskomponenten einen Routenplaner, einen Fahrbahnplaner und einen Verhaltensplaner auf. Jede Komponente kann ein Ergebnis und/oder eine Ergebnismenge erzeugen und an die nächste Komponente in der Planungspipeline weitergeben. Der Routenplaner kann einen Routensatz an den Fahrbahnplaner übermitteln und der Fahrbahnplaner kann einen Fahrbahnplan an den Verhaltensplaner übermitteln. Der Verhaltensplaner kann mehrere Trajektorien entwickeln und bewerten. Der Fahrbahnplan kann die Form eines Fahrbahngraphen mit Zeitbelohnungen bzw. Zeitgewinnen haben, die den Knoten des Graphen zugeordnet sind. Diese Art von Fahrbahnplan kann sich von herkömmlichen Fahrbahnplänen unterscheiden, die eine oder mehrere Fahrbahnfolgen umfassen. Eine ausgewählte oder optimierte Trajektorie kann von dem Verhaltensplaner an eine Bewegungssteuerung gesendet werden, die für die Umsetzung der geplanten Trajektorie verantwortlich ist.
Der Routenplaner kann über geografische Informationen verfügen, die einen großen geografischen Bereich abdecken (z. B. ein Stadtgebiet, ein Bundesland, ein Land, eine Region), jedoch mit einem relativ geringen Detaillierungsgrad (z. B. weniger detailliert als die geografischen Informationen, die für die Fahrbahnplanung und die Trajektorienplanung verwendet werden). Der Planungshorizont des Routenplaners kann das gesamte Gebiet zwischen einem Startpunkt (z. B. dem aktuellen Standort) und einem Zielpunkt sein. Der Routenplaner kann Karten mit geringer Detailtiefe eines vergleichsweise großen Gebiets verwenden, um mehrere Routen zu einem Ziel zu berechnen. Das große geografische Gebiet kann beispielsweise mehr als 50 Quadratmeilen, mehr als 500 Quadratmeilen, mehr als 1000 Quadratmeilen oder noch größer sein. In einem Aspekt wird eine einzelne Route nicht von vornherein als optimal ausgewählt, sondern jede Route kann nach einer geschätzten Fahrzeit zum Zielort oder nach einem anderen Bewertungsmechanismus bewertet werden, der eine optimale oder bevorzugte Route quantifiziert. Da eine nahezu unendliche Anzahl von Routen möglich ist, können verschiedene Verfahren verwendet werden, um die besten Routen zu ermitteln. So können beispielsweise die fünf, zehn, fünfzig und/oder eine andere Anzahl der besten Routen, gemessen an der geschätzten Fahrzeit und/oder anderen Faktoren, ermittelt werden. Diese Routen können an den Fahrbahnplaner übermittelt werden, und der Fahrbahnplaner kann - zusätzlich zu anderen Komponenten wie dem Verhaltensplaner - eine bevorzugte Route aus der Vielzahl der Routen bestimmen.
Der Fahrbahnplaner kann einen Fahrbahnplan auf der Grundlage einer oder mehrerer von dem Routenplaner empfangenen Routen erstellen. Der Fahrbahnplaner kann eine zweite geografische Karte verwenden, die mehr Details aufweist als die von dem Routenplaner verwendete Karte. Die zweite geografische Karte kann ein kleineres geografisches Gebiet abdecken als die von dem Routenplaner verwendete Karte. Beispielsweise kann das kleinere geografische Gebiet weniger als 50 Quadratmeilen groß sein. Bei einigen Ausführungsformen kann der Fahrbahnplan die Form eines kommentierten Fahrbahngraphen annehmen, der einen Planungshorizont von mehreren Meilen haben kann. Ein Fahrbahngraph kann im Allgemeinen die für das autonome Fahrzeug verfügbaren Fahrbahnen auf einer Route (z. B. einer Straße) anzeigen. Die Anmerkungen auf dem Fahrbahngraph können eine zeitliche Bewertung für verschiedene Positionen oder Punkte auf dem Fahrbahngraph angeben. Beispielsweise kann eine zeitliche Bewertung alle 10 Meter, 20 Meter oder in einem anderen Intervall angegeben werden. Die zeitliche Bewertung kann den Gesamtwert dafür angeben, dass das autonome Fahrzeug einen bestimmten Punkt auf dem Fahrbahngraphen erreicht.
Die Verhaltensplanungskomponente kann diese Werte dann bei der Bewertung verschiedener Trajektorien berücksichtigen. In einigen Situationen kann beispielsweise eine Fahrbahn genauso gut funktionieren wie jede andere verfügbare Fahrbahn. So kann ein autonomes Fahrzeug, das auf einer Interstate-Autobahn 20 Meilen von einer auf der Route angegebenen Ausfahrt entfernt unterwegs ist, eine von zwei Fahrbahnen benutzen, ohne dass sich die Fahrzeit nennenswert ändert. Unter diesen Umständen kann die zeitliche Bewertung für jede Fahrbahn sehr ähnlich oder sogar identisch sein. Wenn sich das autonome Fahrzeug jedoch der Ausfahrt nähert, zeigt die zeitliche Bewertung auf der Ausfahrtsfahrbahn zunehmend eine Präferenz für die Ausfahrtsfahrbahn gegenüber der zeitlichen Bewertung auf der Nicht-Ausfahrtsfahrbahn an. An der Ausfahrt kann die Differenz zwischen den zeitlichen Bewertungen auf der Ausfahrtsfahrbahn und der anderen Fahrbahn einem Zeitverlust entsprechen, der durch das Verpassen der Ausfahrt entsteht. Wenn also das Verpassen der Ausfahrt zu einer fünfminütigen Verlängerung der Fahrzeit zum Ziel führt, kann der Unterschied der zeitlichen Bewertungen diese fünf Minuten Verlängerung widerspiegeln.
Die Verhaltensplanungskomponente kann diese unterschiedlichen zeitlichen Bewertungen bei der Planung einer Trajektorie berücksichtigen. Der Verhaltensplaner kann einen kleineren Planungshorizont haben als der Routenplaner oder der Fahrbahnplaner. Im Allgemeinen kann der Verhaltensplaner die Bewegung eines Fahrzeugs für die nächste halbe Sekunde, Sekunde, zwei Sekunden, drei Sekunden, vier Sekunden, fünf Sekunden, zehn Sekunden, zwanzig Sekunden usw. und/oder auf der Grundlage eines Entfernungsmaßes, wie z. B. die nächsten 5 m, 10 m, 50 m, 100 m, 200 m, 300 m usw., planen Die zurückgelegte Strecke hängt von der Fahrgeschwindigkeit des Fahrzeugs ab. Der Verhaltensplaner kann eine Karte verwenden, die einen hohen Detaillierungsgrad für einen kleinen Bereich aufweist. Der kleine Bereich kann z. B. kleiner sein als der Bereich in einer Karte, die vom Fahrbahnplaner oder Routenplaner verwendet wird. Die vom Verhaltensplaner verwendete Karte kann zum Beispiel weniger als hundert Quadratmeter umfassen. Der höhere Detaillierungsgrad kann Objekte (z. B. andere Fahrzeuge, Fußgänger) aufweisen, die von den mit dem autonomen Fahrzeug verbundenen Sensoren erfasst werden. In einem Aspekt können zumindest einige dieser Objekte nicht in den Informationen enthalten sein, die dem Fahrbahnplaner zur Verfügung stehen. Die tatsächlich gewählte Trajektorie kann die Bewegung des autonomen Fahrzeugs nur für eine kurze Zeitspanne, z. B. eine Sekunde, oder eine kurze Strecke, z. B. fünf Meter, bestimmen. Neue Trajektorien können ständig evaluiert und angewendet werden, um sich an veränderte Bedingungen (z. B. fahrende Fahrzeuge, sich bewegende Fußgänger, Wartebedingungen usw.) in der Umgebung des autonomen Fahrzeugs anzupassen.
Der Verhaltensplaner kann anfangs eine oder mehrere erstrebenswerte Aktionen für das autonome Fahrzeug auswählen, die es ausführen soll. Die Aktionen können auf der Grundlage des vom Fahrbahnplaner bereitgestellten kommentierten Fahrbahngraphen erfolgen. Die ausgewählte(n) Aktion(en) kann(können) darauf basieren, ein sicheres, effizientes oder bestes Ergebnis zu erzielen, das durch die im kommentierten Fahrbahngraphen enthaltenen zeitlichen Bewertungen angezeigt wird. Mögliche Aktionen weisen unter anderem die folgenden auf: Folgen der Fahrbahn, Anpassen der Geschwindigkeit beim Fahrbahnwechsel, Überholen, zweifacher Fahrbahnwechsel und Drängeln beim Fahrbahnwechsel. Der Verhaltensplaner kann eine Vielzahl möglicher oder hypothetischer Trajektorien generieren, die die angestrebte(n) Aktion(en) erzielen. Verschiedene Komponenten innerhalb des Verhaltensplaners können die hypothetischen Trajektorien bewerten und/oder möglicherweise Trajektorien eliminieren. Wenn zum Beispiel eine Komponente zur Kollisionsvermeidung feststellt, dass eine hypothetische Trajektorie zu einer Kollision führen würde oder könnte, kann die hypothetische Trajektorie von der weiteren Betrachtung ausgeschlossen werden. Im Gegensatz dazu kann ein Komfortmodul jeder Trajektorie eine Bewertung zuweisen, die darauf basiert, dass sie einem Insassen, der in dem autonomen Fahrzeug mitfährt, eine komfortable Fahrt bietet. Andere Module oder Komponenten können auf ähnliche Weise Bewertungen erzeugen und zuweisen, so dass die ausgewählte oder bevorzugte Trajektorie aus einer Vielzahl von Trajektorien mit der höchsten oder besten Bewertung ausgewählt wird.
Infolgedessen kann das hier beschriebene Verfahren die gegenwärtigen Verfahren verbessern, indem es einen iterativen Ansatz zur Identifizierung einer optimalen Trajektorie verwendet. In einer ersten Iteration kann die anfängliche Vielzahl hypothetischer Trajektorien bewertet werden, wobei die Trajektorie mit der höchsten Optimierungsbewertung als Ausgangspunkt bzw. Ausgang für die Erzeugung weiterer hypothetischer Trajektorien zur Bewertung dient. In einer zweiten Iteration kann die zweite Vielzahl hypothetischer Trajektorien durch geringfügige Änderung verschiedener Parameter der Ausgangstrajektorie erzeugt werden. Die zweite Vielzahl hypothetischer Trajektorien kann dann ausgewertet werden, um festzustellen, ob eine dieser Trajektorien einen höheren Optimierungswert aufweist als die Ausgangstrajektorie. Die hypothetische Trajektorie mit dem besten Optimierungsergebnis kann für die Anwendung ausgewählt werden.
1 zeigt ein Beispiel einer Verhaltensplanungsarchitektur 100 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es ist klar, dass diese und andere Anordnungen, wie es hier beschrieben ist, nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu den gezeigten oder anstelle von ihnen verwendet werden, und einige Elemente können ganz weggelassen werden. Darüber hinaus handelt es sich bei vielen der hier beschriebenen Elemente um funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert sein können. Verschiedene Funktionen, wie es hier beschrieben ist, können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
Die Verhaltensplanungsarchitektur 100 kann verschiedene Planungskomponenten verwenden (z. B. drei Planungskomponenten), die jeweils einen unterschiedlichen Planungshorizont haben. In einer Ausführungsform weisen die verschiedenen Planungskomponenten einen Routenplaner 110, einen Fahrbahnplaner 120 und einen Verhaltensplaner 140 auf. Jede Komponente kann ein Ergebnis und/oder eine Ergebnismenge erzeugen und es/sie an die nächste Komponente in der Planungspipeline übermitteln. Der Routenplaner 110 kann einen Routensatz an den Fahrbahnplaner 120 übermitteln, und der Fahrbahnplaner 120 kann einen Fahrbahnplan an den Verhaltensplaner 140 übermitteln. Der Verhaltensplaner 140 kann mehrere Trajektorien entwickeln und bewerten, und eine ausgewählte oder bevorzugte Trajektorie kann vom Verhaltensplaner an eine Bewegungssteuerung 180 gesendet werden, die für die Umsetzung der geplanten Trajektorie verantwortlich ist.
In Ausführungsformen kann der Routenplaner 110 geografische Informationen 112 verwenden, die ein geografisches Gebiet (z. B. eine Stadt, einen Ballungsraum, ein Bundesland, ein Land, eine Region usw.) jedoch mit einem relativ geringen Detailgrad abdecken. Der Planungshorizont des Routenplaners kann das gesamte Gebiet zwischen einem Startpunkt (z. B. dem aktuellen Standort) und einem Zielpunkt (z. B. dem endgültigen Standort) sein. Das Verfahren kann Karten mit geringerem Detailgrad (z. B. eine GNSS-basierte Karte im Vergleich zu einer hochauflösenden HD-Karte) eines vergleichsweisen großen Gebiets verwenden, um mehrere Routen zu einem Ziel zu berechnen. Der Routenplaner 110 kann Karten mit geringer Detailtiefe eines vergleichsweisen großen Gebiets verwenden, um mehrere Routen zu einem Ziel zu berechnen. Das große geografische Gebiet kann beispielsweise mehr als 50 Quadratmeilen, mehr als 500 Quadratmeilen, mehr als 1000 Quadratmeilen oder größer sein. Dies ist jedoch nicht als Einschränkung zu verstehen, und bei einigen Ausführungsformen kann eine Karte mit beliebigem Detailgrad verwendet werden. In einem Aspekt wird eine einzelne Route nicht von vornherein als optimal oder bevorzugt ausgewählt, sondern jede Route aus einer Vielzahl von Routen kann nach einer geschätzten Fahrzeit zum Zielort der Route oder nach einem anderen Bewertungsmechanismus bewertet werden, der eine bevorzugte Route quantifiziert. Da eine nahezu unendliche Anzahl von Routen möglich ist, können verschiedene Verfahren angewandt werden, um eine gewisse Anzahl potenzieller Routen aus einer Vielzahl von Routen zu ermitteln. Zum Beispiel können die zehn besten Routen, gemessen an der geschätzten Fahrzeit und/oder anderen Faktoren, ermittelt werden. Diese Routen können an den Fahrbahnplaner 120 weitergeleitet werden, so dass dem Fahrbahnplaner 120 mehrere Routen zur Verfügung stehen.
In einer oder mehreren Ausführungsformen kann dem Routenplaner 110 ein Fahrauftrag 116 zugewiesen oder erteilt werden. Der Fahrauftrag 116 kann als eine Abfolge von einem oder mehreren Wegpunkten ausgedrückt werden, die als GPS-Punkte und/oder Positionen im großen Fahrbahngraphen 130 kodiert sein können (z. B. genau an dieser Bushaltestelle zum Absetzen oder Abholen anhalten). Der Fahrauftrag 116 kann auch mit einem Parkbereich enden (Aufforderung zum Parken in einem bestimmten Parkbereich). Gemäß einer oder mehreren Ausführungsformen ist ein Parkbereich eine Teilmenge des großen Fahrbahngraphen 130, die typischerweise Schleifenstrukturen um einen Parkplatz und optional Kartenwissen über die Parkplätze selbst enthält.
Der Routenplaner 110 kann als modular von den anderen Planungsschritten trennbar aufgebaut sein. Der architektonische Aufbau kann Langstreckenrouten effizient unterstützen. Der Routenplaner 110 kann den resultierenden Routenplan sowie einige grundlegende Zustandsinformationen an den Fahrbahnplaner 120 weitergeben. Der Routenplan kann eine oder mehrere GPS-Spuren aufweisen, die als potenzielle ungefähre Routen ermittelt wurden, um von der aktuellen Position zu den Wegpunkten oder Parkbereichen zu gelangen. Die GPS-Punkte im Routenplan können auch mit erwarteten Zeitgewinnen versehen sein (oder, falls gewünscht, können die Zeitgewinne als erwartete Restzeit bis zum Ziel dargestellt werden). Die Routenplanung kann unter Verwendung einer Kontraktionshierarchie 118 erfolgen, die es ermöglicht, innerhalb von Millisekunden die kürzesten Routen zu ermitteln, selbst für Routen über einen ganzen Kontinent. Die GPS-Spur des Routenplans kann dem Fahrbahnplaner 120 eine ungefähre Orientierung geben, anstatt auf einer bestimmten Fahrbahn oder Straße zu beharren. Der Routenplaner 110 kann mehrere Routen oder Routenvarianten bereitstellen, die innerhalb eines Schwellenwerts für die Fahrzeit liegen, und bei anderen Ausführungen kann jede Route einer geschätzten Fahrzeit zugeordent sein. In einer Ausführungsform wird den Routensegmenten jeweils eine Fahrzeit zugewiesen, die dem Fahrbahnplaner 120 und anderen Komponenten Informationen liefert, die zur Berechnung der Kosten verwendet werden können, die entstehen, wenn eine Ausfahrt verpasst wird und man auf eine alternative Route ausweichen muss. Bei anderen Ausführungsformen kann die Fahrzeit auch von anderen Komponenten, wie dem Fahrbahnplaner 120, berechnet werden, und die Fahrzeit kann anhand von Entfernungen und Geschwindigkeitsbegrenzungen berechnet werden, aber auch mit Echtzeit-Verkehrsdaten, Baudaten, Wetterdaten und/oder Ähnlichem verfeinert werden.
Der Routenplaner 110 kann auch eine Zustandsverwaltungskomponente 114 aufweisen, um eine grundlegende Zustandsverwaltung durchzuführen. Zum Beispiel kann die Zustandsverwaltungskomponente 114 bestätigen, dass beim Kaltstart die Sensoren und Berechnungen in Betrieb sind und dass die Lokalisierung ihre Position findet, bevor sich das autonome Fahrzeug in Bewegung setzt (z. B. bevor das Missionssteuerungssystem beginnt, das autonome Fahrzeug zu navigieren). Bis dahin kann sich der Routenplaner 110 in einem START-Zustand befinden. Danach, wenn das autonome Fahrzeug (oder sein Verhaltensplaner 140) auf einem bekannten Fahrbahngraphen fährt, kann der Routenplaner 110 in den FAHR-Zustand wechseln. Der Routenplaner 110 kann auch in den PARK-Zustand wechseln, wenn er in der Fahrmission einen Parkbereich erreicht. Es gibt auch spezielle SUMMON- und LIMP-Zustände (Vorwarnung). Limping tritt auf, wenn etwas Unerwartetes eintritt und das autonome Fahrzeug bis zum Stillstand verlangsamt wird oder sich vorsichtig fortbewegt; ein LIMP-Zustand kann beispielsweise auftreten, wenn die Lokalisierung feststellt, dass sich das autonome Fahrzeug außerhalb der Karte befindet oder nicht lokalisieren kann.
Der Fahrbahnplaner 120 kann einen Fahrbahnplan auf der Grundlage der einen oder mehreren vom Routenplaner empfangenen Routen erstellen. Der Fahrbahnplaner 120 kann eine zweite geografische Karte verwenden, die mehr Details aufweist als die vom Routenplaner verwendete Karte. Die zweite geografische Karte kann einen kleineren geografischen Bereich abdecken als die vom Routenplaner verwendete Karte. Das kleinere geografische Gebiet kann zum Beispiel weniger als 50 Quadratmeilen umfassen. Der Fahrbahnplan kann die Form eines kommentierten Fahrbahngraphen bzw. mit Anmerkungen versehene Fahrbahngraphen aufweisen, und der kommentierte Fahrbahngraph kann einen Planungshorizont von mehreren Meilen aufweisen. Ein Fahrbahngraph kann Fahrbahnen darstellen, die für das autonome Fahrzeug auf einer Route (z. B. einer Straße) verfügbar sind. Die Anmerkungen auf dem Fahrbahngraph können eine zeitliche Bewertung für verschiedene Positionen auf dem Fahrbahngraph angeben. Beispielsweise kann eine zeitliche Bewertung alle 10 Meter, 20 Meter oder in einem anderen Intervall auf dem Fahrbahngraph angegeben werden. Die zeitlichen Bewertungen können als aufeinanderfolgende Zeitgewinne für potenzielle zukünftige Positionen beschrieben werden. Der größere oder bessere Gewinn kann mit dem schnelleren Weg zum Routenziel verbunden sein, oder bei anderen Ausführungen kann eine niedrigere Bewertung einen besseren oder schnelleren Weg anzeigen. Die Skala des Gewinns kann eine Zeiteinheit sein, z. B. Sekunden.
Die zeitlichen Bewertungen geben den Gesamtwert an, um das autonome Fahrzeug zu einem bestimmten Punkt auf dem Fahrbahngraphen zu bringen. Der Verhaltensplaner 140 kann diese Bewertungen dann bei der Bewertung verschiedener Trajektorien in Betracht ziehen. In einigen Situationen kann beispielsweise eine Fahrbahn genauso gut sein wie jede andere verfügbare Fahrbahn. So kann ein autonomes Fahrzeug, das auf einer Interstate-Autobahn fährt, und 20 Meilen von einer auf der Route angegebenen Ausfahrt entfernt ist, eine von zwei Fahrbahnen benutzen, ohne dass sich die Fahrzeit nennenswert ändert. Unter diesen Umständen kann die zeitliche Bewertung für jede Fahrbahn sehr ähnlich oder sogar identisch sein. Wenn sich das autonome Fahrzeug jedoch der Ausfahrt nähert, zeigt die zeitliche Bewertung auf der Ausfahrtsfahrbahn zunehmend eine Präferenz für die Ausfahrtsfahrbahn gegenüber der zeitlichen Bewertung auf der Nicht-Ausfahrtsfahrbahn an. An der Ausfahrt kann die Differenz zwischen den zeitlichen Bewertungen auf der Ausfahrtsfahrbahn und der anderen Fahrbahn einem Zeitverlust entsprechen, der durch das Verpassen der Ausfahrt entsteht. Wenn also das Verpassen der Ausfahrt eine fünfminütige Verlängerung der Fahrzeit zum Zielort zur Folge hat, kann der Unterschied in den zeitlichen Bewertungen diese fünfminütige Verlängerung widerspiegeln.
Der Fahrbahnplaner 120 kann einen Fahrbahnverlaufsvorhersager 122 und einen Parkfahrbahnplaner 126 umfassen. Der Fahrbahnplaner 120 kann den Routenplan und grundlegende Zustandsinformationen vom Routenplaner 110 erhalten. Der Zweck der Fahrbahnplanung kann darin bestehen, Informationen darüber zu liefern, wie wertvoll es ist, sich mit dem autonomen Fahrzeug in der Nähe der verschiedenen Fahrbahnen aufzuhalten. Wenn sich das autonome Fahrzeug beispielsweise einer Stelle nähert, an der sich eine Fahrbahn von den anderen trennt und abzweigt, kann der Fahrbahnplaner Informationen darüber liefern, wie viel mehr Zeit verloren gehen kann, wenn diese Ausfahrt verpasst wird. Die Ausgabe des Fahrbahnplaners 120 kann als erwartete Zeitgewinne dargestellt werden, die im großen Fahrbahngraphen 130 kodiert sind, der dem lokalen Fahrbahngraphen 132 zugeordnet ist. Diese Kodierung kann mehr Flexibilität bieten als eine direkte Reihenfolge oder eine Empfehlung für die richtige Fahrbahn, da sie es dem Verhaltensplaner 140 ermöglicht, den Wert einer bestimmten Fahrbahn gegen die Schwierigkeit des Manövers abzuwägen, um dorthin zu gelangen.
Der Fahrbahnplaner 120 arbeitet mit dem großen Fahrbahngraphen 130, der einer leichtgewichtigen Darstellung der Fahrbahnpositionen und der erwarteten Zeiten für den Übergang zwischen ihnen entsprechen kann. Der Fahrbahnplaner 120 kann die vom Routenplaner 110 gelieferte GPS-Spur als Führung verwenden, um einen Korridor (z. B. von einigen hundert Metern Breite) aus dem großen Fahrbahngraph 130 um die vorgeschlagene Route herum auszuschneiden. Der Fahrbahnplaner 120 kann dann einen Bereich anvisieren, der in einiger Entfernung (z. B. einige Meilen) entlang der vorgeschlagenen Route liegt, und ihn als temporäres Ersatzziel verwenden. Das Ersatzziel kann einen erwarteten Zeitgewinn aus dem Routenplan aufweisen, der nun an alle Knoten im großen Fahrbahngraphen 130 innerhalb des Korridors weitergegeben werden kann. Der Fahrbahnplaner 120 berücksichtigt Fahrbahnwechsel und die Wahrscheinlichkeit, dass sie nicht sofort oder gar nicht gelingen. Dies bedeutet, dass die erwarteten Zeitgewinne eine probabilistische Berechnung erfordern können. Beispielsweise kann jeder Knoten mit einer Reihe von Aktionen verbunden sein (z. B. Fahbahn halten, Abzweigen, Fahrbahnwechsel), und die Aktionen führen probabilistisch zu einer neuen Fahrbahnposition (z. B. einer anderen Fahrbahn bei erfolgreichem Fahrbahnwechsel und weiter auf derselben Fahrbahn, wenn der Wechsel fehlschlägt).
Bei einigen Ausführungsformen kann diese Wahrscheinlichkeit als Markov-Entscheidungsprozess (MDP) ausgedrückt werden, der ausgehend von vorgegebenen festen Werten am Ersatzziel für den Wert des Aufenthalts an einem beliebigen Knoten gelöst wird. Der MDP behandelt Dinge wie die Schätzung der zunehmenden Dringlichkeit, einen Fahrbahnwechsel rechtzeitig vorzunehmen, wenn sich das autonome Fahrzeug einer Aufteilung der Straße nähert, oder die Durchführbarkeit, auf eine andere Fahrbahn zu wechseln und später auf eine bevorzugte Fahrbahn zurückzukehren.
Es gibt viele Algorithmen zur Schätzung der Werte der Zustände (in diesem Fall der Knoten im großen Fahrbahngraphen) in einem MDP, zum Beispiel die klassische Wertiteration. Um effizient zu sein, kann eine Heuristik verwendet werden, um alle Zyklen im großen Fahrbahngraphen zu entfernen, was die Wertiteration auf einen einzigen Durchgang einer dynamischen Programmierung reduziert. Die Heuristik kann verwendet werden, wenn es einen Zyklus gibt, um die Kante zu entfernen, die am weitesten von dem autonomen Fahrzeug auf dem Zyklus entfernt ist. Diese Heuristik vermeidet das Entfernen einer Kante, die Teil des kürzesten Weges zwischen dem autonomen Fahrzeug und dem Ziel ist, aber zu einem Zyklus gehört. Bei der Unterbrechung von Zyklen darf jedoch die Wahrscheinlichkeitsanpassung nicht ignoriert werden, die durch unnötige Zyklen auf dem Weg zum Ziel entsteht. Wenn das autonome Fahrzeug beispielsweise einen Fahrbahnwechsel verpasst und eine Kleeblatt-artige Kreuzung umfahren muss, um genau denselben Fahrbahnwechsel erneut zu versuchen, kann dies zu einem unnötigen Zyklus führen. Durch die Unterbrechung von Zyklen wird diese Möglichkeit beseitigt, aber dies kann eine akzeptable Annäherung sein, da es unerwünscht sein kann, unnötige Zyklen zu verwenden. Der Graph kann gerichtet sein, und es können mehrere Pfade zum selben Ziel in Betracht gezogen werden. Auch reflexive Kanten, die auf denselben Knoten zurückführen, wie z. B. beim Warten auf einen Fahrbahnwechsel, können korrekt behandelt werden (ein Knoten, der außer einer reflexiven Kante keine weiteren Abhängigkeiten aufweist, kann als erledigt gelten).
Zunächst kann der Dijkstra-Algorithmus - und/oder ein anderer Algorithmus für den kürzesten Weg - ausgeführt werden, um die Entfernung und den kürzesten Weg zu allen Knoten unter Verwendung beliebiger Aktionen zu ermitteln. Dann werden die Gewinne der Knoten verrechnet oder Kanten von Zyklen iterativ mit einer einzigen Graphendurchquerung entfernt. Dijkstra wird dann über den großen Fahrbahngraphen ausgeführt, um die kürzesten optimistischen Pfade zu finden (unter der Annahme, dass Fahrbahnwechsel erfolgreich sind, wo sie möglich sind). Daraus ergibt sich eine Ordnung der Knoten im Bereich der Fahrbahnplanung nach der optimistischen Zeit, um sie zu erreichen. Auch die Kanten können geordnet werden, z. B. nach der Zeit, um zum Ende der entsprechenden Kanten zu gelangen, so dass die Kanten genauso geordnet sein können wie die Knoten, auf die sie zeigen.
Rückwärtskanten bzw. rückwärtsgerichtete Kanten werden verwendet, um für jeden Knoten zu verfolgen, von welchen Knoten er abhängt, um seine erwartete Zeit zu erreichen (alle Knoten, auf die er für seine Aktionen und fehlgeschlagenen Aktionen zeigt). In ähnlicher Weise können Kanten, die auf nicht erledigte bzw. abgearbeitete Knoten zeigen, verfolgt werden. Alle Knoten, die keine Abhängigkeiten haben, können gefunden und abgearbeitet werden. Wenn die Knoten erledigt sind, können Rückwärtskanten verwendet werden, um die Anzahl der Abhängigkeiten anderer Knoten zu verringern. Wenn diese Aktualisierungen neue Knoten mit keinen Abhängigkeiten finden, können die neuen Knoten ebenfalls in die Warteschlange aufgenommen werden. Außerdem können alle abgearbeiteten Knoten und Kanten, die auf abgearbeitete Knoten zeigen, aus den zuvor berechneten Knoten- und Kantenordnungen entfernt werden.
Wenn es keine Knoten mit keinen Abhängigkeiten gibt, kann die am weitesten entfernte nicht abgebildete Kante gemäß den Ergebnissen des Dijkstra-Algorithmus (und/oder eines anderen Algorithmus vom Typ kürzester Weg) entfernt werden. Die Abhängigkeiten zwischen den Knoten können dann aktualisiert werden. Bei einigen Ausführungsformen können ein oder mehrere Knoten mit keinen Abhängigkeiten entstehen, was bedeutet, dass es keine Verbindung zu anderen Knoten gibt. Dies stellt eine Sackgasse dar, und die mit diesen Knoten verbundenen Zeiten können als eine Zeit abgearbeitet bzw. abgerechnet werden, die dem Scheitern der Mission entspricht. Das Verfahren stoppt, wenn alle Knoten abgearbeitet sind. Die Komplexität dieses Algorithmus entspricht im Wesentlichen der Komplexität des Dijkstra-Algorithmus plus einer einzigen Graphendurchquerung.
Der Fahrbahnplaner 120 verwendet den aus den Kartendaten abgeleiteten großen Fahrbahngraphen 130, der auch mit dem lokalen Fahrbahngraphen 132 der Fahrbahnen verknüpft ist. In einer oder mehreren Ausführungsformen kann der Fahrbahnplaner 120 Werte für den gesamten großen Fahrbahngraphen 130 ableiten. Der Verhaltensplaner 140 kann jedoch (nur oder hauptsächlich) die Werte für Entscheidungen in der Nähe des autonomen Fahrzeugs auf dem lokalen Fahrbahngraph 132 verwenden. Der Fahrbahnverlaufsvorhersager 122 kann eine Schätzung des Fahrbahn-Fortschritts auf der Grundlage von Live-Wahrnehmungen erstellen, z. B. einer Fahrbahngeschwindigkeit, eines Staus und einer Geschwindigkeit der nächsten Fahrzeuge auf den verschiedenen Fahrbahnen. Die Verlaufsvorhersage wird verwendet, um die erwarteten allgemeinen Durchfahrtzeiten zu ändern. Anhand der erwarteten Durchfahrtzeiten kann der Fahrbahnplaner entscheiden, ob ein Fahrbahnwechsel auf eine derzeit schnellere Fahrbahn sinnvoll ist.
Der Fahrbahnplaner 120 kann seine Funktion ändern, wenn der Routenplaner 110 den Zustand ändert (z. B., als nicht einschränkende Beispiele, in PARKEN, SUMMON, oder LIMP). Beim Parken kann der Fahrbahnplaner 120 den Parkfahrbahnplaner 126 verwenden, um einen Fahrbahnplan zu erstellen. Der Parkfahrbahnplaner 126 kann die großen Zyklen des Fahrbahngraphen des Parkplatzes nutzen, um den Verhaltensplaner 140 zu veranlassen, die Teile des Parkplatzes zu erkunden, die zuletzt am wenigsten erkundet wurden. Das Parken kann eine beliebige Anzahl von Phasen aufweisen. Nicht einschränkende Beispiele für Phasen weisen das Herumfahren auf dem Parkplatz und das Einparken in eine Parklücke auf. Ein Parkplatzsuchen funktioniert ähnlich wie das Umfahren des Fahrbahngraphen in einem städtischen Gebiet, mit dem Unterschied, dass der Zweck darin besteht, in Zyklen herumzufahren, bis ein Parkplatz gefunden wird. Der Fahrbahnplaner kann dies erreichen, indem er die Werte so einstellt, dass ein gutes Fahrmuster um die Schleifen herum erzielt wird. Sobald die Sichtverbindung zu einem freien Platz hergestellt ist, wird das Einparkmanöver vom Verhaltensplaner 140 eingeleitet.
In ähnlicher Weise kann auch das Summon bzw. Herbeirufen eine beliebige Anzahl von Phasen aufweisen. Sobald sich das autonome Fahrzeug auf einer bekannten Fahrbahn befindet, kann der Fahrplan zum Zielort ausgeführt werden, wie im normalen FAHR-Zustand. Befindet sich das autonome Fahrzeug jedoch noch nicht auf dem bekannten Fahrbahngraphen, z. B. auf einem Parkplatz, der etwas abseits der kartierten Pfade liegt, oder wenn es keinen Standardweg gibt, um auf die kartierten Pfade zu gelangen, dann kann der Parkfahrbahnplaner 126 verwendet werden, um einen Weg zu einer der nächstgelegenen Positionen auf dem Fahrbahngraphen zu finden, von dem aus das autonome Fahrzeug startet. Wenn es überhaupt keine Karte gibt, sondern nur eine ungefähre Richtung zum Herbeirufenden, dann wird diese ungefähre Richtung einfach an den Verhaltensplaner 140 weitergegeben. Der LIMP-Modus kann in ähnlicher Weise funktionieren, wenn keine oder nur unzureichend detaillierte Karteninformationen verfügbar sind.
Der Verhaltensplaner 140 kann eine oder mehrere Aktionen in Betracht ziehen und eine oder mehrere Iterationen der Hypothesen-Generierung und Bewertung einer detaillierteren Anmeldung dieser Aktionen durchlaufen. Die detailliertere Anwendung kann als präziser Bewegungsplan ausgedrückt werden (eine Pose-Trajektorie über die Zeit für einige Sekunden in die Zukunft) und wird vom Bewegungsplaner 172 bewertet. Der Verhaltensplaner 140 umfasst einen Aktionsgenerator 142, eine Längsvorbegrenzungskomponente 150, eine Hypothesengenerierung 160 und einen Aktionsplanselektor 170.
Der Verhaltensplaner 140 kann einen kleineren Planungshorizont haben als der Routenplaner oder der Fahrbahnplaner. Im Allgemeinen kann der Verhaltensplaner 140 die Bewegung eines Fahrzeugs für die nächsten paar Sekunden planen. Die zurückgelegte Strecke hängt von der Fahrgeschwindigkeit des Fahrzeugs ab. So kann der Verhaltensplaner beispielsweise einen Planungshorizont von 50 m, 100 m, 200 m, 300 m o. ä. haben. Der Verhaltensplaner 140 kann eine Karte verwenden, die einen hohen Detaillierungsgrad für ein kleines Gebiet aufweist. Der kleine Bereich kann z. B. kleiner sein als der Bereich in einer Karte, die vom Fahrbahnplaner 120 oder Routenplaner 110 verwendet wird. Die vom Verhaltensplaner verwendete Karte kann zum Beispiel weniger als hundert Quadratmeter umfassen. Der höhere Detaillierungsgrad kann Objekte (z. B. andere Fahrzeuge, Fußgänger) aufweisen, die von den dem autonomen Fahrzeug zugeordneten Sensoren erfasst werden. In einem Aspekt können zumindest einige dieser Objekte nicht in den Informationen enthalten sein, die dem Fahrbahnplaner 120 zur Verfügung stehen. Die tatsächlich gewählte Trajektorie kann die Bewegung des autonomen Fahrzeugs nur für eine kurze Zeitspanne, z. B. eine Sekunde, steuern. Neue Trajektorien können ständig evaluiert und angewendet werden, um sich an veränderte Bedingungen (z. B. fahrende Fahrzeuge, sich bewegende Fußgänger) in der Umgebung des autonomen Fahrzeugs anzupassen.
Der Berechnungsablauf für jede vom Verhaltensplaner 140 bewertete Aktion kann durch den Aktionsgenerator 142 eingeleitet werden. Der Aktionsgenerator 142 kann zunächst eine oder mehrere angestrebte Aktionen für das autonome Fahrzeug auswählen, die es ausführen soll. Und die Aktionen können auf dem kommentierten Fahrbahngraphen basieren, der vom Fahrbahnplaner 120 bereitgestellt wird. Die ausgewählte(n) Aktion(en) kann(können) auf dem Erreichen des besten Ergebnisses basieren, das durch die in dem kommentierten Fahrbahngraphen enthaltenen Zeitgewinnen angezeigt wird. Mögliche Aktionen weisen unter anderem die folgenden auf: Fahrbahn folgen, Anpassen der Geschwindigkeit beim Fahrbahnwechseln, Überholen, Drängeln beim Fahrbahnwechseln, Anhalten am Randstreifen, Parkplatzsuchen (Park Prowl), Einparken (Park Endgame), Herbeirufen (Summon), und Langsamfahren (Limp). Wie bei den zuvor besprochenen Komponenten, kann der Aktionsgenerator 142 mehrere Aktionen auswählen oder bewerten. Bei einigen Ausführungsformen können die Aktionen in Form einer nominalen Bahn ausgedrückt werden und/oder jede Aktion kann mehreren nominalen Bahnen zugeordnet sein.
Eine oder mehrere der Aktionen können in der ersten Phase durch eine nominale seitliche Bahn oder Fahrbahn eingeleitet werden. Das Weltmodell 164 kann eine explizite Auflistung aller Fahrbahnen in einem aufgelösten Format bereitstellen, das beispielsweise alle Abzweigungen der Fahrbahn aufweist, in der sich das autonome Fahrzeug gerade befindet, sowie Fahrbahnen, in die das autonome Fahrzeug mit einem oder mehreren aufeinanderfolgenden Fahrbahnwechseln wechseln kann. Jede der Fahrbahnen, auf der sich das autonome Fahrzeug gerade befindet, stellt eine Fahrbahnfolgeaktion bereit. Jede der Fahrbahnen, in die das autonome Fahrzeug plausibel wechseln kann, stellt eine Fahrbahnwechsel-Aktion bereit. Ebenso kann das autonome Fahrzeug ein Überholmanöver in Erwägung ziehen, bei dem es die Ego-Fahrbahn verlässt und wieder auf diese fährt, während es sich kurzzeitig auf einer anderen Fahrbahn befindet, die sogar für den Gegenverkehr bestimmt sein kann. Das autonome Fahrzeug kann auch in Erwägung ziehen, auf einem Randstreifen anzuhalten, der im Weltmodell eine spezielle Fahrbahn ist. Das autonome Fahrzeug kann auch einen U-Turn in Betracht ziehen. Jede dieser Aktionen kann mit einer nominalen Bahn und sogar Fahrbahnkanten aus dem Weltmodell verbunden sein und ist oft auch mit Fahrbahnen in der Karte verknüpft, die Informationen über den Weg außerhalb des Live-Wahrnehmungsbereichs bereitstellen.
Im Fall des Parkens baut der Parkplatzsuchen-Zustand auf denselben Aktionsanwendungen auf wie das Fahrbahn-Halten durch die Anreize, die durch den Parkfahrbahnplaner 126 bereitgestellt werden. Während des Parkplatzsuchens überwacht der Verhaltensplaner das Vorhandensein eines freien Parkplatzes innerhalb der Sichtlinie. Dies kann durch Live-Wahrnehmung (z. B. mit Hilfe eines neuronalen Netzes, das Parkplätze erkennt) oder durch eine Kombination von kartierten Parkplätzen und Hinderniswahrnehmung oder beides redundant erfolgen. Dieses Vorgehen kann ein Zielviereck liefern, wenn ein freier Parkplatz erkannt wird - der sich geringfügig von einer nominalen Fahrbahn unterscheiden kann -, das vom Parkplaner 144 in einen Bewegungsplan umgewandelt werden kann. Der Parkplaner 144 kann eine Suche nach einer Trajektorie von Posen zwischen einer aktuellen Pose und der Zielpose durchführen, die frei von Hindernisbeeinflussungen ist. In einer oder mehreren Ausführungsformen kann ein Suchalgorithmus aus der A*/D*-Familie von Algorithmen für die Suche nach der Trajektorie der Posen verwendet werden. Der Suchalgorithmus kann verwendet werden, um zu entscheiden, ob der Raum tatsächlich kinematisch durchführbar ist, und wenn ja, eine oder mehrere Sequenzen von Posen bestimmen, um dorthin zu gelangen. In einer oder mehreren Ausführungsformen kann diese Suche mit der aktuellen Hindernisumgebung durchgeführt werden (z. B. zu einem bestimmten Zeitpunkt). Das bedeutet, dass Bewegungseffekte, wie z. B. ein Fahrradfahrer, der zwischen dem autonomen Fahrzeug und dem Raum an dem autonomen Fahrzeug vorbeifahren will, noch nicht vollständig berücksichtigt werden. Aus diesem Grund wird der Plan des Parkplaners 144 als nominale Bahn für den Rest des Verfahrens betrachtet, das diese Bewegungseffekte berücksichtigt, um sicherzustellen, dass die Aktionen des autonomen Fahrzeugs sicher sind (es ist zu beachten, dass sich andere Akteure natürlich schnell bewegen können, auch wenn das autonome Fahrzeug langsam fährt). Der Parkplaner 144 ist dennoch leistungsfähig, da er z. B. Dreipunktwendevorgänge entdecken kann, um in den Parkplatz zu gelangen, die sonst nicht gefunden werden würden.
Die Summon-Komponente 146 kann ähnlich wie der Parkplaner 144 funktionieren, allerdings in umgekehrter Weise. Der Parkplaner 144 wird verwendet, um einen Bewegungsplan zu finden, der das autonome Fahrzeug auf einen nahe gelegenen Teil des Fahrbahngraphen bringt. Sobald sich das autonome Fahrzeug auf dem Fahrbahngraphen befindet, fährt es wie gewohnt weiter, wobei Aktionen zum Fahrbahn-Halten eingesetzt werden, und folgt der Fahrbahn. Wenn es keine Karte gibt oder wenn sich das autonome Fahrzeug im LIMP-Modus befindet, hat das autonome Fahrzeug möglicherweise nur eine allgemeine Vorstellung davon, in welche Himmelsrichtung es fahren soll. In diesem Fall kann das autonome Fahrzeug einfach diese Himmelsrichtung verwenden, um eine nominale Bahn aufzubauen, an der sich der Rest des Verfahrens orientiert. Der Berechnungsablauf für jede der Aktionen verläuft dann ähnlich. Am Ende des Verfahrens, dem der Aktionsgenerator 142 folgt, kann jede Aktion einer nominalen Bahn und/oder Fahrbahnrändern und Fahrbahnen aus der Karte verknüpft werden.
Die Längsvorbegrenzungskomponente 150 kann nominale Bahnen empfangen, die den vom Aktionsgenerator 142 erzeugten Aktionen entsprechen. Jede dieser nominalen Bahnen kann von der Längsvorbegrenzungskomponente 150 ausgewertet werden. Die Längsvorbegrenzungskomponente 150 berücksichtigt grundlegende Längsbeschränkungen pro Fahrbahn (oder pro nominale Bahn). Unterschiedliche Beschränkungen können von verschiedenen Komponenten berücksichtigt werden. Die Komponenten der Längsvorbegrenzungskomponente 150 weisen eine Kurvengeschwindigkeitsanpassung 152, eine Geschwindigkeitsregulierung 154, ein Abstandhalten 156, ein Sicherheitsbremsen 158 und/oder einen Ausweichplaner 159 auf. Die Ausgabe der Längsvorbegrenzungskomponente 150 kann eine Beschleunigungsbeschränkung aufweisen, die die Geschwindigkeit für jede der eingegebenen nominalen Bahnen/Fahrbahnen begrenzt. So kann die Längsvorbegrenzungskomponente 150 eine Fahrbahn/Bahn mit einem Beschleunigungslimit, einer Geschwindigkeitsbeschränkung oder einer Abstandsbegrenzung versehen.
Die Kurvengeschwindigkeitsanpassung 152 kann durch Berücksichtigung der Zentripetalkräfte erfolgen, die in Zukunft auftreten können, wenn man der Kurve der gegebenen Fahrbahn/Bahn mit einer bestimmten Geschwindigkeit folgt. Dies geschieht derzeit auf der Fahrbahn der zugehörigen Karten, kann aber auch auf den Fahrbahnen der Live-Wahrnehmung erfolgen, wenn deren Krümmungen im Bereich ausreichend genau für diese Aufgabe sind. Das Ergebnis der Kurvengeschwindigkeitsanpassung 152 kann eine Beschleunigungsbeschränkung sein, die auf der Grundlage des zulässigen Bereichs der Zentripetalkräfte berechnet wird. Die Zentripetalkraftbeschränkungen können auf dem Insassenkomfort, der Sicherheit und/oder anderen Faktoren basieren.
Die Geschwindigkeitsregulierung 154 kann die standardmäßige Einhaltung von Geschwindigkeitsbegrenzungen bei der Benutzung dieser Fahrbahn anwenden. Das Abstandhalten 156 und das Sicherheitsbremsen 158 können einige Aufgaben der Längsregelung in Bezug auf Fahrzeuge und andere Konkurrenten bei großen Abständen und hoher Geschwindigkeit übernehmen. Die Komponente Abstandhalten 156 kann eine Beschleunigungsvorgabe erzeugen, die einen Abstand zwischen einem anderen sich bewegenden Objekt und dem autonomen Fahrzeug erzwingt. Die Komponente Sicherheitsbremsen 158 kann ähnliche Beschränkungen erzeugen, die die Fähigkeit sicherstellen, das autonome Fahrzeug durch Bremsen anzuhalten, um eine mögliche Kollision zu vermeiden, die unter verschiedenen modellierten Bedingungen auftreten kann. Der größte Teil der Längssteuerung im Zusammenhang mit der Hindernisvermeidung kann vom Bewegungsplaner 172 übernommen werden. Bei großen Entfernungen, die für hohe Geschwindigkeiten relevant sind, ist die Wahrnehmungsgranularität von Dingen wie der genauen seitlichen Position und Ausdehnung vorausfahrender Fahrzeuge in einer Fahrbahn möglicherweise nicht fein genug, um eine Bewegungsplanung seitlich an einem vorausfahrendem Fahrzeug vorbei zu gewährleisten. Bei den höchsten Entfernungen und Geschwindigkeiten, die für den Gegenverkehr bei voller Geschwindigkeit oder für die Begegnung mit einem angehaltenen Fahrzeug oder einer Gefahr relevant sind, kann die Granularität der Entscheidung darin bestehen, abzubremsen oder nicht abzubremsen, weil auf der aktuellen Fahrbahn des autonomen Fahrzeugs etwas langsam zu sein scheint. Die Logik ist ähnlich für langsamen Verkehr oder andere Situationen auf den Fahrbahnen neben der aktuellen Fahrbahn des autonomen Fahrzeugs, die das autonome Fahrzeug dazu veranlassen, langsamer zu fahren. Wenn der Abstand groß ist, kann das Hindernis im Weg (Obstacle-In-Path-Assignment (OIPA)) verwendet werden, um auf Hindernisse zu reagieren. Wenn sich Hindernisse nähern, kann der Bewegungsplaner 172 eine Feinabstimmung vornehmen, wie z. B. seitliches Anfahren anstelle des Bremsens. Diese Architektur ermöglicht auch die Verwendung bereits abgestimmter Längsbegrenzungen für Hochgeschwindigkeitsfahrten auf Autobahnen ohne wesentliche Änderungen.
Der Ausweichplaner 159 kann das Ausweichen pro Fahrbahn (oder von Fahrbahn zu Fahrbahn) in dem Sinne handhaben, dass bei einem Ausweichen nicht genau berücksichtigt werden muss, wo sich das autonome Fahrzeug seitlich in einer Fahrbahn befindet, um zu wissen, dass ein Ausweichen erforderlich ist. Dies schließt die Handhabung einer Stopp- oder Vorfahrtslinie ein, an der andere die Vorfahrt haben. Das Vorhandensein einer solchen Bedingung wird im Weltmodell 164 über Wartebedingungen bereitgestellt. Die Wartebedingungen werden mit einem Abschnitt des Ego-Pfads zwischen einer Einfahrts- und einer Ausfahrtslinie, einem konkurrierenden Pfad mit einem ähnlichen konkurrierenden Abschnitt sowie einem Wartezustand kodiert, den man sich als Vorfahrts-Zustand vorstellen kann. Das Weltmodell 164 kann auch eine Pfadzuordnung von Konkurrenten liefern, aus der das Verhaltens- und Steuerungsmodul des autonomen Fahrzeugs ableiten kann, dass andere Konkurrenten Vorfahrt haben (oder dass das autonome Fahrzeug Vorfahrt hat). Wartebedingungen können eine Teilmenge der oben genannten Bedingungen einschließen, wie z. B. eine Ampel zur Anzeige einer Auffahrt, die keine direkte Verbindung zu einem Konkurrentenpfad hat, sondern nur zu einer Haltelinie mit einem damit verbundenen Wartezustand. Die architektonische Trennung von Belangen, die mit Wartebedingungen erreicht wird, besteht darin, dass Wartebedingungen die Erwartung, Regel oder Konvention kodieren. Es kann dann die Aufgabe des Verhaltensplaners 140 sein, das Ausweichen zu überwachen und anzuwenden und die tatsächliche kinematische Machbarkeit oder etwaige Gefahren zu bestimmen. Der Ausweichplaner 159 berücksichtigt die Verzögerung, die erforderlich ist, um an einer Linie mit dem Wartezustand Halt beim Ankommen bzw. STOP_AT_ENTRY (z. B. durch eine rote Ampel) anzuhalten. Der Ausweichsplaner 149 kann auch Vorfahrt Achten bzw. TAKE_WAY_TRANSIENT (z. B. ausgelöst durch eine gelbe Ampel) behandeln und berechnen, welches Maß an Verzögerung erforderlich wäre, um an der Linie oder vor einer gewissen Überschreitung anzuhalten. Auf diese Weise kann der Ausweichsplaner 149 beispielsweise zwischen einem Szenario, in dem die Ampel auf Gelb umschaltet, wenn die Linie fast passiert ist, so dass ein Anhalten nicht erforderlich ist, und einem Szenario, in dem ein Anhalten angebracht ist, unterscheiden.
Der Ausweichplaner 159 behandelt auch den Wartezustand Konkurrenz Ausweichen bzw. YIELD_CONTENTION, der anzeigen kann, dass das autonome Fahrzeug dem konkurrierenden Weg ausweichen soll. Dieser Fall schließt Fußgängerüberwege, Stoppschilder, bei denen andere Fahrzeuge Vorfahrt haben, Vorfahrtsschilder, Gegenverkehr beim ungeschützten Linksabbiegen, Vorfahrt für Rechtsabbieger in Europa und viele weitere Fälle ein.
Allen diesen Fällen ist gemeinsam, dass die Konkurrenten auf dem zugehörigen konkurrierenden Pfad bzw. Konkurrentenpfad berücksichtigt werden müssen und dass sichergestellt werden muss, dass das autonome Fahrzeug sie nicht behindert und dass ihnen klar ist, dass das autonome Fahrzeug Vorfahrt gewährt. Zu diesem Zweck kann der Ausweichplaner 159 eine vereinfachte (und daher rechnerisch effiziente) Form der Bewegungsplanung durchführen. In einer oder mehreren Ausführungsformen verwendet der Ausweichplaner ein vereinfachtes Modell, bei dem sich das autonome Fahrzeug und der konkurrierende Akteur entlang ihrer jeweiligen Fahrbahnen bewegen und den vollen Umfang ihrer jeweiligen Fahrbahnen plus einen gewissen Spielraum für die Durchfahrt benötigen. Der Ausweichplaner 159 kann für bestimmte Paare von Längsprofilen für das autonome Fahrzeug und die konkurrierenden Akteure berechnen, ob sich die beanspruchten Mengen überschneiden werden, wenn diese Zukunft ausgeführt wird (mehr dazu weiter unten im Abschnitt über die Bewegungsplanung). Kurz gesagt, die beanspruchte Menge ist die Menge der Punkte vor einem Akteur, die durch seinen Bremsweg „beansprucht“ wird. Es kann besser und konservativer sein, die Überschneidung der beanspruchten Mengen als stattdessen die einfache Überschneidung der physischen Körper zu betrachten, denn selbst wenn es keine physische Überschneidung gibt, bedeutet die Überschneidung der beanspruchten Mengen, dass eine gefährliche Situation stattfindet, die schwer zu kontrollieren sein kann und zumindest andere verärgert oder die Absicht des Ausweichens in Frage stellen wird. Beschleunigungspläne, die zu einer Überschneidung der beanspruchten Mengen (oder zu einer tatsächlichen physikalischen Überschneidung) führen, können als Längsbeschränkung ausgegeben werden.
In dem Fall, in dem das autonome Fahrzeug eine Ausweichverpflichtung hat, kann der Ausweichplaner 159 analysieren, ob eine Wahl für den Längsfortschritt mit einer der plausiblen Wahlmöglichkeiten für den Konkurrenten kollidiert. Das bedeutet, dass das autonome Fahrzeug unabhängig davon, ob der Konkurrent langsamer wird oder beschleunigt, ob er nach links abbiegt oder geradeaus fährt usw., einen ausreichenden Sicherheitsabstand einhalten wird.
Der Ausweichplaner 159 kann auch Wartebedingungen, auch Wartegruppen genannt, in Betracht ziehen. So muss er beispielsweise sicherstellen, dass dem von links und rechts kommender Verkehr die Vorfahrt gewährt wird, bevor er versucht, nur dem ersten die Vorfahrt zu gewähren, weil es keinen sicheren Zwischenraum gibt, um auf den von rechts kommenden Verkehr zu warten. Ein weiteres Beispiel ist ein Fußgänger, der nach einem Linksabbieger beim ungeschützten Linksabbiegen die Straße überquert. In diesem Fall muss der Ausweichplaner 159 sicherstellen, dass er sowohl den Gegenverkehr als auch den Fußgängerüberweg gleichzeitig berücksichtigt. Dies wird im Weltmodell durch die Gruppierung dieser Wartebedingungen in eine Wartegruppe signalisiert.
Der Ausweichplaner 159 kann auch zwischen den Fällen YIELD_ENTRY und YIELD_CONTENTION unterscheiden. Im ersten Fall wird erwartet, dass das autonome Fahrzeug so lange an der Haltelinie bleibt, bis es das Hindernis ohne Verzögerung überwinden kann. Im zweiten Fall kann das autonome Fahrzeug vorwärts fahren und ist nur durch die aktuelle Konkurrenz eingeschränkt, so dass es z. B. in die Kreuzung hineinfahren und warten kann, bis der Gegenverkehr eine Lücke freigibt. In dieser Situation kann die Beschränkung alle Geschwindigkeiten ausschließen, die mit dem Vorwärtsfahren nicht vereinbar sind.
Der Ausweichplaner 159 kann auch Mehr-Wege-Stops behandeln, die durch den Wartezustand Wer zuerst anhält, hat Vorfahrt (STOPPED_FIRST_HAS_PRECEDENCE) signalisiert werden. In diesem Fall (das kanonische Beispiel ist der Vier-Wege-Stop in den USA) wird die Vorfahrt davon abgeleitet, wer zuerst vor der Kreuzung angehalten hat. Hierfür stützt sich der Ausweichplaner 159 auf eine Kombination aus der Analyse, wer zuerst vor der Kreuzung angehalten hat, und einer kurzfristigen Vorhersage. Nach der Bestimmung des Vorrangs gilt die gleiche Analyse wie bei Vorfahrt, Vorfahrt bei Einfahrt oder Vorfahrt bei Ausfahrt. Wenn sowohl das autonome Fahrzeug als auch ein Konkurrent an der Kreuzung angehalten haben, verwendet die Kurzzeitprognose die Historie, um die zukünftige Bewegung der Konkurrenten vorherzusagen. In einer Situation, in der ein anderer Konkurrent vor dem autonomen Fahrzeug angehalten hat, sollte die Vorhersage so ausfallen, dass das autonome Fahrzeug sich nun bewegt (oder dass ein anderer Konkurrent sich bewegt). Wenn das autonome Fahrzeug als erstes von allen Konkurrenten angehalten hat, sollte die Vorhersage für alle Teilnehmer lauten, dass sie an Ort und Stelle bleiben. Dies ist sehr wirkungsvoll, da es eine Verfahrensweise ermöglicht, die fast so einfach ist wie, „wenn niemand anderes fährt, fahre, ansonsten warte“. Man beachte, dass dies davon abhängt, dass genügend Trainingsdaten für den jeweiligen Fall vorliegen. Diese Form der kurzfristigen Vorhersage kann auch bei der Bewegungsplanung verwendet werden und hilft bei der Vorhersage, ob in unstrukturierten Fällen nachgegeben werden soll.
Für den Wartezustand Verhandeln bzw. NEGOTIATE delegiert der Ausweichplaner 159 die Zuständigkeiten bezüglich der sichtbaren Konkurrenten an den Bewegungsplaner 172. In diesem Zustand gibt es möglicherweise keine klare Erwartung der Vorfahrt für eine der beiden Parteien, sondern es wird erwartet, dass die Situation entsprechend dem kinematisch Machbaren, der Sicherheit und der Effizienz ausgehandelt wird. Der Bewegungsplaner 172 wird das kinematisch Machbare und Sichere angesichts der Vorhersage und der Vermeidung der Überschneidung der beanspruchten Mengen tun, aber nicht darüber hinaus nachgeben. Dies führt zu einem aufdringlichen, durchsetzungsfähigen Verhalten, das effektiv so viel Weg wie möglich nimmt. Der Ausweichplaner 159 berücksichtigt jedoch auch unsichtbare Akteure auf konkurrierenden Wegen. Dies rechtfertigt eine kurze Diskussion über die Sichtbarkeit.
Das Weltmodell 164 drückt die Sichtbarkeit in drei Formen aus: als unbekannte Regionen in der Karte der radialen Entfernung, als polygonale Verdeckungsgrenzen und als unbekannte Pfadbelegung. In der vollständigen Implementierung des Wahrnehmungs- und Kartierungssystems können alle diese Formen konsistent sein, wobei verdeckte Bereiche als Regionen mit ihren Grenzen angezeigt werden und auch die Pfadbelegung konsistent beeinflussen. Die Verdeckungsgrenzen können von einem durchgängig trainierten neuronalen Netz erzeugt werden, ebenso wie die Pfadbelegung. Dies kann jedoch in einigen Implementierungen nicht verfügbar sein, so dass die Planung die Pfadbelegung verwenden kann. In alternativen Ausführungsformen können Verdeckungsgrenzen verwendet werden, um expandierende beanspruchte Mengen für den Bewegungsplaner 172 zu erzeugen. Wenn der Ausweichplaner 159 einen Konkurrentenpfad findet, der keinen TAKE_WAY-Wartezustand und unbekannte Belegungspunkte (oder eine kurze Entfernung) aufweist, nimmt er einen Konkurrenten mit Worst-Case-Geschwindigkeiten (das gesamte Intervall von der niedrigsten bis zur höchsten) an diesen Punkten an und führt die Ausweichplanung mit diesen virtuellen Konkurrenten durch. Dies bietet die architektonische Möglichkeit, alle verdeckten Konkurrenten zu behandeln, die auf bekannten Konkurrentenpfaden kommen.
Die Konkurrentenpfade können aus der Karte oder durch Live-Erkennung bekannt sein, oder beides. Eine Anwendung kann auf kartierten Konkurrentenpfaden basieren, wobei die Sichtbarkeit durch Projektion von Punkten oberhalb des Pfades, auf dem der Konkurrent erwartet wird, auf Sensoren analysiert wird und die Abstände mit Tiefenkarten verglichen werden. Auf diese Weise kann im Prinzip die Verdeckung durch statische und dynamische Verdeckungen bewältigt werden.
Die kombinierte Ausgabe der verschiedenen Komponenten der Längsvorbegrenzungskomponente 150 kann eine Vielzahl von längsbegrenzten nominalen Bahnen sein. Die vom Aktionsgenerator 142 erzeugten Bahnen können mit mehreren unterschiedlichen Beschleunigungsplänen kombiniert werden, um eine große Anzahl von Trajektorien entlang der Bahn zu erzeugen. Die mehreren längsbegrenzten nominalen Bahnen weisen Bahnen auf, die die verschiedenen von der Längsvorbegrenzungskomponente 150 berechneten Einschränkungen erfüllen. Die Mehrzahl der längsbegrenzten nominalen Bahnen kann zur weiteren Verfeinerung darüber hinaus an die Komponente der Hypothesengenerierung 160 weitergeleitet werden.
Die Bewegungsplanung erfolgt durch Hypothesengenerierung und -bewertung (Bewegungsplaner 172). Die Idee ist, dass der Bewegungsplaner 172 gegebene Trajektorien (vollständige geplante Posen in der Zukunft für das autonome Fahrzeug) sehr gründlich auf ihre Qualität hin bewertet, und die Hypothesengenerierung 160 liefert vielversprechende oder plausible Trajektorien, da der Raum aller Trajektorien zu groß ist, um ihn zu durchsuchen.
Gemäß Ausführungsformen kann ein hoher Grad an Variabilität für die Hypothesengenerierung für einen Bewegungsplaner 172 verwendet werden. Bei einigen Ausführungsformen ist eine zentrale Komponente ein Pfadauffächerungsgenerator 162, der von der längsbegrenzten nominalen Bahn ausgeht und unter Beibehaltung ihrer Krümmung seitlich variierende Wahlmöglichkeiten um sie herum erzeugt. Dies ist auf die Absicht zugeschnitten, einer Fahrbahn zu folgen und gleichzeitig statische und dynamische Hindernisse zu umgehen. Längsvariationen innerhalb der Längsgrenzen können zu jeder seitlichen Auswahl hinzugefügt werden, wodurch ein 2D-Gitter von Trajektorien für den Bewegungsplaner entsteht. Dies wird für den Standard-Fall des Fahrbahn-Folgens sowie für darauf aufbauende Aktionen wie (z. B. und ohne Einschränkung Parkplatzsuchen (Park Prowl), Einparken (Park Endgame), Herbeirufen (Summon), und Langsamfahren (Limp) verwendet.
In 2 sind beispielhafte Trajektorien dargestellt. Die nominale Bahn kann der rechten Fahrbahn entsprechen, auf der sich das autonome Fahrzeug befindet. Wie zu sehen ist, stellt eine Reihe von Pylonen 224 ein Hindernis dar, das umfahren werden muss. Der Pfadauffächerungsgenerator 162 kann 11 verschiedene, quer bzw. seitliche variierende Auswahlmöglichkeiten in Verbindung mit der nominalen Bahn erzeugen. Die verschiedenen Möglichkeiten weisen Pfad 202, Pfad 204, Pfad 206, Pfad 208, Pfad 210, Pfad 212, Pfad 214, Pfad 216, Pfad 218, Pfad 220 und Pfad 222 auf. Jedem Pfad kann ein Geschwindigkeitsprofil zugeordnet werden, wie es im Profilgraph 230 dargestellt ist. Wie zu sehen ist, kommen die Pfade 218, 220 und 222 innerhalb einer kurzen Strecke zum Stillstand. Im Gegensatz dazu kann auf dem Pfad 202 eine höhere Geschwindigkeit beibehalten werden.
Der Fahrbahnwechsel kann in drei Stufen erfolgen, die sich wie folgt darstellen 1) Folgen der aktuellen Fahrbahn in der Hoffnung auf eine Lücke auf der anderen Fahrbahn, 2) Folgen der aktuellen Fahrbahn bei gleichzeitiger Geschwindigkeitsanpassung, um aktiv zu versuchen, sich in eine Lücke einzufügen, und schließlich seitliches Drängeln, um zu versuchen, eine Lücke zu nutzen oder eine zu schaffen. Es ist zu beachten, dass mehrere Iterationen der Hypothesengenerierung und -bewertung möglich sind, die auf den Ergebnissen der vorherigen Runde aufbauen. Für den Fahrbahnwechsel kann zunächst eine Iteration des regulären Fahrbahnwechsels (Pfadauffächerungsgenerierung und Auswertung des Bewegungsplaners) durchgeführt werden. Für die erste Stufe des Fahrbahnwechsels ist dies möglicherweise ausreichend. In der Phase der Geschwindigkeitsanpassung wird die beste seitliche Wahl bestimmt oder ausgewählt und darauf aufgebaut. Dies kann unter Verwendung der besten seitlichen Wahl und einer kleinen Anzahl zusätzlicher Wahlmöglichkeiten (z. B. eine links und eine rechts von der besten Wahl) geschehen, um eine Suche nach der besten Geschwindigkeitsanpassung durchzuführen. Dazu kann eine zweidimensionale Familie von S-Kurven in Längsrichtung erzeugt werden, z. B. mit dem S-Kurven-Generator 163, der nach Beschleunigungswert und Schaltzeit sucht. Die Hypothesen durchlaufen dann den Bewegungsplaner 172 zur Bewertung. Während der Phase des Drängelns kann das beste Ergebnis verwendet werden, um den Umfang des seitlichen Drängelns zu untersuchen.
3 und 4 veranschaulichen die Hypothesenbildung im Zusammenhang mit einem Fahrbahnwechsel, der durch benachbarte Fahrzeuge behindert wird. 3 weist eine Vorwärtsansicht 302 auf, die ein Fahrzeug auf der linken Fahrbahn unmittelbar vor dem autonomen Fahrzeug zeigt. Eine nach hinten gerichtete Ansicht 304 auf der Fahrerseite zeigt ein Fahrzeug auf der linken Fahrbahn direkt hinter dem autonomen Fahrzeug. Eine nach hinten gerichtete Ansicht 308 auf der Beifahrerseite zeigt Pylonen, die das autonome Fahrzeug passiert hat. Und eine Rückwärtsansicht 310 zeigt ebenfalls das Fahrzeug auf der linken Fahrbahn direkt hinter dem autonomen Fahrzeug. Diese Ansichten können verwendet werden, um die Position der Autos in der Nähe zu bestimmen, die wiederum verwendet werden können, um nach hypothetischen Trajektorien zu suchen, die mit einem Fahrbahnwechsel in den Raum zwischen dem hinteren und dem vorderen Auto auf der linken Fahrbahn vereinbar sind.
4 zeigt mögliche Pfade innerhalb der nominalen Bahn, die vom Pfadauffächerungsgenerator 162 erzeugt werden. Diese Pfade weisen Pfad 402, Pfad 404, Pfad 406, Pfad 408, Pfad 410, Pfad 412, Pfad 414, Pfad 416, Pfad 418, Pfad 420 und Pfad 422 auf. Der Geschwindigkeitsprofilgraph 430 zeigt die für einige der Pfade verfügbare Geschwindigkeit an.
Die Hypothesengenerierung 160 ist flexibel und kann andere, weniger strukturierte Ansätze verwenden, z. B. eine dynamische Programmierung zur Suche nach einem Pfad mit freier Form, die von der dynamischen Programmierkomponente 166 durchgeführt wird, oder linear-quadratische Regler (LQR)/hindernisbewusste MPC-Steuerung 168, die einen anfänglichen Pfad (z. B. die nominale Bahn) nimmt und ihn iterativ anpasst, um Hindernisse zu vermeiden. Dies kann entweder auf einer statischen Szene, die eine Bewegung ignoriert, geschehen, im Vertrauen darauf, dass der Bewegungsplaner dann gefährliche, bewegungsbedingte Situationen erkennt und vermeidet, oder durch die Verwendung von beanspruchten Mengen direkt bei der Suche.
Jede hypothetische Trajektorie kann von der Planbewertungskomponente 171 bewertet werden, um die qualitativ beste oder optimale Trajektorie zu ermitteln. Die Qualität weist dabei viele Aspekte auf, kann aber durch eine Optimierungsbewertung quantifiziert werden. Verschiedene Qualitäten können bei der Berechnung einer Bewertung unterschiedlich gewichtet werden. Im Großen und Ganzen lässt sich die ideale Fahrweise auf fünf Kategorien von Begriffen zurückführen. Die Ziele können unter anderem die Maximierung des Komforts und des Fortkommens einschließen (ein Ziel mit minimalem Aufwand an Ressourcen wie Zeit, Geld, Kraftstoff und Verschleiß zu erreichen). Ein weiteres Ziel kann darin bestehen, die Kollisionssicherheit zu maximieren (Hindernisse), unter sonst gleichen Bedingungen den Fahrbahnen zu folgen (Pfade) und die geltenden Regeln und Konventionen einzuhalten (Wartebedingungen). Einige dieser Präferenzen sind auf konkrete Weise mit einem Bewegungsplan verbunden. Fortschritt und Gleichmäßigkeit können direkt anhand des Bewegungsplans bewertet werden. Bei anderen Aspekten kann es schwierig sein, die Verbindung direkt herzustellen. So kann es zum Beispiel eine gute Strategie für die Einhaltung des Abstands sein, nah dran zu bleiben, um das Eindringen von Fahrzeugen zu vermeiden, die noch nicht einmal in der Nähe aufgetaucht sind, und dies ist nicht direkt aus der Analyse von Hindernissen in dieser Szene ersichtlich. Direkte kinematische Einschränkungen durch Hindernisse in der Umgebung des autonomen Fahrzeugs können jedoch mit kurzfristigen Vorhersagen bewertet werden. Dies wird im Folgenden weiter unten erörtert.
In einem Aspekt wird die Optimierungsbewertung bezüglich der Zeit normiert. Die sequenziellen Zeitgewinne für potenzielle zukünftige Positionen können direkt in die Bewertung einfließen und als Ausgangspunkt dienen, während die anderen Komponenten, die zur Bewertung beitragen, Zeit als Strafe hinzufügen können. Eine vorhergesagte Kollision würde zum Beispiel 100 Stunden hinzufügen, was eine erhebliche Anpassung oder einen Ausgleich (z. B. eine Strafe) darstellen und dazu führen kann, dass diese Trajektorie nicht ausgewählt wird. Geringere, aber dennoch unerwünschte Bedingungen können zu kleineren Anpassungen führen. Die Anpassungen können in Abhängigkeit von der Routenlänge oder der geschätzten Fahrzeit skaliert oder normalisiert werden. Auf diese Weise kann die Anpassung, die sich aus einem unerwünschten Merkmal einer Route ergibt, auf einer längeren Route mehr Zeit hinzufügen und auf einer kürzeren Route weniger. Die Normalisierung kann durch Berechnung der Anpassung als Prozentsatz der Zeit bis zum Ziel erfolgen. Beispielsweise können einige Bedingungen auf einer Route zu einer Anpassung von 2 % der geschätzten verbleibenden Zeit bis zum Erreichen des Ziels führen.
Der Bewegungsplaner 172 verfügt auch über Bedingungen für die Bevorzugung eines Verbleibens in der Nähe der nominalen Bahn oder zwischen den Rändern der betrachteten Fahrbahn. Diese Präferenzen können zur Berechnung der Optimierungsbewertung herangezogen werden. Beim Folgen der Fahrbahn kann es von großem Vorteil sein, nicht über die Ränder der Fahrbahn hinauszufahren, selbst wenn der Fahrbahnrand kein physisches Hindernis darstellt. Dies kann jedoch vorzuziehen sein, wenn das Überfahren der Fahrbahnränder die einzige plausible Möglichkeit ist, eine Kollision zu vermeiden. Dies ist jedoch etwas anderes als ein geplanter kontrollierter Fahrbahnwechsel. Insbesondere deshalb, weil bei einem geplanten kontrollierten Fahrbahnwechsel Zeit bleibt, um das Blinkersignal zu setzen und anderen Zeit zu geben, das Signal zu bemerken. Aus diesem Grund betrachtet der Bewegungsplaner 172 Trajektorien im Kontext von Fahrbahnfolgen und Fahrbahnwechsel unterschiedlich, auch wenn es sich um dieselbe Trajektorie handeln kann. Die Optimierungsbewertung für eine Trajektorie kann sich erhöhen, je genauer der Fahrbahnmitte gefolgt wird. Die Optimierungsbewertung kann sich verringern, wenn eine Trajektorie eine Fahrbahngrenze überquert. Die Höhe der Bewertungsverringerung kann vom Kontext der Fahrbahnüberquerung abhängen. Zum Beispiel kann das Überqueren einer gestrichelten Linie eine geringere Strafe nach sich ziehen als das Überqueren einer durchgezogenen Linie oder einer doppelt durchgezogenen Linie. Das Kreuzen mit Gegenverkehr kann eine sehr hohe Strafe bedeuten.
Zumindest einige der Wartebedingungen können durch den Ausweichplaner 159 gehandhabt werden, obwohl der Bewegungsplaner 172 auch einige Bedingungen aufweisen kann, die durch Ausweichanforderungen an andere Akteure bekannt gemacht werden. Der Bewegungsplaner 172 kann auch Bedingungen aufweisen, die es vorziehen, eine Fahrbahn nicht Seite an Seite zu teilen oder es zu vermeiden, auch mit Konkurrenten auf anderen Fahrbahnen Seite an Seite zu sein. Dies hilft bei Verhaltensweisen wie der Berücksichtigung von Motorrädern, die sich die Fahrbahn teilen, oder der gemeinsamen Nutzung von Fahrbahnen nebeneinander, wenn eine stark umkämpfte Langsamfahrstelle durchfahren wird, während diese Bedingungen nicht eingeleitet werden. Ebenso ist es möglich, ein geparktes Fahrzeug zu überholen oder sich im toten Winkel eines anderen Fahrzeugs aufzuhalten, wobei diese Bedingungen nach Möglichkeit vorübergehend sein sollten.
Der Kern der Bewegungsplanung kann die Analyse eines Bewegungsplans anhand von konkurrierenden Hindernissen aufweisen. Die Analyse kann aufweisen, dass auf Überschneidungen zwischen beanspruchten Mengen geachtet wird. Anstatt zu prüfen, ob eine Kollision zwischen physischen Körpern jetzt oder in der Zukunft stattfindet, wird bei der Bewegungsplanung gemäß den offengelegten Ausführungsformen geprüft, ob es eine Überschneidung zwischen beanspruchten Mengen gibt. Auf diese Weise lässt sich die statische Bewegungsplanung auf eine Umgebung mit sich bewegenden Konkurrenten mit Geschwindigkeiten übertragen, die ein nahezu sofortiges Anhalten nicht zulassen. Die beanspruchte Menge ist die Form in der Raumzeit, die ein Akteur durchläuft, während er versucht, sicher anzuhalten und sich quer bzw. seitlich an die Straße anzupassen. Ein Akteur erhebt praktisch Anspruch auf diese Menge, da er sie benötigt, um die Kollisionssicherheit zu gewährleisten. Selbst wenn sich die Körper nicht überschneiden, wäre es schwierig, Überschneidungen der beanspruchten Mengen zuzulassen und gleichzeitig eine Form der kontrollierten Sicherheit aufrechtzuerhalten. Umgekehrt können die Akteure innerhalb der beanspruchten Mengen bleiben, wenn diese gegenseitig respektiert werden. Wenn dies der Fall ist, werden die beanspruchten Mengen in der Raumzeit abgespielt und dehnen sich nicht aus. Auf diese Weise kann das statische Bewegungsplanungsproblem zu einem Problem mit Bewegung erweitert werden. Die beanspruchten Mengen können sofort anhalten, die sich bewegenden Akteure jedoch nicht. Ein weiterer Vorteil dieses Ansatzes besteht darin, dass er sich nicht auf Trainingsdaten oder Vorhersagen in nahen oder tatsächlichen Kollisionssituationen stützt, die selten oder nur schwer zu erhalten sind. Er gewährleistet auch eine Kollisionssicherheit, die über das einfache Vermeiden einer physischen Kollision hinausgeht.
In einer oder mehreren Ausführungsformen kann der Ansatz des Safety Force Field (SFF) 184 innerhalb des Verhaltensplaners 140 und des Steuerungssystems des autonomen Fahrzeugs in Betrieb sein und wird nicht durch eine andere Funktion unterbrochen. Er blockiert reaktiv eine unerlaubte momentane Steuerung und wandelt sie in eine erlaubte Steuerung um. Es ist jedoch nicht vorgesehen, dass sie im Normalbetrieb ausgelöst wird. Der Bewegungsplaner 172 behandelt ähnliche zugrundeliegende Beschränkungen auf eine proaktivere Weise. Er stellt im Wesentlichen die Frage: „Wenn ich mich auf diese Weise in die Zukunft bewege und die Konkurrenten sich wie vorhergesagt bewegen, werden dann die Beschränkungen ausgelöst?“ Dann können Bewegungspläne bevorzugt werden, bei denen es unwahrscheinlich ist, dass sie in der Zukunft Beschränkungen auslösen, oder solche, die sie später in der Zukunft auslösen. Auf diese Weise kann das autonome Fahrzeug viel früher mit der Verlangsamung oder der Queranpassung beginnen und somit gleichmäßiger und sicherer fahren. Man beachte, dass die zugrundeliegenden Zwänge es einem Ego-Fahrzeug erlauben, auf diese Weise recht selbstbewusst zu agieren. Solange die Vorhersagen darauf hindeuten, dass das autonome Fahrzeug nicht in eine gefährliche Situation gerät, und keine Vorbeschränkung durch den Ausweichplaner 159 erfolgt, kann der Bewegungsplaner 172 ein selbstbewusstes Verhalten erzeugen.
Gemäß Ausführungsformen kann der Bewegungsplaner 172 eine CUDA-Implementierung verwenden, um viele zukünftige Überschneidungen von beanspruchten Mengen auszuwerten. CUDA ist eine von der NVIDIA Corporation entwickelte Plattform für parallele Datenverarbeitung und ein Modell für Anwendungsprogrammierschnittstellen. Es ermöglicht Software-Entwicklern und Software-Ingenieuren, eine CUDA-fähige Grafikverarbeitungseinheit für die allgemeine Verarbeitung zu verwenden. Bei dieser CUDA-Implementierung werden viele Auswahlmöglichkeiten für die Trajektorie parallel berücksichtigt, typischerweise eine zweidimensionale Familie von Trajektorien (z. B. ein 10x10-Raster), die sich sowohl bezüglich quer zum Pfad als auch bezüglich der Längsgeschwindigkeit unterscheiden. Der Bewegungsplaner 172 prüft dann für jede dieser zukünftigen Trajektorien und für jeden Zeitschritt, ob die vorhergesagten Akteurszustände zu Überschneidungen beanspruchter Mengen relativ zum autonomen Fahrzeug führen. Dies wird durch eine etwas konservativere Einschränkung als die Überschneidung beanspruchter Mengen in Raum-Zeit effizient gemacht. Stattdessen sollte der andere Akteur in Längsrichtung des autonomen Fahrzeugs frei sein (dies ist wie eine schnelle Überprüfung, dass sich die beanspruchten Mengen nicht überschneiden, wenn man „von der Seite“ nur eine Projektion betrachtet, die die Längsrichtung und die Zeitrichtung beibehält) oder dass die beanspruchten Mengen getrennt sind, wenn man sie aus der „Draufsicht“ betrachtet und weg von der Zeitrichtung projiziert. Es wird eine Annäherung der beanspruchten Mengen aller Akteure bei Projektion weg von der Zeit verwendet (beanspruchte Mengen in 2D). Kollisionsprüfungen werden dann an einer polygonalen Darstellung dieser beanspruchten Mengen in 2D durchgeführt. Es ist zu beachten, dass statische Hindernisse direkt als beanspruchte Mengen in 2D verwendet werden können. Das oben beschriebene Verfahren bedeutet, dass Kollisionsprüfungen zwischen polygonalen Darstellungen für viele Szenenkonfigurationen parallel durchgeführt werden. Die Längsvorbegrenzung steht dem Bewegungsplaner 172 pro Aktion zur Verfügung und kann sowohl vor der Auswertung des Bewegungsplaners 172 verwendet werden, um die Hypothesengenerierung zu ändern, als auch nach der Auswertung, um die schnelleren Trajektorien im Wesentlichen zu blockieren oder weitgehend zu vermeiden.
Der Last Safe Arrival (LSA)-Planer 174 arbeitet mit dem Bewegungsplaner 172 zusammen. Der LSA-Planer 174 beruht auf einer konservativeren Annahme als der SFF 184, die auf Fußgänger angewendet werden kann, bei denen kein Grund zur Annahme besteht, dass sie wachsam sind, oder bei denen Grund zur Annahme besteht, dass sie sich unberechenbar verhalten könnten. Sie leitet sich aus der Annahme ab, dass der Konkurrent (Fußgänger) in jede Richtung beschleunigen kann und erst dann langsamer wird, wenn das autonome Fahrzeug buchstäblich seinen Weg blockiert. Dies führt zu einer Randbedingung, die der Überschneidung beanspruchter Mengen von SFF 184 ähnelt, die sowohl unmittelbar als auch als Beschränkung für einen Planer (den LSA-Planer 174) angewendet wird, der über die Kernbeschränkung hinaus die Zukunft voraussagt. Wenn dieselbe Vorhersage wie die Kernbeschränkung verwendet wird, was recht konservativ ist, aber einen sicheren Ausgangspunkt für Fußgänger darstellt, dann läuft dies darauf hinaus, zu überprüfen, dass keine der aktuellen oder zukünftigen beanspruchten Mengen nach der LSA-Zeit einen Punkt beansprucht, den das autonome Fahrzeug nicht bereits beansprucht hat. Dies lässt sich effizient bewerkstelligen, indem man den am weitesten entfernten Punkt jeder beanspruchten Menge sowie alle ankommenden Mengen bis zur aktuellen Anhalteentfernung überprüft. Dies läuft parallel zur Auswertung des Bewegungsplaners für dieselbe Trajektoriengruppe und kann nur für Fußgänger gelten.
Die Kurzzeitvorhersagekomponente 161 kann sowohl einen analytischen Ansatz als auch einen datengesteuerten Ansatz verwenden, um eine vorhergesagte Position für ein Hindernis zu erzeugen. Der analytische Ansatz nimmt die durch das Weltmodell 164 gegebenen Hindernisse und sagt voraus, dass sie sich entlang des gegebenen Geschwindigkeitsvektors mit einer allmählichen Anpassung an die Fahrbahnstruktur fortsetzen werden (zu beachten ist, dass es mehrere Fahrbahnoptionen pro Konkurrent geben kann, wie z. B. links, rechts, U-Turn oder geradeaus). Die Stärke der analytischen Vorhersage liegt darin, dass eine geringe, aber von Null abweichende Wahrscheinlichkeit kodiert und mit Dingen in Verbindung gebracht werden kann, von denen bekannt ist, dass sie relevant sind, die aber in den Trainingsdaten selten vorkommen können, wie z. B. Einfahren (cut-ins) oder extrem starkes Bremsen.
Der datengesteuerte Ansatz nutzt die Historie der wahrgenommenen Szene, um vorherzusagen, was die Konkurrenten tun werden, trainiert aus Episoden, in denen die Zukunft als Trainingsdaten bekannt ist. Reale Daten können für diese Form des Trainings besonders nützlich sein. Gemäß Ausführungsformen kann diese Art des Trainings mit den Ergebnissen des automatischen Systems durchgeführt werden und kann daher von großen Datenmengen profitieren, ohne manuell erstellte Ground-Truth.
Der Planselektor 175 wählt den Plan auf der Grundlage der von der Planbewertungskomponente 171 abgegebenen Bewertungen oder Beurteilungen aus. In einem Fall wird die Trajektorie mit der höchsten Qualitätsbewertung ausgewählt. Der Planselektor 175 kann auch eine Längskonditionierung 176 und eine Querkonditionierung 178 vornehmen. Beide sorgen für eine geringfügige Glättung der ausgewählten Trajektorie.
Der ausgewählte Plan kann von dem SFF 184, dem LSA 186, dem Fahrbahnhaltenassistenten (Lane Keeping Assistent (LKA)) 188 und der automatischen Notbremsung (Autonomische Emergency Brake (AEB)) 190 ausgewertet werden. Der Bewegungsplaner 172 oder andere Komponenten können die Eingaben dieser Komponenten bei der Bewertung der Trajektorien oder zumindest der Einhaltung der von diesen Komponenten auferlegten Beschränkungen berücksichtigt haben. Zum Beispiel kann die Sicherheitsbremskomponente 158 Einschränkungen erzeugen, die eine automatische Notbremsung verhindern sollen.
Das hier beschriebene Verfahren kann die derzeitigen Verfahren verbessern, indem es einen iterativen Ansatz zur Ermittlung einer optimalen Trajektorie verwendet. In einer ersten Iteration kann die anfängliche Vielzahl hypothetischer Trajektorien bewertet werden, wobei die Trajektorie mit der höchsten Optimierungsbewertung als Ausgangspunkt für die Erzeugung weiterer hypothetischer Trajektorien zur Bewertung dient. In einer zweiten Iteration kann die zweite Vielzahl von hypothetischen Trajektorien durch geringfügige Änderung verschiedener Parameter der Ausgangstrajektorien erzeugt werden. Beispielsweise kann die Ausgangstrajektorie an den Pfadauffächerungsgenerator 162 übermittelt und als Eingabe anstelle einer nominalen Bahn verwendet werden. Der Pfadauffächerungsgenerator kann dann eine zweite Vielzahl von Trajektorien erzeugen, die kleine Quervariationen (kleinere seitliche Unebenheiten als die in der ersten Iteration auf der nominalen Bahn verwendeten) und kleine Längsvariationen aufweisen. Die zweite Vielzahl hypothetischer Trajektorien kann dann ausgewertet werden, um festzustellen, ob eine dieser Trajektorien eine höhere Optimierungsbewertung hat als die Ausgangstrajektorie. Die hypothetische Trajektorie mit der besten Optimierungsbewertung kann für die Anwendung ausgewählt werden.
Die modellprädiktive Steuerung (Model Predicitve Controller (MPC)) 180 verwendet die gewählte Trajektorie und ein verfeinertes Fahrzeugmodell, um die momentane Quer- und Längsbeschleunigung zu steuern 195. Die MPC-Steuerung kann durch Berechnung der Trajektorie in die Zukunft auf der Grundlage einer Steuersequenz und des Modells und durch iterative Anpassung der Steuersequenz mit einem nichtlinearen Optimierer zur Optimierung einer Kostenfunktion arbeiten. In diesem Fall kann die Kostenfunktion so ausgelegt sein, dass ein Kompromiss zwischen Glätte und Folgen der geforderten Trajektorie gefunden wird (da diese Stufe jedoch keine Hindernisse berücksichtigt, kann sie so eingestellt werden, dass sie der Trajektorie getreu folgt, und die Gleichmäßigkeit der Trajektorie sollte durch die Bewegungsplanungsstufe sichergestellt werden). Der SFF 184 und andere Komponenten können auch verwendet werden, um inakzeptable Beschleunigungsentscheidungen zu verhindern.
In den Figuren 5-7, umfasst jeder Block der Verfahren 500, 600 und 700, wie es hier beschrieben ist, ein Rechenverfahren, das mit einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Die Ausführungsformen können auch als computerverwendbare Anweisungen auf Computerspeichermedien gespeichert sein. Das Verfahren kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige zu nennen. Darüber hinaus werden die Verfahren 500, 600 und 700 beispielhaft in Bezug auf das Verhaltensplanungssystem 100 von 1 beschrieben. Diese Verfahren können jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich, aber nicht beschränkt auf die hier beschriebenen Systeme.
5 ist ein Flussdiagramm, das ein Verfahren 500 zur Auswahl einer Trajektorie für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 500 weist in Block 502 ein Erzeugen eines Fahrbahngraphen auf, der eine erste Reihe von Zeitgewinnen für potentielle zukünftige Positionen der autonomen Maschine umfasst. Das Verfahren 500 weist in Block 504 ein Erzeugen einer Vielzahl möglicher Trajektorien auf, die es der autonomen Maschine ermöglichen, eine Aktion der autonomen Maschinen durchzuführen. Das Verfahren 500 weist in Block 506 ein Erzeugen eines Optimierungsmaßes für die möglichen Trajektorien unter Verwendung der ersten Reihe von Zeitgewinnen als Eingabe auf. Das Verfahren 500 weist in Block 508 ein Auswählen einer Trajektorie zur Anwendung unter Verwendung des Optimierungsmaßes auf. Das Verfahren 500 weist in Block 510 ein Anwenden der Trajektorie unter Verwendung der autonomen Maschine auf.
6 ist ein Flussdiagramm, das ein Verfahren 600 zur Auswahl einer Trajektorie für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 600 weist in Block 602 ein Erzeugen einer Szenenvorhersage auf, die eine vorhergesagte zukünftige Objektposition für ein Objekt aufweist, das von einem oder mehreren Sensoren, die der autonomen Maschine entsprechen, erfasst wurde;
Das Verfahren 600 weist in Block 604 ein Erzeugen einer Vielzahl möglicher Trajektorien für eine Aktion der autonomen Maschine auf, wobei die Vielzahl möglicher Trajektorien eine Vielzahl von Längsbedingungen und Querbedingungen innerhalb einer nominal breiten Bahn aufweist, die der Aktion der autonomen Maschine entspricht. Das Verfahren 600 weist in Block 606 ein Auswerten der Vielzahl möglicher Trajektorien unter Verwendung der Szenenvorhersage und einer ersten Reihe von Zeitgewinnen auf, die einer Vielzahl möglicher zukünftiger Positionen der autonomen Maschine entsprechen, um ein Optimierungsmaß für die Vielzahl möglicher Trajektorien zu erzeugen. Das Verfahren 600 weist in Block 608 ein Auswählen einer Trajektorie für einen Startparametersatz auf, der verwendet wird, um zusätzliche Trajektorien für die Auswertung zu erzeugen, wobei das Optimierungsmaß verwendet wird. Das Verfahren 600 weist in Block 610 ein Auswählen einer individuellen Trajektorie aus den zusätzlichen Trajektorien unter Verwendung des Optimierungsmaßes auf. Das Verfahren 600 weist im Block 612 ein Anwenden der individuellen Trajektorie für die autonome Maschine auf.
7 ist ein Flussdiagramm, das ein Verfahren 700 zur Auswahl einer Trajektorie für ein autonomes Fahrzeug gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 700 weist in Block 702 ein Erzeugen einer Vielzahl möglicher Trajektorien für eine Aktion der autonomen Maschine auf, wobei die Vielzahl möglicher Trajektorien eine Vielzahl von Längsbedingungen und eine Vielzahl von Querbedingungen aufweist. Das Verfahren 700 weist in Block 704 ein Auswerten von Trajektorien in der Vielzahl möglicher Trajektorien unter Verwendung einer Szenenvorhersage auf, um ein Optimierungsmaß für die Trajektorien zu erzeugen. Das Verfahren 700 weist in Block 706 ein Auswählen einer individuellen Trajektorie aus der Vielzahl der möglichen Trajektorien unter Verwendung des Optimierungsmaßes auf. Das Verfahren 700 weist in Block 708 ein Anwenden der individuellen Trajektorie für eine autonome Maschine auf, wobei die Vielzahl der Längsbedingungen zumindest auf der Szenenvorhersage basieren, und wobei die Vielzahl der Querbedingungen zumindest auf einer nominalen Bahn basieren, die einer Fahrtrichtung der autonomen Maschine entspricht.
BEISPIELHAFTES AUTONOMES FAHRZEUG
8A ist eine Veranschaulichung eines Beispiels für ein autonomes Fahrzeug 800 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 800 (hier alternativ als „Fahrzeug 800“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug sein, wie z. B. ein Auto, ein Lastwagen, ein Bus, ein Rettungsfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, ein Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne und/oder eine andere Art von Fahrzeug (z. B. ein unbemanntes Fahrzeug und/oder ein Fahrzeug, das einen oder mehrere Passagiere aufnimmt). Autonome Fahrzeuge sind im Allgemeinen im Hinblick auf Automatisierungslevels beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (Standard Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert sind. Das Fahrzeug 800 kann zu einer Funktionalität gemäß einem oder mehreren von Level 3 - Level 5 der Levels für autonomes Fahren in der Lage sein. Zum Beispiel kann das Fahrzeug 800 in Abhängigkeit von der Ausführungsform zu einer bedingten Automatisierung (Level 3), einer hohen Automatisierung (Level 4) und/oder einer vollständigen Automatisierung (Level 5) in der Lage sein.
Das Fahrzeug 800 kann Komponenten wie etwa ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs beinhalten. Das Fahrzeug 800 kann ein Antriebssystem 850 beinhalten, wie z. B. einen Verbrennungsmotor, ein Hybridelektrotriebwerk, einen vollelektrischen Motor und/oder eine andere Art von Antriebssystem. Das Antriebssystem 850 kann mit einem Antriebsstrang des Fahrzeugs 800 verbunden sein, der ein Getriebe beinhalten kann, um den Antrieb des Fahrzeugs 800 zu ermöglichen. Das Antriebssystem 850 als Reaktion auf den Empfang von Signalen von der Drossel/dem Fahrpedal (852) gesteuert werden.
Ein Lenksystem 854, das ein Lenkrad beinhalten kann, kann verwendet werden, um das Fahrzeug 800 zu lenken (z. B. entlang eines angestrebten Pfads oder einer angestrebten Route), wenn das Antriebssystem 850 in Betrieb ist (z. B., wenn das Fahrzeug in Bewegung ist). Das Lenksystem 854 kann Signale von einem Lenkungsaktor 856 empfangen. Für die vollständige Automatisierungsfunktionalität (Level 5) kann das Lenkrad optional sein.
Das Bremssensorsystem 846 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf den Empfang von Signalen von den Bremsaktoren 848 und/oder Bremssensoren zu betreiben.
Die Steuerung(en) 836, die ein oder mehrere System-on-Chips (SoCs) 804 (8C) und/oder GPU(s) beinhalten können, können Signale (z. B. in Form von Befehlen) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 800 bereitstellen. Beispielsweise können die Steuerung(en) Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktuatoren 848, zur Betätigung des Lenksystems 854 über einen oder mehrere Lenkaktuatoren 856 und zur Betätigung des Antriebssystems 850 über einen oder mehrere Drossel-/Beschleunigungsregler 852 senden. Die Steuerung(en) 836 können eine oder mehrere bordeigene (z. B. integrierte) Rechenvorrichtungen (z. B. Supercomputer) beinhalten, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z. B. Signale, die Befehle darstellen), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Führen des Fahrzeugs 800 zu unterstützen. Die Steuerung(en) 836 können eine erste Steuerung 836 für Funktionen des autonomen Fahren, eine zweite Steuerung 836 für funktionelle Sicherheitsfunktionen, eine dritte Steuerung 836 für eine Funktionalität der künstlichen Intelligenz (z. B. maschinelles Sehen), eine vierte Steuerung 836 für eine Infotainment-Funktionalität, eine fünfte Steuerung 836 für Redundanz in Notfällen und/oder andere Controller beinhalten. In einigen Beispielen kann eine einzelne Steuerung 836 zwei oder mehrere der vorstehenden Funktionalitäten handhaben, können zwei oder mehr Steuerungen 836 eine einzelne Funktionalität handhaben und/oder eine beliebige Kombination davon.
Die Steuerung(en) 836 können die Signale zum Steuern einer/eines oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 800 als Reaktion auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren empfangen werden (z. B. Sensoreingaben). Die Sensordaten zum Beispiel und ohne Einschränkung empfangen werden von Sensor(en) 858 von globalen Navigationssatellitensystemen (z. B. Sensor(en) des globalen Positionsbestimmungssystems), RADAR-Sensor(en) 860, Ultraschallsensor(en) 862, LiDAR-Sensor(en) 864, Sensor(en) 866 einer Trägheitsmesseinheit (inertial measurement unit - „IMU“) (z. B. (einem) Beschleunigungsmesser, Gyroskop(en), Magnetkompass(en), (einem) Magnetometer usw.), Mikrofon(en) 896, Stereokamera(s) 868, Weitsichtkamera(s) 870 (z. B. Fischaugenkameras), Infrarotkamera(s) 872, Rundumkamera(s) 874 (z. B. 360-Grad-Kameras), Langstreckenkameras und/oder Mittelstreckenkamera(s) 898, Geschwindigkeitssensor(en) 844 (z. B. zum Messen der Geschwindigkeit des Fahrzeugs 800), Vibrationssensor(en) 842, Lenksensor(en) 840, Bremssensor(en) (z. B. als Teil des Bremssensorsystems 846) und/oder anderen Sensorarten.
Eine oder mehrere der Steuerung(en) 836 können Eingaben (z. B. durch Eingabedaten dargestellt) von einem Kombiinstrument 832 des Fahrzeugs 800 empfangen und Ausgaben (z. B. durch Ausgabedaten, Anzeigedaten usw. dargestellt) über eine Anzeige 834 einer Mensch-Maschine-Schnittstelle (humanmachine interface - HMI), einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 800 bereitstellen. Die Ausgaben können Informationen wie Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Kartendaten (z. B. die HD-Karte 822 von 8C), Positionsdaten (z. B. die Position des Fahrzeugs 800, z. B. auf einer Karte), Richtung, Position anderer Fahrzeuge (z. B. ein Belegungsgitter), Informationen über Objekte und den Status von Objekten, wie von der/den Steuerung(en) 836 wahrgenommen, usw. beinhalten. Beispielsweise kann die HMI-Anzeige 834 Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. eines Straßenschilds, eines Warnschilds, einer sich ändernden Ampel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z. B. jetzt die Spur wechseln, in zwei Meilen die Ausfahrt 34B nehmen usw.).
Das Fahrzeug 800 beinhaltet ferner eine Netzschnittstelle 824, die eine oder mehrere drahtlose Antenne(n) 826 und/oder Modem(s) zum Kommunizieren über ein oder mehrere Netze verwenden kann. Die Netzwerkschnittstelle 824 kann beispielsweise die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. ermöglichen. Die drahtlose(n) Antenne(n) 826 kann/können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Vorrichtungen usw.) über lokale Netzwerke wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Low Power Wide Area Network(s) (LPWANs) wie LoRaWAN, SigFox usw. ermöglichen.
8B ist ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug 800 aus 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die entsprechenden Sichtfelder stellen eine beispielhafte Ausführungsform dar und sind nicht als einschränkend aufzufassen. Zum Beispiel können zusätzliche und/oder alternative Kameras enthalten sein und/oder können sich die Kameras an unterschiedlichen Positionen am Fahrzeug 800 befinden.
Die Kameratypen für die Kameras können Digitalkameras beinhalten, ohne darauf beschränkt zu sein, die zur Verwendung mit Komponenten und/oder Systemen des Fahrzeugs 800 ausgelegt sind. Die Kamera(s) können mit dem Automobilsicherheitsintegritätslevel (automotive safety integrity level - ASIL) B und/oder mit einem anderen ASIL betrieben werden. Die Kameratypen können in Abhängigkeit von der Ausführungsform zu einer beliebigen Bildaufnahmerate in der Lage sein, wie z. B. 60 Bilder pro Sekunde (frames per second - fps), 120 fps, 240 fps usw. Die Kameras können in der Lage sein, Rollblendenverschlüsse, globale Blendenverschlüsse, eine andere Art von Blendenverschluss oder eine Kombination davon zu verwenden. In einigen Beispielen kann die Farbfilteranordnung eine Rot-Klar-Klar-Klar (red clear clear clear - RCCC)-Farbfilteranordnung, eine Rot-Klar-Klar-Blau (red clear clear blue - RCCB)-Farbfilteranordnung, eine Rot-Blau-Grün-Klar (red blue green clear - RBGC)-Farbfilteranordnung, eine Foveon-X3-Farbfilteranordnung, ein Bayer-Sensoren (RGGB)-Farbfilteranordnung, eine Monochrom-Sensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung beinhalten. In einigen Ausführungsformen können Klarpixelkameras, wie zum Beispiel Kameras mit einer RCCC-, einer RCCB- und/oder einer RBGC-Farbfilteranordnung, in einem Bestreben zur Erhöhung der Lichtempfindlichkeit verwendet werden.
In einigen Ausführungsformen können eine oder mehrere der Kamera(s) verwendet werden, um Funktionen der weiterentwickelten Fahrerassistenzsysteme (advanced driver assistance systems - ADAS) durchzuführen (z. B. als Teil einer redundanten oder ausfallsicheren Ausgestaltung). Zum Beispiel kann eine Multifunktions-Monokamera installiert sein, die Funktionen wie Spurverlassenswarnung, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitstellt. Eine oder mehrere der Kamera(s) (z. B. alle Kameras) können simultan Bilddaten (z. B. ein Video) aufnehmen und bereitstellen.
Eine oder mehrere der Kameras in einer Montagebaugruppe, z. B. einer kundenspezifisch entworfenen (3-D-gedruckten) Baugruppe, montiert sein, um Streulicht und Reflexionen aus dem Inneren des Autos (z. B. Reflexionen vom Armaturenbrett, die sich in den Windschutzscheibenspiegeln spiegeln) auszuschließen, welche die Bilddatenerfassungsfähigkeiten der Kamera beeinträchtigen können. Unter Bezugnahme auf Seitenspiegelmontagebaugruppen können die Seitenspiegelbaugruppen kundenspezifisch 3-D-gedruckt werden, sodass die Kameramontageplatte mit der Form des Seitenspiegels übereinstimmt. In einigen Beispielen kann die Kamera(s) in den Seitenspiegel integriert sein. Bei Seitensichtkameras können die Kamera(s) in den vier Säulen an jeder Ecke des Fahrerhauses integriert sein.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung vor dem Fahrzeug 800 beinhaltet (z. B. nach vorn gerichtete Kameras), für die Rundumsicht verwendet werden, um dabei zu helfen, nach vorn gerichtete Pfade und Hindernisse zu identifizieren, sowie mit der Hilfe einer oder mehrerer Steuerungen 836 und/oder Steuer-SoCs beim Bereitstellen von Informationen zu helfen, die für die Erzeugung eines Belegungsgitters und/oder die Bestimmung der bevorzugten Fahrzeugpfade entscheidend sind. Nach vorn gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LiDAR auszuführen, einschließlich, Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorn gerichtete Kameras können auch für ADAS-Funktionen und -Systeme verwendet werden, einschließlich, Spurverlassenswarnungen (Lane Departure Warning - „LDW“), autonome Geschwindigkeitssteuerung (Autonomous Cruise Control - „ACC“) und/oder andere Funktionen wie Verkehrszeichenerkennung.
Eine Vielfalt an Kameras kann in einer nach vorn gerichteten Konfiguration verwendet werden, einschließlich zum Beispiel einer monokularen Kameraplattform, die einen Farbbildsensor mit CMOS (complementary metal oxide semiconductor - komplementärer Metalloxid-Halbleiter) beinhaltet. Ein weiteres Beispiel kann/können eine Weitsichtkamera(s) 870 sein, die verwendet werden kann/können, um Objekte wahrzunehmen, die aus der Peripherie ins Blickfeld kommen (z. B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl in 8B nur eine Weitwinkelkamera dargestellt ist, kann eine beliebige Anzahl von Weitwinkelkameras 870 am Fahrzeug 800 vorhanden sein. Zusätzlich können Langstreckenkamera(s) 898 (z. B. ein Weitsichtstereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die noch kein neuronales Netzwerk trainiert wurde. Die Langstreckenkamera(s) 898 können auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
Eine oder mehrere Stereokameras 868 können auch in einer nach vorne gerichteten Konfiguration beinhaltet sein. Die Stereokamera(s) 868 können eine integrierte Steuereinheit beinhalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten CAN- oder Ethernet-Schnittstelle auf einem einzelnen Chip bereitstellen kann. Mit einer solchen Einheit kann eine 3-D-Karte der Fahrzeugumgebung erstellt werden, die auch eine Entfernungsschätzung für alle Punkte im Bild beinhaltet. Eine oder mehrere alternative Stereokamera(s) 868 können (einen) kompakte(n) Stereosichtsensor(en) beinhalten, die zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip beinhalten können, der den Abstand von dem Fahrzeug zu dem Zielobjekt messen und die erzeugten Informationen (z. B. Metadaten) verwenden kann, um autonome Notbrems- und Spurverlassenswarnfunktionen zu aktivieren. Andere Arten von Stereokamera(s) 868 können zusätzlich oder alternativ zu den hierin beschriebenen verwendet werden.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung seitlich des Fahrzeugs 800 beinhaltet (z. B. Seitensichtkameras), können für die Rundumsicht verwendet werden, wodurch Informationen bereitgestellt werden, die zum Erstellen und Aktualisieren des Belegungsgitters sowie zum Erzeugen von Seitenaufprallkollisionswarnungen verwendet werden. Zum Beispiel können die Umgebungskamera(s) 874 (z. B. vier Umgebungskameras 874, wie in 8B) auf dem Fahrzeug 800 positioniert werden. Die Umgebungskamera(s) 874 kann/können Weitwinkelkamera(s) 870, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches beinhalten. So können beispielsweise vier Fischaugenkameras an der Vorderseite, am Heck und an den Seiten des Fahrzeugs angebracht werden. In einer alternativen Anordnung kann das Fahrzeug drei Rundumkamera(s) 874 (z. B. links, rechts und hinten) verwenden und kann eine oder mehrere andere Kamera(s) (z. B. eine nach vorn gerichtete Kamera) als eine vierte Rundumsichtkamera nutzen.
Kameras mit einem Sichtfeld, das Abschnitte der Umgebung hinter dem Fahrzeug 800 einschließt (z. B. Rückfahrkameras), können als Einparkhilfe, für die Rundumsicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsgitters verwendet werden. Eine Vielfalt von Kameras kann verwendet werden, einschließlich, aber nicht beschränkt auf, Kameras, die auch als nach vorn gerichtete Kamera(s) geeignet sind (z. B. Langstreckenkameras und/oder Mittelstreckenkamera(s) 898, Stereokamera(s) 868), Infrarotkamera(s) 872 usw.), wie hierin beschrieben.
8C ist ein Blockdiagramm einer Beispiel-Systemarchitektur des beispielhaften autonomen Fahrzeugs 800 von 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.
Jede der Komponenten, Merkmale und Systeme des Fahrzeugs 800 sind in 8C so dargestellt, dass sie über den Bus 802 verbunden sind. Der Bus 802 kann eine Controller Area Network (CAN)-Datenschnittstelle beinhalten (hier alternativ als „CAN-Bus“ bezeichnet). Ein CAN kann ein Netzwerk innerhalb des Fahrzeugs 800 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 800 verwendet wird, wie z. B. Betätigung der Bremsen, Beschleunigung, Bremsen, Lenkung, Scheibenwischer usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten aufweist, jeder mit seiner eigenen eindeutigen Kennung (z. B. eine CAN-ID). Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, Grundgeschwindigkeit, die Umdrehungen des Motors pro Minute (revolutions per minute - RPMs), Tastenpositionen und/oder andere Fahrzeugstatusindikatoren zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.
Obwohl der Bus 802 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können zusätzlich zu oder alternativ zu dem CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Obwohl der Bus 802 mit einer einzigen Linie dargestellt wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel kann eine beliebige Anzahl von Bussen 802 vorhanden sein, die einen oder mehr CAN-Busse, einen oder mehr FlexRay-Busse, einen oder mehr Ethernet-Busse und/oder einen oder mehr andere Arten von Bussen mit einem anderen Protokoll beinhalten können. In einigen Beispiel können zwei oder mehr Busse 802 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder können sie zur Redundanz verwendet werden. Zum Beispiel kann ein erster Bus 802 für die Kollisionsvermeidungsfunktionalität verwendet werden und kann ein zweiter Bus 802 für die Antriebssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 802 mit beliebigen Komponenten des Fahrzeugs 800 kommunizieren und können zwei oder mehr Busse 802 mit denselben Komponenten kommunizieren. In einigen Beispielen können jedes SoC 804, jede Steuerung 836 und/oder jeder Computer im Fahrzeug Zugriff auf dieselben Eingabedaten (z. B. Eingaben von Sensoren des Fahrzeugs 800) haben und mit einem gemeinsamen Bus, wie z. B. dem CAN-Bus, verbunden sein.
Das Fahrzeug 800 kann eine oder mehrere Steuerung(en) 836 beinhalten, wie etwa diejenigen, die hierin in Bezug auf 8A. Die Steuerung(en) 836 können für eine Vielfalt von Funktionen verwendet werden. Die Steuerung(en) 836 können mit beliebigen der verschiedenen anderen Komponenten und Systemen des Fahrzeugs 800 gekoppelt sein und können sie zur Steuerung des Fahrzeugs 800, der künstlichen Intelligenz des Fahrzeugs 800, des Infotainment für das Fahrzeug 800 und/oder dergleichen verwendet werden.
Das Fahrzeug 800 kann ein System (oder mehrere Systeme) auf einem Chip (SoC) 804 beinhalten. Das SoC 804 kann CPU(s) 806, GPU(s) 808, Prozessor(en) 810, Cache(s) 812, Beschleuniger 814, Datenspeicher 816 und/oder andere nicht dargestellte Komponenten und Funktionen beinalten. Das/die SoC(s) 804 können zur Steuerung des Fahrzeugs 800 in einer Vielfalt von Plattformen und Systemen verwendet werden. Beispielsweise können die SoC(s) 804 in einem System (z. B. dem System des Fahrzeugs 800) mit einer HD-Karte 822 kombiniert werden, die über eine Netzwerkschnittstelle 824 von einem oder mehreren Servern (z. B. dem/den Server(n) 878 von 8D) Aktualisierungen der Karte erhalten kann.
Die CPU(s) 806 können einen CPU-Cluster oder CPU-Komplex (hierin alternativ als „CCPLEX“ bezeichnet) beinhalten. Die CPU(s) 806 können mehrere Kerne und/oder L2-Caches beinhalten. Zum Beispiel können in einigen Ausführungsformen die CPU(s) 806 acht Kerne in einer kohärenten Mehrprozessorkonfiguration beinhalten. In einigen Ausführungsform können die CPU(s) 806 vier Doppelkerncluster beinhalten, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z. B. einen L2-Cache mit 2 MB). Die CPU(s) 806 (z. B. CCPLEX) können so konfiguriert sein, dass sie den simultanen Clusterbetrieb unterstützen, sodass eine beliebige Kombination von den Clustern von den CPU(s) 806 zu einem beliebigen gegebenen Zeitpunkt aktiv sein kann.
Die CPU(s) 806 können Leistungsverwaltungsfähigkeiten implementieren, die eines oder mehrere der folgenden Merkmale beinhalten: einzelne Hardwareblöcke können automatisch taktgesteuert werden, wenn sie inaktiv sind, um dynamische Leistung zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI-/WFE-Anweisungen keine Anweisungen aktiv ausführt; jeder Kern kann unabhängig leistungsgesteuert sein; jeder Kerncluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder leistungsgesteuert sind; und/oder jeder Kerncluster kann unabhängig leistungsgesteuert sein, wenn alle Kerne leistungsgesteuert sind. Die CPU(s) 806 können ferner einen erweiterten Algorithmus zur Verwaltung von Leistungsstatus implementieren, bei dem zulässige Leistungsstatus und erwartete Aufwachzeiten spezifiziert werden und die Hardware/der Mikrocode den besten Leistungsstatus bestimmt, in den für den Kern, Cluster und CCPLEX einzutreten ist. Die Verarbeitungskerne können vereinfachte Leistungsstatus-Eintragssequenzen in der Software unterstützen, wobei die Arbeit in den Mikrocode ausgelagert wird.
Die GPU(s) 808 können eine integrierte GPU (hierin alternativ als „iGPU“ bezeichnet) beinhalten. Die GPU(s) 808 können programmierbar sein und für parallele Arbeitslasten effizient sein. Die GPU(s) 808 können in einigen Beispielen einen erweiterten Tensor-Anweisungssatz verwenden. Die GPU(s) 808 einen oder mehrere Streaming-Mikroprozessoren beinhalten, wobei jeder Streaming-Mikroprozessor einen L1-Cache beinhalten kann (z. B. einen L1-Cache mit einer Speicherkapazität von mindestens 96 KB), und zwei oder mehr der Streaming-Mikroprozessoren können einen L2-Cache gemeinsam nutzen (z. B. einen L2-Cache mit einer Speicherkapazität von 812 KB). In einigen Ausführungsformen können die GPU(s) 808 mindestens acht Streaming-Mikroprozessoren beinhalten. Die GPU(s) 808 können (eine) Berechnungs-Anwendungsprogrammierschnittstelle(n) (API(s)) verwenden. Zusätzlich können die GPU(s) 808 eine oder mehrere Parallelrechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA Corporation) verwenden.
Die GPU(s) 808 können für die beste Rechenleistung in Automobil- und eingebetteten Anwendungsfällen leistungsoptimiert sein. Die GPU(s) 808 können zum Beispiel auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Dies ist jedoch nicht als Einschränkung zu verstehen, und die GPU(s) 808 können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von Verarbeitungskernen mit gemischter Genauigkeit beinhalten, die in mehrere Blöcke partitioniert sind. Zum Beispiel, und ohne Einschränkung, könnten 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke partitioniert sein. In solch einem Beispiel könnten jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Genauigkeit für Deep-Learning-Matrixarithmetik, ein L0" Anweisungs-Cache, ein Warp-Planer, eine Verteilungseinheit und/oder eine Registerdatei mit 64 KB zugewiesen sein. Zusätzlich können Streaming-Mikroprozessoren unabhängige parallele Integer- und Fließkomma-Datenpfade beinhalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnung und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfunktion beinhalten, um eine feinkörnigere Synchronisation und Kooperation zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können eine Einheit aus kombiniertem L1-Daten-Cache und gemeinsam genutztem Speicher beinhalten, um die Performance zu verbessern, während die Programmierung vereinfacht wird.
Die GPU(s) 808 können einen Speicher mit hoher Bandbreite (high bandwidth memory - HBM) und/oder ein 16-GB-HBM2-Speicherteilsystem beinhalten, um in einigen Beispielen eine Spitzenspeicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispiel kann zusätzlich oder alternativ zum HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher („SGRAM“) verwendet werden, z. B. ein synchroner Grafik-Double-Data-Rate-Typ-Fünf-Direktzugriffsspeicher („GDDR5“).
Die GPU(s) 808 kann/können eine einheitliche Speichertechnologie mit Zugriffszählern beinhalten , die eine genauere Zuweisung von Speicherseiten an den Prozessor ermöglicht, der am häufigsten darauf zugreift, und so die Effizienz von Speicherbereichen verbessert, die von mehreren Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (address translation services - ATS) verwendet werden, um zu ermöglichen, dass die GPU(s) 808 direkt auf die Seitentabellen von CPU(s) 806 zugreifen. In derartigen Beispielen, wenn die Speicherverwaltungseinheit (MMU) der GPU(s) 808 eine Auslassung erleidet, kann eine Adressübersetzungsanforderung an die CPU(s) 806 übertragen werden. Als Reaktion darauf können die CPU(s) 806 iin ihren Seitentabellen nach einer Virtuell-zu-Physisch-Zuordnung für die Adresse suchen und die Übersetzung zurück an die GPU(s) 808 übertragen. Daher kann die einheitliche Speichertechnologie einen einzelnen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 806 als auch der GPU(s) 808 ermöglichen, wodurch die Programmierung der GPU(s) 808 und die Portierung von Anwendungen auf die GPU(s) 808 vereinfacht werden.
Zusätzlich können die GPU(s) 808 einen Zugriffszähler beinhalten, der die Häufigkeit des Zugriffs der GPU(s) 808 auf Speicher anderer Prozessoren nachverfolgen können. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher des Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
Die SoC(s) 804 können eine beliebige Anzahl von Cache(s) 812 beinhalten, einschließlich der hierin beschriebenen. Der/die Cache(s) 812 kann/können beispielsweise einen L3-Cache beinhalten, der sowohl der/den CPU(s) 806 als auch der/den GPU(s) 808 zur Verfügung steht (z. B. der sowohl mit der/den CPU(s) 806 als auch mit der/den GPU(s) 808 verbunden ist). Der/die Cache(s) 812 können einen Rückschreib-Cache beinhalten, der die Status von Zeilen verfolgen kann, wie z. B. durch die Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann in Abhängigkeit von der Ausführungsform 4 MB oder mehr beinhalten, obwohl auch kleinere Cache-Größen verwendet werden können.
Der/die SoC(s) 804 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) beinhalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der vielen Aufgaben oder Operationen des Fahrzeugs 800 - wie z. B. der Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus können die SoC(s) 804 eine oder mehrere Gleitkommaeinheiten (floating point units - FPU(s)) - oder andere mathematische Coprozessoren oder numerische Coprozessoren - zur Durchführung mathematischer Operationen innerhalb des Systems beinhalten. Zum Beispiel können die SoC(s) 104 eine oder mehrere FPUs beinhalten, die als Ausführungseinheiten in einer oder mehreren CPU(s) 806 und/oder GPU(s) 808 integriert sind.
Die SoC(s) 804 können einen oder mehrere Beschleuniger 814 beinhalten (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Zum Beispiel können das/die SoC(s) 804 einen Hardware-Beschleunigungscluster beinhalten, der optimierte Hardware-Beschleuniger und/oder einen großen chipinternen Speicher beinhalten kann. Der große chipinterne Speicher (z. B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster zum Beschleunigen neuronaler Netze und anderer Berechnungen ermöglichen. Der Hardware-Beschleunigungscluster kann verwendet werden, um die GPU(s) 808 zu ergänzen und einige Tasks der GPU(s) 808 auszulagern (um z. B. mehr Zyklen der GPU(s) 808 für die Durchführung anderer Tasks freizumachen). Als Beispiel können der/die Beschleuniger 814 für zielgerichtete Arbeitslasten (z. B. Wahrnehmung, neuronale Faltungsnetzwerke (CNNs usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der Begriff „CNN“, wie er hier verwendet wird, kann alle Arten von CNNs umfassen, einschließlich regionenbasierter oder regionaler neuronaler Faltungsnetzwerke (RCNNs) und Fast RCNNs (z. B. für die Objekterkennung).
Der/die Beschleuniger 814 können (z. B. Hardware-Beschleunigungscluster) (einen) Deep-Learning-Beschleuniger (deep learning accelerator(s) - DLA(s)) beinhalten. Die DLA(s) können eine oder mehrere Tensor-Verarbeitungseinheiten (TPU(s)) beinhalten, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Vorgänge pro Sekunde für Deep-Learning-Anwendungen und -Ableitung bereitstellen. Die TPUs können Beschleuniger sein, die zum Durchführen von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Die DLA(s) können ferner für einen spezifischen Satz von Arten von neuronalen Netzwerken und Fließkommavorgängen sowie für die Ableitung optimiert sein. Das Design der DLA(s) kann mehr Performance pro Millimeter bereitstellen als eine typische Universal-GPU und übertrifft die Performance einer CPU bei weitem. Die TPU(s) können mehrere Funktionen durchführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datenarten sowohl für Merkmale als auch für Gewichtungen unterstützt, sowie Postprozessorfunktionen.
Die DLA(s) können neuronale Netzwerke, insbesondere CNNs, an verarbeiteten oder unverarbeiteten Daten für eine Vielfalt von Funktionen schnell und effizient ausführen, darunter zum Beispiel und ohne Einschränkung: ein CNN für die Identifizierung und Erkennung von Objekten unter Verwendung von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Erkennung und Identifizierung und Erkennung von Einsatzfahrzeugen unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und Identifizierung von Fahrzeugbesitzern unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsrelevante Ereignisse.
Die DLA(s) können eine beliebige Funktion der GPU(s) 808 durchführen und durch Verwenden eines Inferenzbeschleunigers kann ein Designer zum Beispiel entweder die DLA(s) oder die GPU(s) 808 für eine beliebige Funktion anvisieren. Der Designer kann beispielsweise die Verarbeitung von CNNs und Fließkommavorgängen auf die DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 808 und/oder anderen Beschleuniger(n) 814 überlassen.
Der/die Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) können (einen) programmierbare(n) Sichtbeschleuniger (programmable vision accelerator - „PVA“) beinhalten, der hierin alternativ als ein Beschleuniger für maschinelles Sehen bezeichnet werden kann. Die PVA(s) können zur Beschleunigung von Algorithmen des maschinellen Sehens für weiterentwickelte Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder Augmented-Reality (AR)-Anwendungen und/oder Virtual-Reality (VR)-Anwendungen konstruiert und konfiguriert sein. Die PVA(s) können ein Gleichgewicht zwischen Performance und Flexibilität bereitstellen. Beispielswiese können alle PVA(s) und ohne Einschränkung eine beliebige Anzahl von Reduced-Instruction-Set-Computer (RISC)-Kerne, direkten Speicherzugriff (direct memory access - DMA) und/oder eine beliebige Anzahl von Vektorprozessoren beinhalten.
Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren einer beliebigen der hierin beschriebenen Kameras), Bildsignalprozessor(en) und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher beinhalten. Die RISC-Kerne können in Abhängigkeit von der Ausführungsform ein beliebiges von einer Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (real-time operating system - RTOS) ausführen. Die RISC-Kerne können unter Verwendung einer oder mehrerer Vorrichtungen für integrierte Schaltungen, anwendungsspezifischer integrierter Schaltungen (ASICs) und/oder Speichervorrichtungen implementiert sein. Die RISC-Kerne können beispielsweise einen Anweisungs-Cache und/oder einen eng gekoppelten RAM beinhalten.
Der DMA kann es den Komponenten des/der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 806 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Merkmalen unterstützen, die zum Bereitstellen der Optimierung des PVA verwendet werden, einschließlich der Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung, ohne darauf beschränkt zu sein. In einigen Beispiel kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die Blockbreite, Blockhöhe, Blocktiefe, horizontale Blockabstufung, vertikale Blockabstufung und/oder Tiefenabstufung beinhalten können.
Die Vektorprozessoren können programmierbare Prozessoren sein, die so ausgestaltet sein können, dass sie die Programmierung für Algorithmen des maschinellen Sehens effizient und flexibel ausführen und Signalverarbeitungsfähigkeiten bereitstellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungsteilsystempartitionen beinhalten. Der PVA-Kern kann ein Prozessorteilsystem, DMA-Engine(s) (z. B. zwei DMA-Engines) und/oder andere Peripheriegeräte beinhalten. Das Vektorverarbeitungsteilsystem kann als primäre Verarbeitungs-Engine des PVA arbeiten und kann eine Vektorverarbeitungseinheit (vector processing unit - VPU), einen Anweisungs-Cache und/oder einen Vektorspeicher (z. B. VMEM) beinhalten. Ein VPU-Kern kann einen digitalen Signalprozessor beinhalten, wie zum Beispiel einen digitalen Single-Instruction-Multiple-Data-(SIMD-)Very-Long-Instruction-Word-(VLIW-)Signalprozessor. Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
Jeder der Vektorprozessoren kann einen Anweisungs-Cache beinhalten und an dedizierten Speicher gekoppelt sein. Daher kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren ausgeführt wird. In anderen Beispielen können Vektorprozessoren, die in einem konkreten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität einsetzen. Zum Beispiel kann in einigen Ausführungsformen die Vielzahl von Vektorprozessoren, die in einem einzelnen PVA enthalten ist, denselben Algorithmus des maschinellen Sehens ausführen, jedoch an unterschiedlichen Regionen eines Bildes. In anderen Beispielen können die in einem konkreten PVA enthaltenen Vektorprozessoren simultan unterschiedliche Algorithmen des maschinellen Sehens an demselben Bild ausführen oder sogar unterschiedliche Algorithmen an sequentiellen Bildern oder Abschnitten eines Bildes ausführen. Unter anderem eine beliebige Anzahl von PVAs in dem Hardware-Beschleunigungscluster enthalten sein und kann eine beliebige Anzahl von Vektorprozessoren in jedem der PVAs enthalten sein. Zusätzlich können der/die PVA(s) einen zusätzlichen Fehlerkorrekturcode (ECC)-Speicher beinhalten, um die Gesamtsystemsicherheit zu erhöhen.
Der/die Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) können ein Netzwerk auf dem Chip für maschinelles Sehen und einen SRAM beinhalten, um einen SRAM mit hoher Bandbreite und niedriger Latenz für den/die Beschleuniger 814 bereitzustellen. In einigen Beispielen kann der chipinterne Speicher mindestens 4 MB SRAM beinhalten, der z. B. und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine weiterentwickelte Peripheriebus (advanced peripheral bus - APB)-Schnittstelle, eine Konfigurationsschaltung, eine Steuerung und einen Multiplexer beinhalten. Es kann jede Art von Speicher verwendet werden. Der PVA und DLA können auf den Speicher über einen Backbone zugreifen, der dem PVA und DLA einen Hochgeschwindigkeitszugriff auf den Speicher bereitstellt. Der Backbone kann ein Netzwerk auf dem Chip für maschinelles Sehen beinhalten, das den PVA und DLA mit dem Speicher verbindet (z. B. unter Verwendung von dem APB).
Das Netzwerk kann auf dem Chip für maschinelles Sehen eine Schnittstelle beinhalten, die vor der Übertragung eines beliebigen Steuersignals/einer beliebigen Adresse/ beliebiger Daten bestimmt, dass sowohl der PVA als auch der DLA einsatzbereite und gültige Signale bereitstellen. Eine derartige Schnittstelle kann separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-artige Kommunikation für eine kontinuierliche Datenübertragung bereitstellen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, obwohl auch andere Normen und Protokolle verwendet werden können.
In einigen Beispielen können die SoC(s) 804 einen Echtzeit-Raytracing-Hardware-Beschleuniger enthalten, wie er in der US-Patentanmeldung Nr. 16/101,232 , eingereicht am 10. August 2018, beschrieben ist. Der Echtzeit-Raytracing-Hardware-Beschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeitvisualisierungssimulationen zu erzeugen, für die RADAR-Signalinterpretation, für die Schallausbreitungssynthese und/oder - analyse, für die Simulation von SONAR-Systemen, für die allgemeine Wellenausbreitungssimulation, für den Vergleich mit LiDAR-Daten zum Zwecke der Lokalisierung und/oder für andere Funktionen und/oder für andere Anwendungen. In einigen Ausführungsformen können eine oder mehrere Tree Traversal Units (TTUs) für die Ausführung einer oder mehrerer Raytracingbezogener Operationen verwendet werden.
Der/die Beschleuniger 814 (z. B. der Hardware-Beschleunigercluster) weisen ein breites Spektrum von Verwendungen für das autonome Fahren auf. Der PVA kann ein programmierbarer Sichtbeschleuniger sein, der für wichtige Verarbeitungsstufen im ADAS und in autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten des PVA sind eine gute Ergänzung für algorithmische Domänen, die eine vorhersagbare Verarbeitung bei niedriger Leistung und niedriger Latenz benötigen. Anders ausgedrückt zeigt der PVA eine gute Performance für halbdichte oder dichte reguläre Berechnungen, auch an kleinen Datensätzen, die vorhersagbare Laufzeiten mit niedriger Latenz und niedriger Leistung benötigen. Folglich sind die PVAs im Zusammenhang mit Plattformen für autonome Fahrzeuge für die Ausführung klassischer Algorithmen für maschinelles Sehen konstruiert, da diese effizient bei der Objekterkennung sind und mit Integer-Mathematik arbeiten.
Zum Beispiel wird gemäß einer Ausführungsform der Technologie der PVA verwendet, um maschinelles Stereo-Sehen durchzuführen. Ein auf semiglobalem Abgleich basierender Algorithmus kann verwendet werden, obwohl dies nicht als Einschränkung auszulegen ist. Viele Anwendungen für das autonome Fahren auf Level 3-5 erfordern Bewegungsschätzung/ Stereo-Abgleich spontan (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Der PVA kann eine Funktion des maschinellen Stereo-Sehens an Eingaben von zwei monokularen Kameras durchführen. In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Gemäß der Verarbeitung von RADAR-Rohdaten (z. B. mit einer 4D-Fast-Fourier-Transformation) zur Bereitstellung von verarbeitetem RADAR. In anderen Beispielen wird der PVA für die Laufzeit-Tiefenverarbeitung verwendet, indem z. B. Laufzeit-Rohdaten verarbeitet werden, um verarbeitete Laufzeitdaten bereitzustellen.
Der DLA kann verwendet werden, um eine beliebige Art von Netzwerk auszuführen, um die Steuerung und Fahrsicherheit zu verbessern, einschließlich zum Beispiel ein neuronales Netzwerk, das ein Maß an Konfidenz für jede Objekterkennung ausgibt. Ein derartigre Konfidenzwert kann als eine Wahrscheinlichkeit interpretiert werden oder als Bereitstellung einer relativen „Gewichtung“ jeder Erkennung im Vergleich zu anderen Erkennungen. Der Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als richtig positive Erkennungen und nicht als falsch positive Erkennungen betrachtet werden sollten. Zum Beispiel kann das System einen Schwellenwert für die Konfidenz festlegen und nur Erkennungen, die den Schwellenwert überschreiten, als richtig positive Erkennungen betrachten. In einem automatischen Notbrems (automatic emergency braking - AEB)-System würden falsch positive Erkennungen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was natürlich unerwünscht ist. Daher sollten nur die sichersten Entdeckungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netzwerk zur Regression des Konfidenzwerts ausführen. Das neuronale Netzwerk kann als seine Eingabe mindestens eine Teilmenge von Parametern verwenden, wie z. B. die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Teilsystem) erhaltene Bodenebenenschätzung, die Ausgabe von Inertial Measurement Unit (IMU)-Sensor 866, die mit der Ausrichtung des Fahrzeugs 800 korreliert, den Abstand, die 3D-Positionsschätzungen des Objekts, die vom neuronalen Netzwerk und/oder anderen Sensoren (z. B. LiDAR-Sensor(en) 864 oder RADAR-Sensor(en) 860) erhalten werden, usw.
Der/die SoC(s) 804 kann/können Datenspeicher 816 (z. B. Speicher) enthalten. Bei den Datenspeicher(n) 816 kann es sich um den chipinternen Speicher der SoC(s) 804 handeln, der neuronale Netze speichern kann, die auf den GPU(s) und/oder dem DLA ausgeführt werden sollen. In einigen Beispiel kann die Kapazität des/der Datenspeicher(s) 816 groß genug sein, um mehrere Instanzen von neuronalen Netzwerken zur Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 812 können L2 oder L3 Cache(s) 812 umfassen. Der Verweis auf den/die Datenspeicher 816 kann einen Verweis auf den Speicher beinhalten, der dem PVA, DLA und/oder anderen Beschleunigern 814 zugeordnet ist, wie hier beschrieben.
Der/die SoC(s) 804 kann/können einen oder mehrere Prozessor(en) 810 (z. B. eingebettete Prozessoren) enthalten. Der/die Prozessor(en) 810 können einen Booting- und Leistungsverwaltungsprozessor beinhalten, der ein dedizierter Prozessor und ein Teilsystem sein kann, um die Booting-Leistungs- und - verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Booting- und Leistungsverwaltungsprozessor kann ein Teil der Booting-Sequenz des/der SoC(s) 804 sein und Laufzeit-Leistungsverwaltungsdienste bereitstellen. Der Booting-Leistungs- und - verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Übergängen des Systems in einen Status mit niedriger Leistung, Verwaltung von Thermik und Temperatursensoren des/der SoC(s) 804 und/oder Verwaltung von Leistungsstatus des/der SoC(s) 804 bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und können das/die SoC(s) 804 Ringoszillatoren verwenden, um Temperaturen von den CPU(s) 806, GPU(s) 808 und/oder Beschleuniger(n) 814 zu erkennen. Wenn bestimmt wird, dass Temperaturen einen Schwellenwert überschreiten, kann der Booting- und Leistungsverwaltungsprozessor dann in eine Temperaturfehlerroutine eintreten und den/die SoC(s) 804 in einen Status mit niedrigerer Leistung versetzen und/oder das Fahrzeug 800 in einen Modus des Chauffierens zu einem sicheren Halt versetzen (z. B. das Fahrzeug 800 zu einem sicheren Halt bringen).
Der/die Prozessor(en) 810 können ferner einen Satz von eingebetteten Prozessoren beinhalten, die als eine Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audioteilsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen sowie eine breite und flexible Palette von Audio-I/O-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
Der/die Prozessor(en) 810 können ferner eine stets eingeschaltete Prozessor-Engine beinhalten, welche die notwendigen Hardware-Merkmale zur Unterstützung der Sensorverwaltung mit niedriger Leistung und der Aufwach-Anwendungsfälle bereitstellen kann. Die stets eingeschaltete Prozessor-Engine kann einen Prozessorkern, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Timer und Unterbrechungssteuerungen), verschiedene I/O-Steuerungsperipheriegeräte und Routing-Logik beinhalten.
Die Prozessor(en) 810 können ferner eine Sicherheitscluster-Engine beinhalten, die ein dediziertes Prozessorteilsystem zum Handhaben der Sicherheitsverwaltung für Automobilanwendungen beinhaltet. Die Sicherheitscluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Timer, eine Unterbrechungssteuerung usw.) und/oder Routing-Logik beinhalten. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Gleichschrittmodus arbeiten und als ein einzelner Kern mit einer Vergleichslogik funktionieren, um beliebige Unterschiede zwischen ihren Vorgängen zu erkennen.
Der/die Prozessor(en) 810 können ferner eine Echtzeitkamera-Engine beinhalten, die ein dediziertes Prozessorteilsystem zur Handhabung der Echtzeitkameraverwaltung beinhalten kann.
Der/die Prozessor(en) 810 können ferner einen Signalprozessor mit hohem Dynamikbereich beinhalten, der einen Bildsignalprozessor beinhalten kann, der eine Hardware-Engine ist, die Teil einer Kameraverarbeitungspipeline ist.
Die Prozessor(en) 810 können einen Videobildkompositor beinhalten, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachverarbeitungsfunktionen implementiert, die durch eine Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Fenster des Wiedergabeprogramms zu erzeugen. Der Videobildkompositor kann eine Linsenverzerrungskorrektur an der/den Weitsichtkamera(s) 870, der/den Rundumkamera(s) 874 und/oder an den kabineninternen Überwachungskamerasensoren durchführen. Der kabineninterne Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netzwerk überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein kabineninternes System kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, ein Ziel des Fahrzeugs zu ändern, ein Infotainmentsystem des Fahrzeugs und dessen Einstellungen zu aktivieren oder zu ändern oder sprachaktiviertes Surfen im Internet bereitzustellen. Dem Fahrer stehen bestimmte Funktionen nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
Der Videobildkompositor kann eine erweiterte zeitliche Rauschunterdrückung sowohl für die räumliche als auch für die zeitliche Rauschunterdrückung beinhalten. Wenn, zum Beispiel Bewegung in einem Video vorkommt, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend, indem sie die Gewichtung der Informationen, die von benachbarten Frames bereitgestellt werden, verringert. Wenn ein Bild oder ein Abschnitt eines Bildes keine Bewegung beinhaltet, kann die durch den Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus einem vorherigen Bild verwenden, um das Rauschen in einem derzeitigen Bild zu unterdrücken.
Der Videobildkompositor kann auch so konfiguriert sein, dass er eine Stereoentzerrung an den eingegebenen Stereolinsen-Frames durchführt. Der Videobildkompositor kann ferner für die Benutzerschnittstellenzusammensetzung verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 808 nicht zum kontinuierlichen Rendern neuer Oberflächen benötigt werden. Sogar wenn die GPU(s) 808 eingeschaltet sind und aktiv 3D-Rendering durchführen,kann der Videobildkompositor verwendet werden, um die GPU(s) 808 zu entlasten, um die Performance und Reaktionsfähigkeit zu verbessern.
Das/die SoC(s) 804 können ferner eine serielle Mobile-Industry-Processor-Interface (MIPI)-Kameraschnittstelle zum Empfangen von Videos und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock beinhalten, der für Kamera- und zugehörige Pixeleingabefunktionen verwendet werden kann. Das/die SoC(s) 804 können ferner (eine) Eingabe/Ausgabe-Steuerung(en) beinhalten, die durch Software gesteuert werden können und für den Empfang von I/O-Signalen verwendet werden können, die keiner bestimmten Rolle zugewiesen sind.
Das/die SoC(s) 804 können ferner eine breite Palette von Peripherieschnittstellen beinhalten, um die Kommunikation mit Peripheriegeräten, Audio-Codecs, Leistungsverwaltungs- und/oder anderen Vorrichtungen zu ermöglichen. Das/die SoC(s) 804 kann/können verwendet werden, um Daten von Kameras (z. B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LiDAR-Sensor(en) 864, RADAR-Sensor(en) 860 usw., die über Ethernet verbunden sein können), Daten vom Bus 802 (z. B. Geschwindigkeit des Fahrzeugs 800, Lenkradposition usw.), Daten von GNSS-Sensor(en) 858 (z. B. verbunden über Ethernet oder CAN-Bus) zu verarbeiten. Das/die SoC(s) 804 kann/können außerdem dedizierte Hochleistungs-Massenspeicher-Controller enthalten, die ihre eigenen DMA-Engines enthalten können und die verwendet werden können, um die CPU(s) 806 von Routineaufgaben der Datenverwaltung zu befreien.
Das/die SoC(s) 804 können eine Ende-zu-Ende-Plattform mit einer flexiblen Architektur sein, welche die Automatisierungslevels 3-5 überspannt und dadurch eine umfassende funktionelle Sicherheitsarchitektur bereitstellt, die Techniken des maschinellen Sehens und des ADAS für Diversität und Redundanz nutzt und effizient einsetzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftwarestapel zusammen mit Deep-Learning-Werkzeugen bereitstellt. Das/die SoC(s) 804 können schneller, zuverlässiger und sogar energieeffizienter und raumeffizienter sein als herkömmliche Systeme. Zum Beispiel können der/die Beschleuniger 814, wenn sie mit der/den CPU(s) 806, der/den GPU(s) 808 und dem/den Datenspeicher(n) 816 kombiniert sind, eine schnelle, effiziente Plattform für autonome Fahrzeuge der Levels 3-5 bereitstellen.
Die Technologie stellt somit Fähigkeiten und Funktionen bereit, die mit herkömmlichen Systemen nicht erreicht werden können. Zum Beispiel können Algorithmen des maschinellen Sehens auf CPUs ausgeführt werden, die unter Verwendung einer Programmiersprache auf hohem Level, wie z. B. der Programmiersprache C, konfiguriert werden können, um eine große Vielfalt von Verarbeitungsalgorithmen über eine große Vielfalt von visuellen Daten auszuführen. Die CPUs sind jedoch oft nicht in der Lage, die Performance-Anforderungen vieler Anwendungen des maschinellen Sehens zu erfüllen, wie z. B. in Bezug auf die Ausführungszeit und den Leistungsverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, die in fahrzeuginternen ADAS-Anwendungen und in praktischen autonomen Fahrzeugen der Levels 3-5 erforderlich sind.
Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungclusters die gleichzeitige und/oder sequentielle Ausführung mehrerer neuronaler Netze und die Kombination der Ergebnisse, um autonome Fahrfunktionen der Level 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder dGPU (z. B. GPU(s) 820) ausgeführt wird, eine Text- und Worterkennung beinhalten, die es dem Supercomputer ermöglicht, Verkehrsschilder zu lesen und zu verstehen, einschließlich Schildern, für die das neuronale Netzwerk nicht speziell trainiert wurde. Der DLA kann ferner ein neuronales Netzwerk enthalten, das in der Lage ist, Zeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis davon bereitzustellen und dieses semantische Verständnis an den Pfadplanungsmodule weiterzugeben, die auf dem CPU-Komplex laufen.
Als weiteres Beispiel können mehrere neuronale Netze simultan ausgeführt werden, wie für das Fahren bei Level 3, 4 oder 5 erforderlich ist. Zum Beispiel kann ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Vereisung hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzwerken unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netzwerk (z. B. einem trainierten neuronalen Netzwerk) als Verkehrsschild identifiziert werden und kann der Text „Blinkende Lichter weisen auf Verweisung hin“ von einem zweiten eingesetzten neuronalen Netzwerk interpretiert werden, das die Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass, wenn blinkende Lichter erkannt werden, Vereisungen vorliegen. Das blinkende Licht kann identifiziert werden, indem ein drittes eingesetztes neuronales Netz über mehrere Einzelbilder hinweg betrieben wird, das eine Pfadplanungssoftware des Fahrzeugs über das Vorhandensein (oder Nichtvorhandensein) von blinkenden Lichtern informiert. Alle drei neuronalen Netze können simultan laufen, wie etwa innerhalb des DLA und/oder auf den GPU(s) 808.
In einigen Beispielen kann ein CNN zur Gesichtserkennung und Fahrzeugbesitzeridentifizierung Daten von Kamerasensoren verwenden, um das Vorhandensein eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 800 zu identifizieren. Die stets eingeschaltete Sensorverarbeitungs-Engine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn sich der Besitzer der Fahrertür nähert und Lichter einschaltet, und um in dem Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise stellen das/die SoC(s) 804 Sicherheit gegen Diebstahl und/oder Carjacking bereit.
In einem weiteren Beispiel kann ein CNN zur Detektion und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 896 verwenden, um Sirenen von Einsatzfahrzeugen zu detektieren und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Erkennung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, nutzen die SoC(s) 804 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung von visuellen Daten. In einer bevorzugten Ausführungsform wird das CNN, das auf dem DLA läuft, dafür trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu identifizieren (z. B. durch Verwenden des Dopplereffekts). Das CNN kann auch dafür trainiert werden, Einsatzfahrzeuge zu identifizieren, die für das lokale Gebiet, in dem das Fahrzeug betrieben wird, spezifisch sind, wie durch den/die GNSS-Sensor(en) 858. Folglich versucht das CNN zum Beispiel, wenn es in Europa betrieben wird, europäische Sirenen zu erkennen, und in den Vereinigten Staaten versucht das CNN, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Einsatzfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge auszuführen, um das Fahrzeug zu verlangsamen, an den Straßenrand zu fahren, das Fahrzeug zu parken und/oder das Fahrzeug im Leerlauf laufen zu lassen, und zwar mit der Hilfe der Ultraschallsensoren 862, bis das/die Einsatzfahrzeug/e vorbeigefahren ist/sind.
Das Fahrzeug kann (eine) CPU(s) 818 (z. B. diskrete CPU(s) oder dCPU(s)) beinhalten, die über eine Hochgeschwindigkeitszusammenschaltung (z. B. PCle) an die SoC(s) 804 gekoppelt sein können. Die CPU(s) 818 können zum Beispiel einen X86-Prozessor beinhalten. Die CPU(s) 818 können dazu verwendet werden, eine beliebige einer Vielfalt von Funktionen durchzuführen, z. B. die Vermittlung potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und SoC(s) 804 und/oder die Überwachung des Status und Zustands der Steuerung(en) 836 und/oder Infotainment-SoC 830.
Das Fahrzeug 800 kann GPU(s) 820 (z. B. diskrete GPU(s) oder dGPU(s)) beinhalten, die über eine Hochgeschwindigkeitszusammenschaltung (z. B. NVLINK von NVIDIA Coporation) mit dem/den SoC(s) 804 gekoppelt sein können. Die GPU(s) 820 können eine zusätzliche Funktionalität für künstliche Intelligenz bereitstellen, z. B. durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netzwerke, und können zum Trainieren und/oder Aktualisieren neuronaler Netzwerke verwendet werden, die auf Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 800 basieren.
Das Fahrzeug 800 kann ferner die Netzschnittstelle 824 beinhalten, die eine oder mehrere drahtlose Antennen 826 beinhalten kann (z. B. eine oder mehrere drahtlose Antennen für unterschiedliche Kommunikationsprotokolle, wie etwa eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzwerkschnittstelle 824 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit (einem) Server(n) 878 und/oder anderen Netzwerkvorrichtungen), mit anderen Fahrzeugen und/oder mit Rechenvorrichtungen (z. B. Client-Vorrichtungen von Fahrgästen) zu ermöglichen. Zum Kommunizieren mit anderen Fahrzeugen kann eine direkte Verknüpfung zwischen den zwei Fahrzeugen hergestellt werden und/oder eine indirekte Verknüpfung (z. B. über Netze und über das Internet) hergestellt werden. Direkte Verknüpfungen können unter Verwendung einer Fahrzeug-zu-Fahrzeug-Kommunikationsverknüpfung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverknüpfung kann dem Fahrzeug 800 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 800 bereitstellen (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 800). Die vorgenannte Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitssteuerungsfunktionalität des Fahrzeugs 800 sein.
Die Netzschnittstelle 824 kann ein SoC beinhalten, das eine Modulations- und Demodulationsfunktionalität bereitstellt und es den Steuerung(en) 836 ermöglicht, über drahtlose Netze zu kommunizieren. Die Netzwerkschnittstelle 824 kann ein Hochfrequenz-Frontend für die Aufwärtskonvertierung vom Basisband auf die Hochfrequenz und die Abwärtskonvertierung von der Hochfrequenz auf das Basisband beinhalten. Die Frequenzkonvertierungen können durch hinreichend bekannte Prozesse und/oder unter Verwendung von Überlagerungsverfahren durchgeführt werden. In einigen Beispielen kann die Hochfrequenz-Frontend-Funktionalität durch einen separaten Chip bereitgestellt sein. Die Netzwerkschnittstelle kann eine drahtlose Funktionalität zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle beinhalten.
Das Fahrzeug 800 kann ferner Datenspeicher 828 beinhalten, die außerhalb des Chips (z. B. außerhalb der SoC(s) 804) gespeichert sein können. Der/die Datenspeicher 828 können ein oder mehrere Speicherelemente umfassen, darunter RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Vorrichtungen, die mindestens ein Datenbit speichern können.
Das Fahrzeug 800 kann ferner GNSS-Sensor(en) 858 beinhalten. Der/die GNSS-Sensor(en) 858 (z. B. GPS, unterstützte GPS-Sensoren, Differential-GPS (DGPS)-Sensoren usw.), um bei der Kartierung, der Wahrnehmung, der Erstellung von Belegungsrastern und/oder der Pfadplanung zu helfen. Eine beliebige Anzahl von GNSS-Sensor(en) 858 kann verwendet werden, zum Beispiel und ohne Einschränkung ein GPS unter Verwendung eines USB-Steckers mit einer Ethernet-zu-Seriell (RS-232)-Brücke.
Das Fahrzeug 800 kann ferner RADAR-Sensor(en) 860 beinhalten. Der/die RADAR-Sensor(en) 860 können von dem Fahrzeug 800 zur Fahrzeugerkennung mit großer Reichweite verwendet werden, auch bei Dunkelheit und/oder schlechten Wetterbedingungen. Die RADAR-Funktionssicherheitslevel ASIL B sein. Der/die RADAR-Sensor(en) 860 können das CAN und/oder den Bus 802 (z. B. zur Übertragung der von dem/den RADAR-Sensor(en) 860 erzeugten Daten) zur Steuerung von und zum Zugriff auf Objektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugriff auf Rohdaten über Ethernet erfolgt. Eine große Vielfalt von RADAR-Sensorarten kann verwendet werden. Zum Beispiel und ohne Einschränkung können der/die RADAR-Sensor(en) 860 für die Verwendung als Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensoren verwendet.
Der/die RADAR-Sensor(en) 860 können unterschiedliche Konfigurationen beinhalten, z. B. mit großer Reichweite und schmalem Sichtfeld, mit geringer Reichweite und breitem Sichtfeld, mit seitlicher Abdeckung mit kurzer Reichweite usw. In einigen Beispielen kann das RADAR mit großer Reichweite für die adaptive Geschwindigkeitssteuerungsfunktionalität verwendet werden. Die RADAR-Systeme können mit großer Reichweite ein breites Sichtfeld bereitstellen, das durch zwei oder mehr unabhängige Scans realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Der/die RADAR-Sensor(en) 860 können dabei helfen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und können von ADAS-Systemen für den Notbremsassistenten und die Vorwärtskollisionswarnung verwendet werden. RADAR-Sensoren mit großer Reichweite können ein monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle beinhalten. In einem Beispiel mit sechs Antennen können die vier zentrale Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu ausgestaltet ist, die Umgebung des Fahrzeugs 800 bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den benachbarten Fahrspuren aufzuzeichnen. Die beiden anderen Antennen können das Sichtfeld erweitern, wodurch es möglich ist, Fahrzeuge, die in die Fahrspur des Fahrzeugs 800 einfahren oder diese verlassen, schnell zu erkennen.
Die RADAR-Systeme mit mittlerer Reichweite können beispielsweise eine Reichweite von bis zu 860 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 850 Grad (hinten) beinhalten. RADAR-Systeme mit kurzer Reichweite können ohne Einschränkung RADAR-Sensoren beinhalten, die für die Installation an beiden Enden des hinteren Stoßfängers ausgestaltet sind. Wenn das RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers installiert ist, kann ein derartiges RADAR-Sensorsystem zwei Strahlen erzeugen, die den toten Winkel hinter und neben dem Fahrzeug konstant überwachen.
RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder zur Unterstützung beim Fahrspurwechsel verwendet werden.
Das Fahrzeug 800 kann ferner Ultraschallsensor(en) 862 beinhalten. Der/die Ultraschallsensor(en) 862, die vorne, hinten und/oder an den Seiten des Fahrzeugs 800 positioniert sein können, können als Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsgitters verwendet werden. Eine große Vielfalt von Ultraschallsensor(en) 862 kann verwendet werden und können unterschiedliche Ultraschallsensor(en) 862 können für unterschiedliche Erkennungsreichweiten (z. B. 2,5 m, 4 m) verwendet werden. Der/die Ultraschallsensor(en) 862 können bei funktionellen Sicherheitslevels von ASIL B arbeiten.
Das Fahrzeug 800 kann LiDAR-Sensor(en) 864 beinhalten. Der/die LiDAR-Sensor(en) 864 können zur Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LiDAR-Sensor(en) 864 können dem funktionellen Sicherheitslevel ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 800 mehrere LiDAR-Sensoren 864 (z. B. zwei, vier, sechs usw.) beinhalten, die Ethernet verwenden können (um z. B. Daten für einen Gigabit-Ethernet-Switch bereitzustellen).
In einigen Beispielen können die LiDAR-Sensor(en) 864 dazu in der Lage sein, eine Liste von Objekten und deren Abstände für ein 360-Grad-Sichtfeld bereitzustellen. Handelsübliche LiDAR-Sensor(en) 864 können zum Beispiel eine beworbene Reichweite von ungefähr 800 m aufweisen, mit einer Genauigkeit von 2 cm-3 cm und mit Unterstützung für eine 800 Mbps-Ethernet-Verbindung. In einigen Beispielen können ein oder mehrere nicht vorstehende LiDAR-Sensoren 864 verwendet werden. In einem solchen Beispiel können der/die LiDAR-Sensor(en) 864 als eine kleine Vorrichtung implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 800 eingebettet werden kann. Der/die LiDAR-Sensor(en) 864 können in solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von bis zu 35 Grad mit einer Reichweite von 200 m selbst bei Objekten mit niedrigem Reflexionsvermögen bereitstellen. Der/die an der Front montierte(n) LiDAR-Sensor(en) 864 können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert sein.
In einigen Beispielen können auch LiDAR-Technologien, wie z. B. 3D-Blitz-LiDAR, verwendet werden. 3D-Blitz-LiDAR verwendet einen Laserblitz als Sendequelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von ca. 200 m zu beleuchten. Eine Blitz-LiDAR-Einheit beinhaltet einen Rezeptor, der die Laserpuls-Laufzeit und das reflektierte Licht an jedem Pixel aufzeichnet, was wiederum der Reichweite vom Fahrzeug zu den Objekten entspricht. Blitz-LiDAR kann ermöglichen, dass mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung erzeugt werden. In einigen Beispielen können vier Blitz-LiDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 800. Verfügbare 3D-Blitz-LiDAR-Systeme beinhalten eine Festkörper-3D-Staring-Array-LiDAR-Kamera ohne bewegliche Teile außer einem Lüfter (z. B. eine nicht scannende LiDAR-Vorrichtung). Die Blitz-LiDAR-Vorrichtung kann einen 5-Nanosekunden-Laserpuls der Klasse I (augensicher) pro Bild verwenden und kann das reflektierte Laserlicht in Form von den 3D-Reichweitenpunktwolken und gemeinsam registrierten Intensitätsdaten erfassen. Durch die Verwendung von Blitz-LiDAR und weil Blitz-LiDAR eine Festkörpervorrichtung ohne bewegliche Teile ist, ist der/die LiDAR-Sensor(en) 864 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße.
Das Fahrzeug kann ferner IMU-Sensor(en) 866 beinhalten. Der/die IMU-Sensor(en) 866 kann/können sich in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 800 befinden. Der/die IMU-Sensor(en) 866 können zum Beispiel und ohne Einschränkung (einen) Beschleunigungsmesser, (ein) Magnetometer, (ein) Gyroskop(e), (einen) Magnetkompass(e) und/oder andere Sensorarten beinhalten. In einigen Beispielen, wie z. B. in sechsachsigen Anwendungen, kann der/die IMU-Sensor(en) 866 Beschleunigungsmesser und Gyroskope beinhalten, während in neunachsigen Anwendungen der/die IMU-Sensor(en) 866 Beschleunigungsmesser, Gyroskope und Magnetometer beinhalten kann/können.
In einigen Ausführungsformen können die IMU-Sensor(en) 866 als miniaturisiertes GPS-gestütztes Trägheitsnavigationssystem (GPS-Aided Inertial Navigation System - GPS/INS) mit hoher Rechenleistung implementiert sein, das Trägheitssensoren von mikroelektromechanischen Systemen (micro-electromechanical systems - MEMS), einen hochempfindlichen GPS-Empfänger und weiterentwickelte Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage bereitzustellen. So können der/die IMU-Sensor(en) 866 in einigen Beispiel es dem Fahrzeug 800 ermöglichen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem vom GPS an den/die IMU-Sensor(en) 866 Änderungen der Geschwindigkeit direkt beobachtet und korreliert werden. In einigen Beispielen können der/die IMU-Sensor(en) 866 und GNSS-Sensor(en) 858 in einer einzelnen integrierten Einheit kombiniert sein.
Das Fahrzeug kann Mikrofon(e) 896 beinhalten, das/die in und/oder um das Fahrzeug 800 herum angebracht sind. Das/die Mikrofon(e) 896 können unter anderem zur Erkennung und Identifizierung von Einsatzfahrzeugen verwendet werden.
Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen beinhalten, darunter Stereokamera(s) 868, Weitsichtkamera(s) 870, Infrarotkamera(s) 872, Rundumkamera(s) 874, Langstrecken- und/oder Mittelstreckenkamera(s) 898 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten um die gesamte Peripherie des Fahrzeugs 800 herum zu erfassen. Die Art der verwendeten Kameras hängt von den Ausführungsformen und Anforderungen für das Fahrzeug 800 ab, und es kann eine beliebige Kombination von Kameraarten verwendet werden, um die notwendige Abdeckung rund um das Fahrzeug 800 zu gewährleisten. Zusätzlich kann die Anzahl der Kameras in Abhängigkeit von der Ausführungsform unterschiedlich sein. Zum Beispiel kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras beinhalten. Die Kameras können zum Beispiel und ohne Einschränkung Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras wird hier in Bezug auf 8A und 8B.
Das Fahrzeug 800 kann ferner Vibrationssensor(en) 842 beinhalten. Der/die Vibrationssensor(en) 842 können Vibrationen von Komponenten des Fahrzeugs, wie z. B. der der Achse(n), messen. Zum Beispiel können Änderungen der Vibrationen eine Änderung des Straßenbelags angeben. In einem weiteren Beispiel, wenn zwei oder mehr Vibrationssensoren 842 verwendet werden, können die Unterschiede zwischen den Vibrationen verwendet werden, um die Reibung oder den Schlupf des Straßenbelags zu bestimmen (z. B., wenn der Unterschied der Vibration zwischen einer leistungsbetriebenen Achse und einer sich frei drehenden Achse besteht).
Das Fahrzeug 800 kann ein ADAS-System 838 beinhalten. Das ADAS-System 838 kann in einigen Beispielen ein SoC beinhalten. Das ADAS-System 838 kann autonome/adaptive/automatische Geschwindigkeitssteuerung (autonomous/adaptive/automatic cruise control - ACC), kooperative adaptive Geschwindigkeitssteuerung (cooperative adaptive cruise control - CACC), Vorwärtszusammenstoßwarnungen (forward crash warning - FCW), automatisches Notbremsen (AEB), Spurverlassenswarnungen (lane departure warning - LDW), Spurhalteassistenz (lane keep assist - LKA), Totwinkelwarnung (blind spot warning - BSW), Querverkehrswarnung (rear cross-traffic warning - RCTW), Kollisionswarn (collision warning - CWS)-Systeme, Spurzentrierung (lane centering - LC) und/oder andere Systeme, Merkmale und/oder Funktionen beinhalten.
Die ACC-Systeme können RADAR-Sensor(en) 860, LiDAR-Sensor(en) 864 und/oder eine Kamera(en) verwenden. Die ACC-Systeme können ACC in Längsrichtung und/oder ACC in Querrichtung beinhalten. Die Längs-ACC steuert den Abstand zum Fahrzeug, das sich unmittelbar vor dem Fahrzeug 800 befindet, und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Die Quer-ACC führt eine Abstandshaltung durch und rät dem Fahrzeug 800, die Fahrspuren zu wechseln, wenn dies erforderlich ist. Die Quer-ACC ist mit anderen ADAS-Anwendungen, wie zum Beispiel LCA und CWS, verbunden.
Eine CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzschnittstelle 824 und/oder die drahtlose(n) Antenne(n) 826 von anderen Fahrzeugen über eine drahtlose Verknüpfung oder indirekt über eine Netzverbindung (z. B. über das Internet) empfangen werden können. Direkte Verknüpfungen können durch eine Fahrzeug-zu-Fahrzeug (F-F)-Kommunikationsverknüpfung bereitgestellt werden, während indirekte Verknüpfungen durch eine Infrastruktur-zu-Fahrzeug (I-F)-Kommunikationsverknüpfung bereitgestellt werden können. Im Allgemeinen stellt das F-F-Kommunikationskonzept Informationen über unmittelbar vorausfahrende Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem und auf derselben Spur wie das Fahrzeug 800 befinden) bereit, während das I-F-Kommunikationskonzept Informationen über den weiter entfernt vorausfahrenden Verkehr bereitstellt. CACC-Systeme können entweder eine oder beide der I-F- und F-F-Informationsquellen beinhalten. Angesichts der Informationen über die Fahrzeuge vor dem dem Fahrzeug 800 kann die CACC zuverlässiger sein und hat das Potenzial, den Gleichmäßigkeit des Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
FCW-Systeme sind so ausgestaltet, dass es einen Fahrer vor einer Gefahr warnt, sodass der Fahrer eine korrigierende Maßnahme ergreifen kann. FCW-Systeme verwenden eine nach vorn gerichtete Kamera und/oder RADAR-Sensor(en) 860, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente. Die FCW-Systeme können eine Warnung bereitstellen, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
AEB-System erkennen eine drohende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und kann automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines spezifizierten Zeit- oder Abstandsparameters eine korrigierende Handlung durchführt. AEB-Systeme können nach vorn gerichtete Kamera(s) und/oder RADAR-Sensor(en) 860 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn ein AEB-System eine Gefahr detektiert, warnt es typischerweise zuerst den Fahrer, um eine korrigierende Maßnahme zu ergreifen, um eine Kollision zu vermeiden, und falls der Fahrer keine korrigierende Maßnahme ergreift, kann das AEB-System automatisch die Bremsen in dem Bestreben betätigen, den Aufprall der vorhergesagten Kollision zu verhindern oder mindestens abzuschwächen. AEB-Systeme können Techniken, wie zum Beispiel dynamische Bremsunterstützung und/oder Bremsung aufgrund eines bevorstehenden Zusammenstoßes, beinhalten.
LDW-Systeme stellen optische, akustische und/oder taktile Warnungen bereit, wie z. B. Lenkrad- oder Sitzvibrationen, um den Fahrer zu warnen, wenn das Fahrzeug 800 die Fahrspurmarkierungen überquert. Ein LDW-System wird nicht aktiviert, wenn der Fahrer ein absichtliches Verlassen der Fahrspur anzeigt, indem er den Blinker betätigt. LDW-Systeme können können nach vorne gerichtete Kameras verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
LKA-Systeme sind eine Variante der LDW-Systeme. LKA-Systeme stellen eine Lenkeingabe oder eine Bremsung bereit, um das Fahrzeug 800 zu korrigieren, wenn das Fahrzeug 800 beginnt, die Fahrspur zu verlassen.
BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen in einem toten Winkel eines Automobils. BSW-Systeme können einen optischen, akustischen und/oder taktilen Alarm bereitstellen, um anzugeben, dass Einfädeln in oder Wechseln der Fahrspuren unsicher ist. Das System kann eine zusätzliche Warnung ausgeben, wenn der Fahrer einen Blinker betätigt. BSW-Systeme können nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 860 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
RCTW-Systeme können eine optische, akustische und/oder taktile Benachrichtigung bereitstellen, wenn ein Objekt außerhalb der Reichweite der Heckkamera erkannt wird, wenn das Fahrzeug 800 rückwärts fährt. Einige RCTW-Systeme beinhalten AEB, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Zusammenstoß zu vermeiden. Die RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensor(en) 860 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
Herkömmliche ADAS-Systeme können anfällig für falsch positive Ergebnisse sein, die für den Fahrer ärgerlich und ablenkend sein können, aber typischerweise nicht katastrophal sind, da die ADAS-Systeme den Fahrer warnen und es dem Fahrer ermöglichen, zu entscheiden, ob wirklich eine Sicherheitsbedingung vorliegt, und entsprechend zu handeln. In einem autonomen Fahrzeug 800 muss das Fahrzeug 800 jedoch im Falle von widersprüchlichen Ergebnissen selbst entscheiden, ob das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. einer ersten Steuerung 836 oder einer zweiten Steuerung 836) zu beachten ist. In einigen Ausführungsformen kann das ADAS-System 838 beispielsweise ein Backup- und/oder sekundärer Computer sein, der Wahrnehmungsinformationen für ein Rationalitätsmodul eines Backup-Computers bereitstellt. Der Rationalitätsmonitor des Backup-Computers kann eine redundante, diverse Software auf Hardware-Komponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahr-Tasks zu erkennen. Die Ausgaben des ADAS-Systems 838 können für eine Überwachungs-MCU bereitgestellt werden. Wenn die Ausgaben des primären und des sekundären Computers miteinander in Konflikt geraten, muss die übergeordnete MCU festlegen, wie der Konflikt gelöst werden kann, um einen sicheren Betrieb zu gewährleisten.
In einigen Beispielen kann der primäre Computer so konfiguriert sein, dass er der Überwachungs-MCU eine Konfidenzbewertung bereitstellt, die eine Konfidenz des primären Computers für das gewählte Ergebnis angibt. Falls die Konfidenzbewertung einen Schwellenwert überschreitet, kann diese Überwachungs-MCU der Führung des primären Computers folgen, unabhängig davon, ob dieser sekundäre Computer ein widersprüchliches oder inkonsistentes Ergebnis bereitstellt. Wenn die eine Konfidenzbewertung den Schwellenwert nicht erreicht und der primäre und der sekundäre Computer unterschiedliche Ergebnisse angeben (z. B. den Widerspruch), kann die Überwachungs-MCU zwischen den Computern vermitteln, um das zweckmäßige Resultat zu bestimmen.
Die Überwachungs-MCU kann so konfiguriert sein, dass sie neuronale(s) Netz(e) ausführt, die dafür trainiert und konfiguriert sind, mindestens auf Grundlage von Ausgaben aus dem primären Computer und dem sekundären Computer die Bedingungen zu bestimmen, unter denen der sekundäre Computer Fehlalarme bereitstellt. Folglich können das/die neuronale Netz(e) in der Überwachungs-MCU lernen, wann der Ausgabe eines sekundären Computers vertraut werden kann und wann nicht. Zum Beispiel können, wenn der sekundäre Computer ein RADAR-basiertes FCW-System ist, neuronale Netz(e) in der Überwachungs-MCU lernen, wann das FCW-System metallische Objekte identifiziert, die tatsächlich keine Gefahren sind, wie etwa ein Abflussgitter oder ein Gullydeckel, das/der einen Alarm auslöst. Wenn der sekundärer Computer ein kamerabasiertes LDW-System ist, kann ein neuronales Netz in der Überwachungs-MCU ähnlich lernen, die LDW zu überschreiben, wenn Fahrradfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, die (ein) neuronale(s) Netz(e) beinhalten, die auf der Überwachungs-MCU laufen, kann die Überwachungs-MCU mindestens einen DLA oder eine GPU beinhalten, der/die für die Ausführung von dem/den neuronalen Netzwerk(en) mit assoziiertem Speicher geeignet ist. In bevorzugten Ausführungsformen kann die Überwachungs-MCU eine Komponente eines oder mehrerer der SoC(s) 804 umfassen und/oder als solche enthalten sein.
In anderen Beispielen kann das ADAS-System 838 einen sekundären Computer beinhalten, der die ADAS-Funktionalität unter Verwendung der traditionellen Regeln des maschinellen Sehens durchführt. So kann der sekundäre Computer klassische Regeln des maschinellen Sehens (wenn-dann) verwenden und kann das Vorhandensein eines neuronalen Netzwerks/von neuronalen Netzwerken in der Überwachungs-MCU die Zuverlässigkeit, Sicherheit und Performance verbessern. Zum Beispiel macht die vielfältige Implementation und absichtliche Nicht-Identität das Gesamtsystem fehlertoleranter, insbesondere gegenüber Fehlern, die durch Software(oder Software-Hardware-Schnittstellen)-Funktionalität verursacht werden. Wenn zum Beispiel ein Software-Bug oder -Fehler in der auf dem primären Computer laufenden Software vorliegt und der nicht identische Software-Code, der auf dem sekundären Computer läuft, dasselbe Gesamtergebnis bereitstellt, kann die Überwachungs-MCU eine größere Konfidenz darin haben, dass das Gesamtergebnis korrekt ist und der Bug in der Software oder Hardware auf dem primären Computer keinen wesentlichen Fehler verursacht.
In einigen Beispielen kann die Ausgabe des ADAS-Systems 838 in einen Wahrnehmungsblock des primären Computers und/oder in einen Block für dynamische Fahr-Tasks des primären Computers eingespeist werden. Wenn das ADAS-System 838 z. B. eine Vorwärtszusammenstoßwarnung aufgrund eines unmittelbar vorausliegenden Objekts angibt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der sekundäre Computer über sein eigenes neuronales Netzwerk verfügen, das trainiert ist und somit das Risiko von falsch positiven Ergebnissen reduziert, wie hierin beschrieben.
Das Fahrzeug 800 kann ferner das Infotainment-SoC 830 (z. B. ein fahrzeuginternes Infotainment-System (in-vehicle infotainment system - IVI-System)) beinhalten. Obwohl als ein SoC veranschaulicht und beschrieben, kann das Infotainment-System kein SoC sein und kann zwei oder mehr diskrete Komponenten beinhalten. Das Infotainment-SoC 830 kann eine Kombination aus Hardware und Software enthalten, die verwendet werden kann, um Audio (z. B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon (z. B. Freisprechen), Netzwerkkonnektivität (z. B. LTE, Wi-Fi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Rückwärtseinparkhilfe, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstofffüllstand, insgesamt zurückgelegte Gesamt Strecke, Bremskraftstofffüllstand, Ölfüllstand, Tür öffnen/schließen, Luftfilterinformationen usw.) für das Fahrzeug 800 bereitzustellen. Das Infotainment-SoC 830 kann beispielsweise Radios, Plattenspieler, Navigationssysteme, Videowiedergabevorrichtungen, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Audiosteuerungen am Lenkrad, eine Freisprech-Sprachsteuerung, eine Heads-up-Anzeige (heads-up display- HUD), eine HMI-Anzeige 834, eine Telematikvorrichtung, ein Steuerfeld (z. B. zur Steuerung von und/oder Interaktion mit verschiedenen Komponenten, Merkmalen und/oder Systemen) und/oder andere Komponenten beinhalten. Das Infotainment-SoC 830 kann ferner dazu verwendet werden, um einem Benutzer(n) des Fahrzeugs Informationen (z. B. optisch und/oder akustisch) bereitzustellen, wie z. B. Informationen vom ADAS-System 838, Informationen zum autonomen Fahren, wie z. B. geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
Das Infotainment-SoC 830 kann GPU-Funktionen beinhalten. Das Infotainment-SoC 830 über den Bus 802 (z. B. CAN-Bus, Ethernet usw.) mit anderen Vorrichtungen, Systemen und/oder Komponenten des Fahrzeugs 800 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 830 mit einer Überwachungs-MCU gekoppelt sein, sodass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primäre(n) Steuerung(en) 836 (z. B. der primäre und/oder der Backup-Computer des Fahrzeugs 800) ausfallen. In solch einem Beispiel kann das Infotainment-SoC 830 das Fahrzeug 800 in einen Modus des Chauffierens zu einem sicheren Halt versetzen, wie hierin beschrieben.
Das Fahrzeug 800 kann ferner ein Kombiinstrument 832 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) beinhalten. Das Kombiinstrument 832 kann eine Steuerung und/oder einen Supercomputer (z. B. eine diskrete Steuerung oder einen diskreten Supercomputer) beinhalten. Das Kombiinstrument 832 kann einen Satz von Messausrüstung beinhalten, wie z. B. Geschwindigkeitsmesser, Kraftstoffstand, Öldruck, Drehzahlmesser, Wegstreckenzähler, Blinker, Schaltknüppelpositionsangabe, Sicherheitsgurt-Warnleuchte(n), Feststellbremsen-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Informationen über Airbag (SRS)-Systeme, Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen usw. In einigen Beispielen können Informationen angezeigt und/oder vom Infotainment-SoC 830 und dem Kombiinstrument 832 gemeinsam genutzt werden. In anderen Worten kann das Kombiinstrument 832 als Teil des Infotainment-SoC 830 enthalten sein oder umgekehrt.
8D ist ein Systemdiagramm für die Kommunikation zwischen dem/den Cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug 800 aus 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System 876 kann Server 878, Netzwerk(e) 890 und Fahrzeuge, einschließlich des Fahrzeugs 800, beinhalten. Der/die Server 878 können eine Vielzahl von GPUs 884(A)-884(H) (hierin kollektiv als GPUs 884 bezeichnet), PCIe-Switches 882(A)-882(H) (hierin kollektiv als PCIe-Switches 882 bezeichnet) und/oder CPUs 880(A)-880(B) (hierin kollektiv als CPUs 880 bezeichnet) beinhalten. Die GPUs 884, die CPUs 880 und die PCIe-Switches können mit Hochgeschwindigkeitszusammenschaltungen miteinander verbunden sein, wie z. B. und ohne Einschränkung den von NVIDIA entwickelten NVLink-Schnittstellen 888 und/oder PCIe-Verbindungen 886. In einigen Beispielen sind die GPUs 884 über ein NVLink- und/oder NVSwitch-SoC verbunden und die GPUs 884 und die PCIe-Switches 882 sind über PCIe-Zusammenschaltungen verbunden. Obwohl acht GPUs 884, zwei CPUs 880 und zwei PCIe-Switches veranschaulicht sind, soll dies nicht einschränkend sein. Je nach Ausführungsform kann jeder der Server 878 eine beliebige Anzahl von GPUs 884, CPUs 880 und/oder PCIe-Switches beinhalten. Zum Beispiel können der/die Server 878 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 884 beinhalten.
Der/die Server 878 können über die Netz(e) 890 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenbedingungen zeigen, wie etwa kürzlich begonnene Straßenarbeiten. Der/die Server 878 können über das/die Netzwerk(e) 890 und an die Fahrzeuge neuronale Netzwerke 892, aktualisierte neuronale Netzwerke 892 und/oder Karteninformationen 894 übertragen, einschließlich Informationen über Verkehrs- und Straßenbedingungen. Die Aktualisierungen der Karteninformationen 894 können Aktualisierungen für die HD-Karte 822 beinhalten, wie z. B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In einigen Beispielen können die neuronalen Netzwerke 892, die aktualisierten neuronalen Netzwerke 892 und/oderdie Karteninformationen 894 aus einem neuen Training und/oder Erfahrungen resultieren, das/die in Daten dargestellt wird/werden, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder basierend auf Training, das in einem Rechenzentrum (z. B. unter Verwendung von dem/den Server(n) 878 und/oder anderen Servern) durchgeführt wurde.
Der/die Server 878 können verwendet werden, um Modelle des maschinellen Lernens (z. B. neuronale Netzwerke) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen erzeugt werden und/oder können sie in einer Simulation (z. B. unter Verwendung einer Spiele-Engine) erzeugt werden. In einigen Beispielen werden die Trainingsdaten mit Tags versehen (z. B. wenn das neuronale Netzwerk von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B. wenn das neuronale Netzwerk kein überwachtes Lernen benötigt). Das Training kann nach einer oder mehreren Klassen von maschinellen Lerntechniken durchgeführt werden, einschließlich, aber nicht beschränkt auf Klassen wie: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, Selbstlernen, Verstärkungslernen, föderiertes Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraumlernen, vielfältiges Lernen, Repräsentationslernen (einschließlich Ersatzwörterbuchlernen), regelbasiertes maschinelles Lernen, Anomalieerkennung und alle Varianten oder Kombinationen davon. Sobald die Modelle des maschinellen Lernens trainiert sind, können die Modelle des maschinellen Lernens von den Fahrzeugen verwendet werden (z. B. über das/die Netzwerk(e) 890 an die Fahrzeuge übertragen werden und/oder können die Modelle des maschinellen Lernens von dem/den Server(n) 878 verwendet werden, um die Fahrzeuge aus der Ferne zu überwachen.
In einigen Beispielen kann der/können die Server 878 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Echtzeit-Netze zum intelligenten Echtzeit-Inferenzieren anwenden. Der/die Server 878 können Deep-Learning-Supercomputer und/oder dedizierte KI-Computer beinhalten, die von GPU(s) 884 angetrieben werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen können der/die Server 878 jedoch eine Deep-Learning-Infrastruktur beinhalten, die nur CPU-angetriebene Rechenzentren verwendet.
Die Deep-Learning-Infrastruktur des/der Server(s) 878 kann zum schnellen Echtzeit-Inferenzieren in der Lage sein und diese Fähigkeit verwenden, um den Zustand von den Prozessoren, Software und/oder assoziierter Hardware in dem Fahrzeug 800 zu bewerten und zu verifizieren. Zum Beispiel kann die Deep-Learning-Infrastruktur periodische Aktualisierungen vom Fahrzeug 800 empfangen, wie z. B. eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 800 in dieser Sequenz von Bildern lokalisiert hat (z. B. über maschinelles Sehen und/oder andere Objekt-Klassifizierungstechniken des maschinellen Lernens). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netzwerk laufen lassen, um die Objekte zu identifizieren und sie mit den Objekten zu vergleichen, die vom Fahrzeug 800 identifiziert wurden, und wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 800 eine Fehlfunktion aufweist, dann können der/die Server 878 ein Signal an das Fahrzeug 800 übertragen, das einen ausfallsicheren Computer des Fahrzeugs 800 anweist, die Kontrolle zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
Zum Ableiten können der/die Server 878 die GPU(s) 884 und einen oder mehrere programmierbare Ableitungsbeschleuniger (z. B. TensorRT von NVIDIA) beinhalten. Die Kombination von GPU-angetriebenen Servern und Ableitungsbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, wenn z. B. die Performance weniger kritisch ist, können von CPUs, FPGAs und anderen Prozessoren angetriebene Server für die Ableitung verwendet werden.
BEISPIELHAFTE RECHENVORRICHTUNG
9 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung(en) 900, die zur Verwendung beim Implementieren einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist/sind. Die Rechenvorrichtung 900 kann ein Verschaltungssystem 902 beinhalten, das die folgenden Vorrichtungen direkt oder indirekt koppelt: Speicher 904, eine oder mehrere Zentraleinheiten (CPUs) 906, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 908, eine Kommunikationsschnittstelle 910, Eingabe-/Ausgabe-(I/O)-Anschlüsse 912, Eingabe-/Ausgabekomponenten 914, eine Stromversorgung 916, eine oder mehrere Präsentationskomponenten 918 (z. B. Anzeige(n)) und eine oder mehrere Logikeinheiten 920. In mindestens einer Ausführungsform kann/können die Rechenvorrichtung(en) 900 eine oder mehrere virtuelle Maschinen (VM) umfassen und/oder jede ihrer Komponenten kann aus virtuellen Komponenten bestehen (z. B. virtuelle Hardwarekomponenten). Nicht einschränkende Beispiele können eine oder mehrere GPUs 908 eine oder mehrere vGPUs umfassen, eine oder mehrere CPUs 906 können eine oder mehrere vCPUs umfassen und/oder eine oder mehrere Logikeinheiten 920 können eine oder mehrere virtuelle Logikeinheiten umfassen. Die Rechenvorrichtung(en) 900 kann (können) diskrete Komponenten (z. B. eine vollständigen, der Rechenvorrichtung 900 zugeordneten GPU), virtuelle Komponenten (z. B. einen Teil einer der Rechenvorrichtung 900 zugeordneten GPU) oder eine Kombination davon beinhalten.
Auch wenn die verschiedenen Blöcke von 9 als über das Verschaltungssystem 902 mit Leitungen verbunden gezeigt sind, soll dies nicht einschränkend sein und dient nur der Klarheit. Zum Beispiel kann in einigen Ausführungsformen eine Präsentationskomponente 918, wie etwa Anzeigevorrichtung, als I/O-Komponente 914 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 906 und/oder GPUs 908 Speicher beinhalten (z. B. kann der Speicher 904 repräsentativ für eine Speichervorrichtung zusätzlich zum Speicher der GPUs 908, der CPUs 906 und/oder anderen Komponenten sein). Mit anderen Worten dient die Rechenvorrichtung aus 9 lediglich der Veranschaulichung. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Vorrichtung“, „mobile Vorrichtung“, „Handheld-Vorrichtung“, „Spielekonsole“, „elektronische Steuereinheit (electronic control unit - ECU),“ „Virtual-Reality-System“ und/oder andere Vorrichtungs- oder Systemtypen unterschieden, da alle im Umfang der Rechenvorrichtung der 9 in Betracht gezogen werden.
Das Verschaltungssystem 902 kann eine oder mehrere Verbindungen oder Busse darstellen, wie beispielsweise einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verschaltungssystem 902 kann einen oder mehrere Bus- oder Verbindungstypen beinhalten, wie beispielsweise einen Bus mit Industriestandardarchitektur (industry standard architecture - ISA), einen Bus mit erweiterter Industriestandardarchitektur (extended industry standard architecture - EISA), einen Bus der Video Electronic Standards Association (VESA), einen Bus für Verschaltung einer Periphärkomponente (PCI), ein Bus für Expressverschaltung einer Periphärkomponente (PCle) und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen Komponenten. Als ein Beispiel kann die CPU 906 direkt mit dem Speicher 904 verbunden sein. Ferner kann die CPU 906 direkt mit der GPU 908 verbunden sein. Wo eine direkte oder Punkt-zu-Punkt-Verbindung zwischen Komponenten besteht, kann das Verschaltungssystem 902 eine PCIe-Verbindung beinhalten, um die Verbindung auszuführen. In diesen Beispielen muss kein PCI-Bus in der Rechenvorrichtung 900 beinhaltet sein.
Der Speicher 904 kann eine beliebige Vielfalt computerlesbarer Medien beinhalten. Die computerlesbaren Medien können beliebige verfügbare Medien sein, auf welche die Rechenvorrichtung 900 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entfernbare und nicht entfernbare Medien beinhalten. Beispielhaft und nicht einschränkend können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige und/oder entfernbare und nicht entfernbare Medien beinhalten, die in jedem beliebigen Verfahren oder jeder beliebigen Technologie zum Speichern von Informationen wie etwa computerlesbare Anweisungen, Datenstrukturen, Programmmodule oder anderen Daten implementiert werden. Zum Beispiel kann der Speicher 904 computerlesbare Anweisungen speichern (die z. B. ein Programm oder Programme und/oder ein oder mehrere Programmelemente darstellen, wie etwa ein Betriebssystem). Computerspeichermedien können RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium beinhalten, das verwendet werden kann, um die gewünschten Informationen zu speichern und auf das die Rechenvorrichtung 900 zugreifen kann, sind aber nicht darauf beschränkt. Im hierin verwendeten Sinne umfassen Computerspeichermedien keine Signale an sich.
Die Computerspeichermedien können computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal wie etwa einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und beinhalten beliebige Informationsliefermedien. Der Begriff „moduliertes Datensignal“ kann ein Signal betreffen, das eine oder mehrere seiner Eigenschaften auf solch eine Weise verändert aufweist, dass Informationen in dem Signal kodiert werden. Zum Beispiel, und nicht als Einschränkung, können Computerspeichermedien verkabelte Medien beinhalten, wie beispielsweise ein verkabeltes Netzwerk oder eine drahtgebundene Verbindung, und drahtlose Medien, wie beispielsweise akustische, RF, infrarote und andere drahtlose Medien. Kombinationen von jeglichen der obigen sollten auch innerhalb des Umfangs der vorliegenden computerlesbaren Medien umfasst sein.
Die CPU(s) 906 können konfiguriert sein, um mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 900 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Die CPU(s) 906 können jeweils einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) beinhalten, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu handhaben. Die CPU(s) 906 können eine beliebige Art von Prozessor beinhalten und können unterschiedliche Arten von Prozessoren beinhalten, abhängig von der Art der Rechenvorrichtung 900 (z. B. Prozessoren mit weniger Kernen für mobile Vorrichtungen und Prozessoren mit mehr Kernen für Server). Zum Beispiel kann der Prozessor in Abhängigkeit von der Art der Rechenvorrichtung 900 ein Advanced-RISC-Machines(ARM)-Prozessor sein, der unter Verwendung von Reduced Instruction Set Computing (RISC) implementiert ist, oder ein x86-Prozessor, der unter Verwendung von Complex Instruction Set Computing (CISC) implementiert ist. Die Rechenvorrichtung 900 kann eine oder mehrere CPUs 906 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Coprozessoren, wie etwa mathematischen Coprozessoren, beinhalten.
Zusätzlich oder alternativ zu den CPU(s) 906 können die GPU(s) 908 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Computervorrichtung 900 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Eine oder mehrere der GPU(s) 908 können eine integrierte GPU sein (z. B. mit einer oder mehreren der CPU(s) 906) und/oder eine oder mehrere der GPU(s) 908 können eine diskrete GPU sein. In Ausführungsformen können eine oder mehrere der GPU(s) 908 ein Coprozessor einer oder mehrerer der CPU(s) 906 sein. Die GPU(s) 908 können durch die Computervorrichtung 900 verwendet werden, um Grafiken (z. B. 3D-Grafiken) zu rendern oder Universalberechnungen durchzuführen. Zum Beispiel können die GPU(s) 908 für Universalberechnungen auf GPUs (GPGPU) verwendet werden. Die GPU(s) 908 können Hunderte oder Tausende von Kernen beinhalten, die in der Lage sind, Hunderte oder Tausende von Softwarethreads gleichzeitig zu handhaben. Die GPU(s) 908 können Pixeldaten für Ausgabebilder als Reaktion auf das Rendern von Befehlen erzeugen (z. B. Rendern von Befehlen aus der/den CPU(s) 906, die über eine Host-Schnittstelle empfangen werden). Die GPU(s) 908 können Grafikspeicher beinhalten, wie etwa Anzeigespeicher, um Pixeldaten oder andere geeignete Daten zu speichern, wie etwa GPGPU-Daten. Der Anzeigespeicher kann als Teil des Speichers 904 beinhaltet sein. Der/die GPU(s) 908 können zwei oder mehrere GPUs beinhalten, die parallel arbeiten (z. B. über einen Link). Der Link kann die GPUs direkt verbinden (z. B. unter Verwendung von NVLINK) oder kann die GPUs über ein Switch verbinden (z. B. unter Verwendung von NVSwitch). Wenn sie miteinander kombiniert werden, kann jede GPU 908 Pixeldaten oder GPGPU-Daten für verschiedene Abschnitte einer Ausgabe oder für verschiedene Ausgaben (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild) erzeugen. Jede GPU kann ihren eigenen Speicher beinhalten oder kann Speicher mit anderen GPUs teilen.
Zusätzlich oder alternativ zu den CPU(s) 906 und/oder den GPU(s) 908 kann/können die Logikeinheit(en) 920 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 900 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. In Ausführungsformen können die CPU(s) 906, die GPU(s) 908 und/oder die Logikeinheit(en) 920 einzeln oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 920 kann/können Teil von und/oder integriert in eine oder mehrere der CPU(s) 906 und/oder der GPU(s) 908 sein und/oder eine oder mehrere der Logikeinheiten 920 kann/können diskrete Komponenten oder anderweitig extern zu der/den CPU(s) 906 und/oder der/den GPU(s) 908 sein. In Ausführungsformen können eine oder mehrere der logischen Einheiten 920 ein Coprozessor einer oder mehrerer der CPU(s) 906 und/oder einer oder mehrerer der GPU(s) 908 sein.
Beispiele der Logikeinheit(en) 920 beinhalten einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie etwa Tensorkerne (Tensor Cores - TC), Tensor-Verarbeitungseinheiten (Tensor Processing Unit - TPU), visuelle Pixelkerne (Pixel Visual Cores - PVC), Bildverarbeitungseinheiten (Vision Processing Unit - VPU), Grafikverarbeitungscluster (Graphics Processing Cluster - GPC), Texturverarbeitungscluster (Texture Processing Cluster - TPC), Streaming-Multiprozessoren (SM), Baumdurchquerungseinheiten (Tree Traversal Unit - TTU), Beschleuniger für künstliche Intelligenz (Artificial Intelligence Accelerator - AIA), Deep-Learning-Beschleuniger (Deep Learning Accelerator - DLA), arithmetische Logikeinheiten (ALU), anwendungsspezifische integrierte Schaltungen (ASIC), Gleitkommaeinheiten (Floating Point Unit - FPU), Eingabe/Ausgabe (I/O)-Elemente, Elemente für Verschaltung von Periphärkomponenten (PCI) oder Expressverschaltung von Periphärkomponenten (peripheral component interconnect express - PCle) und/oder dergleichen.
Die Kommunikationsschnittstelle 910 kann einen oder mehrere Empfänger, Sender und/oder Transceiver beinhalten, die es der Rechenvorrichtung 900 ermöglichen, mit anderen Rechenvorrichtungen über ein elektronisches Kommunikationsnetz, einschließlich drahtgebundener und/oder drahtloser Kommunikation, zu kommunizieren. Die Kommunikationsschnittstelle 910 kann Komponenten und Funktionalität beinhalten, um eine Kommunikation über eine Anzahl unterschiedlicher Netzwerke zu ermöglichen, wie etwa drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weiterverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet.
Die I/O-Anschlüsse 912 können die Rechenvorrichtung 900 dazu befähigen, logisch an andere Vorrichtungen gekoppelt zu werden, einschließlich der I/O-Komponenten 914, der Präsentationskomponente(n) 918 und/oder anderer Komponenten, von denen einige in die Rechenvorrichtung 900 eingebaut (z. B. darin integriert) sein können. Veranschaulichende I/O-Komponenten 914 beinhalten ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, eine drahtlose Vorrichtung usw. Die I/O-Komponenten 914 können eine natürliche Benutzerschnittstelle (natural user interface - NUI) bereitstellen, die Luftgesten, Stimme oder andere physiologische Eingaben, die durch einen Benutzer generiert werden, verarbeitet. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten genauer beschrieben) implementieren, die einer Anzeige der Rechenvorrichtung 900 zugeordnet sind. Die Rechenvorrichtung 900 kann Tiefenkameras, wie etwa stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestendetektion und -erkennung beinhalten. Zusätzlich kann die Rechenvorrichtung 900 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (intertia measurement unit - IMU)) beinhalten, die eine Bewegungsdetektion ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope durch die Rechenvorrichtung 900 verwendet werden, um immersive augmentierte Realität oder virtuelle Realität zu rendern.
Die Stromversorgung 916 kann auch eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon beinhalten. Die Stromversorgung 916 kann der Rechenvorrichtung 900 Strom bereitstellen, um den Komponenten der Rechenvorrichtung 900 den Betrieb zu ermöglichen.
Die Präsentationskomponent(en) 918 können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigearten oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten beinhalten. Die Präsentationskomponent(en) 918 können Daten von anderen Komponenten (z. B. den GPU(s) 908, den CPU(s) 906 usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
BEISPIEL RECHENZENTRUM
10 zeigt ein Beispiel für ein Rechenzentrum 1000, das in mindestens einer Ausführungsform der vorliegenden Offenbarung verwendet werden kann. Das Rechenzentrum 1000 kann eine Rechenzentrumsinfrastrukturschicht 1010, eine Framework-Schicht 1020, eine Softwareschicht 1030 und/oder eine Anwendungsschicht 1040 beinhalten.
Wie in 10 gezeigt, kann die Rechenzentrumsinfrastrukturschicht 1010 einen Ressourcenorchestrierer 1012, gruppierte Berechnungsressourcen 1014 und Knotenberechnungsressourcen („Knoten-CRs“) 1016(1)-1016(N) beinhalten, wobei „N“ eine beliebige ganze positive Zahl darstellt. In mindestens einer Ausführungsform können die Knoten-C.R.s 1016(1)-1016(N) eine beliebige Anzahl von zentralen Verarbeitungseinheiten („CPUs“) oder anderen Prozessoren (einschließlich Beschleunigern, feldprogrammierbaren Gate-Anordnungen (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Arbeitsspeichervorrichtungen (z. B. dynamischer Festwertspeicher), Datenspeichervorrichtungen (z. B. Solid-State- oder Festplattenlaufwerke), Netzwerk-Eingabe-/Ausgabe(„NW-I/O“)-Vorrichtungen, Netzwerk-Switches, virtuellen Maschinen („VMs“), Leistungsmodulen und Kühlmodulen usw. beinhalten, sind aber nicht darauf beschränkt. In einigen Ausführungsformen können einer oder mehreren Knoten-C.R.s unter den Knoten-C.R.s 1016(1)-1016(N) einem Server entsprechen, der eine oder mehrere der vorstehend erwähnten Rechenressourcen aufweist. Darüber hinaus können die Knoten C.R.s 1016(1)-10161 (N) in einigen Ausführungsformen eine oder mehrere virtuelle Komponenten beinhalten, wie z. B. vGPUs, vCPUs und/oder dergleichen, und/oder einer oder mehrere der Knoten C.R.s 1016(1)-1016(N) können einer virtuellen Maschine (VM) entsprechen.
In mindestens einer Ausführungsform können gruppierte Berechnungsressourcen 1014 getrennte Gruppierungen von Knoten-CR 1016 beinhalten, die in einem oder mehreren Racks (nicht gezeigt) untergebracht sind, oder vielen Racks, die in Rechenzentren an verschiedenen geografischen Standorten (ebenfalls nicht gezeigt) untergebracht sind. Getrennte Gruppierungen von Knoten-CR 1016 innerhalb gruppierter Rechenressourcen 1014 können gruppierte Rechen-, Netzwerk-, Arbeitsspeicher- oder Datenspeicherressourcen beinhalten, die konfiguriert oder zugewiesen sein können, um eine oder mehrere Rechenlasten zu unterstützen. In mindestens einer Ausführungsform können mehrere Knoten-CR 1016, die CPU, GPU und/oder Prozessoren beinhalten, in einem oder mehreren Racks gruppiert sein, um Rechenressourcen bereitzustellen, um eine oder mehrere Rechenlasten zu unterstützen. Das eine oder mehrere Racks können auch eine beliebige Anzahl von Leistungsmodulen, Kühlmodulen und Netz-Switches in beliebiger Kombination beinhalten.
Der Ressourcen-Orchestrator 1022 kann einen oder mehrere Knoten-CR 1016(1)-1016(N) und/oder gruppierte Rechenressourcen 1014 konfigurieren oder anderweitig steuern. In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 1022 eine Verwaltungseinheit für Software-Design-Infrastruktur („SDI“) für das Rechenzentrum 1000 beinhalten. Der Ressourcen-Orchestrator 1022 kann aus Hardware, Software oder einer Kombination davon bestehen.
In mindestens einer Ausführungsform, wie in 10 gezeigt, kann die Framework-Schicht 1020 einen Aufgabenplaner 1032, einen Konfigurations-Manager 1034, einen Ressourcen-Manager 1036 und ein verteiltes Dateisystem 1038 beinhalten. Die Framework-Schicht 1020 kann ein Framework zur Unterstützung von Software 1032 der Software-Schicht 1030 und/oder einer oder mehrerer Anwendung(en) 1042 der Anwendungsschicht 1040 beinhalten. Die Software 1032 bzw. die Anwendung(en) 1042 können webbasierte DienstSoftware oder -anwendungen beinhalten, wie sie beispielsweise von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. Die Framework-Schicht 1020 kann eine Art freies und quelloffenes Software-Webanwendungs-Framework wie Apache SparkTM (im nachfolgend „Spark“) sein, das ein verteiltes Dateisystem 1038 für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwenden kann, ohne darauf beschränkt zu sein. In mindestens einer Ausführungsform kann der Aufgabenplaner 1032 einen Spark-Treiber beinhalten, um die Planung von Arbeitslasten zu erleichtern, die durch verschiedene Schichten des Rechenzentrums 1000 unterstützt werden. Der Konfigurations-Manager 1034 kann in der Lage sein, unterschiedliche Schichten zu konfigurieren, z. B. die Software-Schicht 1030 und die Framework-Schicht 1020, einschließlich Spark und des verteilten Dateisystems 1038 zur Unterstützung der Verarbeitung großer Datenmengen. Der Ressourcen-Manager 1036 kann in der Lage sein, geclusterte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 1038 und des Aufgabenplaners 1032 zugeordnet oder zugewiesen sind. In mindestens einer Ausführungsform können geclusterte oder gruppierte Rechenressourcen die gruppierte Rechenressource 1014 auf der Rechenzentrumsinfrastrukturschicht 1010 beinhalten. Der Ressourcen-Manager 1036 und der Ressourcen-Orchestrator 1012 können sich aufeinander abstimmen, um diese zugeordneten oder zugewiesenen Rechenressourcen zu verwalten.
In mindestens einer Ausführungsform kann die in der Softwareschicht 1030 beinhaltete Software 1032 Software beinhalten, die durch mindestens Teile der Knoten-CR 1016(1)-1016(N), gruppierte Rechenressourcen 1014 und/oder das verteilte Dateisystem 1038 der Framework-Schicht 1020 verwendet werden. Eine oder mehrere Arten von Software können Internet-Webseiten-Suchsoftware, E-Mail-Virenscan-Software, Datenbanksoftware und Streaming-Videoinhalt-Software beinhalten, ohne darauf beschränkt zu sein.
In mindestens einer Ausführungsform kann/können die Anwendung(en) 1042, die in der Anwendungsschicht 1040 beinhaltet ist/sind, eine oder mehrere Arten von Anwendungen beinhalten, die durch mindestens Teile der Knoten-CR 1016(1)-1016(N), gruppierte Rechenressourcen 1014 und/oder das verteilte Dateisystem 1038 der Framework-Schicht 1020 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl einer Genomikanwendung, einer kognitiven Rechenanwendung und einer maschinellen Lernanwendung umfassen, die Trainings- oder Ableitungssoftware beinhaltet, Framework-Software des maschinellen Lernens (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere maschinelle Lernanwendungen beinhalten, ohne darauf beschränkt zu sein, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden.
In mindestens einer Ausführungsform können beliebige von dem Konfigurationsmanager 1034, Ressourcenmanager 1036 und Ressourcen-Orchestrator 1012 eine beliebige Anzahl und Art von selbstmodifizierenden Handlungen auf Grundlage einer beliebigen Menge und Art von Daten implementieren, die auf jede technisch machbare Weise erfasst werden. Selbstmodifizierende Handlungen können einen Rechenzentrumsbetreiber des Rechenzentrums 1000 dahingehend entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Abschnitte eines Rechenzentrums zu vermeiden.
Das Rechenzentrum 1000 kann Werkzeuge, Dienste, Software oder andere Ressourcen beinhalten, um ein oder mehrere Modelle des maschinellen Lernens zu trainieren oder Informationen unter Verwendung eines oder mehrerer Modelle des maschinellen Lernens gemäß einer oder mehreren in dieser Schrift beschriebenen Ausführungsformen vorherzusagen oder abzuleiten. Zum Beispiel kann/können ein Modell(e) für maschinelles Lernen trainiert werden, indem Gewichtungsparameter gemäß einer Architektur eines neuronalen Netzes unter Verwendung von Software und/oder Rechenressourcen berechnet werden, die vorstehend in Bezug auf das Rechenzentrum 1000 beschrieben sind. In mindestens einer Ausführungsform können trainierte oder eingesetzte Modelle für maschinelles Lernen, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um Informationen unter Verwendung der vorstehend in Bezug auf das Rechenzentrum 1000 beschriebenen Ressourcen zu inferenzieren oder vorherzusagen, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere hierin beschriebene Trainingstechniken berechnet werden, sind aber nicht darauf beschränkt.
In mindestens einer Ausführungsform kann das Rechenzentrum 1000 CPUs, anwendungsspezifische integrierte Schaltungen (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder die Inferenzierung mit den oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der oben beschriebenen Software- und/oder Hardwareressourcen als Dienst konfiguriert werden, der es dem Benutzer ermöglicht, Informationen zu trainieren oder zu inferieren, wie z.B. Bilderkennung, Spracherkennung oder andere Dienste künstlicher Intelligenz.
BEISPIELHAFTE NETZWERKUMGEBUNGEN
Netzwerkumgebungen, die für die Verwendung beim Implementieren von Ausführungsformen der Offenbarung geeignet sind, können ein oder mehrere Client-Vorrichtungen, Server, netzwerkverbundenen Speicher (network attached storage - NAS), andere Backend-Vorrichtungen und/oder andere Vorrichtungstypen beinhalten. Die Client-Vorrichtungen, -Server und/oder andere Vorrichtungsarten (z. B. jede Vorrichtung) können auf einer oder mehreren Instanzen der Rechenvorrichtung(en) 900 von 9 implementiert werden - z. B. kann jede Vorrichtung ähnliche Komponenten, Merkmale und/oder Funktionen der Rechenvorrichtung(en) 900 beinhalten. Wenn Backend-Vorrichtungen (z. B. Server, NAS usw.) implementiert werden, können die Backend-Vorrichtungen auch Teil eines Rechenzentrums 1000 sein, dessen Beispiel in 10 näher beschrieben wird.
Komponenten einer Netzwerkumgebung können miteinander über ein oder mehrere Netzwerke kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netzwerk kann mehrere Netzwerke oder ein Netzwerk von Netzwerken beinhalten. Beispielsweise kann das Netzwerk ein oder mehrere Weitverkehrsnetzwerke (WAN), ein oder mehrere lokale Netzwerke (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonvermittlungsnetz (publich switched telephone network - PSTN) und/oder ein oder mehrere private Netzwerke beinhalten. Wenn das Netzwerk ein drahtloses Telekommunikationsnetz beinhaltet, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Konnektivität bereitstellen.
Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebungen beinhalten - in diesem Fall kann ein Server nicht in einer Netzwerkumgebung beinhaltet sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung beinhaltet sein. In Peer-to-Peer-Netzwerkumgebungen kann die hierin in Bezug auf einen oder mehrere Server beschriebene Funktionalität auf einer beliebigen Anzahl von Client-Vorrichtungen implementiert sein.
In mindestens einer Ausführungsform kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. beinhalten. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Job-Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem beinhalten, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzwerkserver und/oder Edge-Server beinhalten können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Software-Schicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht beinhalten. Die Software oder Anwendung(en) können jeweils Web-basierte Dienstsoftware oder Anwendungen beinhalten. In Ausführungsformen können eine oder mehrere der Client-Vorrichtungen die Web-basierte Dienstsoftware oder Anwendungen verwenden (z. B. durch Zugreifen auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (API)). Bei der Framework-Schicht kann es sich um eine Art freies und quelloffenes Software-Webanwendungs-Framework handeln, das etwa ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwenden kann, ist aber nicht darauf beschränkt.
Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination von hierin beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführen. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von zentralen oder Kernservern (z. B. von einem oder mehreren Rechenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Wenn eine Verbindung zu einem Benutzer (z. B. einer Client-Vorrichtung) relativ nahe bei einem oder mehreren Edge-Servern ist, können ein oder mehrere Core-Server dem oder den Edge-Servern mindestens einen Teil der Funktionalität zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat sein (z. B. auf eine einzelne Organisation beschränkt), kann öffentlich sein (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon sein (z. B. eine Hybrid-Cloud-Umgebung).
Die Client-Vorrichtung(en) können mindestens eine der Komponenten, Merkmale und Funktionalität der hierin in Bezug auf 9 beschrieben Rechenvorrichtung(en) 900 beinhalten. Als Beispiel und nicht einschränkend kann eine Client-Vorrichtung als Personal Computer (PC), Laptop-Computer, mobile Vorrichtung, Smartphone, Tablet-Computer, Smartwatch, tragbarer Computer, Personal Digital Assistant (PDA), MP3-Player, Virtual-Reality-Headset, System oder Vorrichtung zur globalen Positionsbestimmung (GPS), Videoplayer, Videokamera, Überwachungsvorrichtung oder -system, Fahrzeug, Boot, Flugschiff, virtuelle Maschine, Drohne, Roboter, tragbare Kommunikationsvorrichtung, Vorrichtung in einem Krankenhaus, Spielgerät oder - system, Unterhaltungssystem, Fahrzeugcomputersystem, eingebetteter Systemcontroller, Fernbedienung, Haushaltsgerät, Unterhaltungselektronikgerät, Workstation, Edge-Vorrichtung, eine beliebige Kombination dieser skizzierten Vorrichtungen oder jede andere geeignete Vorrichtung verkörpert sein.
Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinenverwendbaren Anweisungen beschrieben werden, einschließlich computerausführbarer Anweisungen wie etwa Programmmodulen, die von einem Computer oder einer anderen Maschine wie etwa einem Personal Data Assistant oder einem anderen Handgerät ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw. auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Vorrichtungen, Unterhaltungselektronik, Allzweckcomputern, spezielleren Rechenvorrichtungen usw. Die Offenbarung kann auch in verteilten Rechenumgebungen praktiziert werden, in denen Aufgaben von entfernten Verarbeitungsvorrichtungen, die über ein Kommunikationsnetz verbunden sind, durchgeführt werden.
Wie hierin verwendet, sollte eine Rezitation von „und/oder“ in Bezug auf zwei oder mehr Elemente so ausgelegt werden, dass sie nur ein Element oder eine Kombination von Elementen bedeutet. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder Elemente enthalten A, B und C. Außerdem kann „mindestens eines von Element A oder Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element umfassen B. Ferner kann „mindestens eines von Element A und Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B beinhalten.
Der Gegenstand der vorliegenden Offenbarung wird hierin spezifisch beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Erwägung gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um andere Schritte oder Kombinationen von Schritten ähnlich den in diesem Dokument beschriebenen in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien einzuschließen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden können, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sollten die Begriffe darüber hinaus nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge zwischen oder zwischen verschiedenen hierin offenbarten Schritten implizieren, es sei denn, die Reihenfolge ist der einzelnen Schritte ist explizit beschrieben.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 16101232 [0120]

Claims

Verfahren zum Auswählen einer Trajektorie für eine autonome Maschine, wobei das Verfahren umfasst: Erzeugen eines Fahrspurgraphen, welcher eine erste Reihe von Zeitgewinnen für potentielle zukünftige Positionen der autonomen Maschine umfasst; Erzeugen einer Vielzahl von möglichen Trajektorien, welche es der autonomen Maschine ermöglichen, eine Aktion der autonomen Maschine zu vollenden; Erzeugen eines Optimierungsmaßes für die möglichen Trajektorien unter Verwendung der ersten Reihe von Zeitgewinnen als Eingabe; Auswählen einer Trajektorie zur Anwendung unter Verwendung des Optimierungsmaßes; und Anwenden der Trajektorie unter Verwendung der autonomen Maschine.
Verfahren nach Anspruch 1, welches darüber hinaus ein Auswählen einer Route zwischen einem Startpunkt und einem Routenziel unter Verwendung eines geographischen Datensatzes für ein erstes geographisches Gebiet als Eingabe umfasst.
Verfahren nach Anspruch 2, wobei die erste Reihe von Zeitgewinnen eine Reihe von aufeinanderfolgenden Zeitgewinnen umfasst, welche unter Verwendung von Fahrspurinformationen für ein zweites geographisches Gebiet berechnet werden, welches kleiner als das erste geographische Gebiet ist.
Verfahren nach Anspruch 3, wobei die Vielzahl der möglichen Trajektorien unter Verwendung detaillierter Fahrspurinformationen für ein drittes geografisches Gebiet, welches kleiner als das zweite geografische Gebiet ist, erzeugt wird.
Verfahren nach Anspruch 3, wobei die erste Reihe von Zeitgewinnen ohne Szeneninformationen aus einem lokalen Weltmodell berechnet wird, welches für Objekte repräsentativ ist, welche von Sensoren der autonomen Maschine erfasst werden.
Verfahren nach Anspruch 1, wobei das Verfahren darüber hinaus ein Erzeugen einer Szenenvorhersage umfasst, welche eine vorhergesagte zukünftige Objektposition für ein von Sensoren der autonomen Maschine erfasstes Objekt aufweist.
Verfahren nach Anspruch 1, wobei die Aktion der autonomen Maschine unter Verwendung der ersten Reihe von Zeitgewinnen als Eingabe ausgewählt wird.
Verfahren nach Anspruch 1, wobei der Fahrspurgraph eine zweite Reihe von Zeitgewinnen für mögliche zukünftige Positionen der autonomen Maschine auf einer zweiten Fahrspur einer Route umfasst.
Verfahren zum Auswählen einer Trajektorie für eine autonome Maschine, wobei das Verfahren umfasst: Erzeugen einer Szenenvorhersage, welche eine vorhergesagte zukünftige Objektposition für ein Objekt aufweist, welches von einem oder mehreren Sensoren, welche mit der autonomen Maschine korrespondieren, erfasst wird; Erzeugen einer Vielzahl möglicher Trajektorien für eine Aktion der autonomen Maschine, wobei die Vielzahl der möglichen Trajektorien eine Vielzahl von Längsbedingungen und Querbedingungen innerhalb einer nominal breiten Bahn aufweist, welche der Aktion der autonomen Maschine entspricht; Bewerten der Vielzahl der möglichen Trajektorien unter Verwendung der Szenenvorhersage und einer ersten Reihe von Zeitgewinnen, welche mit einer Vielzahl möglicher zukünftiger Positionen der autonomen Maschine korrespondieren, um ein Optimierungsmaß für die Vielzahl der möglichen Trajektorien zu erzeugen; Auswählen, unter Verwendung des Optimierungsmaßes, einer Trajektorie für einen Startparametersatz, welcher verwendet wird, um zusätzliche Trajektorien zur Bewertung zu erzeugen; Auswählen einer individuellen Trajektorie aus den zusätzlichen Trajektorien unter Verwendung des Optimierungsmaßes; und Anwenden der individuellen Trajektorie für die autonome Maschine.
Verfahren nach Anspruch 9, wobei unter Verwendung der Szenenvorhersage Längsgrenzen für die Aktion der autonomen Maschine erzeugt werden.
Verfahren nach Anspruch 9, welches darüber hinaus umfasst: Auswählen einer zusätzlichen Aktion der autonomen Maschine für ein detailliertes Planen; Erzeugen einer zusätzlichen Vielzahl von Trajektorien für die zusätzliche Aktion der autonomen Maschine; und Auswerten der zusätzlichen Trajektorien in der zusätzlichen Vielzahl von Trajektorien unter Verwendung der Szenenvorhersage und der ersten Reihe von Zeitgewinnen, um das Optimierungsmaß für die zusätzlichen Trajektorien zu erzeugen.
Verfahren nach Anspruch 9, wobei das Auswählen der Aktion der autonomen Maschine unter Verwendung eines Fahrspurgraphen als Auswahl von Eingabedaten durchgeführt wird.
Verfahren nach Anspruch 9, welches darüber hinaus ein Auswählen einer Route zwischen einem Startpunkt und einem Routenziel unter Verwendung eines geographischen Datensatzes für ein erstes geographisches Gebiet als Eingabe umfasst.
Verfahren nach Anspruch 13, wobei die erste Reihe von Zeitgewinnen unter Verwendung von Fahrspurinformationen für ein zweites geographisches Gebiet, welches kleiner als das erste geographische Gebiet ist, berechnet wird.
Verfahren nach Anspruch 9, wobei die erste Reihe von Zeitgewinnen mit einem kommentierten Fahrspurgraphen korrespondiert, welcher eine zweite Reihe von aufeinanderfolgenden Zeitgewinnen für potentielle zukünftige Positionen der autonomen Maschine umfasst.
Verfahren nach Anspruch 9, wobei die erste Reihe von Zeitgewinnen ohne Szeneninformationen von einem lokalen Weltmodell berechnet wird, welches für Objekte repräsentativ ist, welche von dem einen oder den mehreren Sensoren der autonomen Maschine erfasst werden.
Prozessor umfassend: eine oder mehrere Verarbeitungseinheiten, um eine Vielzahl möglicher Trajektorien für eine Aktion einer autonomen Maschine zu erzeugen, wobei die Vielzahl der möglichen Trajektorien eine Vielzahl von Längsbedingungen und eine Vielzahl von Querbedingungen aufweist, um Trajektorien in der Vielzahl der möglichen Trajektorien unter Verwendung einer Szenenvorhersage zu bewerten, um ein Optimierungsmaß für die Trajektorien zu erzeugen, um eine individuelle Trajektorie aus der Vielzahl der möglichen Trajektorien unter Verwendung des Optimierungsmaßes auszuwählen, und um die individuelle Trajektorie für eine autonome Maschine anzuwenden, wobei die Vielzahl der Längsbedingungen zumindest auf der Szenenvorhersage basiert, und wobei die Vielzahl der Querbedingungen zumindest auf einer nominalen Bahn basiert, welche einer Fahrtrichtung der autonomen Maschine entspricht.
Prozessor nach Anspruch 17, wobei die eine oder die mehreren Verarbeitungseinheiten darüber hinaus einen kommentierten Fahrspurgraphen erzeugen, welcher eine erste Reihe von Zeitgewinnen für potentielle zukünftige Positionen der autonomen Maschine auf einer ersten Fahrspur der Fahrtrichtung der autonomen Maschine umfasst, wobei ein individueller Zeitgewinn für eine Fahrzeit zu einem Routenziel repräsentativ ist.
Prozessor nach Anspruch 17, wobei die eine oder die mehreren Verarbeitungseinheiten darüber hinaus vorhanden sind: um unter Verwendung des Optimierungsmaßes eine Trajektorie für einen Startparametersatz auswählen, welcher verwendet wird, um zusätzliche Trajektorien zur Bewertung zu erzeugen; und um die zusätzlichen Trajektorien unter Verwendung der Szenenvorhersage zu bewerten, um das Optimierungsmaß für die zusätzlichen Trajektorien zu erzeugen.
Prozessor nach Anspruch 19, wobei die zusätzlichen Trajektorien eine neue Vielzahl von Längs- und Querbedingungskombinationen aufweisen, welche nicht in der Vielzahl der möglichen Trajektorien gefunden werden.