DE102022119206A1

DE102022119206A1 - Verhaltensplanung für autonome Fahrzeuge in Vorfahrtszenarien

Info

Publication number: DE102022119206A1
Application number: DE102022119206.7A
Authority: DE
Inventors: Fangkai Yang; David Nister; Yizhou Wang; Rotem Aviv; Julia Ng; Birgit Henke; Hon Leung Lee; Yunfei Shi
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2021-08-05
Filing date: 2022-08-01
Publication date: 2023-02-09
Also published as: CN115705060A; US11926346B2; US20230037767A1; JP2023024276A

Abstract

In verschiedenen Beispielen kann ein Vorfahrtszenario für ein erstes Fahrzeug identifiziert werden. Es wird ein Warteelement empfangen, das einen ersten Weg für das erste Fahrzeug zum Durchqueren eines Vorfahrtbereichs und einen zweiten Weg für ein zweites Fahrzeug zum Durchqueren des Vorfahrtbereichs codiert. Der erste Weg wird verwendet, um mindestens auf einer ersten Position des ersten Fahrzeugs zu einem Zeitpunkt basierend eine erste Trajektorie in dem Vorfahrtbereich für das erste Fahrzeug zu bestimmen, und der zweite Weg wird verwendet, um mindestens auf einer zweiten Position des zweiten Fahrzeugs zu dem Zeitpunkt basierend eine zweite Trajektorie in dem Vorfahrtbereich für das zweite Fahrzeug zu bestimmen. Um das erste Fahrzeug gemäß einem Wartezustand zu betreiben, kann bestimmt werden, ob ein Konflikt zwischen der ersten Trajektorie und der zweiten Trajektorie besteht, wobei der Wartezustand ein Vorfahrtsverhalten für das erste Fahrzeug definiert.

Description

HINTERGRUND
Fortschritte bei Verfahren des maschinellen Sehens, Architekturen neuronaler Netze und Rechensubstraten ermöglichen allmählich autonome Fahrzeuge, wie z. B. landgestützte autonome Fahrzeuge (z. B. selbstfahrende Autos und Lastwagen). Damit die öffentlichen und staatlichen Regulierungsbehörden einen breiten Einsatz von selbstfahrenden Autos und Lastwagen auf den Straßen akzeptieren, müssen die selbstfahrenden Autos und Lastwagen ein Sicherheitsniveau erreichen, das das derzeitige Sicherheitsniveau eines durchschnittlichen menschlichen Fahrers übertrifft. Sicheres und effektives Fahren erfordert, dass die Fahrer darauf vertrauen können, dass andere Fahrzeuge in der Umgebung ordnungsgemäß die Vorfahrt gewähren, wenn sie dazu verpflichtet sind. Wenn ein Fahrzeug nicht die Vorfahrt gewährt, kann es sein, dass die Fahrer anderer Fahrzeuge in der Nähe nicht in der Lage sind, sicher und effizient zu fahren, weil andere Fahrer „unberechenbar“ sind, z. B. Fahrer, die durch ihr Verhalten signalisiert haben, dass sie möglicherweise nicht die Vorfahrt gewähren, wenn sie dazu verpflichtet sind. Eine notwendige Voraussetzung für den Einsatz selbstfahrender Autos und Lastwagen ist daher die Fähigkeit, erfolgreich, sicher und „höflich“ Vorfahrtszenarien zu passieren - Szenarien, in denen die Gewährung der Vorfahrt angebracht sein kann (z. B. an Kreuzungen und einmündenden Fahrspuren).
Normalerweise schreiben die örtlichen Verkehrsvorschriften und die Fahrnormen und -praktiken vor, welche Fahrzeugführer (und unter welchen Bedingungen) die Verantwortung oder Verpflichtung haben, anderen Vorfahrt zu gewähren. Zu diesen Vorschriften gehören Verkehrsgesetze (z. B. müssen Fahrzeuge Fußgängern an einem Zebrastreifen Vorrang gewähren), situationsbedingte Beschilderung (z. B. ein Straßenschild, das anzeigt, welche Zufahrten in eine Kreuzung anderen Zufahrten Vorfahrt gewähren müssen) und andere Echtzeithinweise (z. B. die nahezu gleichzeitige Ankunft mehrerer Fahrzeuge in einem Kreisverkehr). Herkömmliche autonome Fahrzeuge sind jedoch nicht in der Lage, solche Protokolle zu codieren und einzusetzen. Stattdessen können konventionelle Systeme versuchen, Kollisionen zu vermeiden, ohne dabei Vorfahrtsgewährungsprotokolle zu berücksichtigen, und sind daher nicht in der Lage, in Vorfahrtszenarien sicher und vorhersehbar zu navigieren oder umgekehrt auf unbestimmte Zeit Vorfahrt zu gewähren, bis sich keine anderen Fahrzeuge mehr im Konkurrenzbereich befinden.
Zusammenfassung
Ausführungsformen der vorliegenden Offenbarung betreffen die Verhaltensplanung für autonome Fahrzeuge in Vorfahrtszenarien. Es werden Systeme und Verfahren offenbart, die die Echtzeitsteuerung von landgestützten autonomen Fahrzeugen ermöglichen, wenn sich die Fahrzeuge einem Vorfahrtszenario nähern.
Im Gegensatz zu herkömmlichen Systemen, wie den oben beschriebenen, ermöglichen es offenbarte Ausführungsformen autonomen Fahrzeugen, Vorfahrtszenarien auf sichere und vorhersehbare Weise zu passieren. In mindestens einer Ausführungsform kann ein Vorfahrtszenario für ein erstes Fahrzeug identifiziert werden, indem Sensordaten analysiert werden, die von einem Sensor des ersten Fahrzeugs in einer Umgebung erzeugt werden. Ein oder mehrere Warteelemente können in Verbindung mit dem Vorfahrtszenario empfangen werden. Ein Warteelement kann eine Warteelementdatenstruktur sein. Die Warteelementdatenstruktur kann verschiedene Aspekte des zugehörigen Vorfahrtsszenarios codieren. Ein Warteelement kann einen Wartezustand, eine Wartegeometrie und/oder Ego-Informationen für einen bestimmten Konkurrenz zwischen dem Ego und einem Konkurrenten codieren. Ein Warteelement kann verwendet werden, um einen ersten Weg für das erste Fahrzeug zum Durchqueren eines Vorfahrtbereichs in der Umgebung und einen zweiten Weg für ein zweites Fahrzeug zum Durchqueren des Vorfahrtbereichs zu codieren. Der erste Weg kann verwendet werden, um eine erste Trajektorie im Vorfahrtbereich für das erste Fahrzeug zu bestimmen, die mindestens auf einem ersten Standort des ersten Fahrzeugs zu einem bestimmten Zeitpunkt (z. B. einem aktuellen Zeitpunkt) basiert. Der zweite Weg kann verwendet werden, um eine zweite Trajektorie im Vorfahrtbereich für das zweite Fahrzeug zu bestimmen, die mindestens auf einem zweiten Standort des zweiten Fahrzeugs zu einem bestimmten Zeitpunkt basiert. Die Trajektorien können verwendet werden, um zu bewerten, ob es eine Konkurrenz zwischen der ersten Trajektorie und der zweiten Trajektorie gibt, basierend auf einem Wartezustand, der dem Warteelement zugeordnet ist. Durch die Bewertung des Konkurrenzpotentials zwischen den beiden Trajektorien kann der Wartezustand verwendet werden, um ein Vorfahrtsverhalten für das erste Fahrzeug zu definieren.
Figurenliste
Die vorliegenden Systeme und Verfahren zur Verhaltensplanung für autonome Fahrzeuge in Vorfahrtsszenarien werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungsfiguren detailliert beschrieben, wobei:

1 ist ein Beispiel für ein Vorfahrtsplanungssystem gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
2 ist ein Beispiel für eine Zustandsmaschine, die einem aus Anhalten an der Einfahrt und dann Vorfahrtsgewährung zusammengesetzten Zustand entspricht, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
3 ist ein Flussdiagramm, das ein Verfahren zum Steuern eines autonomen Fahrzeugs (z. B. eines Ego-Fahrzeugs) gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
4 ist ein Flussdiagramm, das ein Verfahren zur Identifizierung von Kreuzungen und Einmündungen für beanspruchte Wege für ein Vorfahrtsszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
5 ist ein Flussdiagramm, das ein Verfahren zur Erzeugung von Trajektorien für Kreuzungen und Einmündungen für ein Vorfahrtsszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
6 ist ein Flussdiagramm, das ein Verfahren zur Analyse von Kreuzungstrajektorien für ein Vorfahrtsszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
7 ist ein Flussdiagramm, das ein Verfahren zur Analyse von Einmündungs-Trajektorien für ein Vorfahrtsszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
8A ist eine Darstellung 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 autonome Fahrzeug der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8D ist ein Systemdiagramm für die Kommunikation zwischen einem oder mehreren Cloud-basierten Server(n) und dem beispielhaften autonomen Fahrzeug der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
9 ist ein Blockdiagramm eines beispielhaften Rechenvorrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
10 ist ein Blockdiagramm eines beispielhaften Datenzentrums, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.

Ausführliche Beschreibung
Es werden Systeme und Verfahren offenbart, die die Verhaltensplanung für autonome Fahrzeuge in Vorfahrtsszenarien betreffen. Obwohl die vorliegende Offenbarung in Bezug auf ein beispielhaftes autonomes Fahrzeug 800 beschrieben wird, (hier alternativ als „Fahrzeug 800“ oder „Ego-Fahrzeug 800“ bezeichnet, von dem ein Beispiel in Bezug auf die 8A-8D beschrieben ist), ist dies nicht als Einschränkung zu verstehen. Beispielsweise können die hier beschriebenen Systeme und Verfahren ohne Einschränkung von nicht-autonomen Fahrzeugen, halbautonomen Fahrzeugen (z. B. in einem oder mehreren adaptiven Fahrerassistenzsystemen (ADAS)), pilotierten und nicht pilotierten Robotern oder Roboterplattformen, Lagerfahrzeugen, Geländefahrzeugen, Fahrzeugen, die mit einem oder mehreren Anhängern gekoppelt sind, Flugschiffen, Booten, Shuttles, Notarzteinsatzfahrzeugen, Motorrädern, elektrischen oder motorisierten Fahrrädern, Flugzeugen, Baufahrzeugen, Unterwasserfahrzeugen, Drohnen und/oder anderen Fahrzeugtypen verwendet werden. Obwohl die vorliegende Offenbarung in Bezug auf die Steuerung eines landgestützten autonomen Fahrzeugs zur Bewältigung eines Vorfahrtszenarios beschrieben wird, ist dies nicht als Einschränkung zu verstehen, und die hier beschriebenen Systeme und Verfahren können in erweiterter Realität, virtueller Realität, gemischter Realität, Robotik, Sicherheit und Überwachung, autonome oder halbautonome Maschinenanwendungen und/oder in jedem anderen Technologiebereich eingesetzt werden, in dem autonome Steuersysteme verwendet werden können.
Im normalen Betrieb eines autonomen Fahrzeugs muss ein Steueragent sowohl fahrende als auch nicht fahrende Hindernisse vermeiden (z. B. andere Fahrzeuge, Fußgänger, Radfahrer, Fahrbahnbegrenzungen und dergleichen). Neben der Vermeidung von Kollisionen hat ein Agent grundsätzlich die Verantwortung, anderen Verkehrsteilnehmern in bestimmten Szenarien Vorfahrt zu gewähren (z. B. „Vorfahrtbedingungen“). Solche Vorfahrtsregeln können an (kontrollierten und unkontrollierten) Kreuzungen, Fußgängerüberwegen, Einmündungen, Auf-/Abfahrten auf Autobahnen (oder Fernstraßen), Kreisverkehren usw. gelten, z. B. bei der Durchfahrt durch Parkhäuser und/oder Parkplätze. Um einem anderen Verkehrsteilnehmer die Möglichkeit zu geben, die Vorfahrtsituation sicher, souverän und effizient „zu klären“, kann das Vorfahrtsverhalten ein Abbremsen oder sogar ein vollständiges Anhalten des Fahrzeugs beinhalten. An einer nicht markierten Kreuzung, an der bereits ein anderes Fahrzeug angekommen ist, kann ein nachfolgendes Fahrzeug ein angemessenes Vorfahrtsverhalten an den Tag legen, indem es abbremst, damit das erste Fahrzeug die Kreuzung sicher passieren kann. Ein solches Vorfahrtsverhalten stellt sicher, dass das nachfolgende Fahrzeug erst in die Kreuzung einfährt, wenn das erste Fahrzeug die Kreuzung sicher verlassen hat. Unter solchen Vorfahrtsbedingungen können ein oder mehrere Verkehrsteilnehmer eine klar definierte Verpflichtung (oder Verantwortung) haben, anderen Verkehrsteilnehmern Vorfahrt zu gewähren.
Das Vorfahrtsverhalten stellt einen Nutzen über die reine Vermeidung von Kollisionen bereit. Richtiges Vorfahrtsverhalten kann eine „höfliche“ und „erwartete“ Fahrdynamik sicherstellen, die für einen sicheren und effizienten Verkehr erforderlich ist. Selbst wenn beispielsweise ein Agent unter einer Vorfahrtsbedingung eine mögliche Kollision vermeidet (z. B. indem durch eine Kreuzung beschleunigt), erzeugt das Unterlassen die Vorfahrt zu gewähren, wenn es eine Verpflichtung dazu gibt, angespannte und nervöse Fahrbedingungen für alle Verkehrsteilnehmer in dem Bereich. Selbst wenn man beschleunigt, um einen Zusammenstoß zu vermeiden, kann ein die Vorfahrt nicht gewährendes Fahrzeug bei anderen Fahrern, Radfahrern und Fußgängern Angst, ein Gefühl der Gefahr und Wut (z. B. Gewalt im Straßenverkehr) auslösen. Das heißt, selbst wenn eine Kollision durch aggressives Handeln vermieden wird, wurde die Kollision nicht auf „sichere und höfliche Weise“ vermieden, wie es von anderen Verkehrsteilnehmern erwartet wird. Dementsprechend kann beim Betrieb eines autonomen Fahrzeugs ein Agent für das autonome Fahrzeug verpflichtet sein (z. B. entweder rechtlich oder normativ), eine oder mehrere verhaltensbezogene Vorfahrtstrategien anzuwenden, wenn er sich einem Vorfahrtszenario nähert.
Im Gegensatz zu herkömmlichen Systemen sieht die Offenbarung einen „Vorfahrtsplaner“ für ein autonomes Fahrzeug („Ego-Fahrzeug“) vor, der aktiv das Eintreffen einer oder mehrerer Vorfahrtbedingungen überwacht (z. B. wenn das Fahrzeug an einer Kreuzung ankommt, wenn das Fahrzeug eine Auf- oder Abfahrt befährt oder wenn das Fahrzeug einen Spurwechsel vorbereitet). Wenn eine Vorfahrtbedingung erkannt wird, kann der Vorfahrtsplaner ein geeignetes Vorfahrtsverhalten festlegen (z. B. Anhalten an der Einfahrt, Vorfahrt gewähren usw.). Wenn ein Steueragent für das Ego-Fahrzeug das festgelegte Vorfahrtsverhalten anwendet, kann das Ego-Fahrzeug seine erforderlichen und erwarteten Vorfahrtverpflichtungen sicher erfüllen und gleichzeitig Kollisionen vermeiden.
Im Betrieb kann der Vorfahrtsplaner die Beziehung zwischen der longitudinalen Vorwärtsbewegung des Ego-Fahrzeugs (z. B. zeitlich vorausschauend) und der longitudinalen Vorwärtsbewegung anderer Verkehrsteilnehmer (z. B. Konkurrenten) analysieren. Der Vorfahrtsplaner kann das Vorfahrtsverhalten des Ego-Fahrzeugs und der anderen Verkehrsteilnehmer bestimmen und vorhersagen, ob die anderen Verkehrsteilnehmer erwartungsgemäß die Vorfahrt gewähren. Bei der Annäherung an ein Fahrszenario, das beinhalten kann, die ein Vorfahrt zu gewähren (z. B. ein Vorfahrtszenario), kann der Vorfahrtsplaner ein oder mehrere Warteelemente empfangen, die solche Informationen codieren können wie einen oder mehrere Wartezustände (die ein bestimmtes Vorfahrtsverhalten definieren), eine Menge von „beanspruchten Wegen“ oder Fahrspuren, die mindestens teilweise in einem Vorfahrtbereich für das Ego-Fahrzeug liegen, sowie Mengen von beanspruchten Wegen oder Fahrspuren, die mindestens teilweise im Vorfahrtbereich für jeden Konkurrenten liegen, der für das Vorfahrtszenario relevant ist.
Es können Vorwärtssimulationen der beanspruchten Wege durchgeführt werden, um Trajektorien zu erzeugen (wobei angenommen werden kann, dass Wege außerhalb einer zeitlichen Dimension existieren, während Trajektorien in eine Raum-Zeit-Vielfalt eingebettet sein können). Die Trajektorien können getestet werden, um festzustellen, ob sich die Trajektorie des Ego-Fahrzeugs während der Zeit, in der sich die Trajektorie eines Konkurrenten im Vorfahrtbereich befindet, innerhalb eines Vorfahrtbereichs befindet. Die Welt kann als zweidimensionales räumliches Terrain modelliert werden, mit Raumkoordinaten (x, y) und Akteuren, die sich in der Zeit t bewegen. Für jede beliebige Zeit t können beanspruchte Mengen von Fahrzeugen betrachtet werden. Die beanspruchten Mengen können sich auch zeitlich erstrecken (in der Zukunft ab t). So können die beanspruchten Mengen in einer sich zeitlich entwickelnden 3D-Raum-Zeit-Mannigfaltigkeit existieren. Es können mehrere verschiedene Zeiten berücksichtigt werden, so dass die Analyse des Vorfahrtsplaners in mindestens einer 4D-Raum-Zeit-Mannigfaltigkeit mit zwei räumlichen und zwei zeitlichen Dimensionen durchgeführt werden kann. Die beiden zeitlichen Koordinaten können miteinander in Beziehung stehen und daher über diese Beziehung zu einer einzigen zeitlichen Koordinate zusammengefasst werden. In bestimmten Ausführungsformen können die zeitlichen Achsen jedoch getrennt bleiben, um die Analyse der Trajektorien der Fahrzeuge durch die Raumzeit zu vereinfachen. Die zeitliche Koordinate, die sich auf das Überstreichen der beanspruchten Mengen bezieht, kann als z bezeichnet werden, was den 3D-Raum der beanspruchten Mengen parametrisiert.
Die Analyse des Vorfahrtsplaners kann in mehrere Stufen unterteilt werden. In einer ersten Phase können Interferenzpaare (oder Konkurrenzpunkte) zwischen Punkten auf den Wegen in Form von Kreuzungen (dargestellt als Wegintervallpaare, die als Ganzes interferieren) und Einmündungen (dargestellt als Wegintervallpaare, die als gleich oder mindestens ähnlich eingestuft werden) gefunden werden. In einem zweiten Schritt kann untersucht werden, wie sich die Akteure und ihre beanspruchten Mengen entlang ihrer individuellen Wege entwickeln.
In der ersten Phase können die beanspruchten Wege verwendet werden, um alle potentiellen Interferenzen zwischen dem Ego-Fahrzeug und jedem der Konkurrenten zu ermitteln. Die physikalischen Ausdehnungen des Ego-Fahrzeugs und der Konkurrenten können als Begrenzungsrahmen (oder Formen) um die beanspruchten Wege modelliert werden. In der zweiten Phase können für jede potentielle Interferenz mehrere Trajektorien bestimmt werden (jede Trajektorie beginnt bei aufeinander folgenden Zeitwerten). Jede Trajektorie kann als dynamische Gleichung zweiter Ordnung modelliert werden, die Obergrenzen für die Größe der Beschleunigungen der einzelnen Fahrzeuge annimmt. Die dynamischen Gleichungen können verwendet werden, um eine Schnittmenge in den Zeitbereichen zu bestimmen, die die Fahrzeuge innerhalb des Vorfahrtbereichs verbringen (entsprechend den modellierten Trajektorien). Je nachdem, ob die ermittelte Schnittmenge der Zeitbereiche die Nullmenge oder eine nicht leere Menge ist, kann für das Ego-Fahrzeug ein Vorfahrtsverhalten gewählt werden (z. B. um in einen Wartezustand einer Zustandsmaschine mit einem oder mehreren Wartezuständen, die das Vorfahrtsverhalten steuern, vorzurücken oder dort zu bleiben).
Bezugnehmend auf 1 ist 1 ein Beispiel für ein Vorfahrtsplanungssystem 100 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dienen. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, 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. Außerdem sind viele der hier beschriebenen Elemente 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 werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können von 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.
Wie bereits erwähnt, kann ein Vorfahrtsverhalten erforderlich sein, wenn ein Fahrzeug (z. B. ein Auto, ein Lkw, ein Motorrad, ein Motorroller oder ähnliches) betrieben wird, das den „Verkehrsregeln“ unterliegt. Ein Szenario oder eine Situation, die zu einem erforderlichen Vorfahrtsverhalten führt, kann als Vorfahrts- (oder Vorfahrtsgewährungs-) Szenario bezeichnet werden. Beispiele für Vorfahrtszenarien sind Szenarien, in denen mehrere Akteure (z. B. Fahrzeuge, Fußgänger, Radfahrer usw.) anwesend sind, und können Fahrbahnelemente umfassen, wie z. B. mehrspurige Kreuzungen, zusammenlaufende Fahrspuren, Auf- und Abfahrten von Autobahnen oder Schnellstraßen, Ampeln und/oder Verkehrsschilder, Fußgängerüberwege, Baustellenbereiche, Parkplätze/Strukturen, Kreisverkehre und ähnliches. Um ein sicheres und rücksichtsvolles Navigieren auf den Straßen zu gewährleisten, kann ein Vorfahrtsszenario gesetzlich erzwungene Vorfahrtspflichten und/oder sozial erzwungene Vorfahrtspflichten (z. B. normative Vorfahrtspflichten) enthalten. Bei der Annäherung an ein Vorfahrtszenario kann ein Steueragent für ein autonomes Fahrzeug (z. B. das erste Fahrzeug 140) das Vorfahrtplanungssystem 100 einsetzen, um das Vorfahrtszenario zu erkennen und ein Vorfahrtsverhalten für das Fahrzeug zu bestimmen, das die gesetzlichen und normativen Vorfahrtpflichten des autonomen Fahrzeugs erfüllt.
Im Allgemeinen kann das Vorfahrtplanungssystem 100 Sensordaten empfangen, die einen oder mehrere Aspekte einer Umgebung 126 codieren, und die Sensordaten verwenden, um ein Vorfahrtszenario zu erkennen. Als Reaktion auf die Erkennung eines Vorfahrtszenarios kann das Vorfahrtplanungssystem 100 ein geeignetes Verhalten (z. B. ein Vorfahrtsverhalten) für ein beispielhaftes autonomes Fahrzeug 140 (hierin alternativ als „erstes Fahrzeug 140“ oder „autonomes Fahrzeug 140“ bezeichnet) bestimmen, von dem ein Beispiel hierin in Bezug auf die 8A-8D näher beschrieben ist, für den Fall, dass ein Vorfahrtszenario unter Verwendung der Sensordaten erkannt wird. Das ermittelte Vorfahrtsverhalten kann an ein Steuersystem (oder einen Steueragenten) des autonomen Fahrzeugs 140 übermittelt werden. Der Steueragent kann das Fahrzeug 140 gemäß dem ermittelten Vorfahrtsverhalten betreiben, so dass das Fahrzeug 140 das Vorfahrtszenario erfolgreich durchfährt. In Ausführungsformen kann das erfolgreiche Durchfahren eines Vorfahrtszenarios beinhalten, dass das Fahrzeug 140 erfolgreich Kollisionen mit anderen Akteuren vermeidet, die mit dem Vorfahrtszenario verbunden sind, während es gleichzeitig die gesetzlichen und normativen Vorfahrtpflichten des Fahrzeugs 140 erfüllt, z. B. das Fahrzeug 140 „räumt“ das Vorfahrtszenario ohne Zwischenfälle und in einer „sicheren und höflichen Weise“, wie es von anderen erwartet wird. Das Vorfahrtplanungssystem 100 kann ein Subsystem des Steuersystem des Fahrzeugs 140 sein (z. B. der Steueragent des Fahrzeugs). Der Klarheit und Kürze halber sind andere Komponenten des Steuersystems des Fahrzeugs 140 außerhalb des Vorfahrtplanungssystems 100 in 1 nicht dargestellt.
Das in der Umgebung 126 dargestellte Vorfahrtszenario ist ein kreuzungsbasiertes Vorfahrtszenario (z. B. eine Kreuzung), bei dem sich das autonome Fahrzeug 140 einem Vorfahrtbereich 130 nähert (z. B. dem Zentrum der Kreuzung, wo das autonome Fahrzeug 140 und ein oder mehrere andere Akteure möglicherweise kollidieren können). Zusätzlich zum autonomen Fahrzeug 140 umfasst das Vorfahrtszenario (dargestellt in 1) weitere Fahrzeuge 142 und 144, die sich dem Vorfahrtbereich 130 nähern, dort ankommen und/oder ihn durchfahren. Aus Gründen der Übersichtlichkeit kann das autonome Fahrzeug 140 als erstes Fahrzeug 140 (oder Ego-Fahrzeug 140), das zusätzliche Fahrzeug 142 als zweites Fahrzeug 142 und das zusätzliche Fahrzeug 144 als drittes Fahrzeug 144 bezeichnet werden. Da die Ausführungsformen auf die Steuerung des Vorfahrtsverhaltens des ersten Fahrzeugs 140 ausgerichtet sind, können andere Akteure, denen das erste Fahrzeug die Vorfahrt gewähren muss (z. B. das zweite Fahrzeug 142 und das dritte Fahrzeug 144), als Konkurrenten bezeichnet werden.
Konkurrenten können, müssen aber nicht Fahrzeuge sein, sondern können auch andere Akteure wie Fußgänger, Radfahrer usw. umfassen. Konkurrenten, die im Allgemeinen durch eine Fahrbahn eingeschränkt sind, können als nicht-holonome Konkurrenten bezeichnet werden, während Konkurrenten mit größeren Freiheitsgraden (z. B. Konkurrenten, die nicht notwendigerweise durch die Fahrbahn eingeschränkt sind) als holonome Konkurrenten bezeichnet werden können. Zum Beispiel können Autos, Lastwagen und Motorräder als nicht-holonome Konkurrenten bezeichnet werden, während Fußgänger und Radfahrer als holonome Konkurrenten bezeichnet werden können. Aufgrund der geringeren Anzahl von Freiheitsgraden (DOF) lassen sich die erwarteten Wege nicht-holonomer Konkurrenten im Allgemeinen etwas zuverlässiger vorhersagen als das Verhalten holonomer Konkurrenten. Obwohl in 1 nicht dargestellt, kann die Umgebung 126 zusätzliche und/oder alternative Konkurrenten enthalten, wie z. B. zusätzliche nicht-holonome Konkurrenten sowie einen oder mehrere holonome Konkurrenten (z. B. einen oder mehrere Fußgänger in einem oder mehreren Zebrastreifen der Kreuzung). Die Kombination aus dem Fahrzeug 140 und jedem der relevanten Konkurrenten, die mit einem Vorfahrtszenario verbunden sind, kann gemeinsam als die Akteure bezeichnet werden, die mit dem Vorfahrtszenario verbunden sind.
Es versteht sich, dass die Ausführungsformen nicht auf ein Vorfahrtszenario beschränkt sind, das eine Vier-Wege-Kreuzung (z. B. den Vorfahrtbereich 130) mit drei Fahrzeugen (das erste Fahrzeug 140, das zweite Fahrzeug 142 und das dritte Fahrzeug 144) umfasst, die drei der vier Gabelungen der Kreuzung belegen. Wie bereits erwähnt, kann ein Vorfahrtszenario auch Kreuzungen mit einer geringeren Anzahl von ein- und ausfahrenden Wegen (z. B. Drei-Wege-Kreuzungen, T-Kreuzungen usw.) sowie Kreuzungen mit einer größeren Anzahl von ankommenden/abgehenden Wegen (z. B. Fünf-Wege-Kreuzungen, Sechs-Wege-Kreuzungen, Kreisverkehre usw.) umfassen. Weitere Vorfahrtszenarien können den fließenden Verkehr umfassen (z. B. Fahrspurwechsel, Auf-/Abfahrten von Autobahnen und dergleichen). Vorfahrtszenarien können in mehrere Kategorien eingeteilt werden: Kreuzungen (z. B. wie in 1 dargestellt) und Einmündungen (z. B. Zusammenführen von Verkehr auf einer Auf-/Abfahrt).
Jeder Akteur kann einer endlichen maximalen positiven Beschleunigung und einer endlichen minimalen negativen Beschleunigung ausgesetzt sein, z. B. sind die Beschleunigungs- und Bremsfähigkeiten eines Fahrzeugs endlich. Unter der Annahme, dass die Geschwindigkeit eines Akteurs ungleich Null ist (z. B. relativ zur Erdoberfläche), kann jeder Akteur möglicherweise zu einem beliebigen Zeitpunkt aufgrund des Impulses nicht in der Lage sein, eine begrenzte Menge von räumlichen Punkten zu vermeiden. Die Menge der unvermeidbaren räumlichen Punkte kann von den endlichen Beschleunigungs- und Bremsfähigkeiten des Akteurs sowie von der aktuellen Position des Akteurs im Phasenraum (z. B. der aktuellen räumlichen Position und Geschwindigkeit des Akteurs relativ zur Erdoberfläche) und der endlichen Reaktionszeit des Steuersystems des Agenten abhängig sein. Die Menge der unvermeidbaren räumlichen Punkte kann austauschbar als beanspruchte Punkte, beanspruchte Menge, beanspruchte Wege und/oder Menge beanspruchter Punkte bezeichnet werden.
Eine kontinuierliche Menge von beanspruchten Punkten kann einen beanspruchten Weg definieren, den der Akteur in naher Zukunft zu durchfahren bestrebt ist. In einer oder mehreren Ausführungsformen kann das Steuersystem des ersten Fahrzeugs 140 in die Lage versetzt werden, zu jedem Zeitpunkt die beanspruchten Wege des ersten Fahrzeugs 140 zu bestimmen und die beanspruchten Wege für jeden Konkurrent zu schätzen. Das Steuersystem des ersten Fahrzeugs 140 kann auch in die Lage versetzt werden, alle angemessenen Maßnahmen zu ergreifen, um zu vermeiden, dass ein Punkt oder ein Weg beansprucht wird, der Punkte enthält, die bereits von einem Konkurrent beansprucht werden, es sei denn, der Konkurrent gibt seine beanspruchten Punkte durch eine Aktion „frei“ (z. B. beschleunigt, verlangsamt, wendet usw.).
Um diese Funktionen auszuführen, kann das Vorfahrtsplanungssystem 100 beispielsweise einen Vorfahrtsszenarien-Detektor 102, einen Warteelement-Empfänger 104, einen Trajektorien-Generator 106, einen Szenarien-Analysator 110, einen Vorfahrtsverhaltens-Prädiktor 112 und einen Steuerplaner 114 umfassen.
Der Vorfahrtsszenarien-Detektor 102 ist im Allgemeinen für die Erkennung eines Vorfahrtszenarios zuständig. Das heißt, der Vorfahrtsszenarien-Detektor 102 erkennt eine Situation, in der ein Kreuzungs- oder Einmündungsinterferenzmuster mit hoher Wahrscheinlichkeit auftritt. In einigen Ausführungsformen ist der Vorfahrtsszenarien-Detektor 102 in der Lage, ein Kreuzungs- oder Einmündungs-Vorfahrtszenario zu erkennen, wo das erste Fahrzeug 140 eine große Verantwortung hat, die Vorfahrt zu gewähren. In einigen Ausführungsformen kann der Vorfahrtsszenarien-Detektor 102 ein oder mehrere Signale von anderen Komponenten des ersten Fahrzeugs 140 empfangen, um sie bei der Erkennung eines Vorfahrtszenarios zu verwenden. In mindestens einer Ausführungsform kann der Vorfahrtsszenarien-Detektor 102 ein Vorfahrtsignal empfangen, das von einer anderen Komponente erzeugt wird, wobei das Vorfahrtsignal die Erkennung eines sich nähernden Vorfahrtszenarios codiert. Unabhängig davon, ob das Vorfahrtszenario direkt vom Vorfahrtsszenarien-Detektor 102 oder von anderen Komponenten des ersten Fahrzeugs erkannt wird, kann das Vorfahrtszenario durch Analyse von Sensordaten erkannt werden, die von Sensoren des ersten Fahrzeugs 140 in der Umgebung 126 erzeugt werden. Beispielsweise kann ein Vorfahrtszenario mindestens basierend auf der Lokalisierung des Fahrzeugs 140 auf einer Karte (z. B. unter Verwendung von Computervision und/oder GPS-Daten) erkannt werden, wobei die Karte eine Position eines Vorfahrtszenarios in Bezug auf das Fahrzeug 140 identifizieren kann. Zusätzlich oder alternativ kann Computervision verwendet werden, um einen oder mehrere Orte in einem oder mehreren Bildern der Umgebung als einem Vorfahrtszenario entsprechend zu klassifizieren. In mindestens einer Ausführungsform kann der Vorfahrtsszenarien-Detektor 102 ein Vorfahrtszenario mindestens basierend auf der Feststellung erkennen, ob eine Menge von Basisregeln (Verkehrsregeln) auf eine Szene anwendbar ist, und entsprechende Warteelemente bereitstellen. In mindestens einer Ausführungsform kann der Vorfahrtsszenarien-Detektor 102 ein Vorfahrtszenario mindestens basierend auf der Anwendung von in der Karte codierten Regeln erkennen, die gegebenenfalls mit Signalzuständen (z. B. Verkehrszeichen, Ampeln usw.) aufgelöst werden, und entsprechende Warteelemente bereitstellen.
Der Warteelement-Empfänger 104 ist im Allgemeinen für den Empfang einer Warteelementdatenstruktur zuständig. Ein Teil des Betriebssystems 140 des ersten Fahrzeugs, der dem Vorfahrtsplanungssystem 100 vorgeschaltet ist, kann die Warteelementdatenstruktur erzeugen. Die Warteelementdatenstruktur kann verschiedene Aspekte eines Vorfahrtsszenarios codieren. So kann das Warteelement mit einem erkannten Vorfahrtsszenario verbunden sein. Ein Warteelement kann einen Wartezustand, eine Wartegeometrie und/oder Ego-Informationen für eine bestimmte Konkurrenz zwischen dem Ego und einem Konkurrenten codieren. Eine Wartegruppe kann eine Gruppe von Warteelementen für einen bestimmten Vorfahrtbereich (z. B. eine Kreuzung, einen Einmündungsbereich usw.) und/oder ein bestimmtes Szenario repräsentieren. In mindestens einer Ausführungsform müssen alle Wartezustände in einer Wartegruppe zusammen betrachtet und gemeinsam freigegeben werden. Dadurch kann verhindert werden, dass das Fahrzeug 140 am Ende eines Linksabbiegevorgangs auf Fußgänger wartet, während es sich immer noch in der Spur des Gegenverkehrs befindet, indem der Gegenverkehr zusammen mit dem Fußgängerverkehr in derselben Wartegruppe berücksichtigt wird.
Die Wartegeometrie kann der Geometrie entsprechen, die sich ergibt, wenn Informationen über Wartebedingungen oder Vorfahrtszenarien auf einen Fahrspurgraphen angewendet werden. Die Wartegeometrie kann sich auf einen Ego-Weg (z. B. eine Einfahrtslinie), einen Konkurrentenweg (z. B. einen Konkurrentenbereich) oder einen Hintergrundkontext (z. B. die Innenfläche einer Kreuzung oder das Vorhandensein einer Einfahrtslinie) beziehen. Die Wartegeometrie kann aufweisen: Einfahrts- und Ausfahrtslinien (sowohl für Ego-Wege als auch für Konkurrentenwege), Einfahrts- und Ausfahrtsbereiche für Konkurrenten (sowohl für Ego-Wege als auch für Konkurrentenwege), eine Einfahrtslinie in eine Kreuzung und eine Innenfläche (als Teil des allgemeinen Kontexts einer Wartegruppe) und/oder Konkurrenzpunkte zwischen einem Ego-Weg und einem Konkurrentenweg (in Ausführungsformen, in denen eine explizite Codierung eines der Kreuzungs- oder Einmündungspunkte zwischen Wegen verwendet wird). Zwischen einer Einfahrts- und einer Ausfahrtslinie kann eine Geschwindigkeitsbegrenzung gelten. Jedes dieser Elemente kann als ungültig codiert werden, um die Codierung von Wartebedingungen zu ermöglichen, bei denen die Elemente nicht zutreffen (z. B. eine Ampel an einer Auffahrt weist nur eine einen Ego-Weg und eine Einfahrtlinie, jedoch keine Ausfahrtlinie, keinen Konkurrentenweg und keine Innenfläche auf). Ein anderes Beispiel wäre die Codierung einer neuen Geschwindigkeitsbegrenzung durch eine Wartegruppe, die nur eine Einfahrtslinie und eine Geschwindigkeitsbegrenzung im Gesamtkontext enthält, während alles andere auf ungültig gesetzt ist. Die Ausfahrtslinie kann dann als unendlich interpretiert werden oder bis auf Widerruf, und ähnlich verhält es sich mit anderen Eigenschaften.
Eine Einfahrtslinie für einen Ego-Weg kann einen Haltepunkt für mehrere der Vorfahrtsverhaltensweisen codieren. Eine Einfahrtslinie kann auch den Beginn eines allgemeinen Konkurrenzbereichs signalisieren (der auch als Vorfahrtbereich bezeichnet werden kann) und kann von einer Ausfahrtslinie abgeschlossen werden. Eine Ausfahrtslinie kann verwendet werden, um zu bestimmen, welches Segment eines Ego-Wegs freigegeben werden muss, um eine Wartegruppe von Wartebedingungen freizugeben. Die Wartegeometrie kann auch einen Innenflächenbereich umfassen, der den Innenfläche einer Kreuzung oder eines anderen Vorfahrtbereichs als polygonale Fläche darstellen kann. In manchen Fällen kann eine Innenfläche ein Segment zwischen einer Einfahrts- und einer Ausfahrtslinie abdecken (manchmal wird die Ausfahrtslinie nach außen verlegt, z. B. über einen Fußgängerüberweg hinaus, obwohl die Innenfläche dies nicht tut). Die Einfahrtsbereiche und das innere Gelände können den Kontext für die Analyse anderer Akteure liefern. Dies kann durch den Szenarien-Analysator 110 erfolgen, der die Akteure den Wegen und Bereichen zuordnet (in einer sich nicht gegenseitig ausschließenden Weise). Die Geometrie von Ego- und Konkurrentenwegen sowie der Konkurrenzpunkt können vom Vorfahrtsplanungssystem 100 verwendet werden, um die Vorfahrt nach Bedarf zu realisieren. Die Geometrie kann auch verwendet werden, um zu bestimmen, welche Regeln gelten.
Ein Konkurrenzpunkt kann einen expliziten geometrischen Punkt darstellen, aber auch eine bestimmte Konkurrenz, auf die sich ein Warteelement bezieht und deren Zustand es codiert. In diesem Sinne kann der Zustand der Konkurrenz an einem Konkurrenzpunkt eine Nutzlast eines Prozesses zur Auflösung des Konkurrenzzustands darstellen. Die Auflösung des Konkurrenzzustands kann für jeden Konkurrenzpunkt eine Bestimmung der Art und Weise liefern, in der das Fahrzeug 140 in Bezug auf den Konkurrenzpunkt die Vorfahrt gewähren sollte oder nicht (Vorfahrtsverhalten). In diesem Sinne kann ein Konkurrenzpunkt verwendet werden, um bei einer Wahl des Ego-Wegs auf einen Konkurrentenweg und über diesen Konkurrentenweg auf die tatsächlichen Konkurrenten und das Vorfahrtsverhalten in Bezug auf diese zuzugreifen.
In mindestens einer Ausführungsform kann ein Warteelement eine Teilmenge der Wartegeometrie eines Ego-Weges, der Wartegeometrie eines Konkurrenten-Weges, eines Wartegeometrie-Kontextes und eines Konkurrenzzustandes enthalten. Eines oder mehrere dieser Elemente können als ungültig codiert werden, wenn es nicht zutreffend ist. Die Warteelemente können „Atome“ dafür darstellen, wie Informationen über Wartebedingungen codiert werden, damit sie an das Vorfahrtsplanungssystem 100 weitergegeben werden können.
Der Trajektorien-Generator 106 ist im Allgemeinen für die Erzeugung der Trajektorien für das autonome Fahrzeug 140 und jeden der anderen Konkurrenten verantwortlich, die für das Vorfahrtsszenario relevant sind, das in dem einen oder den mehreren Warteelementen codiert ist, die vom Warteelement-Empfänger 104 empfangen werden. Die vom Trajektorien-Generator 106 erzeugten Trajektorien umfassen 1D-Strukturen, die in eine flache 4D-Raum-Zeit-Mannigfaltigkeit eingebettet sind, wie hierin beschrieben. Der Szenarien-Analysator 110 ist im Allgemeinen für die Analyse der einen oder mehreren Trajektorien des ersten Fahrzeugs 140 und einer oder mehrerer Trajektorien für jeden Konkurrent im Vorfahrtszenario verantwortlich, um die Wahrscheinlichkeit einer oder mehrerer potentieller Kollisionen innerhalb eines kreuzungsbasierten Vorfahrtszenarios zu bestimmen, wie z. B., aber nicht beschränkt auf das in 1 dargestellte.
Der Szenarien-Analysator 110 kann zusätzlich oder alternativ die Trajektorien des ersten Fahrzeugs 140 und die Trajektorien für jeden Konkurrenten im Vorfahrtszenario analysieren, um die Wahrscheinlichkeit einer oder mehrerer potentieller Kollisionen innerhalb eines Vorfahrtszenarios basierend auf einer Einmündung (z. B. Auffahren auf eine Autobahn) zu bestimmen. Basierend auf der vom Szenarien-Analysator 110 durchgeführten Kreuzungs- oder Einmündungsanalyse bestimmt der Vorfahrtsverhaltens-Prädiktor 112 ein Vorfahrtsverhalten (oder eine Vorfahrtsaktion), mit dem das erste Fahrzeug 140 gesteuert werden soll.
Bei Annäherung an ein Vorfahrtszenario kann das Vorfahrtplanungssystem 100 (über den Vorfahrtsverhaltens-Prädiktor 112) eine Vorfahrtanalyse durchführen (basierend auf der Analyse des Szenarien-Analysators 110 und/oder des Szenarien-Analysators 110), um ein Vorfahrtsverhalten (z. B. eine Vorfahrtaktion) für das erste Fahrzeug 140 zu bestimmen. Wenn sich das Fahrzeug 140 entsprechend dem ermittelten Vorfahrtsverhalten verhält, wird die Wahrscheinlichkeit, dass sich eine beliebige resultierende beanspruchte Punktemenge (des ersten Fahrzeugs 140) mit der beanspruchten Punktemenge jedes anderen Konkurrenten überschneidet, erheblich verringert, selbst wenn ein oder mehrere Konkurrent ihren Vorfahrtverpflichtungen nicht nachkommen. Das heißt, das Vorfahrtplanungssystem 100 kann mindestens für Vorfahrtszenarien sicherstellen, dass sich die beanspruchten Punktmengen des ersten Fahrzeugs 140 nicht mit den beanspruchten Punktmengen der anderen Konkurrent überschneiden, selbst wenn die Konkurrenten nicht aktiv dazu beitragen, dem ersten Fahrzeug 140 auszuweichen.
Das Vorfahrtplanungssystem 100 kann auch sicherstellen, dass die Vorfahrtregeln des ersten Fahrzeugs 140 einen ausreichenden Abstand zu den Vorfahrtregeln der Mitbewerber einhalten. Der Spielraum ist so groß, dass die Navigation des ersten Fahrzeugs 140, während es gemäß dem ermittelten Vorfahrtsverhalten betrieben wird, den Konkurrenten anzeigt, dass das erste Fahrzeug 140 ihren gesetzlichen und normativen Vorfahrtpflichten nachkommt.
In mindestens einer Ausführungsform kann der Vorfahrtsverhaltens-Prädiktor 112 das Vorfahrtsverhalten mindestens basierend auf der Durchführung der Auflösung des Konkurrenzzustands für das Vorfahrtszenario bestimmen. Dies kann die Bestimmung von Informationen umfassen, die mit einem oder mehreren der ersten Fahrzeuge 140, zweiten Fahrzeuge 142 und/oder dritten Fahrzeuge 144 verbunden sind, die verwendet werden, um Warteelemente auf Vorfahrtsszenarien anzuwenden, wie eine Klassifizierung (oder ein Typ) jedes Akteurs (z. B. holonom vs. nicht-holonom), seine Koordinaten in einem relevanten Phasenraum (z. B. Positions- und Geschwindigkeitskomponenten) und/oder andere Informationen, die vom Szenarien-Analysator 110 und/oder dem Trajektorien-Generator 106 verwendet werden, um Konkurrenzzustände von Warteelementen zu bewerten.
Die Auflösung des Konkurrenzzustands kann einen Konkurrenzzustand (der auch als Wartezustand oder Vorfahrtsverhalten bezeichnet werden kann) für jedes der Warteelemente liefern, die für ein Vorfahrtszenario gelten (z. B. eine oder mehrere Wartegruppen). Ein Konkurrenzzustand eines Warteelements kann eine Anweisung darstellen, die der Art und Weise entspricht, in der das Fahrzeug 140 in Bezug auf das Warteelement die Vorfahrt gewähren sollte oder mit Vorfahrtsrecht weiterfahren sollen, als Regel, Erwartung, formelle oder informelle Konvention oder Norm (z. B. kann es angeben, was gemäß der Konvention geschehen sollte, unabhängig davon, ob es tatsächlich geschieht oder nicht).
Der Steuerplaner 114 des Fahrzeugs 140 ist für die tatsächliche Umsetzung des Vorfahrtsverhaltens aus der Vorfahrtsverhaltens-Prädiktor 112 verantwortlich, wobei er berücksichtigt, was basierend auf der Wartezustände geschehen sollte, ob das Fahrzeug 140 in der Lage ist, anzuhalten und diese Anweisung zu befolgen, ob andere Akteure ihre erwarteten Vorfahrtspflichten zu erfüllen scheinen, und geeignete Maßnahmen ergreifen. In mindestens einer Ausführungsform kann der Steuerplaner 114 Trajektorien bestimmen und einen Möglichkeits- oder Suchraum der Trajektorien mindestens basierend auf von Wartebedingungen oder -zuständen beschneiden, z. B. basierend auf der Feststellung, dass die Trajektorien nicht in der Lage sind, die Wartezustände zu befolgen. Wenn sich beispielsweise eine Trajektorie oder ein Weg über eine Warteeinfahrtslinie hinaus erstreckt, wenn ein aktiver Wartezustand „Stopp am Einfahrt“ beinhaltet, kann sie/er beschnitten werden. Dann kann der Steuerplaner 114 aus den verbleibenden Optionen eine Auswahl treffen, die auf anderen Kriterien wie Komfort und Hindernisvermeidung basiert. In mindestens einer Ausführungsform können Trajektorien durch Anwendung von Geschwindigkeitsprofilen auf Wege erzeugt werden. Das Beschneiden kann das Beschneiden eines oder mehrerer Geschwindigkeitsprofile beinhalten.
Der Steuerplaner 114 kann solche Operationen durchführen wie das Bestimmen, dass, obwohl ein Konkurrenz- oder Wartezustand „nehme Vorfahrtsrecht wahr“ ist, ein anderes Fahrzeug nicht die Vorfahrt gewährt, (im Wesentlichen „zum Hupen angemessen“ Detektieren“), und beschließen, die Vorfahrt zu gewähren, obwohl diese Vorgehensweise gemäß dem Vorfahrtsverhaltens-Prädiktor 112 möglicherweise nicht die vorgeschriebene Vorgehensweise ist. Darüber hinaus können Kollisionsvermeidungssysteme immer in Betrieb sein, so dass unabhängig vom Zustand der Konkurrenz und sogar unabhängig davon, was der Steuerplaner 114 beschließt zu tun, Kollisionsvermeidungsverfahren eingesetzt werden können (z. B. wenn sich beanspruchte Gruppen kreuzen). Der Steuerplaner 114 kann ein Vorfahrtsverhalten durch den Vorfahrtsverhaltens-Prädiktor 112 implementieren, der alle Streitigkeiten in einer Wartegruppe analysiert, bis sie gemeinsam geklärt werden können. In mindestens einer Ausführungsform kann der Steuerplaner 114 so konfiguriert sein, dass er bei einer Menge von Warteelementen und aufgelösten Wartezuständen den restriktivsten Wartezustand verwendet, um das erwartete Nachgiebigkeitsverhalten zu definieren. Wenn beispielsweise ein Wartezustand „Vorfahrt gewähren“ und ein anderer „Anhalten an der Einfahrt“ lautet, kann der Steuerplaner 114 bestimmen, dass das Fahrzeug 140 an der Einfahrtslinie bleiben soll.
Einige nicht einschränkende Beispiele für Wartezustände sind: Anhalten an der Einfahrt, Anhalten an der Einfahrt, dann an der Einfahrt Vorfahrtsgewährung, Anhalten an der Einfahrt, dann am Konkurrenzpunkt Vorfahrtsgewährung, an der Einfahrt Vorfahrtsgewährung und Übergang der Vorfahrtsgewährung an der Einfahrt. Zusätzliche Wartezustände umfassen: Wer zuerst anhält, hat Vorrang, Anhalten an der Einfahrt, dann verhandeln, Verhandeln, Vorfahrtsrecht-Wahrnehmung, Vorfahrtsübergang, Anhalten an der Einfahrt, Vorfahrtsgewährung am Konkurrenzpunkt, und Übergang der Vorfahrtsgewährung am Konkurrenzpunkt. In einigen Ausführungsformen können sechs der oben genannten Wartezustände als „primitive Zustände“ betrachtet werden, und die anderen Wartezustände können durch eine oder mehrere Kombinationen der sechs primitiven Zustände erzeugt werden. Zu den sechs primitiven Zuständen können gehören: Wahrnehmung des Vorfahrtsrechts, Anhalten an der Einfahrt, Vorfahrtsgewährung an der Einfahrt, Vorfahrtsgewährung am Konkurrenzpunkt, Übergang und Verhandeln.
Wahrnehmung des Vorfahrtsrechts kann eine Anweisung für das Fahrzeug 140 sein, von anderen Akteuren zu erwarten, dass sie die Vorfahrt gewähren, und kann keine formale Einschränkung durch die Konkurrenz darstellen (außer für den Steuerplaner 114, der andere Akteure im Zusammenhang mit der Konkurrenz beobachtet und sicherstellt, dass sie wie erwartet die Vorfahrt gewähren).
Vorfahrtsübergang kann signalisieren, dass sich ein Wartezustand bald ändern wird. Er kann anzeigen, dass das Vorfahrtsrecht wahrzunehmen noch gilt, aber wahrscheinlich bald in einen restriktiveren Zustand übergehen wird. So kann z. B. ein „gelber“ Zustand einer Ampel den Vorfahrtsübergang auslösen.
Vorfahrtsgewährung an der Einfahrt kann eine Anweisung darstellen, dass das Fahrzeug 140 bis zu dem Zeitpunkt, zu dem erwartet wird, dass die Konkurrenz ausgeräumt wird, an der Einfahrtslinie bleiben soll. In diesem Fall ist ein Vorstopp möglicherweise nicht per Vorschrift vorgeschrieben, aber die Vorfahrtsverhaltens-Prädiktor 112 sollte sicherstellen, dass die Konkurrenz ausgeräumt ist, bevor das Fahrzeug 140 die Einfahrtslinie passiert, was häufig zu einem Vorstopp führt. Wenn die Wartebedingungen in einer Warteschlange gemeinsam betrachtet werden, kann Vorfahrtsgewährung an der Einfahrt oft bedeuten, dass die Vorfahrtsverhaltens-Prädiktor 112 sicherstellen sollte, dass alle Konkurrenzsituationen in der Warteschlangengruppe ausgeräumt sind, bevor das Fahrzeug 140 die Einfahrtslinie passiert. Mit anderen Worten: Wenn für ein Konkurrenz/Warteelement Vorfahrtsgewährung an der Einfahrt aufweist, kann dies bei der Analyse durch die Vorfahrtsverhaltens-Prädiktor 112 auf alle anderen Elemente übertragen werden, und wenn eines Anhalten an der Einfahrt aufweist, kann der Vorstopp auf alle anderen Elemente übertragen werden.
Übergang der Vorfahrtsgewährung an der Einfahrt kann eine vorübergehende Version der Vorfahrtsgewährung an der Einfahrt darstellen. Er kann darauf hinweisen, dass Vorfahrtsgewährung an der Einfahrt noch gilt, aber wahrscheinlich bald in einen restriktiveren Zustand übergehen wird. In ähnlicher Weise kann sich Übergang der Vorfahrtsgewährung am Konkurrenzpunkt auf eine vorübergehende Version der Vorfahrtsgewährung am Konkurrenzpunkt beziehen.
Verhandeln kann bedeuten, dass es keine bekannte Grundlage für die Bestimmung der Vorfahrt gibt, wie z. B. bei einer Autobahneinmündung, bei der es keine Anhaltspunkte aus Verkehrsregeln, Kartenstatistiken, Geometrie oder Größe der Straße gibt (z. B. gleich große Autobahnen, die zusammengeführt werden und ähnlich gerade verlaufen).
Der primitive Wartezustand „Anhalten an der Einfahrt“ kann erfordern, dass das erste Fahrzeug 140 an der Einfahrtswartelinie 132 der Kreuzung 130 anhält und auf weitere Anweisungen wartet. Im Gegensatz dazu kann der primitive Wartezustand Vorfahrtsgewährung bei Konkurrenz (oder Vorfahrtsgewährung am Konkurrenzpunkt) darauf hinweisen, dass ein Vorstopp nicht durch eine Verkehrsregel vorgeschrieben ist (z. B. bei einer ungeregelten Kreuzung) und/oder das erste Fahrzeug 140 nicht gesetzlich verpflichtet ist, an der Einfahrtswartelinie 132 anzuhalten und zu warten, um die Kreuzung 130 zu räumen. Vielmehr kann der Wartezustand Vorfahrtsgewährung bei Konkurrenz anzeigen, dass das erste Fahrzeug 140 anderen Fahrzeugen, die mit dem ersten Fahrzeug konkurrieren (z. B. das zweite Fahrzeug 142 und das dritte Fahrzeug 144), Vorfahrt gewähren sollte und dass das erste Fahrzeug 140 nicht in einer Weise weiterfährt, die es die Kreuzung 130 „blockieren“ würde während die anderen Konkurrenten die Kreuzung 130 passieren. Zum Beispiel kann das erste Fahrzeug 140 gemäß dem Wartezustand Vorfahrtsgewährung bei Konkurrenz weiterfahren, indem es vorzieht, um eine Linkskurve einzuleiten, aber langsam genug und mit genügend Spielraum, so dass der entgegenkommende Verkehr (z. B. das dritte Fahrzeug 144) versteht, dass das erste Fahrzeug 140 die Absicht hat, die Vorfahrt zu gewähren, und natürlich nicht dem entgegenkommenden Verkehr in die Quere zu kommen. Als Beispiel dafür, wie nicht-primitive Wartezustände (z. B. zusammengesetzte Wartezustände) über Kombinationen von primitiven Wartezuständen erzeugt werden können, kann der Wartezustand „Anhalten an der Einfahrt und dann Vorfahrt gewähren“ das Verhalten beinhalten, dass das erste Fahrzeug dem Verhalten des Wartezustands „Vorfahrt gewähren“ folgt, während es einen Vorstopp an der Einfahrtswartelinie 132 durchführt. Beispiele umfassen Anhalten an der Einfahrt, dann Vorfahrtsgewährung an der Einfahrt, Anhalten an der Einfahrt, dann Übergang der Vorfahrtsgewährung an der Einfahrt, Anhalten an der Einfahrt, dann Vorfahrtsgewährung am Konkurrenzpunkt, Anhalten an der Einfahrt und Übergang der Vorfahrtsgewährung am Konkurrenzpunkt, und Anhalten an der Einfahrt dann Aushandeln.
Wer zuerst anhält, hat Vorrang kann bedeuten, dass die Vorfahrt (z. B. für eine Haltestelle mit mehreren Richtungen) als eine First-in-first-out-Warteschlange bestimmt wird, wobei „in“ so definiert ist, sich als erster Akteur der Kreuzung zu nähern (wahrscheinlich im entsprechenden Konkurrentbereich an der Einfahrtslinie, die in die Innenfläche zeigt) und anzuhalten. Dieser Wartezustand kann eine weitere Verarbeitung von „wer zuerst angehalten hat“ implizieren, um tatsächlich in einen Wartezustand „Vorfahrtsrecht wahrnehmen“ oder „Vorfahrt gewähren“ für jeden Akteur aufzulösen, der mit einem Konkurrentenweg verbunden ist.
Mindestens ein Teil der Wartezustände kann als Zustandsmaschinen oder mindestens als Zustände innerhalb einer Zustandsmaschine modelliert werden. Beispielsweise können die zusammengesetzten Wartezustände als Wartezustände modelliert werden, die aus Zuständen bestehen, die den im zusammengesetzten Wartezustand enthaltenen Wartezuständen entsprechen. Mit Bezug auf 2 ist 2 ein Beispiel für eine Zustandsmaschine 200, die einem aus Anhalten an der Einfahrt und dann Vorfahrtsgewährung zusammengesetzten Zustand entspricht. Die Zustandsmaschine 200 wird im Zustand 202 initiiert, in dem der primitive Wartezustand Anhalten an der Einfahrt verarbeitet wird. Die Zustandsmaschine 200 fährt im Ausgangszustand 202 fort, während die Geschwindigkeit des Ego-Fahrzeugs (z. B. des ersten Fahrzeugs 140 der 1) weniger als 0,5 Meter pro Sekunde (m/s) beträgt und der Abstand zur Wartelinie nicht in Reichweite ist. Wenn die Übergangsbedingung erfüllt ist (z. B. die Ego-Geschwindigkeit ist < 0,5 Meter pro Sekunde und der Abstand zur Wartelinie liegt im Bereich), geht die Zustandsmaschine 200 in den Zustand 204 über, in dem das Ego-Fahrzeug an der Einfahrt zu einer Kreuzung vollständig angehalten wird. Wenn das Ego-Fahrzeug mindestens drei Sekunden gewartet hat, kann die Zustandsmaschine 200 in den Zustand 206 übergehen. Im Zustand 206 kann der primitive Wartezustand „Vorfahrtsgewährung bei Konkurrenz“ verarbeitet werden. Nach Beendigung des Wartezustands „Vorfahrtsgewährung bei Konkurrenz“ kann die Zustandsmaschine 200 verlassen werden.
Wenn wir unsere Aufmerksamkeit wieder 1 zuwenden, vom die vom Trajektorien-Generator 106 durchgeführte Trajektorienanalyse die zeitliche Entwicklung der beanspruchten Mengen erzeugen, was zu zeitabhängigen Trajektorien für das erste Fahrzeug 140 und jeden der Konkurrenten führt. Wie weiter unten erläutert, werden die zeitlich entwickelten Trajektorien (durch den Szenarien-Analysator 110 und/oder den Szenarien-Analysator 110) für jeden Akteur analysiert, um potentielle Kollisionen (oder „Beinahe“-Kollisionen) zwischen den Trajektorien des ersten Fahrzeugs 140 und den Trajektorien der anderen Akteure zu erkennen. Solche (Beinahe- oder expliziten) Kollisionen (oder Kreuzungen) können eine potentielle Kollision zwischen dem ersten Fahrzeug 140 und dem anderen Akteur anzeigen. Der Begriff Schnittmenge kann sich hier auf einen oder mehrere räumliche Punkte beziehen, die in mindestens zwei Trajektorien enthalten sind. Der Vorfahrtsverhaltens-Prädiktor 112 bestimmt über die Trajektorienanalyse ein Vorfahrtsverhalten (oder einen Wartezustand) für das erste Fahrzeug 140, das, wenn es befolgt wird, potentielle Kollisionen wahrscheinlich vermeiden wird. Bei nichtholonomen Konkurrenten kann die Vorfahrtanalyse eine strukturierte Vorfahrtanalyse sein (z. B. weil sich der nicht-holonome Konkurrent aufgrund der geringeren Anzahl von Freiheitsgraden (DOF) strukturiert verhalten kann). Für holonome Konkurrent kann die Vorfahrtanalyse eine unstrukturierte Vorfahrtanalyse sein (z. B. weil der holonome Konkurrent sich aufgrund der Zunahme der Freiheitsgrade unstrukturiert verhalten kann). Wenn die möglichen zukünftigen Trajektorien für holonome Konkurrenten eingeschränkt oder anderweitig auf eine relativ kleine Menge möglicher Trajektorien begrenzt sind, kann die Fließanalyse zu einer strukturierten Fließanalyse zurückkehren.
Unabhängig davon, ob die Analyse strukturiert oder unstrukturiert ist, werden die 140 möglichen Trajektorien des ersten Fahrzeugs (sowie die möglichen Trajektorien der Konkurrenten) zeitlich nach vorne projiziert, und Interferenzen (z. B. Kreuzungen) zwischen Trajektorien verschiedener Akteure werden erkannt. Zwei nicht einschränkende Beispiele für Interferenzmuster sind Kreuzungen und Einmündungen. Die Kreuzungen oder Einmündungen können vom Szenarien-Analysator 110 analysiert werden. Ein sich kreuzendes Interferenzmuster kann entstehen, wenn sowohl das erste Fahrzeug 140 als auch das zweite Fahrzeug 142 versuchen, gleichzeitig gerade durch die Kreuzung der Umgebung 126 gemäß den Wegen eines Warteelements zu fahren. Die Trajektorien der beiden Fahrzeuge werden sich an einem oder mehreren möglichen Punkten entlang ihrer Trajektorie schneiden, z. B. können sich die beiden Trajektorien über eine relativ kleine Menge räumlicher Punkte schneiden, die den jeweiligen Trajektorien gemeinsam sind, während sich die Trajektorien entwickeln und die beiden Fahrzeuge in getrennten Richtungen weiterfahren. Im Gegensatz dazu kann ein zusammenlaufendes Kreuzungsmuster auftreten, wenn sich zwei Wege eines Warteelements und die daraus resultierenden Trajektorien schneiden und in ähnlichen Richtungen fortgesetzt werden, so dass sich die Trajektorien in einer viel größeren Menge von räumlichen Punkten schneiden. Beispielsweise kann ein zusammenlaufendes Interferenzmuster entstehen, wenn das erste Fahrzeug 140 versucht, geradeaus über die Kreuzung zu fahren, und das dritte Fahrzeug 144 ungefähr zu einem ähnlichen Zeitpunkt, zu dem das erste Fahrzeug 140 die Kreuzung überquert, nach rechts abbiegt. Zusammenlaufende Interferenzmuster können außerdem entstehen, wenn ein oder mehrere Fahrzeuge die Fahrspur wechseln, eine Autobahnauffahrt so befahren, dass ein Fahrzeug mit dem bereits vorhandenen Verkehr auf der Autobahn zusammenfließt, und dergleichen.
Beim „Vorwärtssimulieren“ der möglichen Trajektorien (z. B. sich zeitlich entwickelnd) eines Konkurrenten kann die Vorwärtsbewegung der Trajektorie des Konkurrenten uneingeschränkt sein, wenn der Konkurrent eine gesetzliche (oder normative) Vorfahrt hat. Die Trajektorie des ersten Fahrzeugs kann so aggressiv weiterentwickelt werden, wie es vernünftigerweise angemessen ist. Beispielsweise kann eine „aggressive Trajektorie“ projiziert werden, um festzustellen, ob das erste Fahrzeug 140 die Kreuzung „räumen“ kann, lange bevor das zweite Fahrzeug 142 in die Kreuzung einfährt, so dass jedes Kreuzungsmuster in den Trajektorien über ungleiche Zeiträume hinweg auftritt. Wenn die „aggressive Trajektorie“ nicht dazu führt, dass die Kreuzung sicher (und/oder „höflich“) geräumt wird, können weniger aggressive Trajektorien in Betracht gezogen werden, z. B. eine Trajektorie, die das erste Fahrzeug 140 als langsamer oder sogar als an der Kreuzung anhaltend modelliert, kann verwendet werden, um das Vorfahrtsverhalten für das erste Fahrzeug 140 auszuwählen.
In einigen Ausführungsformen wird die Vorfahrtsanalyse in diskreten „Blöcken“ durchgeführt. Zum Beispiel wird jedes Vorfahrtszenario getrennt von jedem anderen Vorfahrtszenario analysiert (z. B. werden aufeinanderfolgende Kreuzungen getrennt und/oder unabhängig voneinander analysiert). Aufeinanderfolgende Kreuzungen können z. B. seriell nach dem FIFO-Prinzip (First-in-First-out) analysiert werden. Im Falle einer Kreuzung (wie z. B. der in Umgebung 126 dargestellten, aber nicht darauf beschränkt) können mindestens zwei mögliche Vorfahrtsverhaltensweisen analysiert werden. Das erste in Betracht gezogene Vorfahrtsverhalten kann ein aggressiveres Vorfahrtsverhalten sein, das beinhaltet, dass das erste Fahrzeug 140 die Kreuzung mit einer positiven (aber angemessenen) Beschleunigung durchfährt. Das zweite Vorfahrtsverhalten kann ein konservativeres Vorfahrtsverhalten sein, bei dem das erste Fahrzeug 140 eine negative Beschleunigung (z. B. Bremsen) einsetzt, um kurz vor der Kreuzung anzuhalten. Verschiedene Strategien zwischen diesen bimodalen Verhaltensweisen (z. B. die aggressivste Vorfahrtstrategie oder die konservativste Vorfahrtstrategie) können in den verschiedenen Ausführungsformen berücksichtigt werden.
In einer oder mehreren Ausführungsformen kann jeder Konkurrent oder jeder Konkurrentenweg eines Warteelements separat betrachtet werden. In einigen Ausführungsformen werden die Konkurrent oder Konkurrentenwege mit Hilfe von parallelen Berechnungsverfahren analysiert. In anderen Ausführungsformen werden die Konkurrent oder Konkurrentenwege seriell über den oben erwähnten FIFO-Analysestapel oder die Warteschlange analysiert. Zum Beispiel kann der Konkurrent, der am frühesten an der Kreuzung ankommt, vor den anderen Konkurrenten analysiert werden. Die Vorfahrtanalyse kann zeitlich so weit im Voraus erfolgen, dass das erste Fahrzeug 140 die Kreuzung nicht „blockiert“. Das heißt, gemäß dem Vorfahrtsverhalten kann entweder das erste Fahrzeug 140 die Kreuzung sicher passieren, oder das erste Fahrzeug 140 kann vor dem Einfahren in die Kreuzung anhalten (oder langsamer werden), z. B. hält das erste Fahrzeug nicht in der Mitte der Kreuzung an oder bremst.
Zusätzlich zur Erkennung des „Beginns“ eines Vorfahrtszenarios können Ausführungsformen auch das „Ende des Vorfahrtszenarios“ erkennen. Bei sich kreuzenden Interferenzmustern kann das Ende eines Vorfahrtszenarios dadurch signalisiert werden, dass das erste Fahrzeug 140 die Menge der Kreuzungspunkte der Trajektorien und/oder Konkurrenzsituationen eines oder mehrerer zugehöriger Warteelemente erfolgreich verlässt. Bei sich einmündenden Wegen kann das Problem komplizierter sein. Bei einmündenden Interferenzmustern kann ein Vorfahrtszenario beendet werden, wenn jeder der zugehörigen Akteure einen Gleichgewichtszustand erreicht hat (z. B. wenn jeder der Akteure unter Berücksichtigung der Geschwindigkeit des umgebenden Verkehrs zu einer angemessenen Geschwindigkeit übergegangen ist und jeder der Akteure einen Abstand von den anderen Akteuren hat, der ein angemessenes Sicherheitsniveau bietet).
Die Funktionalität des Vorfahrtplanungssystems 100 wird nun detaillierter erläutert. Ein Großteil der folgenden Erläuterung ist auf die strukturierte Vorfahrtanalyse in einem Kreuzungsvorfahrtszenario gerichtet, das sich kreuzende Interferenzmuster beinhaltet. Die Ausführungsformen sind jedoch nicht so beschränkt, und es versteht sich, dass solche Verfahren erweitert werden können, um sich kreuzende Muster und/oder holonome Konkurrenten einzubeziehen. Es versteht sich auch, dass die Codierung des Vorfahrtszenarios und die Erkennung der Positionen der einzelnen Akteure in einem für das Szenario relevanten Phasenraum von anderen Systemen durchgeführt werden können, die mit dem ersten Fahrzeug 140 verbunden sind. Solche Informationen können dem Vorfahrtplanungssystem 100 als Eingaben zur Verfügung gestellt werden.
Der Vorfahrtsverhaltens-Prädiktor 112 kann Beziehungen in der longitudinalen Entwicklung (z. B. über eine zeitliche Dimension) der potentiellen Trajektorien jedes Akteurs in einem erkannten Vorfahrtsszenario analysieren, z. B. kann der Vorfahrtsplaner zeitlich vorwärts gerichtete Trajektoriensimulationen durchführen und auf Kreuzungen von beanspruchten Mengen testen. Das Vorfahrtsplanungssystem 100 kann die Umgebung 126 als dreidimensionale Mannigfaltigkeit modellieren (z. B. eine Draufsicht mit zwei räumlichen Dimensionen mit Koordinaten (D, y) und einer zeitlichen Dimension mit Koordinaten (t)). Zu jedem Zeitpunkt t können die beanspruchten Mengen der Akteure betrachtet werden. Ebenfalls zu jedem Zeitpunkt t können die beanspruchten Mengen in die Zukunft projiziert werden. Dementsprechend können die Trajektorien so modelliert werden, dass sie auf einer lokal flachen 4D-Mannigfaltigkeit (zwei räumliche Dimensionen und zwei zeitliche Dimensionen) stattfinden. Die zweite zeitliche Dimension kann durch die Koordinate z referenziert werden. Obwohl die beiden zeitlichen Dimensionen über eine affine Transformation miteinander verbunden sein können, können die beiden zeitlichen Dimensionen in der Analyse getrennt bleiben, um die Projektion der Trajektorien zu vereinfachen. So kann jede Trajektorie zu jedem Zeitpunkt (t) durch drei Koordinaten (x, y, z) beschrieben werden, wobei sich x und y auf Raumkoordinaten und z auf eine (vorausschauende) Zeitkoordinate beziehen.
Bei der Durchführung der Vorfahrtsanalyse kann der Vorfahrtsverhaltens-Prädiktor 112 die folgenden vereinfachenden Annahmen verwenden. Erstens liefert das Steuersystem des ersten Fahrzeugs 140 dem Vorfahrtsplanungssystem 100 den geplanten und/oder gewünschten Weg des ersten Fahrzeugs 140, der in die 4D-Mannigfaltigkeit eingebettet ist. Zweitens ist das Steuersystem in der Lage, dem Vorfahrtsplanungssystem 100 nahezu vollständige Informationen über jeden Konkurrenten zu liefern. Das heißt, das Vorfahrtsplanungssystem 100 kann sich darauf verlassen, dass es die aktuelle Position jedes Konkurrenten im Phasenraum (z. B. sowohl Ort als auch Geschwindigkeit) sowie eine Klassifizierung jedes Konkurrenten (z. B. holonom oder nicht-holonom) und mindestens eine geschätzte Form und/oder Größe erhält (z. B. zur Erzeugung eines Begrenzungsrahmens auf der räumlichen 2D-Mannigfaltigkeit (z. B. der räumlichen Untermannigfaltigkeit der 4D-Raum-Zeit-Mannigfaltigkeit), um die physikalischen Erweiterungen des Konkurrenten zu modellieren). Es kann auch davon ausgegangen werden, dass dem Vorfahrtsplanungssystem 100 für jeden Akteur eine diskrete endliche Menge seiner möglichen beabsichtigten Wege zur Verfügung steht. In der Praxis kann dies z. B. so gehandhabt werden, dass ein Fahrspurgraph der Kreuzung oder eines anderen Vorfahrtbereichs, einschließlich der Querverkehrswege, durch eine Karte gegeben ist und die wahrgenommenen Akteure diesen Wegen zugeordnet werden. Auf diese Weise können für jeden Akteur mögliche Optionen (z. B. mehrere Trajektorien) unter Verwendung entsprechender Warteelemente, die mögliche Wege erfassen, generiert werden. Darüber hinaus kann jeder Weg eines jeden Bewerbers separat betrachtet werden, indem ein entsprechendes Warteelement bereitgestellt wird. Dies kann die Analyse vereinfachen, so dass nur eine Reihe von Zwei-Körper-Interaktionen berücksichtigt werden muss (z. B. Interferenzmuster zwischen der Trajektorie des ersten Fahrzeugs und der eines Konkurrenten), wenn festgestellt wird, ob ein bestimmtes Konkurrenz-/Warteelement eindeutig ist. Das heißt, dass in einigen Ausführungsformen drei oder eine größere Anzahl von Körperinteraktionen nicht in derselben Analyse berücksichtigt werden müssen.
Jede potentielle Interferenz zwischen den Trajektorien des ersten Fahrzeugs 140 und eines Konkurrenten (z. B. des zweiten Fahrzeugs 142 und/oder des dritten Fahrzeugs 144) kann auf einer Annäherung an die Regeln oder Heuristiken basieren, die mit der Navigation auf der Straße verbunden sind. Insbesondere kann bei der Betrachtung einer bestimmten Paarung der Phasenraumkoordinaten des ersten Fahrzeugs 140 (z. B. die Positions- und Geschwindigkeitskoordinaten entlang der aktuellen Trajektorie des ersten Fahrzeugs) und des Zustands eines Konkurrenten (z. B. die Positions- und Geschwindigkeitskoordinaten entlang der Trajektorie des Konkurrenten) bestimmt werden, ob sich die Trajektorien kreuzen oder zusammenlaufen. In diesem Fall kann sich die beanspruchte Menge eines Akteurs auf die Menge der Punkte im Raum beziehen, die von der Form des Akteurs zu einem bestimmten Zeitpunkt eingenommen werden, wenn der Akteur jetzt mit einer bestimmten konstanten Sicherheitsbremsverzögerung zu bremsen beginnt. Dieses Szenario kann durch die Analyse des Fortschritts entlang der Trajektorien angenähert werden, wobei auch nur die beanspruchten Mengen als Fortschritt entlang der Trajektorien betrachtet werden, während die Breite der Akteure räumlich aufgefüllt wird, um zu bestimmen, ob es wahrscheinlich ist, dass eine Interferenz auftritt.
Die Analyse kann in mehrere Stufen unterteilt werden. In einer ersten Stufe können Interferenzpaare zwischen Punkten auf den Wegen in Form von Kreuzungen (z. B. dargestellt als Wegintervallpaare eines Warteelements, die als Ganzes interferieren) und Einmündungen (z. B. dargestellt als Wegintervallpaare eines Warteelements, die als dasselbe bestimmt werden, entsprechend 1:1 Punkt für Punkt) identifiziert und/oder bestimmt werden. In einem zweiten Schritt kann untersucht werden, wie sich die Akteure und die von ihnen beanspruchten Mengen entlang ihrer individuellen Wege weiterentwickeln.
Bei der Bestimmung, ob eine Interferenz auftritt, kann jeder Akteur physikalisch als ein Polygon modelliert werden, das auf der 2D-Raumverteilungsfläche positioniert und auf der Trajektorie zentriert ist. Das heißt, die räumlichen Grenzen jedes Akteurs können mit einem Begrenzungsrahmen oder einer Form modelliert werden, die einen polygonalen Fußabdruck enthält (obwohl auch andere Formen verwendet werden können). So kann für jede betrachtete Trajektorie eine Reihe von Polygonen entlang der Trajektorie zentriert werden, wobei sich das Polygon über die Trajektorie hinaus erstreckt, um die räumlichen Grenzen des Akteurs anzunähern und sich entlang der tangentialen Richtung der Trajektorie zu erstrecken, wenn sich der Akteur in der Zeit weiterentwickelt. Die Vorwärtsbewegung entlang der Trajektorie des ersten Fahrzeugs kann getrennt von der Vorwärtsbewegung entlang der Trajektorie des Konkurrenten betrachtet werden. Die Menge der potentiellen Interferenzpunkte kann als eine Menge von Punkten definiert werden, die sowohl in mindestens einem der möglichen Polygone des ersten Fahrzeugs 140 als auch in mindestens einem der möglichen Polygone des Konkurrenten enthalten sind, z. B. in der Schnittmenge der Polygone. Aus dieser Menge potentieller Interferenzpunkte kann eine Menge von Zuständen entlang der Trajektorie des ersten Fahrzeugs und eine Menge von Zuständen entlang der Trajektorie des Konkurrenten bestimmt werden. Die Menge von Zuständen kann ein Indikator für eine physikalischen Konkurrenz sein. Der Zeitpunkt, zu dem jeder Akteur in den Interferenzbereich eintritt, kann aus der Menge der Zustände auf beiden Wegen bestimmt werden.
Eine erste Breite und eine erste Länge können für den polygonalen Begrenzungsrahmen des ersten Fahrzeugs 140 angenommen werden. Es können getrennte Breiten und Längen für den polygonalen Begrenzungsrahmen für jeden Konkurrenten angenommen werden, die den realen Abmessungen dieser Akteure entsprechen. Die Vorfahrtsverhaltens-Prädiktor 112 kann eine erste Linie mit der ersten Breite konstruieren, die im Wesentlichen senkrecht zur Trajektorie des ersten Fahrzeugs 140 verläuft und entlang der Trajektorie des ersten Fahrzeugs 140 gebogen wird. Der Vorfahrtsverhaltens-Prädiktor 112 kann auch feststellen, ob die erzeugte erste Linie eine ähnlich erzeugte Linie für die angenommene Breite des Konkurrenten schneidet. Die Linie des Konkurrenten kann im Wesentlichen senkrecht zur Trajektorie des Konkurrenten verlaufen und entlang der Trajektorie des Konkurrenten gebogen sein. Die Vorfahrtsverhaltens-Prädiktor 112 kann feststellen, ob sich die beiden Linien schneiden. Tritt eine Schnittmenge auf, kann von einer potentiellen Interferenz ausgegangen werden. In einigen Ausführungsformen kann diese Analyse durch Verwendung eines Kreises (anstelle eines Polygons) mit einem Durchmesser, der der ersten Breite entlang der Trajektorie des ersten Fahrzeugs 140 entspricht, angenähert werden. Der Kreis kann auf der Trajektorie des ersten Fahrzeugs 140 zentriert werden und entlang der Trajektorie verschoben werden, während das erste Fahrzeug 140 in der Zeit vorwärts simuliert wird. Es können Punkte auf der Trajektorie des Konkurrenten identifiziert werden, die in mindestens einem der Kreise enthalten sind.
In ähnlicher Weise kann für jeden Konkurrenten entlang der jeweiligen Trajektorie ein überstreichender Kreis erzeugt werden, und es können alle potentiellen Interferenzpunkte ermittelt werden. Dies kann z. B. über verschachtelte geschlossene Schleifen erfolgen. Der Vorfahrtsverhaltens-Prädiktor 112 kann die Hälfte der Länge des Begrenzungsrahmens 140 des ersten Fahrzeugs subtrahieren (z. B. unabhängig davon, ob es sich bei dem Begrenzungsrahmen oder der Form um ein Polygon oder einen Kreis handelt), um einen Eintrittspunkt und einen Austrittspunkt für das Intervall von Stellungen zu bestimmen, an denen der Begrenzungsrahmen 140 des ersten Fahrzeugs die Interferenzzone berührt. Zusammenfließende Interferenzmuster können in ähnlicher Weise analysiert werden, indem ausgedehnte Intervalle gefunden werden, die sich überschneiden, oder sie können direkt aus dem Fahrspurdiagramm abgeleitet werden.
Bei der Vorwärtsprojektion einer Trajektorie kann die von einem Fahrzeug (z. B. dem ersten Fahrzeug 140) zurückgelegte Strecke als Funktion d(t) und die Geschwindigkeit als Funktion v(t) angegeben werden. Somit kann eine zeitliche Entwicklung einer Trajektorie durch den Phasenraum eines Fahrzeugs über den 2D-Punkt (d(t), v(t)) angegeben werden. Es kann davon ausgegangen werden, dass ein Akteur um einen konstanten Betrag □ beschleunigt (der von der Akteursklasse oder davon abhängen kann, ob der Akteur aggressiv vorgeht oder die Vorfahrt gewährt, oder auf Wunsch Null sein kann), bis er eine Höchstgeschwindigkeit (z. B. die Geschwindigkeitsbegrenzung) oder eine Mindestgeschwindigkeit (z. B. das Anhalten) erreicht. Während einer separaten Routine kann eine Berechnung durchgeführt und ein oder mehrere Arrays berechnet werden (z. B. für d(t) und v(t)).
Angesichts der Phasenraumtrajektorien eines Fahrzeugs können die beanspruchten Mengen zu jedem Zeitpunkt berücksichtigt werden, und es kann geprüft werden, ob sie sich bei Kreuzungen oder Einmündungen überschneiden. Die beanspruchte Menge, die dem Zustand (d(t), v(t)) entspricht, kann so modelliert werden, dass er um den festen Betrag b (der von der Akteursklasse abhängen kann) bis zum Stillstand verlangsamt wird. Die Verzögerung kann in der Form $z (t) = \frac{v (t)}{b}$
annehmen und dem Geschwindigkeitsprofil v(t) - bz folgen (man beachte, dass die zweite zeitliche Koordinate mit z bezeichnet wird, um sie nicht mit t zu verwechseln, und dass es eine Isomorphie zwischen z und t gibt). Der Anhalteweg $\frac{v {(t)}^{2}}{2 b}$
kann zu d(t) addiert werden. Somit kann die beanspruchte Mengenkurve (als Funktion von t und z) wie folgt berechnet werden: $D (t, z) = d (t) + v (t) \cdot z - \frac{1}{2} \cdot b \cdot z^{2}$
über das Intervall zE[0,v(t)b] und stoppt dann bei seinem Maximalwert von: $d (t) + \frac{1}{2} \cdot \frac{v {(t)}^{2}}{b} .$
Angesichts der Modellierung der verschiedenen Trajektorien kann der Szenarien-Analysator 110 die Kreuzung (oder den Übergang) wie folgt analysieren. Bei einer Kreuzung kann jede beanspruchte Menge analysiert werden, indem die Zeit bestimmt wird, zu der die beanspruchte Menge in die Kreuzung 130 einfährt (z. B., z_in(t, D_in)) und die Zeit, zu der die beanspruchte Menge die Kreuzung verlässt (z. B, z_out (t, D_out)), wobei D_in die Entfernung entlang des Weges bezeichnen kann, bei der die Begrenzungsrahmen des Akteurs in das Kreuzungsintervall 132 eintritt, und D_out die Entfernung entlang des Weges bezeichnet, bei der die Begrenzungsrahmen des Akteurs das Kreuzungsintervall 134 verlässt (z. B. in einem Fall, in dem das erste Fahrzeug 140 gerade durch die Kreuzung 130 fährt. Die Einfahrts- und Ausfahrtszeiten können wie folgt berechnet werden: $z_{i n} (t, D_{i n}) = m a x (0, \frac{1}{b} [v (t) - \sqrt{v {(t)}^{2} + 2 b (d (t) - D_{i n})}])$
$z_{o u t} (t, D_{o u t}) = m a x (0, \frac{1}{b} [v (t) - \sqrt{v {(t)}^{2} + 2 b (d (t) - D_{o u t})}]) .$
Wenn die oben berechneten Werte reell sind, können die Werte verwendet werden, um potentielle Kollisionen in Paaren von beanspruchten Mengen zu identifizieren, wie hierin erläutert. Wenn der für z_in(t, D_in) berechnete Wert komplex ist, kann die beanspruchte Menge bei dieser Auswahl von t nicht in die Kreuzung eintreten (und somit keine potentielle Kollision). Wenn der berechnete Wert für z_out (t, D_out) komplex ist, darf die beanspruchte Menge die Kreuzung für diese Auswahl von t nicht verlassen. Die Verwendung der Max-Funktion klemmt negative Werte auf Null, da Zeitumkehrsymmetrien mindestens in einigen Ausführungsformen nicht in Betracht gezogen werden. Das Zeitintervall [z_in(t, D_in), z_out(t, D_out)] kann für jeden beanspruchten Weg berechnet werden, und für jeden beanspruchten Weg kann eine geeignete diskretisierte Menge von t in Betracht gezogen werden. Das Zeitintervall [z_in (t, D_in), z_out(t, D_out)] für die spezifische Zeitspanne t kann als z-Intervall für diese Zeitspanne bezeichnet werden. Es kann ein z-Intervall für das Ego-Fahrzeug sowie ein z-Intervall für den beanspruchten Weg berechnet werden. Das z-Intervall kann den Zeitraum angeben (gemäß der zweiten zeitlichen Koordinate z und für einen bestimmten Wert der ersten zeitlichen Koordinate t), in dem sich der Akteur innerhalb der Kreuzung befindet. Wenn die Schnittmenge der z-Intervalle für zwei beanspruchte Wege (z. B. der beanspruchte Weg des Ego-Fahrzeugs und der beanspruchte Weg des Konkurrenten) eine von Null verschiedene Menge ist, dann können die beanspruchten Wege mit einer potentiellen Kollision verbunden sein. In solchen Fällen kann eine ermittelte Vorfahrtbedingung ein deutliches Bremsverhalten beinhalten, um einen guten Abstand zwischen dem Haltepunkt des ersten Fahrzeugs und der Kreuzung zu lassen, und/oder ein Warteelement kann als nicht freigegeben bestimmt werden. Liegt keine Überlappung vor, kann das erste Fahrzeug 140 entsprechend weiterfahren und/oder ein Warteelement kann als geräumt bestimmt werden.
Der Szenarien-Analysator 110 kann ein separates Verfahren anwenden, um festzustellen, ob Paare beanspruchter Mengen eine potentielle Kollision für einmündende Vorfahrtszenarien anzeigen. Bei Vorfahrtszenarien kann der Szenarien-Analysator 110 einen Abstand zu einem Einmündungspunkt entlang des beanspruchten Weges des ersten Fahrzeugs 140 annehmen (z. B., De_in). Zusätzlich kann ein Abstand zum Einmündungspunkt für den beanspruchten Weg eines Konkurrenten (z. B., Dc_in) angenommen werden. Nach dem Einmündungspunkt kann angenommen werden, dass die beanspruchten Wege übereinstimmen. Der Szenarien-Analysator 110 kann bestimmen, ob für ein beliebiges z das Intervall zwischen der nachstehenden Funktion liegt (z. B. eine Funktion eines nicht-negativen Werts von z für einen festen Wert von t): $D_{e} (t, z) - D_{e_i n} = {\begin{matrix} d_{e} (t) - D_{e_i n} + v_{e} (t) \cdot z - \frac{b_{e} z^{2}}{2},0 \leq z \leq \frac{v_{e} (t)}{b_{e}} \\ d_{e} - D_{e_i n} + \frac{v_{e} {(t)}^{2}}{2 \cdot b_{e}}, \frac{v_{e} (t)}{b_{e}} \leq z \end{matrix},$
die beschreibt, wie weit der vordere Teil der beanspruchten Menge 140 des ersten Fahrzeugs den Überschneidungspunkt passiert hat (zu beachten ist, dass es sich um eine quadratische Funktion gefolgt von einer Konstanten handelt) und die Fahrzeuglänge in Rückwärtsrichtung (z. B. kann das Intervall durch die obige Funktion und dieselbe Funktion abzüglich der Fahrzeuglänge beschrieben werden), für einen nicht negativen Bereichswert der Funktion immer getroffen wird: $D_{c} (t, z) - D_{c_i n} = {\begin{matrix} d_{c} (t) - D_{c_i n} + v_{c} (t) \cdot z - \frac{b_{c} z^{2}}{2},0 \leq z \leq \frac{v_{c} (t)}{b_{c}} \\ d_{c} - D_{c_i n} + \frac{v_{c} {(t)}^{2}}{2 \cdot b_{c}}, \frac{v_{c} (t)}{b_{c}} \leq z \end{matrix},$
der beschreibt, wie weit der vordere Teil der beanspruchten Menge des Konkurrenten den Einmündungspunkt passiert hat. Beachten Sie, dass sich die Indizes e auf das erste Fahrzeug 140 (z. B. das Ego-Fahrzeug) und die Indizes c auf einen Konkurrenten im Einmündungsvorfahrtsszenario beziehen. Dabei wird geprüft, ob sich die beanspruchten Mengen nach dem Einmündungspunkt überschneiden. Dies kann durch Lösen einer Reihe von Quadraten ermittelt werden (Lösen von Schnittmengen zwischen Ego-Front und Konkurrenten-Front und Ego-Heck und Konkurrenten-Front, was, wenn es mit einem Brute-Force-Verfahren durchgeführt wird, das Lösen von 2x4=8 Quadraten und das Schlussfolgern über die Schnittmengen erfordert), wobei darauf geachtet wird, dass alle Fälle behandelt werden (Ego-Front und Heck der beanspruchten Menge des Fahrzeug erreicht den Einmündungspunkt, nur Front erreicht den Einmündungspunkt, oder keine erreicht den Einmündungspunkt, und Konkurrenten-Front erreicht den Einmündungspunkt oder nicht).
Nun auf die 3-7 bezugnehmend, weist jeder Block der Verfahren 300-700 und anderer hierin beschriebener Verfahren einen Rechenprozess auf, der mit einer beliebigen Kombination aus 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 Verfahren können auch als computerverwendbare Anweisungen auf Computerspeichermedien gespeichert sein. Die Verfahren können 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 300-700 beispielhaft in Bezug auf das Vorfahrtsplanungssystem der 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.
3 ist ein Flussdiagramm, das ein Verfahren 300 zur Steuerung eines autonomen Fahrzeugs (z. B. eines Ego-Fahrzeugs) gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 300 umfasst in Block 302 das Erkennen eines Vorfahrtszenarios für das Ego-Fahrzeug. In Block 304 werden ein oder mehrere Warteelemente empfangen, die verschiedene Aspekte des Vorfahrtszenarios codieren. Das eine oder die mehreren Warteelemente können als Reaktion auf die Erkennung des Vorfahrtszenarios empfangen werden. Das eine oder die mehreren Warteelemente können einen oder mehrere für das Vorfahrtszenario relevante Konkurrenten codieren. Für jeden Konkurrenten kann das Warteelement einen oder mehrere beanspruchte Wege für jeden angegebenen Konkurrenten codieren. Das Warteelement kann zusätzlich mindestens einen beanspruchten Weg für das Ego-Fahrzeug codieren. In Block 306 werden eine oder mehrere Kreuzungen (z. B. eine Kreuzung an einer Kreuzung) und/oder Einmündungen (z. B. eine Fahrspureinmündung), die für das Vorfahrtszenario relevant sind, durch eine Analyse der in den empfangenen Warteelementen codierten Daten identifiziert. Verschiedene Ausführungsformen der Identifizierung von Kreuzungen und/oder Einmündungen werden in Verbindung mit dem Verfahren 400 der 4 erläutert.
In Block 308 werden Trajektorien für die in Block 306 identifizierten Kreuzungen und Einmündungen (z. B. aus den Wegen eines Warteelements) erzeugt. Verschiedene Ausführungsformen zum Erzeugen von Trajektorien werden in Verbindung mit dem Verfahren 500 der 5 erläutert. In Block 310 werden Trajektorien, die mit Kreuzungen verbunden sind, analysiert, um zu bestimmen, ob eine potentielle Kollision zwischen dem Ego-Fahrzeug und einem oder mehreren Konkurrenten in einem Vorfahrtszenario an einer Kreuzung (oder Einmündung) vermieden werden soll. Verschiedene Ausführungsformen der Analyse kreuzungsbezogener Trajektorien werden in Verbindung mit dem Verfahren 600 der 6 erläutert. Ebenfalls in Block 310 werden Trajektorien im Zusammenhang mit Einmündungen analysiert, um zu bestimmen, ob eine potentielle Kollision zwischen dem Ego-Fahrzeug und einem oder mehreren Kontrahenten in einem Einmündungsszenario vermieden werden soll. Verschiedene Ausführungsformen der Analyse kreuzungsbezogener Trajektorien werden in Verbindung mit den Verfahren 600 und 700 der 6 bzw. 7 diskutiert. Hier soll jedoch kurz darauf hingewiesen werden, dass die Verwendung von Trajektorien zur Analyse von Kreuzungen und Einmündungen auch die Bewertung umfassen kann, ob eine Konkurrenz zwischen der Trajektorie des Ego-Fahrzeugs und einer oder mehreren Trajektorien des einen oder der mehreren Konkurrenten besteht (z. B. die Bewertung, ob eine Konkurrenz zwischen einer ersten Trajektorie (des Ego-Fahrzeugs) und einer zweiten Trajektorie (eines Konkurrenten) besteht). In Block 312 wird ein Vorfahrtsverhalten basierend auf den Analysen der kreuzenden und einmündenden Trajektorien ausgewählt. In Block 314 wird das Ego-Fahrzeug so gesteuert, dass das Ego-Fahrzeug gemäß dem in Block 312 ausgewählten Vorfahrtsverhalten fährt.
4 ist ein Flussdiagramm, das ein Verfahren 400 zur Identifizierung von Kreuzungen und Einmündungen für beanspruchte Wege für ein Vorfahrtsszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. In einigen Ausführungsformen kann das Verfahren 400 durch das Verfahren 300 der 3 aufgerufen werden. Zum Beispiel kann das Verfahren 400 von Block 306 des Verfahrens 300 aufgerufen werden. Das Verfahren 400 umfasst in Block 402 den Empfang einer Menge von beanspruchten Wegen für das Ego-Fahrzeug. Ebenfalls in Block 402 kann eine Menge beanspruchter Wege für jeden der Konkurrenten empfangen werden, die für ein Vorfahrtsszenario relevant sind (z. B. das in Block 302 des Verfahrens 300 erkannte Vorfahrtsszenario). Beispielsweise können die verschiedenen Mengen der beanspruchten Wege in dem einen oder den mehreren in Block 304 des Verfahrens 300 empfangenen Warteelementen codiert werden. In mindestens einer Ausführungsform kann die Menge der beanspruchten Wege für das Ego-Fahrzeug einen einzigen beanspruchten Weg für das Ego-Fahrzeug enthalten und die Menge der beanspruchten Wege für jeden Konkurrenten kann einen oder mehrere beanspruchte Wege enthalten. In Block 404 wird eine „for“-Schleife über den einen oder die mehreren Konkurrenten eingeleitet, die für das Vorfahrtsszenario relevant sind. In verschiedenen Ausführungsformen können statt einer for-Schleife auch eine „while“-Schleife oder andere programmatische, sich wiederholende oder iterative Schleifenstrukturen in einem der hier erläuterten Verfahren eingeleitet werden.
In Block 406 wird eine for-Schleife über die Menge der beanspruchten Wege für den aktuellen Konkurrenten (der in Block 404 eingeleiteten Konkurrenten-für-Schleife) eingeleitet. In Block 408 wird eine for-Schleife über die diskretisierten beanspruchten Punkte im aktuellen Konkurrentenweg (der Konkurrentenwegschleife) eingeleitet. In Block 410 wird ein Punkt auf dem beanspruchten Weg des Ego-Fahrzeugs identifiziert, der (z. B. gemäß einer L2-Norm für eine euklidische 2D-Mannigfaltigkeit) dem aktuellen Punkt (der in Block 408 eingeleiteten Wegpunkt-for-Schleife) am nächsten ist. Im Entscheidungsblock 412 wird der Abstand (z. B. ein L2-Abstand) zwischen dem Konkurrentenwegpunkt und dem Ego-Fahrzeug-Wegpunkt (z. B. dem in Block 410 identifizierten Punkt) einem Abstandsschwellentest unterzogen. Wenn der Abstand größer ist als max(Ego-Breite, Konkurrenten-Breite), wobei Ego-Breite die modellierte Breite des Ego-Fahrzeugs und die modellierte Breite des Konkurrenten angibt, dann gibt es in einigen Ausführungsformen keine Kreuzung oder Einmündung für den Konkurrentenpunkt und den Ego-Fahrzeugweg, und das Verfahren 400 kann mit Entscheidungsblock 416 fortfahren.
Ist der Abstand kleiner als der Maximalwert (Ego-Breite, Konkurrenten-Breite), dann kann es eine Kreuzung oder Einmündung für den Konkurrentenpunkt und den Ego-Fahrzeugweg geben, und das Verfahren 400 kann zum Entscheidungsblock 414 fortfahren. Es ist zu beachten, dass die modellierte Breite des Ego-Fahrzeugs und der Konkurrenten unter Verwendung von Wahrnehmungskomponenten des Ego-Fahrzeugs bestimmt werden kann. In Block 414 können der Weg des Ego-Fahrzeugs und der Weg des Konkurrenten als ein interferierendes Wegpaar identifiziert werden. Das Wegpaar kann als Kreuzungs- oder Einmündungs-Interferenzwegpaar identifiziert werden. In einigen Ausführungsformen kann das relevante Punktpaar (z. B. der Punkt des Ego-Fahrzeugwegs und der Punkt des Konkurrentenwegs) als Interferenzpunktpaar (z. B. ein Kreuzungs- oder Einmündungs-Interferenzpunktpaar) identifiziert werden. Das Verfahren 400 kann zum Entscheidungsblock 416 übergehen.
Im Entscheidungsblock 416 wird entschieden, ob die Schleife der Konkurrentenpunkte beendet werden soll. Wenn die for-Schleife der Konkurrentenpunkte beendet werden soll, geht das Verfahren 400 zu Entscheidungsblock 418 über. Andernfalls, wenn die Konkurrentpunkt-Flussschleife fortgesetzt werden soll, kehrt das Verfahren 400 zu Block 408 zurück. Im Entscheidungsblock 418 wird entschieden, ob die for-Schleife der Konkurrentenpunkte beendet werden soll. Wenn der die for-Schleife der Konkurrentenpunkte beendet werden soll, geht das Verfahren 400 zum Entscheidungsblock 420 über. Wenn die die for-Schleife der Konkurrentenpunkte fortgesetzt werden soll, kehrt das Verfahren 400 zu Block 406 zurück. Im Entscheidungsblock 420 wird entschieden, ob die die for-Schleife über die Konkurrenten beendet werden soll. Wenn die for-Schleife über die Konkurrenten beendet werden soll, geht das Verfahren 400 zu Block 422 über. Wenn die for-Schleife über die Konkurrenten beendet werden soll, kehrt das Verfahren 400 zu Block 404 zurück. In Block 422 können die interferierenden Wegpaare (und die interferierenden Punktpaare) zurückgegeben werden. Beispielsweise können die interferierenden Wegpaare als Kreuzungen und Einmündungen an den Block 308 des Verfahrens 300 zurückgegeben werden.
5 ist ein Flussdiagramm, das ein Verfahren 500 zur Erzeugung von Trajektorien für Kreuzungen und Einmündungen für ein Vorfahrtsszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. In einigen Ausführungsformen kann das Verfahren 500 durch das Verfahren 300 der 3 aufgerufen werden. Zum Beispiel kann das Verfahren 500 von Block 308 des Verfahrens 300 aufgerufen werden. Das Verfahren 500 umfasst in Block 502 den Empfang der Kreuzungen und Einmündungen. Der Empfang der Kreuzungen und Einmündungen kann den Empfang der interferierenden Wegpaare aus dem Verfahren 400 (z. B. Block 422) beinhalten. In Block 504 kann eine Trajektorie für das Ego-Fahrzeug erzeugt werden. Die Trajektorie des Ego-Fahrzeugs kann durch einen Geschwindigkeits-Abstands-Phasenraum verlaufen und kann die Bestimmung (d_e(t), v_e(t)) wie hierin beschrieben.
In Block 506 wird eine For-Schleife über die Konkurrenten eingeleitet. Die in Block 506 eingeleitete „for“-Schleife kann auf Konkurrenten beschränkt werden, die an mindestens einer Interferenz (z. B. einer Kreuzung oder Einmündung) mit dem Ego-Fahrzeugweg beteiligt sind. In Block 508 wird eine for-Schleife über den beanspruchten Weg des aktuellen Konkurrenten eingeleitet (z. B. in Bezug auf die for-Schleife von Block 506). In einigen Ausführungsformen kann die for-Schleife auf die beanspruchten Wege beschränkt werden, die eine Interferenz mit dem Weg des Ego-Fahrzeugs aufweisen. In Block 510 wird eine Trajektorie für den aktuellen Konkurrentenweg (z. B. in Bezug auf die for-Schleife von Block 508) erzeugt. Die Trajektorie des Konkurrentenwegs kann durch einen Geschwindigkeits-Abstands-Phasenraum verlaufen und kann die Bestimmung (d_c(t), v_c(t)) wie hierin beschrieben.
Im Entscheidungsblock 512 wird entschieden, ob die Schleife des Konkurrentenwegs beendet werden soll. Wenn die Schleife beendet werden soll, geht das Verfahren 500 zu Entscheidungsblock 514 über. Wenn die for-Schleife fortgesetzt werden soll, kann das Verfahren 500 zu Block 508 zurückkehren. Im Entscheidungsblock 514 wird entschieden, ob die for-Schleife der Konkurrenten beendet werden soll. Wenn die for-Schleife beendet werden soll, kann das Verfahren 500 zu Block 516 übergehen. Wenn die for-Schleife fortgesetzt werden soll, kann das Verfahren 500 zu Block 506 zurückkehren. In Block 516 werden die Trajektorie des Ego-Fahrzeugs und die Trajektorien der Konkurrenten zurückgegeben. Die Trajektorien können z. B. als Kreuzungs- und Einmündungs-Trajektorien an Block 310 des Verfahrens 300 zurückgegeben werden.
6 ist ein Flussdiagramm, das ein Verfahren 600 zur Analyse von Kreuzungstrajektorien für ein Vorfahrtsszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. In einigen Ausführungsformen kann das Verfahren 600 durch das Verfahren 300 der 3 aufgerufen werden. Zum Beispiel kann das Verfahren 600 von Block 310 des Verfahrens 300 aufgerufen werden. Das Verfahren 600 umfasst in Block 602 den Empfang von kreuzungsbezogenen Trajektorien. Die kreuzungsbezogenen Trajektorien können von Block 516 der Verfahren 500 zurückgegeben werden. Die kreuzungsbezogenen Trajektorien können mindestens eine Trajektorie des Ego-Fahrzeugs und eine oder mehrere Trajektorien von einem oder mehreren Konkurrenten enthalten. Jede der einen oder mehreren Konkurrent-Trajektorien kann einen oder mehrere Punkte aufweisen, die mit einer oder mehreren Kreuzungsinterferenzen mit einem oder mehreren Punkten der Ego-Fahrzeug-Trajektorie verbunden sind. In Block 604 wird eine for-Schleife über den einen oder die mehreren Konkurrenten eingeleitet. In Block 608 wird eine for-Schleife über die Trajektorien des aktuellen Konkurrenten eingeleitet. Die for-Schleife von Block 608 kann auf die Trajektorien des aktuellen Konkurrenten beschränkt werden, die mindestens eine kreuzende Interferenz mit der Trajektorie des Ego-Fahrzeugs aufweisen. In Block 610 wird eine for-Schleife über die diskretisierten Zeitkästen der aktuellen Konkurrenten-Trajektorie eingeleitet.
In Block 612 wird das z-Intervall für das Ego-Fahrzeug (für den aktuellen t-Kastenwert) wie hierin beschrieben berechnet, z. B., [zin(t,D_in),Z_out(t,D_out)]. Es ist zu beachten, dass es sich bei dem in Block 612 berechneten Intervall um die vom Szenarien-Analysator 110 der 1 berechneten z-Intervalle handelt. In Block 614 wird das z-Intervall für den aktuellen Konkurrentenweg (und für den aktuellen t-Kastenwert) berechnet. Im Entscheidungsblock 616 wird bestimmt, ob es eine Überschneidung zwischen dem z-Intervall für den Ego-Fahrzeugweg und dem Konkurrentenweg gibt. Wenn die Überschneidung die Nullmenge ist, kann das Verfahren 600 zum Entscheidungsblock 620 übergehen. Wenn die Überschneidung der beiden Z-Intervalle eine Nicht-Nullmenge ist, kann das Verfahren 600 zu Block 618 weitergehen. In Block 618 kann eine potentielle Überschneidungskollision für das Trajektorienpaar bei dem bestimmten t-Kastenwert protokolliert oder gespeichert werden. Das Verfahren 600 kann dann zum Entscheidungsblock 620 übergehen.
Im Entscheidungsblock 620 wird bestimmt, ob die for-Schleife über die t Kastenwerte beendet werden soll. Wenn die Schleife beendet werden soll, geht das Verfahren 600 zu Block 622 über. Wenn die Schleife nicht beendet werden soll, kehrt das Verfahren 600 zu Block 610 zurück. Im Entscheidungsblock 622 wird bestimmt, ob die Schleife über die kreuzenden Interferenzen der Trajektorie beendet werden soll. Wenn die Schleife beendet werden soll, kann das Verfahren 600 mit Entscheidungsblock 624 fortfahren. Wird die Schleife nicht beendet, kehrt das Verfahren 600 zu Block 608 zurück. Im Entscheidungsblock 624 wird entschieden, ob die Schleife unter den aktuellen Trajektorien des Konkurrenten beendet werden soll. Wenn die Schleife beendet werden soll, geht das Verfahren 600 zum Entscheidungsblock 626 über. Wenn die Schleife nicht beendet werden soll, kehrt das Verfahren 600 zu Block 606 zurück. Im Entscheidungsblock 626 wird entschieden, ob die Schleife über die Konkurrenten beendet werden soll. Wenn die Schleife beendet werden soll, kann das Verfahren 600 zu Block 628 weitergehen. Wenn die Schleife nicht beendet werden soll, kann das Verfahren 600 zu Block 604 zurückkehren. In Block 628 werden die potentiellen Kreuzungskollisionen zurückgegeben (z. B. diejenigen Interferenzen, bei denen die Trajektorie des Konkurrenten und die Trajektorie des Ego-Fahrzeugs für mindestens einen bestimmten Wert des Zeitbins überlappende z-Intervalle haben). Die potentiellen Kreuzungskollisionen können an Block 312 des Verfahrens 300 zurückgegeben werden.
7 ist ein Flussdiagramm, das ein Verfahren 700 zur Analyse von Einmündungs-Trajektorien für ein Vorfahrtsszenario gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. In einigen Ausführungsformen kann das Verfahren 700 durch das Verfahren 300 der 3 aufgerufen werden. Zum Beispiel kann das Verfahren 700 von Block 310 des Verfahrens 300 aufgerufen werden. Das Verfahren 700 umfasst in Block 702 den Empfang von einmündungsbezogenen Trajektorien. Die mit der einmündungsbezogenen Trajektorien oder Einmündungs-Trajektorien können von Block 516 des Verfahrens 500 zurückgegeben werden. Die Einmündungs-Trajektorien können mindestens eine Ego-Fahrzeug-Trajektorie und eine oder mehrere Trajektorien von einem oder mehreren Konkurrenten enthalten. Jede der einen oder mehreren Konkurrententrajektorien kann einen oder mehrere Punkte aufweisen, die mit einem oder mehreren Einmündungsinterferenzen mit einem oder mehreren Punkten der Ego-Fahrzeugtrajektorie verbunden sind. In Block 704 wird eine for-Schleife über den einen oder die mehreren Konkurrenten eingeleitet. In Block 708 wird eine for-Schleife über die Trajektorien des aktuellen Konkurrenten eingeleitet. Die for-Schleife von Block 708 kann auf die Trajektorien des aktuellen Konkurrenten beschränkt werden, die mindestens eine Interferenz mit der Trajektorie des Ego-Fahrzeugs aufweisen. In Block 710 wird eine for-Schleife über die diskretisierten Zeitkästen der aktuellen Konkurrenten-Trajektorie eingeleitet.
Im Entscheidungsblock 712 wird festgestellt, ob sich die z beanspruchten Mengen überschneiden. Man beachte, dass die z beanspruchten Mengen diejenigen sind, die vom Szenarien-Analysator 110 der 1 berechnet wurden. Die z-Intervalle umfassen also die Bestimmung von (D_e(t,z) - D_{e_in}) (für die Trajektorie des Ego-Fahrzeugs) und (D_c(t, z) - D_{c_in}) (für die Trajektorie des Konkurrenten), wie oben beschrieben. Wenn es keine Überschneidung gibt, kann das Verfahren 700 zum Entscheidungsblock 716 übergehen. Liegt eine Überschneidung vor, so kann das Verfahren 700 zum Block 712 weitergehen. In Block 714 kann für das Trajektorienpaar mit dem bestimmten t-Kastenwert eine potentielle Einmündungs-Kollision protokolliert oder gespeichert werden. Das Verfahren 700 kann dann zum Entscheidungsblock 716 übergehen.
Im Entscheidungsblock 716 wird entschieden, ob die for-Schleife über die t Kastenwerte beendet werden soll. Wenn die Schleife beendet werden soll, geht das Verfahren 700 zum Entscheidungsblock 718 über. Wenn die Schleife nicht beendet werden soll, kehrt das Verfahren 700 zu Block 710 zurück. Im Entscheidungsblock 718 wird entschieden, ob die Schleife über die Einmündungs-Interferenzen der Trajektorie beendet werden soll. Wenn die Schleife beendet werden soll, kann das Verfahren 700 mit Entscheidungsblock 720 fortfahren. Wenn die Schleife nicht beendet wird, kehrt das Verfahren 700 zu Block 708 zurück. Im Entscheidungsblock 720 wird entschieden, ob die Schleife unter den aktuellen Trajektorien des Konkurrenten beendet werden soll. Wenn die Schleife beendet werden soll, geht das Verfahren 700 zum Entscheidungsblock 722 über. Soll die Schleife nicht beendet werden, kehrt das Verfahren 700 zu Block 706 zurück. Im Entscheidungsblock 722 wird entschieden, ob die Schleife über die Konkurrenten beendet werden soll. Wenn die Schleife beendet werden soll, kann das Verfahren 700 zu Block 724 weitergehen. Wenn die Schleife nicht beendet werden soll, kann das Verfahren 700 zu Block 704 zurückkehren. In Block 724 werden die potentiellen Überschneidungskollisionen zurückgegeben (z. B. diejenigen Interferenzen, bei denen die Trajektorie des Konkurrenten und die Trajektorie des Ego-Fahrzeugs sich überschneidende z-Mengen für mindestens einen bestimmten Wert des Zeitbereichs aufweisen). Die potentiellen Kreuzungskollisionen können an Block 312 des Verfahrens 300 zurückgegeben werden.
Beispielhaftes autonomes Fahrzeug
8A ist eine Darstellung 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 Pkw, ein Lkw, ein Bus, ein Ersthelferfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrfahrzeug, ein Polizeifahrzeug, ein Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne, ein an einen Anhänger gekoppeltes Fahrzeug und/oder eine andere Art von Fahrzeug (z. B. ein unbemanntes Fahrzeug und/oder ein Fahrzeug, das einen oder mehrere Fahrgäste aufnimmt). Autonome Fahrzeuge werden im Allgemeinen in Form von Automatisierungsstufen 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 werden. Das Fahrzeug 800 kann in der Lage sein, Funktionen gemäß einer oder mehrerer der Stufen 3 bis 5 der Stufen des autonomen Fahrens auszuführen. Beispielsweise kann das Fahrzeug 800 je nach Ausführungsform bedingt automatisiert (Stufe 3), hochautomatisiert (Stufe 4) und/oder vollständig automatisiert (Stufe 5) sein.
Das Fahrzeug 800 kann Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs umfassen. Das Fahrzeug 800 kann ein Antriebssystem 850 umfassen, wie z. B. einen Verbrennungsmotor, eine Hybrid-Elektrokraftanlage, einen reinen Elektromotor und/oder einen anderen Antriebssystemtyp. Das Antriebssystem 850 kann mit einem Antriebsstrang des Fahrzeugs 800 verbunden sein, der ein Getriebe umfassen kann, um den Antrieb des Fahrzeugs 800 zu ermöglichen. Das Antriebssystem 850 kann in Reaktion auf den Empfang von Signalen von der Drosselklappe/Gaspedal 852 gesteuert werden.
Ein Lenksystem 854, das ein Lenkrad umfassen kann, kann verwendet werden, um das Fahrzeug 800 zu lenken (z. B. entlang eines gewünschten Weges oder einer Route), wenn das Antriebssystem 850 in Betrieb ist (z. B. wenn das Fahrzeug in Bewegung ist). Das Lenksystem 854 kann Signale von einem Lenkaktor 856 empfangen. Das Lenkrad kann optional für die vollständige Automatisierung (Stufe 5) eingesetzt werden.
Das Bremssensorsystem 846 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf den Empfang von Signalen von den Bremsaktoren 848 und/oder Bremssensoren zu betätigen.
Ein oder mehrere Controller 836, die einen oder mehrere System-on-Chips (SoCs) 804 (8C) und/oder GPU(s) enthalten können, können Signale (z. B. repräsentativ für Befehle) an eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 800 senden. Beispielsweise können die Controller Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktoren 848, zur Betätigung des Lenksystems 854 über einen oder mehrere Lenkaktoren 856 und zur Betätigung des Antriebssystems 850 über einen oder mehrere Drosselklappen/ Gaspedale 852 senden. Die Controller 836 können eine oder mehrere eingebaute (z. B. integrierte) Rechenvorrichtungen (z. B. Supercomputer) umfassen, 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 Controller 836 können einen ersten Controller 836 für autonome Fahrfunktionen, einen zweiten Controller 836 für funktionale Sicherheitsfunktionen, einen dritten Controller 836 für Funktionen der künstlichen Intelligenz (z. B. Computervision), einen vierten Controller 836 für Infotainment-Funktionen, ein fünften Controller 836 für Redundanz unter Notfallbedingungen und/oder andere Controller umfassen. In einigen Beispielen kann ein einziger Controller 836 zwei oder mehr der oben genannten Funktionen übernehmen, zwei oder mehrere Controller 836 können eine einzige Funktion übernehmen und/oder eine beliebige Kombination davon.
Die Controller 836 können die Signale zum Steuern einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 800 als Reaktion auf Sensordaten bereitstellen, die von einem oder mehreren Sensoren (z. B. Sensoreingaben) empfangen werden. Die Sensordaten können beispielsweise und ohne Einschränkung empfangen werden von globalen Navigationssatellitensystem- Sensor(en) 858 (z. B. Global Positioning System-Sensor(en)), RADAR-Sensor(en) 860, Ultraschallsensor(en) 862, LIDAR-Sensor(en) 864, Trägheitsmesseinheits- (IMU)-Sensor(en) 866 (z. B., Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(e) 896, Stereokamera(s) 868, Weitwinkelkamera(s) 870 (z. B. Fischaugenkameras), Infrarotkamera(s) 872, Umgebungskamera(s) 874 (z. B. 360-Grad-Kameras), Fernbereichs- und/oder Mittelbereichskamera(s) 898, Geschwindigkeitssensor(en) 844 (z. B. zur Messung der Geschwindigkeit des Fahrzeugs 800), Vibrationssensor(en) 842, Lenksensor(en) 840, Bremssensor(en) (z. B. als Teil des Bremssensorsystems 846) und/oder andere Sensortypen.
Ein oder mehrere Controller 836 können Eingaben (z. B. in Form von Eingabedaten) von einem Kombiinstrument 832 des Fahrzeugs 800 empfangen und Ausgaben (z. B. in Form von Ausgabedaten, Anzeigedaten usw.) über eine Anzeige 834 der Mensch-Maschine-Schnittstelle (HMI), einen akustischen Signalgeber, 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 der 8C), Standortdaten (z. B. der Standort des Fahrzeugs 800, z. B. auf einer Karte), Richtung, Standort anderer Fahrzeuge (z. B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie von dem/den Controller(n) 836 wahrgenommen, usw. umfassen. Beispielsweise kann die HMI-Anzeige 834 Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. ein Straßenschild, ein Warnschild, eine sich ändernde Ampel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z. B. Spurwechsel jetzt, Ausfahrt 34B in zwei Meilen usw.).
Das Fahrzeug 800 umfasst ferner eine Netzwerkschnittstelle 824, die eine oder mehrere drahtlose Antennen 826 und/oder Modem(s) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann die Netzwerkschnittstelle 824 zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. imstande sein. Die drahtlosen Antennen 826 können auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Geräte usw.) unter Verwendung lokaler Netzwerke wie Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Low Power Wide Area Networks (LPWANs) wie LoRaWAN, SigFox usw. ermöglichen.
8B ist ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug 800 der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die jeweiligen Sichtfelder stellen ein Ausführungsbeispiel dar und sind nicht als einschränkend zu betrachten. Beispielsweise können zusätzliche und/oder alternative Kameras enthalten sein und/oder die Kameras können an verschiedenen Stellen des Fahrzeugs 800 angeordnet sein.
Die Kameratypen für die Kameras können Digitalkameras umfassen, sind jedoch nicht darauf beschränkt, die für die Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 800 angepasst werden können. Die Kamera(s) können mit der Sicherheitsstufe B (ASIL) und/oder einer anderen ASIL betrieben werden. Die Kameratypen können je nach Ausführungsform eine beliebige Bildaufnahmerate aufweisen, z. B. 60 Bilder pro Sekunde (fps), 120 fps, 240 fps usw. Die Kameras können Rollblendenverschluss, globalen Blendenverschluss, einen anderen Verschlusstyp oder eine Kombination davon verwenden. In einigen Beispielen kann die Farbfilteranordnung eine Rot-Klar-Klar-Klar-Farbfilteranordnung (RCCC), eine Rot-Klar-Klar-Blau-Farbfilteranordnung (RCCB), eine Rot-Blau-Grün-Klar-Farbfilteranordnung (RBGC), eine Foveon X3-Farbfilteranordnung, eine Bayer-Sensor-Farbfilteranordnung (RGGB), eine Monochromsensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung umfassen. In einigen Ausführungsformen können Kameras mit klaren Pixeln, wie z. B. Kameras mit einer RCCC-, einer RCCB- und/oder einer RBGC-Farbfilteranordnung, verwendet werden, um die Lichtempfindlichkeit zu erhöhen.
In einigen Beispielen können eine oder mehrere der Kameras verwendet werden, um erweiterte Fahrerassistenzsysteme (ADAS) auszuführen (z. B. als Teil einer redundanten oder ausfallsicheren Konstruktion). So kann beispielsweise eine Multifunktions-Monokamera installiert werden, um Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitzustellen. Eine oder mehrere der Kameras (z. B. alle Kameras) können gleichzeitig Bilddaten (z. B. Video) aufzeichnen und liefern.
Eine oder mehrere Kameras können in einer Montagevorrichtung, z. B. einer kundenspezifischen (3-D-gedruckten) Vorrichtung, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z. B. Reflexionen vom Armaturenbrett, die sich in den Windschutzscheibenspiegeln spiegeln) auszuschalten, die die Bilddatenerfassung der Kamera beeinträchtigen könnten. Bei der Montage von Außenspiegeln können die Außenspiegel kundenspezifisch dreidimensional gedruckt werden, so dass die Kameramontageplatte der Form des Außenspiegels entspricht. In einigen Beispielen können die Kameras in den Außenspiegel integriert werden. Bei Seitenkameras können die Kameras auch in die vier Säulen an jeder Ecke der Kabine integriert werden.
Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 800 einschließt (z. B. nach vorne gerichtete Kameras), können für die Umgebungsansicht verwendet werden, um dabei zu helfen, nach vorne gerichtete Wege und Hindernisse zu identifizieren, sowie mit Hilfe eines oder mehrerer Controller 836 und/oder Steuer-SoCs Informationen bereitzustellen, die für die Erstellung eines Belegungsgitters und/oder die Bestimmung der bevorzugten Fahrzeugwege entscheidend sind. Nach vorne 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 vorne gerichtete Kameras können auch für ADAS-Funktionen und -Systeme wie Spurverlassenswarnung (LDW), autonome Geschwindigkeitsregelung (ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung verwendet werden.
In einer nach vorne gerichteten Konfiguration kann eine Vielzahl von Kameras verwendet werden, z. B. eine monokulare Kameraplattform, die einen CMOS-Farbbildsensor (Komplementär-Metalloxid-Halbleiter) enthält. Ein weiteres Beispiel sind eine oder mehrere Weitwinkelkameras 870, die verwendet werden können, um Objekte zu erkennen, die von der Peripherie her ins Blickfeld kommen (z. B. Fußgänger, kreuzende Fahrzeuge oder Fahrräder). Obwohl in 8B nur eine Weitwinkelkamera dargestellt ist, kann das Fahrzeug 800 mit einer beliebigen Anzahl von Weitwinkelkameras 870 ausgestattet sein. Darüber hinaus können eine oder mehrere Kameras mit großer Reichweite 898 (z. B. ein Stereokamerapaar mit großer Reichweite) für die tiefenbasierte Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert wurde. Die Weitbereichskamera(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 enthalten sein. Die Stereokamera(s) 868 können eine integrierte Steuereinheit enthalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (FPGA) und einen Multicore-Mikroprozessor mit integrierter CAN- oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. Mit einer solchen Einheit kann eine 3D-Karte der Fahrzeugumgebung erstellt werden, einschließlich einer Entfernungsschätzung für alle Punkte im Bild. Eine alternative Stereokamera(s) 868 kann einen oder mehrere kompakte Stereosicht-Sensoren mit zwei Kameraobjektiven (je eines links und rechts) und einen Bildverarbeitungschip umfassen, der die Entfernung zwischen dem Fahrzeug und dem Zielobjekt messen und die erzeugten Informationen (z. B. Metadaten) zur Aktivierung der autonomen Notbrems- und Spurhaltewarnfunktionen verwenden kann. Zusätzlich oder alternativ zu den hier beschriebenen Stereokameras können auch andere Typen von Stereokameras (868) verwendet werden.
Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 800 einschließt (z. B. Seitenkameras), können für die Umgebungsansicht verwendet werden und Informationen liefern, die zur Erstellung und Aktualisierung des Belegungsrasters sowie zur Erzeugung von Kollisionswarnungen bei Seitenaufprall verwendet werden. Beispielsweise können die Umgebungskamera(s) 874 (z. B. vier Umgebungskameras 874 wie in 8B dargestellt) am Fahrzeug 800 positioniert werden. Die Umgebungskamera(s) 874 können Weitwinkelkamera(s) 870, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder Ähnliches umfassen. Vier Beispiele: Vier Fischaugenkameras können an der Vorderseite, am Heck und an den Seiten des Fahrzeugs angebracht werden. In einer alternativen Anordnung kann das Fahrzeug drei Umgebungskameras 874 (z. B. links, rechts und hinten) verwenden und eine oder mehrere andere Kamera(s) (z. B. eine nach vorne gerichtete Kamera) als vierte Umgebungskamera nutzen.
Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 800 einschließt (z. B. Rückfahrkameras), können für die Einparkhilfe, die Umgebungsansicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsrasters verwendet werden. Es kann eine Vielzahl von Kameras verwendet werden, einschließlich, aber nicht beschränkt auf Kameras, die auch als nach vorne gerichtete Kamera(s) geeignet sind (z. B. Fern- und/oder Mittelstreckenkamera(s) 898, Stereokamera(s) 868, Infrarotkamera(s) 872 usw.), wie hierin beschrieben.
8C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 800 der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der dargestellten verwendet werden, und einige Elemente können ganz weggelassen werden. Außerdem sind viele der hier beschriebenen Elemente 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 werden können. Verschiedene hier beschriebene Funktionen, die von Einheiten ausgeführt werden, können von 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.
Alle Komponenten, Merkmale und Systeme des Fahrzeugs 800 in 8C sind als über den Bus 802 verbunden dargestellt. Der Bus 802 kann eine Controller Area Network (CAN)-Datenschnittstelle (hier alternativ als „CAN-Bus“ bezeichnet) umfassen. Ein CAN-Bus 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 von Bremsen, Beschleunigung, Bremsen, Lenkung, Scheibenwischern usw. Ein CAN-Bus kann so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten hat, jeder mit seiner eigenen eindeutigen Kennung (z. B. einer CAN-ID). Der CAN-Bus kann ausgelesen werden, um den Lenkradwinkel, die Fahrgeschwindigkeit, die Motordrehzahl pro Minute (RPM), die Tastenpositionen und/oder andere Fahrzeugstatusanzeigen 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. Beispielsweise können zusätzlich oder alternativ zum CAN-Bus auch FlexRay und/oder Ethernet verwendet werden. Auch wenn der Bus 802 durch eine einzige Leitung dargestellt wird, ist dies nicht als Einschränkung zu verstehen. So kann es beispielsweise eine beliebige Anzahl von Bussen 802 geben, die einen oder mehrere CAN-Busse, einen oder mehrere FlexRay-Busse, einen oder mehrere Ethernet-Busse und/oder einen oder mehrere andere Arten von Bussen mit einem anderen Protokoll umfassen können. In einigen Beispielen können zwei oder mehr Busse 802 verwendet werden, um unterschiedliche Funktionen auszuführen, und/oder sie können zur Redundanz verwendet werden. So kann beispielsweise ein erster Bus 802 für die Kollisionsvermeidungsfunktionalität und ein zweiter Bus 802 für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 802 mit einer beliebigen Komponente des Fahrzeugs 800 kommunizieren, und zwei oder mehr Busse 802 können mit denselben Komponenten kommunizieren. In einigen Beispielen kann jeder SoC 804, jedes Controller 836 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf dieselben Eingangsdaten haben (z. B. Eingaben von Sensoren des Fahrzeugs 800) und mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
Das Fahrzeug 800 kann einen oder mehrere Controller 836 enthalten, wie sie hier in Bezug auf 8A beschrieben sind. Die Controller 836 können für eine Vielzahl von Funktionen verwendet werden. Die Controller 836 können mit verschiedenen anderen Komponenten und Systemen des Fahrzeugs 800 gekoppelt werden und können für die Steuerung des Fahrzeugs 800, die künstliche Intelligenz des Fahrzeugs 800, das Infotainment des Fahrzeugs 800 und/oder Ähnliches verwendet werden.
Das Fahrzeug 800 kann ein oder mehrere System on a Chip (SoC) 804 enthalten. Der 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 Merkmale umfassen. Die SoC 804 können zur Steuerung des Fahrzeugs 800 in einer Vielzahl von Plattformen und Systemen verwendet werden. Beispielsweise können die SoCs 804 in einem System (z. B. dem System des Fahrzeugs 800) mit einer HD-Karte 822 kombiniert werden, die Kartenauffrischungen und/oder Aktualisierungen über eine Netzwerkschnittstelle 824 von einem oder mehreren Servern (z. B. dem/den Server(n) 878 der 8D) erhalten kann.
Die CPU(s) 806 können einen CPU-Cluster oder CPU-Komplex (hier auch als „CCPLEX“ bezeichnet) umfassen. Die CPU(s) 806 können mehrere Kerne und/oder L2-Caches enthalten. In einigen Ausführungsformen können die CPUs 806 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In einigen Ausführungsformen können die CPUs 806 vier Dual-Core-Cluster umfassen, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z. B. einen 2 MB L2-Cache). Die CPU(s) 806 (z. B. der CCPLEX) kann so konfiguriert sein, dass sie den gleichzeitigen Clusterbetrieb unterstützt, so dass jede Kombination der Cluster der CPU(s) 806 zu jedem Zeitpunkt aktiv sein kann.
Die CPUs 806 können Energiemanagementfunktionen implementieren, die eines oder mehrere der folgenden Merkmale umfassen: einzelne Hardwareblöcke können im Leerlauf automatisch taktgesteuert werden, um dynamisch Energie zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI/WFE-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig stromgesteuert werden; jeder Kerncluster kann unabhängig taktgesteuert werden, wenn alle Kerne taktgesteuert oder stromgesteuert sind; und/oder jeder Kerncluster kann unabhängig stromgesteuert werden, wenn alle Kerne stromgesteuert sind. Die CPU(s) 806 können darüber hinaus einen erweiterten Algorithmus zum Management von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufwachzeiten festgelegt werden und die Hardware/der Mikrocode den besten Energiezustand für den Kern, den Cluster und CCPLEX bestimmt. Die Prozessorkerne können vereinfachte Sequenzen für den Einfahrt in den Energiezustand in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
Die GPUs 808 können eine integrierte GPU (hier auch als „iGPU“ bezeichnet) umfassen. Die GPUs 808 können programmierbar und für parallele Arbeitslasten effizient sein. Die GPUs 808 können in einigen Beispielen einen erweiterten Tensor-Befehlssatz verwenden. Die GPU(s) 808 können einen oder mehrere Streaming-Mikroprozessoren enthalten, wobei jeder Streaming-Mikroprozessor einen L1-Cache (z. B. einen L1-Cache mit mindestens 96 KB Speicherkapazität) enthalten kann und zwei oder mehr der Streaming-Mikroprozessoren einen L2-Cache (z. B. einen L2-Cache mit 512 KB Speicherkapazität) gemeinsam nutzen können. In einigen Ausführungsformen können die GPUs 808 mindestens acht Streaming-Mikroprozessoren umfassen. Die GPUs 808 können Anwendungsprogrammierschnittstellen (API(s)) für Berechnungen verwenden. Darüber hinaus können die GPUs 808 eine oder mehrere parallele Rechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.
Die GPUs 808 können für die beste Leistung in Automobil- und eingebetteten Anwendungsfällen optimiert werden. Die GPU(s) 808 können beispielsweise auf einem Fin-Feldeffekttransistor (FinFET) hergestellt werden. 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 umfassen, die in mehrere Blöcke unterteilt sind. So können beispielsweise 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke unterteilt werden, ohne darauf beschränkt zu sein. In einem solchen Beispiel können jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA-Tensor-Kerne mit gemischter Präzision für Deep-Leaming-Matrixarithmetik, ein L0-Befehlscache, ein Warp-Scheduler, eine Dispatch-Einheit und/oder eine 64-KB-Registerdatei zugewiesen werden. Darüber hinaus können die Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkomma-Datenwege enthalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnungen und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfähigkeit enthalten, um eine feinere Synchronisierung und Zusammenarbeit zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können einen kombinierten L1-Datencache und eine gemeinsame Speichereinheit enthalten, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
Die GPUs 808 können einen High Bandwidth Memory (HBM) und/oder ein 16-GB-HBM2-Speicher-Subsystem umfassen, um in einigen Beispielen eine Spitzen-Speicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zum HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (SGRAM) verwendet werden, beispielsweise ein synchroner Grafik-Doppeldatenraten-Direktzugriffsspeicher vom Typ 5 (GDDR5).
Die GPU(s) 808 können eine einheitliche Speichertechnologie mit Zugriffszählern enthalten, um eine genauere Migration von Speicherseiten zu dem Prozessor zu ermöglichen, der am häufigsten auf sie zugreift, wodurch die Effizienz von Speicherbereichen verbessert wird, die von den Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, damit die GPU(s) 808 direkt auf die Seitentabellen der CPU(s) 806 zugreifen können. In solchen Beispielen kann, wenn die Speichermanagementeinheit (MMU) der GPU(s) 808 einen Fehlschlag erfährt, eine Adressübersetzungsanforderung an die CPU(s) 806 übertragen werden. Als Reaktion darauf kann die CPU(s) 806 in ihren Seitentabellen nach der Virtuell-auf-Physikalisch-Zuordnung für die Adresse suchen und die Übersetzung an die GPU(s) 808 zurückübertragen. So kann die einheitliche Speichertechnologie einen einzigen, einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 806 als auch der GPU(s) 808 ermöglichen und dadurch die Programmierung der GPU(s) 808 und die Portierung von Anwendungen auf die GPU(s) 808 vereinfachen.
Darüber hinaus kann die GPU(s) 808 einen Zugriffszähler enthalten, der die Häufigkeit des Zugriffs der GPU(s) 808 auf den Speicher anderer Prozessoren verfolgt. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physikalischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.
Der/die SoC(s) 804 können eine beliebige Anzahl von Cache(s) 812 enthalten, einschließlich der hier beschriebenen. Der/die Cache(s) 812 können beispielsweise einen L3-Cache umfassen, 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 Write-Back-Cache enthalten, der die Zustände von Zeilen verfolgen kann, z. B. durch Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann je nach Ausführungsform 4 MB oder mehr umfassen, obwohl auch kleinere Cache-Größen verwendet werden können.
Der/die SoC(s) 804 können eine arithmetische Logikeinheit(en) (ALU(s)) enthalten, die bei der Durchführung von Verarbeitungen in Bezug auf eine der verschiedenen Aufgaben oder Operationen des Fahrzeugs 800 - wie z. B. die Verarbeitung von DNNs - genutzt werden kann. Darüber hinaus können der/die SoC(s) 804 eine Gleitkommaeinheit(en) (FPU(s)) - oder andere mathematische Coprozessoren oder numerische Coprozessor-Typen - zur Durchführung mathematischer Operationen innerhalb des Systems enthalten. Beispielsweise können die SoC(s) 104 eine oder mehrere FPUs enthalten, die als Ausführungseinheiten in eine CPU(s) 806 und/oder GPU(s) 808 integriert sind.
Der/die SoC(s) 804 können einen oder mehrere Beschleuniger 814 enthalten (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Beispielsweise können die SoC(s) 804 einen Hardware-Beschleunigungscluster enthalten, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher umfassen kann. Der große On-Chip-Speicher (z. B. 4 MB SRAM) kann den Hardware-Beschleunigungscluster in die Lage versetzen, neuronale Netzwerke und andere Berechnungen zu beschleunigen. Der Hardware-Beschleunigungscluster kann zur Ergänzung der GPU(s) 808 und zur Entlastung einiger Aufgaben der GPU(s) 808 verwendet werden (z. B. um mehr Zyklen der GPU(s) 808 für die Durchführung anderer Aufgaben freizugeben). Der/die Beschleuniger 814 können beispielsweise für gezielte Arbeitslasten verwendet werden (z. B. Wahrnehmung, Faltungsneuronale Netze (CNNs) usw.), die stabil genug sind, um beschleunigt werden zu können. Der hier verwendete Begriff „CNN“ kann alle Arten von CNNs umfassen, einschließlich regionsbasierter oder regionaler neuronaler Faltungsnetze (RCNNs) und schneller RCNNs (z. B. für die Objekterkennung).
Der/die Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) können einen Deep-Learning-Beschleuniger (DLA) enthalten. Der/die DLA(s) können eine oder mehrere Tensor-Verarbeitungseinheiten (TPUs) umfassen, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Leaming-Anwendungen und Inferenz bereitstellen. Bei den TPUs kann es sich um Beschleuniger handeln, die für die Ausführung von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Die DLA(s) können darüber hinaus für einen bestimmten Satz neuronaler Netzwerktypen und Gleitkommaoperationen sowie für die Inferenz optimiert sein. Das Design der DLA(s) kann mehr Leistung pro Millimeter bieten als eine Allzweck-GPU und übertrifft die Leistung einer CPU bei weitem. Die TPU(s) können mehrere Funktionen ausführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datentypen sowohl für Merkmale als auch für Gewichte sowie Postprozessorfunktionen unterstützt.
Die DLA(s) können schnell und effizient neuronale Netze, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, darunter beispielsweise 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 von Einsatzfahrzeugen und die Erkennung unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und die Identifizierung des Fahrzeughalters unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsbezogene Ereignisse.
Die DLA(s) können jede Funktion der GPU(s) 808 ausführen, und durch die Verwendung eines Inferenzbeschleunigers kann ein Entwickler beispielsweise entweder die DLA(s) oder die GPU(s) 808 für eine beliebige Funktion einsetzen. Zum Beispiel kann der Entwickler die Verarbeitung von CNNs und Gleitkommaoperationen auf die DLA(s) konzentrieren und andere Funktionen der GPU(s) 808 und/oder anderen Beschleunigern 814 überlassen.
Der/die Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) können einen programmierbaren Bildverarbeitungsbeschleuniger (PVA) umfassen, der hier alternativ auch als Computervision-Beschleuniger bezeichnet werden kann. Der/die PVA(s) können zur Beschleunigung von Computervision-Algorithmen für fortschrittliche Fahrerassistenzsysteme (ADAS), autonomes Fahren und/oder erweiterte Realität- (AR) und/oder virtuelle Realität - (VR) Anwendungen entwickelt und konfiguriert werden. Die PVA(s) können ein Gleichgewicht zwischen Leistung und Flexibilität bieten. So kann jede PVA zum Beispiel und ohne Einschränkung eine beliebige Anzahl von RISC-Kernen (Computer mit reduziertem Befehlssatz), direkten Speicherzugriff (DMA) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
Die RISC-Kerne können mit Bildsensoren (z. B. den Bildsensoren einer der hier beschriebenen Kameras), Bildsignalprozessoren und/oder dergleichen zusammenwirken. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher enthalten. Die RISC-Kerne können je nach Ausführungsform eine beliebige Anzahl von Protokollen verwenden. In einigen Beispielen können die RISC-Kerne ein Echtzeitbetriebssystem (RTOS) ausführen. Die RISC-Kerne können mit einem oder mehreren integrierten Schaltkreisen, anwendungsspezifischen integrierten Schaltkreisen (ASICs) und/oder Speicherbausteinen implementiert werden. Die RISC-Kerne können beispielsweise einen Befehls-Cache und/oder ein eng gekoppeltes RAM enthalten.
Der DMA kann es Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 806 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Funktionen unterstützen, die zur Optimierung der PVA verwendet werden, einschließlich, aber nicht beschränkt auf die Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. In einigen Beispielen 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 umfassen können.
Bei den Vektorprozessoren kann es sich um programmierbare Prozessoren handeln, die so konzipiert sein können, dass sie die Programmierung von Computervision-Algorithmen effizient und flexibel ausführen und Signalverarbeitungsfunktionen bereitstellen. In einigen Beispielen kann die PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen umfassen. Der PVA-Kern kann ein Prozessor-Subsystem, DMA-Engine(s) (z. B. zwei DMA-Engines) und/oder andere Peripheriegeräte umfassen. Das Vektorverarbeitungs-Subsystem kann als primäre Verarbeitungseinheit der PVA fungieren und eine Vektorverarbeitungseinheit (VPU), einen Befehlscache und/oder einen Vektorspeicher (z. B. VMEM) umfassen. Ein VPU-Kern kann einen digitalen Signalprozessor enthalten, wie z. B. einen digitalen Signalprozessor mit einem einzigen Befehl und mehreren Daten (SIMD) und sehr langen Befehlsworten (VLIW). Die Kombination von SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.
Jeder der Vektorprozessoren kann einen Befehls-Cache enthalten und mit einem dedizierten Speicher verbunden sein. Daher kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von den anderen Vektorprozessoren arbeitet. In anderen Beispielen können die Vektorprozessoren, die in einer bestimmten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität verwenden. In einigen Ausführungsformen kann beispielsweise die Mehrzahl der in einer einzigen PVA enthaltenen Vektorprozessoren denselben Computervision-Algorithmus ausführen, jedoch für unterschiedliche Bereiche eines Bildes. In anderen Beispielen können die in einer bestimmten PVA enthaltenen Vektorprozessoren gleichzeitig verschiedene Computervision-Algorithmen für dasselbe Bild oder sogar verschiedene Algorithmen für aufeinander folgende Bilder oder Teile eines Bildes ausführen. Unter anderem kann eine beliebige Anzahl von PVAs im Hardware-Beschleunigungscluster enthalten sein und eine beliebige Anzahl von Vektorprozessoren in jeder der PVAs. Darüber hinaus können die PVA(s) einen zusätzlichen Fehlerkorrekturcode (ECC) Speicher enthalten, um die Sicherheit des Systems insgesamt zu erhöhen.
Der (die) Beschleuniger 814 (z. B. der Hardware-Beschleunigungscluster) kann (können) ein Computervision-Netzwerk auf dem Chip und SRAM enthalten, um ein SRAM mit hoher Bandbreite und niedriger Latenz für den (die) Beschleuniger 814 bereitzustellen. In einigen Beispielen kann der On-Chip-Speicher mindestens 4 MB SRAM umfassen, der beispielsweise und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl die PVA als auch die DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine Advanced Peripheral Bus (APB) Schnittstelle, Konfigurationsschaltungen, einen Controller und einen Multiplexer umfassen. Es kann jeder beliebige Speichertyp verwendet werden. Die PVA und die DLA können auf den Speicher über einen Backbone zugreifen, der der PVA und der DLA einen Hochgeschwindigkeitszugriff auf den Speicher ermöglicht. Der Backbone kann ein chipinternes Computervision-Netzwerk umfassen, das die PVA und die DLA mit dem Speicher verbindet (z. B. unter Verwendung des APB).
Das chip interne Computervision-Netz kann eine Schnittstelle enthalten, die vor der Übertragung von Steuersignalen/Adressen/Daten feststellt, dass sowohl die PVA als auch die DLA einsatzbereite und gültige Signale liefern. Eine solche Schnittstelle kann getrennte Phasen und getrennte Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-Kommunikation für die kontinuierliche Datenübertragung vorsehen. 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-Hardwarebeschleuniger enthalten, wie er in der US-Patentanmeldung Nr. 16/101,232 beschrieben ist, die am 10. August 2018 eingereicht wurde. Der Echtzeit-Raytracing-Hardwarebeschleuniger kann verwendet werden, um schnell und effizient die Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeit-Visualisierungssimulationen 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 Zweck der Lokalisierung und/oder für andere Funktionen und/oder für andere Zwecke. In einigen Ausführungsformen können eine oder mehrere Baumtraversierungseinheiten (TTUs) zum Ausführen von einer oder mehreren Raytracing-bezogenen Operationen verwendet werden.
Der/die Beschleuniger 814 (z. B. der Hardware-Beschleuniger-Cluster) können für das autonome Fahren auf vielfältige Weise eingesetzt werden. Der PVA kann ein programmierbarer Bildverarbeitungsbeschleuniger sein, der für wichtige Verarbeitungsschritte in ADAS und autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten der PVA eignen sich gut für algorithmische Bereiche, die eine vorhersehbare Verarbeitung bei geringem Stromverbrauch und geringer Latenzzeit erfordern. Mit anderen Worten: Die PVA eignet sich gut für halbdichte oder dichte reguläre Berechnungen, selbst bei kleinen Datensätzen, die vorhersehbare Laufzeiten mit geringer Latenz und geringem Stromverbrauch erfordern. Im Zusammenhang mit Plattformen für autonome Fahrzeuge sind die PVAs daher für die Ausführung klassischer Computervision-Algorithmen konzipiert, da sie bei der Objekterkennung und der Verarbeitung ganzzahliger mathematischer Daten effizient sind.
Bei einer Ausführungsform der Technologie wird die PVA beispielsweise für die Durchführung von Computer-Stereosehen verwendet. In einigen Beispielen kann ein auf semiglobaler Anpassung basierender Algorithmus verwendet werden, obwohl dies nicht als Einschränkung gedacht ist. Viele Anwendungen für das autonome Fahren der Stufen 3 bis 5 erfordern eine Bewegungsabschätzung/Stereoabgleich während der Fahrt (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Die PVA kann eine Computer-Stereosichtfunktion mit Eingaben von zwei monokularen Kameras durchführen.
In einigen Beispielen kann die PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Entsprechend der Verarbeitung von RADAR-Rohdaten (z. B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um verarbeitete RADAR-Daten zu erhalten. In anderen Beispielen wird die PVA für die Verarbeitung von Flugzeittiefendaten verwendet, z. B. durch Verarbeitung von Flugzeit-Rohdaten, um verarbeitete Flugzeitdaten zu erhalten.
Mit dem DLA kann jede Art von Netzwerk betrieben werden, um die Kontrolle und die Fahrsicherheit zu verbessern, z. B. ein neuronales Netzwerk, das für jede Objekterkennung einen Vertrauenswert ausgibt. Ein solcher Konfidenzwert kann als Wahrscheinlichkeit oder als relative „Gewichtung“ der einzelnen Erkennungen im Vergleich zu anderen Erkennungen interpretiert werden. Dieser Konfidenzwert ermöglicht es dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als echte positive Erkennungen und welche als falschpositive Erkennungen betrachtet werden sollten. So kann das System beispielsweise einen Schwellenwert für die Konfidenz festlegen und nur die Erkennungen, die diesen Schwellenwert überschreiten, als echte positive Erkennungen betrachten. In einem automatischen Notbremssystem (AEB) 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 Erkennungen als Auslöser für AEB in Betracht gezogen werden. Die DLA kann ein neuronales Netz zur Regression des Vertrauenswertes einsetzen. Das neuronale Netz kann als Eingabe mindestens eine Teilmenge von Parametern verwenden, wie z. B. die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Subsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des IMU-Sensors 866, die mit der Ausrichtung des Fahrzeugs 800 korreliert, die Entfernung, die Schätzungen der 3D-Position des Objekts, die vom neuronalen Netz und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 864 oder RADAR-Sensor(en) 860) erhalten werden, und andere.
Der/die SoC(s) 804 können einen oder mehrere Datenspeicher 816 (z. B. einen Speicher) enthalten. Bei dem/den Datenspeicher(n) 816 kann es sich um einen On-Chip-Speicher des/der SoC(s) 804 handeln, der neuronale Netze speichern kann, die auf der GPU und/oder der DLA ausgeführt werden sollen. In einigen Beispielen kann der/die Datenspeicher 816 groß genug sein, um mehrere Instanzen neuronaler Netze 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 mit der PVA, DLA und/oder anderen Beschleunigern 814 verbunden ist, wie hierin beschrieben.
Die SoC(s) 804 können einen oder mehrere Prozessor(en) 810 (z. B. eingebettete Prozessoren) enthalten. Der/die Prozessor(en) 810 können einen Boot- und Energiemanagementprozessor enthalten, der ein dedizierter Prozessor und ein Subsystem sein kann, um Boot-Energie- und Managementfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Boot- und Energiemanagementprozessor kann Teil der Bootsequenz des/der SoC(s) 804 sein und kann Laufzeit-Energiemanagementdienste bereitstellen. Der Boot-Energieversorgungs- und -Managementprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Übergängen in einen Zustand mit geringem Energieverbrauch, Management von SoC(s) 804-Temperaturen und Temperatursensoren und/oder Management der SoC(s) 804-Energieversorgungszustände bieten. Jeder Temperatursensor kann als Ringoszillator implementiert werden, dessen Ausgangsfrequenz proportional zur Temperatur ist, und der/die SoC(s) 804 können die Ringoszillatoren verwenden, um die Temperaturen der CPU(s) 806, GPU(s) 808 und/oder des/der Beschleuniger(s) 814 zu erfassen. Wenn festgestellt wird, dass die Temperaturen einen Schwellenwert überschreiten, kann der Boot- und Energiemanagementprozessor in eine Temperaturfehlerroutine eintreten und den/die SoC(s) 804 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 800 in einen Modus des Fahrens zu einem sicheren Halt versetzen (z. B. das Fahrzeug 800 zu einem sicheren Halt bringen).
Die Prozessoren 810 können außerdem eine Reihe eingebetteter Prozessoren enthalten, die als Audioverarbeitungs-Engine dienen können. Bei der Audioverarbeitungs-Engine kann es sich um ein Audio-Subsystem handeln, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen sowie eine breiten und flexiblen Bereich von Audio-I/O-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
Die Prozessoren 810 können außerdem eine ständig eingeschaltete Prozessor-Engine enthalten, die die erforderlichen Hardware-Funktionen zur Unterstützung der Sensormanagement mit geringem Stromverbrauch und des Aufwachens von Anwendungsfällen bereitstellen kann. Die ständig eingeschaltete Prozessor-Engine kann einen Prozessorkern, einen eng gekoppelten Arbeitsspeicher, unterstützende Peripheriegeräte (z. B. Zeitgeber und Interrupt-Controller), verschiedene I/O-Controller-Peripheriegeräte und Routing-Logik umfassen.
Die Prozessoren 810 können außerdem eine Sicherheitscluster-Engine enthalten, die ein spezielles Prozessor-Subsystem für das Sicherheitsmanagement von Automobilanwendungen umfasst. Die Sicherheitscluster-Engine kann zwei oder mehr Prozessorkeme, einen eng gekoppelten Arbeitsspeicher, unterstützende Peripheriegeräte (z. B. Zeitgeber, einen Interrupt-Controller usw.) und/oder Routing-Logik umfassen. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Gleichschrittmodus arbeiten und als ein einziger Kern mit einer Vergleichslogik zur Erkennung von Unterschieden zwischen ihren Operationen fungieren.
Die Prozessoren 810 können außerdem eine Echtzeit-Kamera-Engine enthalten, die ein dediziertes Prozessor-Subsystem für das Echtzeit-Kameramanagement umfassen kann.
Die Prozessoren 810 können außerdem einen Signalprozessor mit hohem Dynamikbereich enthalten, der einen Bildsignalprozessor umfassen kann, der eine Hardware-Engine ist, die Teil der Kameraverarbeitungspipeline ist.
Die Prozessoren 810 können einen Videobild-Compositor enthalten, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachbearbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Player-Fenster zu erzeugen. Der Videobild-Compositor kann eine Linsenverzerrungskorrektur an der (den) Weitwinkelkamera(s) 870, an der (den) Surround-Kamera(s) 874 und/oder an den Sensoren der kabineninternen Überwachungskamera vornehmen. Der kabineninterne Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netz ü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 System in der Kabine kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, das Fahrtziel zu ändern, das Infotainmentsystem und die Einstellungen des Fahrzeugs zu aktivieren oder zu ändern oder sprachgesteuertes Surfen im Internet zu ermöglichen. Bestimmte Funktionen stehen dem Fahrer nur zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
Der Videobild-Compositor kann eine verbesserte zeitliche Rauschunterdrückung sowohl zur räumlichen als auch zur zeitlichen Rauschunterdrückung enthalten. Tritt beispielsweise Bewegung in einem Video auf, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend und verringert das Gewicht der Informationen, die von benachbarten Bildern stammen. Wenn ein Bild oder ein Teil eines Bildes keine Bewegung enthält, kann die vom Video-Compositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
Der Videobild-Compositor kann auch konfiguriert sein, eine Stereoentzerrung der eingegebenen Stereoobjektivbilder durchzuführen. Der Videobild-Compositor kann außerdem für die Gestaltung der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 808 nicht ständig neue Oberflächen rendem muss. Selbst wenn die GPUs 808 eingeschaltet ist/sind und aktiv 3D-Rendering betreibt/betreiben, kann der Videobild-Compositor verwendet werden, um den/die Grafikprozessor(en) 808 zu entlasten und so die Leistung und Reaktionsfähigkeit zu verbessern.
Der/die SoC(s) 804 können außerdem eine serielle MIPI-Kameraschnittstelle zum Empfang von Video und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock enthalten, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. Der/die SoC(s) 804 können außerdem einen Eingangs-/Ausgangs-Controller enthalten, der durch Software gesteuert werden kann und für den Empfang von I/O-Signalen verwendet werden kann, die keiner bestimmten Funktion zugewiesen sind.
Der/die SoC(s) 804 können außerdem eine breite Palette von Peripherieschnittstellen enthalten, um die Kommunikation mit Peripheriegeräten, Audiocodecs, Energiemanagement und/oder anderen Geräten zu ermöglichen. Der/die SoC(s) 804 können zur Verarbeitung von Daten von Kameras (z. B. über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LIDAR-Sensor(en) 864, RADAR-Sensor(en) 860 usw., die über Ethernet angeschlossen werden können), Daten vom Bus 802 (z. B. Geschwindigkeit des Fahrzeugs 800, Lenkradposition usw.), Daten von GNSS-Sensor(en) 858 (z. B. über Ethernet oder CAN-Bus angeschlossen) verwendet werden. Der/die SoC(s) 804 können darüber hinaus dedizierte Hochleistungs-Massenspeicher-Controller enthalten, die ihre eigenen DMA-Engines enthalten können und die dazu verwendet werden können, die CPU(s) 806 von routinemäßigen Datenmanagementaufgaben zu entlasten.
Der/die SoC(s) 804 können eine End-to-End-Plattform mit einer flexiblen Architektur sein, die die Automatisierungsstufen 3 bis 5 abdeckt und dadurch eine umfassende funktionale Sicherheitsarchitektur bietet, die Computervision- und ADAS-Techniken für Diversität und Redundanz nutzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftware-Stack zusammen mit Deep-Learning-Tools bereitstellt. Die SoC(s) 804 können schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Zum Beispiel kann der/die Beschleuniger 814 in Kombination mit der/den CPU(s) 806, der/den GPU(s) 808 und dem/den Datenspeicher(n) 816 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Stufe 3-5 bilden.
Die Technologie bietet somit Fähigkeiten und Funktionen, die mit herkömmlichen Systemen nicht erreicht werden können. Beispielsweise können Computervision-Algorithmen auf CPUs ausgeführt werden, die mit Hilfe von Hochsprachen wie der Programmiersprache C so konfiguriert werden können, dass sie eine Vielzahl von Verarbeitungsalgorithmen für eine Vielzahl von Bilddaten ausführen können. Allerdings sind CPUs oft nicht in der Lage, die Leistungsanforderungen vieler Computervision-Anwendungen zu erfüllen, z. B. in Bezug auf die Ausführungszeit und den Stromverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, was eine Voraussetzung für fahrzeuginterne ADAS-Anwendungen und eine Voraussetzung für praktische autonome Fahrzeuge der Stufe 3-5 ist.
Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungs-Clusters, dass mehrere neuronale Netze gleichzeitig und/oder nacheinander ausgeführt und die Ergebnisse miteinander kombiniert werden können, um autonome Fahrfunktionen der Stufe 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf der DLA oder dGPU (z. B. die GPU(s) 820) ausgeführt wird, eine Text- und Worterkennung beinhalten, die es dem Supercomputer ermöglicht, Verkehrszeichen zu lesen und zu verstehen, einschließlich Zeichen, für die das neuronale Netz nicht speziell trainiert wurde. Die DLA kann ferner ein neuronales Netz enthalten, das in der Lage ist, das Zeichen zu identifizieren, zu interpretieren und semantisch zu verstehen und dieses semantische Verständnis an die auf dem CPU-Komplex laufenden Wegplanungsmodule weiterzugeben.
Ein weiteres Beispiel ist, dass mehrere neuronale Netze gleichzeitig betrieben werden können, wie es für das Fahren der Stufen 3, 4 oder 5 erforderlich ist. So kann beispielsweise ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Glatteis hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzen unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netz (z. B. einem trainierten neuronalen Netz) als Verkehrsschild identifiziert werden, der Text „Blinkende Lichter deuten auf Glatteis hin“ kann von einem zweiten eingesetzten neuronalen Netz interpretiert werden, das die Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass beim Erkennen blinkender Lichter Glatteis vorliegt. Das Blinklicht kann durch den Betrieb eines dritten neuronalen Netzes über mehrere Frames hinweg identifiziert werden, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. Alle drei neuronalen Netze können gleichzeitig laufen, z. B. innerhalb der DLA und/oder auf der/den GPU(s) 808.
In einigen Beispielen kann ein CNN zur Gesichtserkennung und Identifizierung des Fahrzeugbesitzers Daten von Kamerasensoren verwenden, um die Anwesenheit eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 800 zu erkennen. Die „always on“-Sensorverarbeitungs-Engine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn der Besitzer sich der Fahrertür nähert und die Lichter einschaltet, und um im Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise sorgen die SoC(s) 804 für Sicherheit gegen Diebstahl und/oder Carjacking.
In einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Einsatzfahrzeugen Daten von Mikrofonen 896 verwenden, um Sirenen von Einsatzfahrzeugen zu erkennen 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 visueller Daten. In einer bevorzugten Ausführungsform wird der CNN, der auf dem DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu erkennen (z. B. durch Verwendung des Dopplereffekts). Das CNN kann auch so trainiert werden, dass es Einsatzfahrzeuge erkennt, die spezifisch für den lokalen Bereich sind, in dem das Fahrzeug operiert, wie von GNSS-Sensor(en) 858 ermittelt. So wird das CNN beispielsweise versuchen, europäische Sirenen zu erkennen, wenn es in Europa eingesetzt wird, und nur nordamerikanische Sirenen, wenn es in den Vereinigten Staaten eingesetzt wird. Sobald ein Einsatzfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Einsatzfahrzeuge auszuführen, das Fahrzeug zu verlangsamen, an den Straßenrand zu fahren, das Fahrzeug zu parken und/oder das Fahrzeug im Leerlauf laufen zu lassen, mit Hilfe der Ultraschallsensoren 862, bis das/die Einsatzfahrzeug(e) vorbeifahren.
Das Fahrzeug kann eine oder mehrere CPU(s) 818 (z. B. diskrete CPU(s) oder dCPU(s)) enthalten, die über eine Hochgeschwindigkeitsverbindung (z. B. PCIe) mit dem/den SoC(s) 804 verbunden sein können. Die CPU(s) 818 können zum Beispiel einen X86-Prozessor enthalten. Die CPU(s) 818 können verwendet werden, um eine Vielzahl von Funktionen auszuführen, einschließlich der Schlichtung potentiell widersprüchlicher Ergebnisse zwischen ADAS-Sensoren und dem/den SoC(s) 804 und/oder der Überwachung des Status und des Zustands des/der Controller(s) 836 und/oder des Infotainment-SoC 830, zum Beispiel.
Das Fahrzeug 800 kann eine oder mehrere GPU(s) 820 (z. B. diskrete GPU(s) oder dGPU(s)) enthalten, die über eine Hochgeschwindigkeitsverbindung (z. B. NVIDIAs NVLINK) mit dem/den SoC(s) 804 gekoppelt sein können. Die GPU(s) 820 können zusätzliche Funktionen der künstlichen Intelligenz bereitstellen, z. B. durch die Ausführung redundanter und/oder unterschiedlicher neuronaler Netze, und können zum Trainieren und/oder Aktualisieren neuronaler Netze basierend auf von Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 800 verwendet werden.
Das Fahrzeug 800 kann ferner die Netzwerkschnittstelle 824 enthalten, die eine oder mehrere drahtlose Antennen 826 (z. B. eine oder mehrere drahtlose Antennen für verschiedene Kommunikationsprotokolle, wie eine Mobilfunkantenne, eine Bluetooth-Antenne usw.) enthalten kann. Die Netzwerkschnittstelle 824 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit dem/den Server(n) 878 und/oder anderen Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Datenverarbeitungsgeräten (z. B. Client-Vorrichtungen von Fahrgästen) zu ermöglichen. Zur Kommunikation mit anderen Fahrzeugen kann eine direkte Verbindung zwischen den beiden Fahrzeugen und/oder eine indirekte Verbindung hergestellt werden (z. B. über Netzwerke und das Internet). Direkte Verbindungen können über eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung hergestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 800 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 800 liefern (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 800). Diese Funktion kann Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 800 sein.
Die Netzwerkschnittstelle 824 kann einen SoC enthalten, der Modulations- und Demodulationsfunktionen bereitstellt und es dem/den Controller(n) 836 ermöglicht, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 824 kann ein Hochfrequenz-Frontend für die Abwärtswandlung vom Basisband auf Hochfrequenz und die Abwärtswandlung von Hochfrequenz auf Basisband enthalten. Die Frequenzumwandlungen können mit bekannten Verfahren und/oder mit Superheterodyn-Verfahren durchgeführt werden. In einigen Beispielen kann die Hochfrequenz-Frontend-Funktionalität durch einen separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann drahtlose Funktionen für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle enthalten.
Das Fahrzeug 800 kann ferner einen oder mehrere Datenspeicher 828 umfassen, die einen chipextemen (z. B. außerhalb der SoC(s) 804) Speicher umfassen können. Der/die Datenspeicher 828 können ein oder mehrere Speicherelemente wie RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Geräte umfassen, die mindestens ein Datenbit speichern können.
Das Fahrzeug 800 kann außerdem GNSS-Sensor(en) 858 enthalten. Der/die GNSS-Sensor(en) 858 (z. B. GPS, unterstützte GPS-Sensoren, Differential-GPS-Sensoren (DGPS) usw.) unterstützt/unterstützen die Kartierung, die Wahrnehmung, die Erstellung von Belegungsrastern und/oder die Wegplanungsfunktionen. Es kann eine beliebige Anzahl von GNSS-Sensoren 858 verwendet werden, z. B. und ohne Einschränkung ein GPS, das einen USB-Anschluss mit einer Ethernet-zu-Seriell (RS-232)-Brücke verwendet.
Das Fahrzeug 800 kann außerdem RADAR-Sensor(en) 860 enthalten. Der/die RADAR-Sensor(en) 860 können vom Fahrzeug 800 für die Fahrzeugerkennung über große Entfernungen verwendet werden, selbst bei Dunkelheit und/oder schlechten Wetterbedingungen. Der/die RADAR-Sensor(en) 860 können den CAN-Bus und/oder den Bus 802 (z. B. zur Übertragung von Daten, die von dem/den RADAR-Sensor(en) 860 erzeugt wurden) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugriff auf Rohdaten über Ethernet erfolgt. Es kann eine Vielzahl von RADAR-Sensortypen verwendet werden. Zum Beispiel und ohne Einschränkung können der/die RADAR-Sensor(en) 860 für den Einsatz von Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen werden Impuls-Doppler-RADAR-Sensoren verwendet.
Der/die RADAR-Sensor(en) 860 können verschiedene Konfigurationen umfassen, wie z. B. große Reichweite mit engem Sichtfeld, kurze Reichweite mit breitem Sichtfeld, seitliche Abdeckung kurzer Reichweite usw. In einigen Beispielen kann RADAR mit großer Reichweite für die adaptive Geschwindigkeitsregelung verwendet werden. Die RADAR-Systeme mit großer Reichweite können ein breites Sichtfeld bieten, das durch zwei oder mehr unabhängige Abtastungen, z. B. innerhalb einer Reichweite von 250 m, realisiert wird. Der/die RADAR-Sensor(en) 860 können helfen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und können von ADAS-Systemen für Notbremsassistenten und Vorwärtskollisionswarnungen verwendet werden. RADAR-Sensoren mit großer Reichweite können monostatische multimodale RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle umfassen. In einem Beispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu dient, die Umgebung des Fahrzeugs bei höheren Geschwindigkeiten mit minimalen Interferenzen durch den Verkehr auf den angrenzenden Fahrspuren zu erfassen. Die beiden anderen Antennen können das Sichtfeld erweitern, so dass Fahrzeuge, die in die 800 Fahrspur des Fahrzeugs einfahren oder sie verlassen, schnell erfasst werden können.
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) haben. Zu den RADAR-Systemen mit geringer Reichweite können unter anderem RADAR-Sensoren gehören, die an beiden Enden des hinteren Stoßfängers angebracht werden. Wenn ein solches RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers angebracht ist, kann es zwei Strahlen erzeugen, die den toten Winkel hinter und neben dem Fahrzeug ständig überwachen.
RADAR-Systeme mit geringer Reichweite können in einem ADAS-System zur Erkennung des toten Winkels und/oder als Spurwechselassistent eingesetzt werden.
Das Fahrzeug 800 kann außerdem Ultraschallsensor(en) 862 enthalten. Der/die Ultraschallsensor(en) 862, der/die vorne, hinten und/oder an den Seiten des Fahrzeugs 800 angebracht sein können, können zur Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsrasters verwendet werden. Es kann eine Vielzahl von Ultraschallsensoren 862 verwendet werden, und unterschiedliche Ultraschallsensoren 862 können für unterschiedliche Erfassungsbereiche (z. B. 2,5 m, 4 m) eingesetzt werden. Der/die Ultraschallsensor(en) 862 können bei funktionalen Sicherheitsstufen von ASIL B arbeiten.
Das Fahrzeug 800 kann LIDAR-Sensor(en) 864 enthalten. Der/die LIDAR-Sensor(en) 864 können für Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 864 können der funktionalen Sicherheitsstufe ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 800 mehrere LIDAR-Sensoren 864 (z. B. zwei, vier, sechs usw.) enthalten, die Ethernet verwenden können (z. B. zur Bereitstellung von Daten an einen Gigabit-Ethemet-Switch).
In einigen Beispielen kann der/die LIDAR-Sensor(en) 864 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld zu liefern. Im Handel erhältliche LIDAR-Sensoren 864 können eine Reichweite von etwa 800 m haben, mit einer Genauigkeit von 2 cm bis 3 cm und mit Unterstützung für eine Ethernet-Verbindung mit 800 Mbit/s, zum Beispiel. In einigen Beispielen können ein oder mehrere nicht vorstehende LIDAR-Sensoren 864 verwendet werden. In solchen Beispielen können der/die LIDAR-Sensor(en) 864 als kleines Gerät 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 geringem Reflexionsvermögen bieten. Der/die frontmontierte(n) LIDAR-Sensor(en) 864 können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert werden.
In einigen Beispielen können auch LIDAR-Technologien wie 3D-Flash-LIDAR eingesetzt werden. 3D-Flash-LIDAR verwendet einen Laserblitz als Übertragungsquelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von etwa 200 m zu beleuchten. Eine Flash-LIDAR-Einheit umfasst einen Empfänger, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum der Entfernung zwischen dem Fahrzeug und den Objekten entspricht. Mit Flash-LIDAR lassen sich mit jedem Laserblitz hochpräzise und verzerrungsfreie Bilder der Umgebung erzeugen. In einigen Beispielen können vier Flash-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 800. Zu den verfügbaren 3D-Flash-LIDAR-Systemen gehört eine Festkörper-3D-Staring-Array-LIDAR-Kamera, die außer einem Gebläse keine beweglichen Teile aufweist (z. B. ein nicht scannendes LIDAR-Gerät). Das Flash-LIDAR-Gerät kann einen 5-Nanosekunden-Laserimpuls der Klasse I (augensicher) pro Bild verwenden und das reflektierte Laserlicht in Form von 3D-Entfernungspunktwolken und gemeinsam registrierte Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR und weil Flash-LIDAR ein Festkörpergerät ohne bewegliche Teile ist, kann der/die LIDAR-Sensor(en) 864 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße sein.
Das Fahrzeug kann außerdem einen oder mehrere IMU-Sensoren 866 enthalten. Der/die IMU-Sensor(en) 866 können in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 800 angeordnet sein. Der (die) IMU-Sensor(en) 866 kann (können) beispielsweise und ohne Einschränkung einen (mehrere) Beschleunigungsmesser, einen (mehrere) Magnetometer, ein (mehrere) Gyroskop(e), einen (mehrere) Magnetkompass(e) und/oder andere Sensortypen umfassen. In einigen Beispielen, wie z. B. bei sechsachsigen Anwendungen, können der/die IMU-Sensor(en) 866 Beschleunigungsmesser und Gyroskope umfassen, während bei neunachsigen Anwendungen der/die IMU-Sensor(en) 866 Beschleunigungsmesser, Gyroskope und Magnetometer umfassen können.
In einigen Ausführungsformen können der/die IMU-Sensor(en) 866 als ein miniaturisiertes, hochleistungsfähiges GPS-gestütztes Trägheitsnavigationssystem (GPS/INS) implementiert werden, das mikroelektromechanische Trägheitssensoren (MEMS), einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage zu liefern. In einigen Beispielen können die IMU-Sensoren 866 das Fahrzeug 800 in die Lage versetzen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem die Geschwindigkeitsänderungen von GPS direkt beobachtet und mit den IMU-Sensoren 866 korreliert werden. In einigen Beispielen können der/die IMU-Sensor(en) 866 und der/die GNSS-Sensor(en) 858 in einer einzigen integrierten Einheit kombiniert werden.
Das Fahrzeug kann Mikrofon(e) 896 enthalten, die im 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 enthalten, einschließlich Stereokamera(s) 868, Weitwinkelkamera(s) 870, Infrarotkamera(s) 872, Umgebungskamera(s) 874, Fern- und/oder Mittelbereichskamera(s) 898 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten rund um den gesamten Umfang des Fahrzeugs 800 zu erfassen. Die verwendeten Kameratypen hängen von den Ausführungsformen und Anforderungen für das Fahrzeug 800 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 800 herum zu gewährleisten. Darüber hinaus kann sich die Anzahl der Kameras je nach Ausführungsform unterscheiden. Beispielsweise kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras umfassen. 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 hierin in Bezug auf 8A und 8B ausführlicher beschrieben.
Das Fahrzeug 800 kann außerdem einen oder mehrere Schwingungssensoren 842 enthalten. Der/die Schwingungssensor(en) 842 können Schwingungen von Komponenten des Fahrzeugs, wie z. B. der Achse(n), messen. So können beispielsweise Änderungen der Vibrationen auf eine Änderung der Straßenoberfläche hinweisen. In einem anderen Beispiel können bei Verwendung von zwei oder mehr Schwingungssensoren 842 die Unterschiede zwischen den Schwingungen verwendet werden, um die Reibung oder den Schlupf der Straßenoberfläche zu bestimmen (z. B. wenn der Unterschied in der Schwingung zwischen einer angetriebenen Achse und einer frei drehenden Achse besteht).
Das Fahrzeug 800 kann ein ADAS-System 838 enthalten. Das ADAS-System 838 kann in einigen Beispielen einen SoC enthalten. Das ADAS-System 838 kann einen autonomen/adaptiven/automatischen Geschwindigkeitsregler (ACC), einen kooperativen adaptiven Geschwindigkeitsregler (CACC), eine Auffahrwarnung (FCW), eine automatische Notbremsung (AEB), eine Spurverlassenswarnung (LDW), einen Spurhalteassistenten (LKA), einen Toter-Winkel-Warner (BSW), einen Querverkehrswarner (RCTW), ein Kollisionswarnsystem (CWS), eine Spurenzentrierung (LC) und/oder andere Merkmale und Funktionen umfassen.
Die ACC-Systeme können RADAR-Sensor(en) 860, LIDAR-Sensor(en) 864 und/oder eine Kamera(s) verwenden. Die ACC-Systeme können einen ACC in Längsrichtung und/oder einen ACC in Querrichtung umfassen. Der ACC in Längsrichtung überwacht und steuert den Abstand zum unmittelbar vor dem Fahrzeug 800 befindlichen Fahrzeug und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Der Quer-ACC sorgt für die Einhaltung des Abstands und rät dem Fahrzeug 800, bei Bedarf die Spur zu wechseln. Der Quer-ACC steht mit anderen ADAS-Anwendungen wie LCA und CWS in Bezug.
Der CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 824 und/oder die Funkantenne(n) 826 von anderen Fahrzeugen über eine drahtlose Verbindung oder indirekt über eine Netzwerkverbindung (z. B. über das Internet) empfangen werden können. Direkte Verbindungen können durch eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung (V2V) bereitgestellt werden, während indirekte Verbindungen eine Infrastruktur-zu-Fahrzeug-Kommunikationsverbindung (12V) sein können. Im Allgemeinen liefert das V2V-Kommunikationskonzept Informationen über die unmittelbar vorausfahrenden Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem Fahrzeug 800 und auf derselben Fahrspur wie dieses befinden), während das I2 V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr liefert. CACC-Systeme können sowohl I2V- als auch V2V-Informationsquellen enthalten. Angesichts der Informationen über die Fahrzeuge vor dem Fahrzeug 800 kann CACC zuverlässiger sein und hat das Potential, den Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
FCW-Systeme sind so konzipiert, dass sie den Fahrer vor einer Gefahr warnen, so dass er korrigierend eingreifen kann. FCW-Systeme verwenden eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 860, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit der Rückmeldung an den Fahrer verbunden ist, z. B. mit einem Display, einem Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung ausgeben, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
AEB-Systeme erkennen einen drohenden Zusammenstoß mit einem anderen Fahrzeug oder einem anderen Objekt und können automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines bestimmten Zeit- oder Entfernungsparameters korrigierend eingreift. AEB-Systeme können nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 860 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC verbunden sind. Wenn das AEB-System eine Gefahr erkennt, warnt es in der Regel zunächst den Fahrer, damit er korrigierend eingreift, um die Kollision zu vermeiden. Wenn der Fahrer keine korrigierenden Maßnahmen ergreift, kann das AEB-System automatisch die Bremsen betätigen, um die Auswirkungen der vorhergesagten Kollision zu verhindern oder mindestens abzumildern. AEB-Systeme können Techniken wie die dynamische Bremsunterstützung und/oder Bremsen bei einem bevorstehenden Zusammenstoß umfassen.
LDW-Systeme warnen den Fahrer durch optische, akustische und/oder taktile Signale, z. B. durch Vibrationen am Lenkrad oder am Sitz, wenn das Fahrzeug 800 die Fahrbahnmarkierungen überfährt. Ein LDW-System wird nicht aktiviert, wenn der Fahrer durch Betätigen des Blinkers ein absichtliches Verlassen der Fahrspur anzeigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC verbunden sind, der elektrisch mit einer Fahrerrückmeldung gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
LKA-Systeme sind eine Variante von LDW-Systemen. LKA-Systeme sorgen für einen Lenkeingriff oder eine Bremsung, um das Fahrzeug 800 zu korrigieren, wenn das Fahrzeug 800 beginnt, die Fahrspur zu verlassen.
BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen im toten Winkel des Fahrzeugs. BSW-Systeme können ein optisches, akustisches und/oder taktiles Warnsignal ausgeben, um darauf hinzuweisen, dass das Einfädeln in oder Wechseln von 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 speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit einer Fahrerrückmeldung gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
RCTW-Systeme können eine optische, akustische und/oder taktile Benachrichtigung bereitstellen, wenn beim Rückwärtsfahren des Fahrzeugs 800 ein Objekt außerhalb des Bereichs der Heckkamera erkannt wird. Einige RCTW-Systeme umfassen AEB, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensoren 860 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit einer Fahrerrückmeldung gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.
Bei herkömmlichen ADAS-Systemen kann es zu falsch-positiven Ergebnissen kommen, die für den Fahrer ärgerlich und ablenkend sein können, aber in der Regel nicht katastrophal sind, da die ADAS-Systeme den Fahrer warnen und ihm die Möglichkeit geben, zu entscheiden, ob wirklich eine Sicherheitsbedingung vorliegt und entsprechend zu handeln. In einem autonomen Fahrzeug 800 muss das Fahrzeug 800 jedoch im Falle widersprüchlicher Ergebnisse selbst entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. eines ersten Controllers 836 oder eines zweiten Controllers 836) beachtet. In einigen Ausführungsformen kann das ADAS-System 838 beispielsweise ein Reserve- und/oder Sekundärcomputer sein, der Wahrnehmungsinformationen an ein Rationalitätsmodul des Reserve-Computers liefert. Der Rationalitätsmonitor des Reserve-Computers kann eine redundante Software auf Hardwarekomponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahraufgaben zu erkennen. Die Ausgaben des ADAS-Systems 838 können an eine Überwachungs-MCU weitergeleitet werden. Wenn die Ausgaben des Primärrechners und des Sekundärrechners kollidieren, muss die Überwachungs-MCU bestimmen, wie der Konflikt gelöst werden kann, um einen sicheren Betrieb zu gewährleisten.
In einigen Beispielen kann der primäre Computer konfiguriert sein, der Überwachungs-MCU eine Konfidenzbewertung bereitzustellen, der die Konfidenz des primären Computers für das gewählte Ergebnis angibt. Übersteigt die Konfidenzbewertung einen Schwellenwert, kann die Überwachungs-MCU der Anweisung des Primärcomputers folgen, unabhängig davon, ob der Sekundärcomputer ein widersprüchliches oder inkonsistentes Ergebnis liefert. Erreicht die Konfidenzbewertung den Schwellenwert nicht und geben der primäre und der sekundäre Computer unterschiedliche Ergebnisse an (z. B. den Konflikt), kann die übergeordnete MCU zwischen den Computern vermitteln, um das geeignete Ergebnis zu bestimmen.
Die Überwachungs-MCU kann konfiguriert sein, neuronale Netze auszuführen, die trainiert und konfiguriert sind, basierend auf Ausgaben des Primärcomputers und des Sekundärcomputers die Bedingungen zu bestimmen, unter denen der Sekundärcomputer Fehlalarme auslöst. So können die neuronalen Netze in der Überwachungs-MCU lernen, wann der Ausgabe des Sekundärcomputers vertraut werden kann und wann nicht. Handelt es sich bei dem sekundären Computer beispielsweise um ein RADAR-basiertes FCW-System, kann ein neuronales Netz in der Überwachungs-MCU lernen, wann das FCW-System metallische Objekte identifiziert, die in Wirklichkeit keine Gefahr darstellen, wie etwa ein Abflussgitter oder ein Schachtdeckel, der einen Alarm auslöst. Wenn der Sekundärcomputer ein kamerabasiertes LDW-System ist, kann ein neuronales Netz in der Überwachungs-MCU lernen, das LDW zu übergehen, wenn Radfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, die neuronale Netze aufweisen, die auf der Überwachungs-MCU ausgeführt werden, kann die Überwachungs-MCU mindestens eine DLA oder eine GPU, die zum Ausführen der neuronalen Netze geeignet sind, mit einem zugehörigem Speicher enthalten. In bevorzugten Ausführungsformen kann die Überwachungs-MCU eine Komponente der SoC(s) 804 umfassen und/oder darin enthalten sein.
In anderen Beispielen kann das ADAS-System 838 einen sekundären Computer enthalten, der die ADAS-Funktionen unter Verwendung herkömmlicher Regeln der Computervision ausführt. Der sekundäre Computer kann also klassische Regeln der Computervision verwenden (wenn-dann), und das Vorhandensein eines neuronalen Netzes in der Überwachungs-MCU kann die Zuverlässigkeit, Sicherheit und Leistung verbessern. Beispielsweise wird das Gesamtsystem durch die unterschiedliche Implementierung und die absichtliche Nichtidentität fehlertoleranter, insbesondere gegenüber Fehlern, die durch Softwarefunktionen (oder Software-Hardware-Schnittstellen) verursacht werden. Wenn beispielsweise ein Softwarefehler in der auf dem Primärcomputer laufenden Software auftritt und der nicht identische Softwarecode auf dem Sekundärcomputer das gleiche Gesamtergebnis liefert, kann die Überwachungs-MCU mit größerer Sicherheit davon ausgehen, dass das Gesamtergebnis korrekt ist und der Fehler in der Software oder Hardware des Primärcomputers keinen wesentlichen Fehler verursacht.
In einigen Beispielen kann die Ausgabe des ADAS-Systems 838 in den Wahrnehmungsblock des Primärrechners und/oder in den dynamischen Fahraufgabenblock des Primärrechners eingespeist werden. Wenn das ADAS-System 838 beispielsweise eine Warnung vor einem Aufprall aufgrund eines unmittelbar vorausfahrenden Objekts anzeigt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der Sekundärcomputer über ein eigenes neuronales Netz verfügen, das trainiert ist und somit das Risiko von Fehlalarmen reduziert, wie hierin beschrieben.
Das Fahrzeug 800 kann ferner das Infotainment-SoC 830 (z. B. ein fahrzeuginternes Infotainment-System (IVI)) enthalten. Obwohl das Infotainment-System als SoC dargestellt und beschrieben wird, muss es nicht unbedingt ein SoC sein, sondern kann auch zwei oder mehr diskrete Komponenten umfassen. Das Infotainment-SoC 830 kann eine Kombination aus Hardware und Software enthalten, die zur Bereitstellung von Audio (z. B. Musik, einem persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. Fernsehen, Filme, Streaming usw.), Telefon (z. B. Freisprechen), Netzwerkkonnektivität (z. B., LTE, Wi-Fi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Einparkhilfe hinten, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremskraftstoffstand, Ölstand, Tür öffnen/schließen, Luftfilterinformationen usw.) an das Fahrzeug 800. Das Infotainment-SoC 830 kann beispielsweise Radios, Plattenspieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, Wi-Fi, Audiobedienelemente am Lenkrad, Freisprecheinrichtung, ein Heads-up-Display (HUD), ein HMI-Display 834, eine Telematikvorrichtung, ein Bedienfeld (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten enthalten. Das Infotainment-SoC 830 kann ferner verwendet werden, um einem oder mehreren Nutzern des Fahrzeugs Informationen (z. B. visuell und/oder akustisch) bereitzustellen, wie etwa Informationen vom ADAS-System 838, Informationen zum autonomen Fahren wie geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.
Das Infotainment-SoC 830 kann eine GPU-Funktionalität enthalten. Das Infotainment-SoC 830 kann über den Bus 802 (z. B. CAN-Bus, Ethernet usw.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 800 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 830 mit einer Überwachungs-MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primären Controller 836 (z. B. die primären und/oder Backup-Computer des Fahrzeugs 800) ausfallen. In einem solchen Beispiel kann das Infotainment-SoC 830 das Fahrzeug 800, wie hierin beschrieben, in einen Modus des Fahrens zu einem sicheren Halt versetzen.
Das Fahrzeug 800 kann ferner ein Kombiinstrument 832 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) enthalten. Das Kombiinstrument 832 kann ein Controller und/oder einen Supercomputer (z. B. einen diskreten Controller oder einen Supercomputer) enthalten. Das Kombiinstrument 832 kann eine Reihe von Instrumenten enthalten, z. B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltstellungsanzeige, Sicherheitsgurt-Warnleuchte(n), Parkbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Informationen über das Airbag-System (SRS), Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen usw. In einigen Beispielen können die Informationen vom Infotainment-SoC 830 und dem Kombiinstrument 832 angezeigt und/oder gemeinsam genutzt werden. Mit anderen Worten: Das Kombiinstrument 832 kann als Teil des Infotainment-SoC 830 enthalten sein oder umgekehrt.
8D ist ein Systemdiagramm für die Kommunikation zwischen cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug 800 der 8A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das System 876 kann Server 878, Netzwerke 890 und die Fahrzeuge, einschließlich des Fahrzeugs 800, umfassen. Die Server 878 können eine Vielzahl von GPUs 884(A)-884(H) (hier zusammenfassend als GPUs 884 bezeichnet), PCIe-Switches 882(A)-882(H) (hier zusammenfassend als PCIe-Switches 882 bezeichnet) und/oder CPUs 880(A)-880(B) (hier zusammenfassend als CPUs 880 bezeichnet) umfassen. Die GPUs 884, die CPUs 880 und die PCIe-Switches können über Hochgeschwindigkeits-Interconnects miteinander verbunden werden, wie z. B. und ohne Einschränkung über die von NVIDIA entwickelten NVLink-Schnittstellen 888 und/oder PCIe-Verbindungen 886. In einigen Beispielen sind die GPUs 884 über NVLink und/oder NVSwitch SoC und die GPUs 884 und die PCIe-Switches 882 über PCIe-Interconnects verbunden. Obwohl acht GPUs 884, zwei CPUs 880 und zwei PCIe-Switches abgebildet sind, ist dies nicht als Einschränkung zu verstehen. Je nach Ausführungsform kann jeder der Server 878 eine beliebige Anzahl von GPUs 884, CPUs 880 und/oder PCIe-Switches umfassen. Beispielsweise können die Server 878 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 884 enthalten.
Die Server 878 können über die Netzwerke 890 und von den Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenzustände zeigen, z. B. kürzlich begonnene Straßenarbeiten. Die Server 878 können über die Netzwerke 890 und an die Fahrzeuge neuronale Netze 892, aktualisierte neuronale Netze 892 und/oder Karteninformationen 894, einschließlich Informationen über Verkehrs- und Straßenbedingungen, übertragen. Die Aktualisierungen der Karteninformationen 894 können Aktualisierungen für die HD-Karte 822 enthalten, z. B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In einigen Beispielen können die neuronalen Netze 892, die aktualisierten neuronalen Netze 892 und/oder die Karteninformationen 894 aus neuem Training und/oder Erfahrungen resultieren, die in Daten dargestellt sind, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder auf einem Training basieren, das in einem Datenzentrum durchgeführt wurde (z. B. unter Verwendung des/der Server(s) 878 und/oder anderer Server).
Die Server 878 können verwendet werden, um Modelle für maschinelles Lernen (z. B. neuronale Netze) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten können von den Fahrzeugen und/oder in einer Simulation (z. B. mit einer Spiele-Engine) erzeugt werden. In einigen Beispielen werden die Trainingsdaten markiert (z. B. wenn das neuronale Netz von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht markiert und/oder vorverarbeitet werden (z. B. wenn das neuronale Netz 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, selbstlernendes Lernen, Verstärkungs lernen, föderiertes Lernen, Transferlernen, Merkmalslemen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraumlemen, vielfältiges Lernen, Repräsentationslemen (einschließlich Lernen mit Ersatzwörterbüchern), regelbasiertes maschinelles Lernen, Anomalieerkennung und alle Varianten oder Kombinationen davon. Sobald die maschinellen Lernmodelle trainiert sind, können die maschinellen Lernmodelle von den Fahrzeugen verwendet werden (z. B. durch Übertragung an die Fahrzeuge über das/die Netzwerk(e) 890 und/oder die maschinellen Lernmodelle können von dem/den Server(n) 878 zur Fernüberwachung der Fahrzeuge verwendet werden.
In einigen Beispielen können die Server 878 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Netze in Echtzeit für intelligente Schlussfolgerungen in Echtzeit anwenden. Der/die Server 878 können Deep-Learning-Supercomputer und/oder dedizierte KI-Computer umfassen, die von GPUs 884 angetrieben werden, wie z. B. die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen können die Server 878 jedoch auch Deep-Learning-Infrastrukturen enthalten, die nur CPU-betriebene Rechenzentren verwenden.
Die Deep-Learning-Infrastruktur des/der Server(s) 878 kann zur schnellen Inferenz in Echtzeit fähig sein und kann diese Fähigkeit nutzen, um den Zustand der Prozessoren, der Software und/oder der zugehörigen Hardware im Fahrzeug 800 zu bewerten und zu überprüfen. Beispielsweise kann die Deep-Learning-Infrastruktur regelmäßige Aktualisierungen vom Fahrzeug 800 erhalten, wie etwa eine Bildsequenz und/oder Objekte, die das Fahrzeug 800 in dieser Bildsequenz lokalisiert hat (z. B. über Computervision und/oder andere maschinelle Objektklassifizierungstechniken). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netz ausführen, um die Objekte zu identifizieren und sie mit den vom Fahrzeug 800 identifizierten Objekten zu vergleichen. Wenn die Ergebnisse nicht übereinstimmen und die Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 800 eine Fehlfunktion aufweist, kann der/die Server 878 ein Signal an das Fahrzeug 800 senden, das einen ausfallsicheren Computer des Fahrzeugs 800 anweist, die Kontrolle zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
Zur Inferenz kann der/die Server 878 die GPU(s) 884 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. TensorRT von NVIDIA) enthalten. Die Kombination von GPU-gesteuerten Servern und Inferenzbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, in denen die Leistung weniger kritisch ist, können Server mit CPUs, FPGAs und anderen Prozessoren zur Inferenz verwendet werden.
Beispielhafte Rechenvorrichtung
9 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung(en) 900, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist. Die Rechenvorrichtung 900 kann ein Interconnect-System 902 enthalten, das direkt oder indirekt die folgenden Geräte koppelt: Speicher 904, eine oder mehrere zentrale Verarbeitungseinheiten (CPUs) 906, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 908, eine Kommunikationsschnittstelle 910, Eingabe-/Ausgabe- (I/O) Ports 912, Ein-/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 das (die) Computergerät(e) 900 eine oder mehrere virtuelle Maschinen (VMs) umfassen und/oder jede der Komponenten davon kann virtuelle Komponenten (z. B. virtuelle Hardwarekomponenten) umfassen. Als nicht einschränkende Beispiele können eine oder mehrere der GPUs 908 eine oder mehrere vGPUs umfassen, eine oder mehrere der CPUs 906 können eine oder mehrere vCPUs umfassen, und/oder eine oder mehrere der Logikeinheiten 920 können eine oder mehrere virtuelle Logikeinheiten umfassen. So kann eine Rechenvorrichtung 900 diskrete Komponenten (z. B. eine vollständige GPU, die der Rechenvorrichtung 900 zugeordnet ist), virtuelle Komponenten (z. B. einen Teil einer GPU, die der Rechenvorrichtung 900 zugeordnet ist) oder eine Kombination davon umfassen.
Obwohl die verschiedenen Blöcke in 9 als über das Interconnect-System 902 mit Leitungen verbunden dargestellt sind, ist dies nicht als Einschränkung gedacht und dient nur der Übersichtlichkeit. In einigen Ausführungsformen kann beispielsweise eine Präsentationskomponente 918, wie z. B. ein Anzeigegerät, 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 enthalten (z. B. kann der Speicher 904 zusätzlich zum Speicher der GPUs 908, der CPUs 906 und/oder anderer Komponenten eine Speichereinrichtung darstellen). Mit anderen Worten, die Rechnereinrichtung der 9 ist lediglich illustrativ. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Vorrichtung“, „mobiles Gerät“, „tragbares Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da sie alle in den Anwendungsbereich der Rechenvorrichtung der 9 fallen.
Das Interconnect-System 902 kann eine oder mehrere Verbindungen oder Busse darstellen, wie z. B. einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Interconnect-System 902 kann einen oder mehrere Bus- oder Verbindungstypen umfassen, z. B. einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express) und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen den Komponenten. Zum Beispiel kann die CPU 906 direkt mit dem Speicher 904 verbunden sein. Außerdem kann die CPU 906 direkt mit der GPU 908 verbunden sein. Bei einer direkten oder Punkt-zu-Punkt-Verbindung zwischen Komponenten kann das Interconnect-System 902 eine PCIe-Verbindung enthalten, um die Verbindung herzustellen. In diesen Beispielen muss ein PCI-Bus nicht in das Computergerät 900 integriert sein.
Der Speicher 904 kann aus einer Vielzahl von computerlesbaren Medien bestehen. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das Computergerät 900 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie austauschbare und nicht-entfernbare Medien umfassen. Als Beispiel und ohne Einschränkung können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.
Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entfernbare und nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen wie computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen implementiert sind. Beispielsweise kann der Speicher 904 computerlesbare Anweisungen speichern (z. B. solche, die ein Programm bzw. Programme und/oder ein Programmelement bzw. Programmelemente darstellen, wie z. B. ein Betriebssystem. Zu den Computerspeichermedien können unter anderem RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium gehören, das zur Speicherung der gewünschten Informationen verwendet werden kann und auf das die Rechenvorrichtung 900 zugreifen kann. Der hier verwendete Begriff „Computerspeichermedium“ umfasst nicht per se Signale.
Die Computerspeichermedien können computerlesbare Befehle, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal wie z. B. einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und umfassen beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert sind, dass Informationen in dem Signal codiert werden. Die Computerspeichermedien können beispielsweise verdrahtete Medien, wie ein verdrahtetes Netzwerk oder eine direkte Kabelverbindung, und drahtlose Medien, wie akustische, RF-, Infrarot- und andere drahtlose Medien, umfassen. Kombinationen der oben genannten Medien sollten ebenfalls in den Bereich der computerlesbaren Medien fallen.
Die CPU(s) 906 können so konfiguriert sein, dass sie mindestens einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Computergeräts 900 zu steuern und eines oder mehrere der hierin beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 906 können jeweils einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) umfassen, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 906 können jede Art von Prozessor umfassen und je nach Art des implementierten Computergeräts 900 verschiedene Arten von Prozessoren umfassen (z. B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Je nach Art des Rechengeräts 900 kann der Prozessor zum Beispiel ein Advanced RISC Machines (ARM)-Prozessor sein, der mit Reduced Instruction Set Computing (RISC) arbeitet, oder ein x86-Prozessor, der mit Complex Instruction Set Computing (CISC) arbeitet. Die Recheneinheit 900 kann eine oder mehrere CPUs 906 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Coprozessoren, wie z. B. mathematischen Coprozessoren, enthalten.
Zusätzlich zu oder alternativ zu der/den CPU(s) 906 können die GPU(s) 908 so konfiguriert sein, dass sie mindestens einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Computergeräts 900 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzufü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 kann eine oder mehrere der GPU(s) 908 ein Coprozessor einer oder mehrerer der CPU(s) 906 sein. Die GPUs 908 können von der Rechenvorrichtung 900 zum Rendern von Grafiken (z. B. 3D-Grafiken) oder zur Durchführung von allgemeinen Berechnungen verwendet werden. Die GPU(s) 908 können zum Beispiel für General-Purpose Computing on GPUs (GPGPU) verwendet werden. Die GPU(s) 908 können Hunderte oder Tausende von Kernen umfassen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 908 können als Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von der/den CPU(s) 906, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 908 können einen Grafikspeicher, z. B. einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, z. B. GPGPU-Daten, enthalten. Der Anzeigespeicher kann als Teil des Speichers 904 enthalten sein. Die GPU(s) 908 können zwei oder mehr GPUs umfassen, die parallel arbeiten (z. B. über eine Verbindung). Die Verbindung kann die GPUs direkt verbinden (z. B. mit NVLINK) oder die GPUs über einen Switch verbinden (z. B. mit NVSwitch). Wenn sie miteinander kombiniert werden, kann jede GPU 908 Pixeldaten oder GPGPU-Daten für verschiedene Teile einer Ausgabe oder für verschiedene Ausgaben erzeugen (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU fiir ein zweites Bild). Jede GPU kann ihren eigenen Speicher haben oder sich den Speicher mit anderen GPUs teilen.
Zusätzlich zu oder alternativ zu der (den) CPU(s) 906 und/oder der (den) GPU(s) 908 kann (können) die Logikeinheit(en) 920 so konfiguriert sein, dass sie mindestens einige der computerlesbaren Anweisungen ausführen, um eine oder mehrere Komponenten des Computergeräts 900 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsformen können die CPU(s) 906, die GPU(s) 908 und/oder die Logikeinheit(en) 920 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 920 können Teil einer oder mehrerer der CPU(s) 906 und/oder der GPU(s) 908 sein und/oder eine oder mehrere der Logikeinheiten 920 können diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 906 und/oder der GPU(s) 908 liegen. In Ausführungsformen kann eine oder mehrere der Logikeinheiten 920 ein Coprozessor einer oder mehrerer der CPU(s) 906 und/oder einer oder mehrerer der GPU(s) 908 sein.
Beispiele für die logische(n) Einheit(en) 920 umfassen einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie z. B. Datenverarbeitungseinheiten (DPUs), Tensorkerne (TCs), Tensorverarbeitungseinheiten (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Grafikverarbeitungscluster (GPCs), Texturverarbeitungscluster (TPCs), Streaming-Multiprozessoren (SMs), Tree Traversal Units (TTUs), Artificial Intelligence Accelerators (AIAs), Deep Learning Accelerators (DLAs), Arithmetic-Logic Units (ALUs), Application-Specific Integrated Circuits (ASICs), Floating Point Units (FPUs), Input/Output (IIO)-Elemente, Peripheral Component Interconnect (PCI) oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
Die Kommunikationsschnittstelle 910 kann einen oder mehrere Empfänger, Sender und/oder Transceiver enthalten, die es dem Computergerät 900 ermöglichen, mit anderen Computergeräten über ein elektronisches Kommunikationsnetzwerk zu kommunizieren, einschließlich drahtgebundener und/oder drahtloser Kommunikation. Die Kommunikationsschnittstelle 910 kann Komponenten und Funktionen enthalten, die die Kommunikation über eine Reihe verschiedener Netzwerke ermöglichen, wie z. B. drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weitverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet. In einer oder mehreren Ausführungsformen können die Logikeinheit(en) 920 und/oder die Kommunikationsschnittstelle 910 eine oder mehrere Datenverarbeitungseinheiten (DPUs) enthalten, um über ein Netzwerk und/oder über das Interconnect-System 902 empfangene Daten direkt an eine oder mehrere GPU(s) 908 (z. B. einen Speicher) zu übertragen.
Über die I/O-Ports 912 kann das Computergerät 900 logisch mit anderen Geräten gekoppelt werden, einschließlich der I/O-Komponenten 914, der Präsentationskomponente(n) 918 und/oder anderer Komponenten, von denen einige in das Computergerät 900 eingebaut (z. B. integriert) sein können. Illustrative I/O-Komponenten 914 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die I/O-Komponenten 914 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben eines Benutzers verarbeitet. In einigen Fällen können die 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 ausführlicher beschrieben) in Verbindung mit einer Anzeige des Computergeräts 900 implementieren. Das Computergerät 900 kann Tiefenkameras, wie z. B. stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung enthalten. Darüber hinaus kann das Computergerät 900 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (IMU)) enthalten, die die Erkennung von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von der Computervorrichtung 900 verwendet werden, um immersive erweiterter Realität oder Virtual Reality darzustellen.
Die Stromversorgung 916 kann eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon sein. Die Stromversorgung 916 kann das Computergerät 900 mit Strom versorgen, um den Betrieb der Komponenten des Computergeräts 900 zu ermöglichen.
Die Präsentationskomponente(n) 918 kann (können) eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Head-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 918 können Daten von anderen Komponenten (z. B. der/den GPU(s) 908, der/den CPU(s) 906, DPUs usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
Beispielhaftes Datenzentrum
10 zeigt ein beispielhaftes Datenzentrum 1000, das in mindestens einer Ausführungsform der vorliegenden Offenbarung verwendet werden kann. Das Datenzentrum 1000 kann eine Datenzentrumsinfrastrukturschicht 1010, eine Framework-Schicht 1020, eine Softwareschicht 1030 und/oder eine Anwendungsschicht 1040 umfassen.
Wie in 10 dargestellt, kann die Infrastrukturschicht 1010 des Datenzentrums einen Ressourcen-Orchestrator 1012, gruppierte Rechenressourcen 1014 und Knotenrechenressourcen („Knoten-C.R.s“) 1016(1)-1016(N) umfassen, 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 Zentraleinheiten (CPUs) oder anderen Prozessoren (einschließlich DPUs, Beschleunigern, feldprogrammierbaren Gate-Arrays (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Speichergeräten (z. B., dynamischer Festwertspeicher), Speichergeräte (z. B. Festkörper- oder Plattenlaufwerke), Netzwerk-Eingabe-/Ausgabegeräte (NW I/O), Netzwerk-Switches, virtuelle Maschinen (VMs), Stromversorgungsmodule und/oder Kühlmodule usw. In einigen Ausführungsformen können ein oder mehrere Knoten-C.R.s unter den Knoten-C.R.s 1016(1)-1016(N) einem Server entsprechen, der über eine oder mehrere der oben erwähnten Rechenressourcen verfügt. Darüber hinaus können in einigen Ausführungsformen die Knoten C.R.s 1016(1)-10161(N) eine oder mehrere virtuelle Komponenten enthalten, 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 die gruppierten Rechenressourcen 1014 separate Gruppierungen von Knoten-CRs 1016 umfassen, die in einem oder mehreren Racks (nicht dargestellt) oder in vielen Racks in Datenzentren an verschiedenen geografischen Standorten (ebenfalls nicht dargestellt) untergebracht sind. Separate Gruppierungen von Knoten-C.R.s 1016 innerhalb der gruppierten Rechenressourcen 1014 können gruppierte Rechen-, Netzwerk-, Speicher- oder Speicherressourcen umfassen, die zur Unterstützung einer oder mehrerer Arbeitslasten konfiguriert oder zugewiesen werden können. In mindestens einer Ausführungsform können mehrere Knoten-CRs 1016 mit CPUs, GPUs, DPUs und/oder anderen Prozessoren in einem oder mehreren Racks gruppiert werden, um Rechenressourcen zur Unterstützung einer oder mehrerer Arbeitslasten bereitzustellen. Das eine oder die mehreren Racks können auch eine beliebige Anzahl von Stromversorgungsmodulen, Kühlmodulen und/oder Netzwerk-Switches in beliebiger Kombination enthalten.
Der Ressourcen-Orchestrator 1012 kann einen oder mehrere Knoten-CRs 1016(1)-1016(N) und/oder gruppierte Rechenressourcen 1014 konfigurieren oder anderweitig steuern. In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 1012 eine Software-Design-Infrastruktur (SDI)-Managementeinheit für das Datenzentrum 1000 umfassen. Der Ressourcen-Orchestrator 1012 kann Hardware, Software oder eine Kombination davon umfassen.
In mindestens einer Ausführungsform, wie in 10 gezeigt, kann die Framework-Schicht 1020 einen Job-Scheduler 1033, einen Konfigurationsmanager 1034, einen Ressourcenmanager 1036 und/oder ein verteiltes Dateisystem 1038 enthalten. Die Framework-Schicht 1020 kann ein Framework zur Unterstützung der Software 1032 der Softwareschicht 1030 und/oder einer oder mehrerer Anwendungen 1042 der Anwendungsschicht 1040 enthalten. Die Software 1032 oder die Anwendung(en) 1042 können jeweils webbasierte Dienstsoftware oder Anwendungen umfassen, wie sie von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. Bei der Framework-Schicht 1020 kann es sich um eine Art von freiem und quelloffenem Software-Webanwendungs-Framework wie Apache Spark™ (im Folgenden „Spark“) handeln, das ein verteiltes Dateisystem 1038 für die Verarbeitung großer Datenmengen (z. B. „Big Data“) nutzen kann, ohne darauf beschränkt zu sein. In mindestens einer Ausführungsform kann der Job-Scheduler 1033 einen Spark-Treiber enthalten, um die Planung von Arbeitslasten zu erleichtern, die von verschiedenen Schichten des Datenzentrums 1000 unterstützt werden. Der Konfigurationsmanager 1034 kann in der Lage sein, verschiedene Schichten zu konfigurieren, z. B. die Softwareschicht 1030 und die Framework-Schicht 1020 einschließlich Spark und das verteilte Dateisystem 1038 zur Unterstützung der Verarbeitung großer Datenmengen. Der Ressourcenmanager 1036 kann in der Lage sein, geclusterte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 1038 und des Job-Schedulers 1033 zugeordnet sind. In mindestens einer Ausführungsform können geclusterte oder gruppierte Rechenressourcen gruppierte Rechenressourcen 1014 auf der Infrastrukturschicht 1010 des Datenzentrums umfassen. Der Ressourcenmanager 1036 kann sich mit dem Ressourcen-Orchestrator 1012 abstimmen, um diese zugeordneten oder zugewiesenen Computerressourcen zu verwalten.
In mindestens einer Ausführungsform kann die in der Softwareschicht 1030 enthaltene Software 1032 Software enthalten, die von mindestens Teilen der Knoten C.R.s 1016(1)-1016(N), der gruppierten Rechenressourcen 1014 und/oder des verteilten Dateisystems 1038 der Framework-Schicht 1020 verwendet wird. Eine oder mehrere Arten von Software können unter anderem Internet-Suchsoftware, E-Mail-Virenscan-Software, Datenbanksoftware und Software für Streaming-Videoinhalte umfassen.
In mindestens einer Ausführungsform kann (können) die in der Anwendungsschicht 1040 enthaltene(n) Anwendung(en) 1042 eine oder mehrere Arten von Anwendungen umfassen, die von mindestens Teilen der Knoten C.R.s 1016(1)-1016(N), gruppierten Rechenressourcen 1014 und/oder dem verteilten Dateisystem 1038 der Framework-Schicht 1020 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl von Genomanwendungen, kognitiven Berechnungen und Anwendungen für maschinelles Lernen umfassen, einschließlich Trainings- oder Inferenzsoftware, Framework-Software für maschinelles Lernen (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere Anwendungen für maschinelles Lernen, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden, sind jedoch nicht darauf beschränkt.
In mindestens einer Ausführungsform können der Konfigurationsmanager 1034, der Ressourcenmanager 1036 und der Ressourcen-Orchestrator 1012 eine beliebige Anzahl und Art von selbstmodifizierenden Aktionen implementieren, die auf einer beliebigen Menge und Art von Daten basieren, die auf jede technisch mögliche Weise erfasst wurden. Selbstmodifizierende Aktionen können einen Datenzentrumsbetreiber des Datenzentrums 1000 davon entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Teile eines Datenzentrums zu vermeiden.
Das Datenzentrum 1000 kann Werkzeuge, Dienste, Software oder andere Ressourcen enthalten, um ein oder mehrere maschinelle Lernmodelle zu trainieren oder Informationen unter Verwendung eines oder mehrerer maschineller Lernmodelle gemäß einer oder mehrerer hierin beschriebener Ausführungsformen vorherzusagen oder abzuleiten. Beispielsweise kann ein maschinelles Lernmodell bzw. können maschinelle Lernmodelle trainiert werden, indem Gewichtsparameter gemäß einer neuronalen Netzwerkarchitektur unter Verwendung von Software und/oder Computerressourcen berechnet werden, die oben in Bezug auf das Datenzentrum 1000 beschrieben wurden. In mindestens einer Ausführungsform können trainierte oder eingesetzte maschinelle Lernmodelle, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um Informationen abzuleiten oder vorherzusagen, wobei die oben beschriebenen Ressourcen in Bezug auf das Datenzentrum 1000 verwendet werden, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere Trainingstechniken berechnet werden, wie zum Beispiel, aber nicht beschränkt auf die hierin beschriebenen.
In mindestens einer Ausführungsform kann das Datenzentrum 1000 CPUs, anwendungsspezifische integrierte Schaltkreise (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder die Inferenz 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, um Benutzern das Training oder die Inferenz von Informationen zu ermöglichen, wie z. B. Bilderkennung, Spracherkennung oder andere Dienste der künstlichen Intelligenz.
Beispielhafte Netzwerkumgebungen
Netzwerkumgebungen, die zur Verwendung bei der Implementierung von Ausführungsformen der Offenbarung geeignet sind, können ein oder mehrere Client-Vorrichtungen, Server, Network Attached Storage (NAS), andere Backend-Geräte und/oder andere Gerätetypen umfassen. Die Client-Vorrichtungen, Server und/oder anderen Gerätetypen (z. B. jedes Gerät) können auf einer oder mehreren Instanzen des/der Computergeräts/e 900 der 9 implementiert werden - z. B. kann jedes Gerät ähnliche Komponenten, Merkmale und/oder Funktionalität des/der Computergeräts/e 900 enthalten. Wenn Backend-Geräte (z. B. Server, NAS usw.) implementiert sind, können die Backend-Geräte außerdem als Teil eines Datenzentrums 1000 enthalten sein, von dem ein Beispiel hierin in Bezug auf 10 ausführlicher beschrieben wird.
Die Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerke miteinander kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netz kann mehrere Netze oder ein Netz von Netzen umfassen. Beispielsweise kann das Netzwerk ein oder mehrere Wide Area Networks (WANs), ein oder mehrere Local Area Networks (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonnetz (PSTN) und/oder ein oder mehrere private Netzwerke umfassen. Wenn das Netz ein drahtloses Telekommunikationsnetz umfasst, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Konnektivität bieten.
Zu den kompatiblen Netzwerkumgebungen gehören eine oder mehrere Peer-to-Peer-Netzwerkumgebungen - in diesem Fall kann ein Server nicht in eine Netzwerkumgebung eingebunden sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in eine Netzwerkumgebung eingebunden sein. In Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Vorrichtungen implementiert werden.
In mindestens einer Ausführungsform kann eine Netzumgebung eine oder mehrere Cloud-basierte Netzumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. umfassen. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Job-Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem umfassen, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzwerkserver und/oder Edge-Server umfassen können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Softwareschicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht umfassen. Die Software oder die Anwendung(en) können jeweils webbasierte Dienstsoftware oder Anwendungen umfassen. In Ausführungsformen können ein oder mehrere Client-Vorrichtungen die webbasierte Dienstsoftware oder Anwendungen nutzen (z. B. durch Zugriff auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs)). Bei der Framework-Schicht kann es sich um eine Art von freiem und quelloffenem Software-Webanwendungs-Framework handeln, das z. B. ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwendet, ohne darauf beschränkt zu sein.
Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination der hier 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 Datenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Befindet sich eine Verbindung zu einem Benutzer (z. B. einem Client-Vorrichtung) relativ nahe an einem oder mehreren Edge-Servern, kann ein Kernserver mindestens einen Teil der Funktionalität dem oder den Edge-Servern zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat (z. B. auf eine einzelne Organisation beschränkt), öffentlich (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z. B. eine hybride Cloud-Umgebung) sein.
Die Client-Vorrichtung(en) kann (können) mindestens einige der Komponenten, Merkmale und Funktionen des (der) hier in Bezug auf 9 beschriebenen beispielhaften Rechenvorrichtung(en) 900 enthalten. Beispielhaft und ohne Einschränkung kann ein Client-Vorrichtung ein Personal Computer (PC), ein Laptop, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smartwatch, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder ein Gerät, ein Videoplayer, eine Videokamera, ein Überwachungsgerät oder -system, ein Fahrzeug, ein Boot, ein fliegendes Schiff, eine virtuelle Maschine ein Boot, ein fliegendes Schiff, eine virtuelle Maschine, eine Drohne, ein Roboter, ein tragbares Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeugcomputersystem, ein eingebettetes Systemsteuergerät, eine Fernbedienung, ein Gerät, ein Unterhaltungselektronikgerät, eine Workstation, ein Edge-Vorrichtung, eine beliebige Kombination dieser beschriebenen Geräte oder jedes andere geeignete Gerät.
Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinell verwendbaren Anweisungen, einschließlich von computerausführbaren Anweisungen wie Programmmodulen, beschrieben werden, die von einem Computer oder einer anderen Maschine, z. B. einem persönlichen Datenassistenten oder einem anderen tragbaren Gerä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 angewendet werden, einschließlich tragbaren Geräten, Unterhaltungselektronik, Allzweckcomputern, spezielleren Datenverarbeitungsgeräten usw. Die Offenbarung kann auch in verteilten Rechenumgebungen angewendet werden, in denen Aufgaben von ferngesteuerten Geräten ausgeführt werden, die über ein Kommunikationsnetz verbunden sind.
Wenn hier von „und/oder“ in Bezug auf zwei oder mehr Elemente die Rede ist, sollte dies so verstanden werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. So kann beispielsweise „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 die Elemente A, B und C umfassen. Darüber hinaus kann „mindestens eines der Elemente A oder B“ mindestens eines der Elemente A, mindestens eines der Elemente B oder mindestens eines der Elemente A und mindestens eines der Elemente B einschließen.
Der Gegenstand der vorliegenden Offenbarung wird hier mit einer Genauigkeit beschrieben, die den gesetzlichen Anforderungen entspricht. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien zu umfassen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente der angewandten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offenbarten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich 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 [0123]

Claims

Verfahren, das aufweist: Identifizieren eines Szenarios für ein erstes Fahrzeug mindestens basierend auf der Analyse von Sensordaten, die von mindestens einem Sensor des ersten Fahrzeugs in einer Umgebung erzeugt wurden; Empfangen eines Warteelements, das mit dem Szenario verbunden ist, wobei das Warteelement einen ersten Weg für das erste Fahrzeug zum Durchqueren eines Bereichs in der Umgebung und einen zweiten Weg für ein zweites Fahrzeug zum Durchqueren des Bereichs codiert; Bestimmen, aus dem ersten Weg, einer ersten Trajektorie in dem Gebiet für das erste Fahrzeug, mindestens basierend auf einer ersten Position des ersten Fahrzeugs zu einem Zeitpunkt; Bestimmen, aus dem zweiten Weg, einer zweiten Trajektorie in dem Gebiet für das zweite Fahrzeug, mindestens basierend auf einem zweiten Standort des zweiten Fahrzeugs zu dem Zeitpunkt; Beurteilen, ob es einen Konflikt zwischen der ersten Trajektorie und der zweiten Trajektorie gibt; und Übertragen von Daten, die das erste Fahrzeug veranlassen, gemäß einem Wartezustand zu arbeiten, mindestens basierend auf der Beurteilung, wobei der Wartezustand ein Vorfahrtsverhalten für das erste Fahrzeug definiert.
Verfahren nach Anspruch 1, wobei der Zeitpunkt ein erster Zeitpunkt ist und das Verfahren ferner das Identifizieren des Konflikts zwischen der ersten Trajektorie und der zweiten Trajektorie basierend auf dem Bestimmen einer Schnittmenge zwischen mindestens einem Teil einer ersten beanspruchten Menge des ersten Fahrzeugs ab einem zweiten Zeitpunkt auf der ersten Trajektorie und mindestens einem Teil einer zweiten beanspruchten Menge des zweiten Fahrzeugs ab dem zweiten Zeitpunkt auf der zweiten Trajektorie umfasst.
Verfahren nach Anspruch 2, wobei das Bestimmen der Schnittmenge mindestens auf dem Identifizieren einer potentiellen Schnittmenge zwischen einem ersten Begrenzungsrahmen, der eine Geometrie des ersten Fahrzeugs repräsentiert, das die erste Trajektorie durchquert, und einer zweiten Begrenzungsrahmen basiert, der eine Geometrie des zweiten Fahrzeugs repräsentiert, das die zweite Trajektorie durchquert.
Verfahren nach einem der vorhergehenden Ansprüche, das ferner aufweist: Bestimmen eines ersten Zeitintervalls, das eine erste Menge von zeitlichen Koordinaten angibt, die die erste Trajektorie kennzeichnen, die das Gebiet durchquert; Bestimmen eines zweiten Zeitintervalls, das eine zweite Menge von zeitlichen Koordinaten angibt, die die zweite Trajektorie kennzeichnen, die das Gebiet durchquert; Bestimmen einer Schnittmenge der ersten Menge der zeitlichen Koordinaten und der zweiten Menge der zeitlichen Koordinaten; und Identifizieren des Konflikts zwischen der ersten Trajektorie und der zweiten Trajektorie mindestens basierend auf dem Erfassen, dass die Schnittmenge der ersten Menge von zeitlichen Koordinaten und der zweiten Menge von zeitlichen Koordinaten keine Nullmenge ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die erste Trajektorie und die zweite Trajektorie jeweils Trajektorien innerhalb einer vierdimensionalen Mannigfaltigkeit mit mindestens zwei räumlichen Dimensionen und mindestens zwei zeitlichen Dimensionen sind.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Szenario eines oder mehrere der folgenden Szenarien aufweist: ein Kreuzungsszenario, wobei der Bereich eine Kreuzung aufweist, oder ein Einmündungsszenario, wobei der Bereich einmündende Fahrspuren aufweist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die zweite Trajektorie eine Beschleunigung des zweiten Fahrzeugs nach dem Zeitpunkt simuliert.
Prozessor, der aufweist: eine oder mehrere Schaltungen, um: ein Szenario für ein erstes Fahrzeug mindestens auf der Analyse von Sensordaten basierend zu identifizieren, die von mindestens einem Sensor des ersten Fahrzeugs in einer Umgebung erzeugt wurden; ein mit dem Szenario verbundenes Warteelement zu empfangen, wobei das Warteelement einen ersten Weg für das erste Fahrzeug zum Durchqueren eines Bereichs in der Umgebung und einen zweiten Weg für ein zweites Fahrzeug zum Durchqueren des Bereichs codiert; den ersten Weg zu verwenden, um mindestens basierend auf einem ersten Standort des ersten Fahrzeugs zu einem bestimmten Zeitpunkt eine erste Trajektorie in dem Gebiet für das erste Fahrzeug zu bestimmen; den zweiten Weg zu verwenden, um mindestens auf einem zweiten Standort des zweiten Fahrzeugs zu dem Zeitpunkt basierend eine zweite Trajektorie in dem Gebiet für das zweite Fahrzeug zu bestimmen; zu bewerten, ob es einen Konflikt zwischen der ersten Trajektorie und der zweiten Trajektorie gibt; und Daten zu übertragen, die das erste Fahrzeug veranlassen, mindestens basierend auf der Bewertung gemäß einem Wartezustand zu arbeiten, wobei der Wartezustand ein Vorfahrtsverhalten für das erste Fahrzeug definiert.
Prozessor nach Anspruch 8, wobei der Zeitpunkt ein erster Zeitpunkt ist und die eine oder die mehreren Schaltungen ferner den Konflikt zwischen der ersten Trajektorie und der zweiten Trajektorie basierend auf der Bestimmung einer Schnittmenge zwischen mindestens einem Teil einer ersten beanspruchten Menge des ersten Fahrzeugs ab einem zweiten Zeitpunkt auf der ersten Trajektorie und mindestens einem Teil einer zweiten beanspruchten Menge des zweiten Fahrzeugs ab dem zweiten Zeitpunkt auf der zweiten Trajektorie identifizieren.
Prozessor nach Anspruch 9, wobei das Bestimmen der Schnittmenge auf dem Identifizieren einer potentiellen Schnittmenge zwischen einem ersten Begrenzungsrahmen, der eine Geometrie des ersten Fahrzeugs darstellt, und einem zweiten Begrenzungsrahmen basiert, der eine Geometrie des zweiten Fahrzeugs darstellt.
Prozessor nach einem der Ansprüche 8 bis 10, wobei die eine oder die mehreren Schaltungen ferner dazu dienen: ein erstes Zeitintervall zu bestimmen, das eine erste Menge von zeitlichen Koordinaten angibt, die die erste Trajektorie durch das Gebiet kennzeichnen; ein zweites Zeitintervall zu bestimmen, das eine zweite Menge von zeitlichen Koordinaten angibt, die die zweite Trajektorie durch das Gebiet kennzeichnen; eine Schnittmenge der ersten Menge der zeitlichen Koordinaten und der zweiten Menge der zeitlichen Koordinaten zu bestimmen; und den Konflikt zwischen der ersten Trajektorie und der zweiten Trajektorie basierend auf dem Erfassen zu bestimmen, dass die Schnittmenge der ersten Menge der zeitlichen Koordinaten und der zweiten Menge der zeitlichen Koordinaten keine Nullmenge ist.
Prozessor nach einem der Ansprüche 8 bis 11, wobei die erste Trajektorie und die zweite Trajektorie jeweils Trajektorien innerhalb einer vierdimensionalen Mannigfaltigkeit mit mindestens zwei räumlichen Dimensionen und mindestens zwei zeitlichen Dimensionen sind.
Prozessor nach einem der Ansprüche 8 bis 12, wobei das Szenario eines oder mehrere der folgenden Szenarien aufweist: ein Kreuzungsszenario, bei dem der Bereich eine Kreuzung aufweist, oder ein Einmündungsszenario, bei dem der Bereich einmündende Fahrspuren aufweist.
Prozessor nach einem der Ansprüche 8 bis 13, wobei die zweite Trajektorie simuliert, dass das zweiten Fahrzeugs nach der Zeit beschleunigt.
System, das aufweist: eine oder mehrere Verarbeitungseinheiten; und eine oder mehrere Speichervorrichtungen, die Anweisungen speichern, die, wenn sie unter Verwendung der einen oder mehreren Verarbeitungseinheiten ausgeführt werden, die eine oder mehreren Verarbeitungseinheiten veranlassen, Aktionen auszuführen, die aufweisen: Identifizieren eines Szenarios für ein erstes Fahrzeug mindestens basierend auf der Analyse von Sensordaten, die von mindestens einem Sensor des ersten Fahrzeugs in einer Umgebung erzeugt wurden; Empfangen eines Warteelements, das mit dem Szenario verbunden ist, wobei das Warteelement einen ersten Weg für das erste Fahrzeug zum Durchqueren eines Bereichs in der Umgebung und einen zweiten Weg für ein zweites Fahrzeug zum Durchqueren des Bereichs codiert; Bestimmen, aus dem ersten Weg, einer ersten Trajektorie in dem Gebiet für das erste Fahrzeug, mindestens basierend auf einer ersten Position des ersten Fahrzeugs zu einem Zeitpunkt; Bestimmen, aus dem zweiten Weg, einer zweiten Trajektorie in dem Gebiet für das zweite Fahrzeug, mindestens basierend auf einem zweiten Standort des zweiten Fahrzeugs zu dem Zeitpunkt; Bewerten, ob es einen Konflikt zwischen der ersten Trajektorie und der zweiten Trajektorie gibt; und Übertragen von Daten, die das erste Fahrzeug veranlassen, mindestens basierend auf der Bewertung gemäß einem Wartezustand zu arbeiten, wobei der Wartezustand ein Vorfahrtsverhalten für das erste Fahrzeug definiert.
System nach Anspruch 15, wobei der Zeitpunkt ein erster Zeitpunkt ist und die Aktionen ferner das Identifizieren des Konflikts zwischen der ersten Trajektorie und der zweiten Trajektorie basierend auf dem Bestimmen einer Schnittmenge zwischen mindestens einem Teil einer ersten beanspruchten Menge des ersten Fahrzeugs ab einem zweiten Zeitpunkt auf der ersten Trajektorie und mindestens einem Teil einer zweiten beanspruchten Menge des zweiten Fahrzeugs ab dem zweiten Zeitpunkt auf der zweiten Trajektorie aufweisen.
System nach Anspruch 16, wobei das Bestimmen der Schnittmenge auf dem Identifizieren einer potentiellen Schnittmenge zwischen einem ersten Begrenzungsrahmen, der eine Geometrie des ersten Fahrzeugs repräsentiert, und einem zweiten Begrenzungsrahmen basiert, der eine Geometrie des zweiten Fahrzeugs repräsentiert.
System nach einem der Ansprüche 15 bis 17, wobei die Aktionen ferner aufweisen: Bestimmen eines ersten Zeitintervalls, das eine erste Menge von zeitlichen Koordinaten angibt, die die erste Trajektorie durch das Gebiet kennzeichnen; Bestimmen eines zweiten Zeitintervalls, das eine zweite Menge von zeitlichen Koordinaten angibt, die die zweite Trajektorie durch das Gebiet kennzeichnen; Bestimmen einer Schnittmenge der ersten Menge der zeitlichen Koordinaten und der zweiten Menge der zeitlichen Koordinaten; und Identifizieren des Konflikts zwischen der ersten Trajektorie und der zweiten Trajektorie basierend auf dem Erfassen, dass die Schnittmenge der ersten Menge der zeitlichen Koordinaten und der zweiten Menge von zeitlichen Koordinaten keine Nullmenge ist.
System nach einem der Ansprüche 15 bis 18, wobei die erste Trajektorie und die zweite Trajektorie jeweils Trajektorien innerhalb einer vierdimensionalen Mannigfaltigkeit mit mindestens zwei räumlichen Dimensionen und mindestens zwei zeitlichen Dimensionen sind.
System nach einem der Ansprüche 15 bis 19, das in mindestens einem enthalten ist von: einem Steuersystem für eine autonome oder halbautonome Maschine; einem Wahrnehmungssystem für eine autonome oder halbautonome Maschine; einem System zum Durchführen von Simulationsoperationen; einem System zum Durchführen von Deep-Learning-Operationen; einem System, das unter Verwendung einer Edge-Vorrichtung implementiert ist; einem System, das unter Verwendung eines Roboters implementiert ist; einem System, das eine oder mehrere virtuelle Maschinen (VMs) enthält; einem System, das mindestens teilweise in einem Datenzentrum implementiert ist; oder einem System, das mindestens teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.