DE102022127739A1

DE102022127739A1 - Intelligente fahrzeugsysteme und steuerlogik für die vorhersage von vorfällen und die unterstützung bei fahrten im gelände

Info

Publication number: DE102022127739A1
Application number: DE102022127739.9A
Authority: DE
Inventors: Ariel Telpaz; Ravid Erez; Michael Baltaxe; Barak Hershkovitz; Nadav Baron; Christopher A. Stanek
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2021-12-07
Filing date: 2022-10-20
Publication date: 2023-06-07
Also published as: US20230177840A1; CN116238535A

Abstract

Vorgestellt werden intelligente Fahrzeugsysteme zur Vorhersage und Unterstützung bei Fahrten im Gelände, Verfahren zur Herstellung/Betrieb solcher Systeme und Fahrzeuge, die mit solchen Systemen vernetzt sind. Ein Verfahren zum Betrieb eines Kraftfahrzeugs umfasst eine Systemsteuerung, die Geolokalisierungsdaten empfängt, die anzeigen, dass sich das Fahrzeug in einem Gelände befindet oder in ein solches einfährt. Als Reaktion auf die Geolokalisierungsdaten des Fahrzeugs empfängt das Steuergerät von im Fahrzeug montierten Kameras kameragestützte Bilder, die jeweils das/die Antriebsrad/räder des Fahrzeugs und/oder die Oberfläche des Geländes enthalten. Das Steuergerät empfängt von einem Controller Area Network Bus Fahrzeugbetriebsdaten und Fahrzeugdynamikdaten für das Kraftfahrzeug. Die Kameradaten, die Daten zu den Betriebseigenschaften des Fahrzeugs und die Daten zur Fahrzeugdynamik werden über ein konvolutionales Netzwerk-Backbone verarbeitet, um das Auftreten eines Fahrvorfalls auf dem Gelände innerhalb eines Vorhersagezeithorizonts vorherzusagen. Der Systemcontroller befiehlt einem residenten Fahrzeugsystem, als Reaktion auf das vorhergesagte Auftreten des Fahrvorfalls einen Steuerungsvorgang auszuführen.

Description

EINFÜHRUNG
Die vorliegende Offenbarung bezieht sich allgemein auf Steuersysteme für Kraftfahrzeuge. Genauer gesagt beziehen sich Aspekte dieser Offenbarung auf intelligente Fahrzeugnavigationssysteme und Steuerlogik zur Vorhersage von Fahrvorfällen in Situationen abseits der Straße.
Heutige Serienfahrzeuge, wie z. B. das moderne Automobil, können mit einem Netzwerk von elektronischen Geräten an Bord und drahtlosen Kommunikationsmöglichkeiten ausgestattet sein, die automatisierte Fahrfunktionen und Navigationshilfe bieten. In dem Maße, wie sich die Verarbeitungs-, Kommunikations- und Sensorfähigkeiten der Fahrzeuge verbessern, bieten die Hersteller immer mehr automatisierte Fahrfunktionen an, mit dem Ziel, vollständig autonome „selbstfahrende“ Fahrzeuge zu produzieren, die in der Lage sind, zwischen heterogenen Fahrzeugtypen sowohl in städtischen als auch in ländlichen Szenarien zu navigieren. Die Erstausrüster (OEM) bewegen sich auf „sprechende“ Fahrzeuge von Fahrzeug zu Fahrzeug (V2V) und von Fahrzeug zu Infrastruktur (V2I) mit höherer Fahrautomatisierung zu, die autonome Steuersysteme einsetzen, um Fahrzeugrouting mit Lenkung, Spurwechsel, Szenarienplanung usw. zu ermöglichen. Automatisierte Wegplanungssysteme nutzen beispielsweise Fahrzeugzustands- und -dynamiksensoren, Geolokalisierungsinformationen, Karten- und Straßenzustandsdaten sowie Algorithmen zur Wegvorhersage, um eine Routenableitung mit automatischer Vorhersage der Fahrspurmitte und des Fahrspurwechsels zu ermöglichen.
Viele Kraftfahrzeuge sind heute mit fahrzeuginternen Computernavigationssystemen ausgestattet, die einen GPS-Sender-Empfänger (Global Positioning System) in Zusammenarbeit mit Navigationssoftware und Geolocation-Mapping-Diensten nutzen, um Straßentopografie-, Verkehrs- und Geschwindigkeitsbegrenzungsdaten in Verbindung mit dem aktuellen Standort des Fahrzeugs zu erhalten. Ad-hoc-Netzwerk-basierte Fahrerassistenzsysteme können beispielsweise GPS- und Kartierungsdaten in Verbindung mit einem Multi-Hop-Geocast-V2V- und V2I-Datenaustausch nutzen, um das automatisierte Manövrieren des Fahrzeugs und die Steuerung des Antriebsstrangs zu erleichtern. Während des Fahrzeugbetriebs kann das residente Navigationssystem eine empfohlene Reiseroute ermitteln, die auf der geschätzten kürzesten Reisezeit oder der geschätzten kürzesten Reisedistanz zwischen dem Ausgangspunkt und dem Ziel der Route für eine bestimmte Fahrt basiert. Diese empfohlene Reiseroute kann dann als Kartenausschnitt oder als Abbiegeanweisung auf einer geocodierten und mit Anmerkungen versehenen Karte mit optionalen Sprachbefehlen über das bordeigene Audiosystem angezeigt werden.
BESCHREIBUNG
Vorgestellt werden intelligente Fahrzeugnavigationssysteme mit zugehöriger Steuerlogik für die Vorhersage und Unterstützung bei Fahrten im Gelände, Verfahren zur Herstellung und zum Einsatz solcher Systeme sowie Kraftfahrzeuge, die mit solchen Systemen vernetzt sind. Bei Fahrten im Gelände kann es beispielsweise zu „Notsituationen“ kommen, in denen das Fahrzeug aufgrund der besonderen Bedingungen einer bestimmten Strecke nicht mehr fahrbereit ist oder außer Gefecht gesetzt wird (z. B. wenn ein Fahrzeug auf einem Felsbrocken oder im Schlamm auf einem Waldweg stecken bleibt). Diese Situationen können auftreten, weil das Host-Fahrzeug seine Geländefähigkeiten überschritten hat (z. B. Fahren mit einem höheren Anfahr- oder Abfahrtswinkel als vorgesehen). Es werden intelligente Fahrzeugsysteme und Steuerlogik für die automatische Vorhersage einer bevorstehenden Notsituation vorgestellt, wobei beispielsweise Geolokalisierungsdaten des Fahrzeugs, Telemetriedaten, Topographiedaten und Fahrzeugsensorikdaten (z. B. mit Schwerpunkt auf Unterbodenkameras) verwendet werden. Unter Verwendung dieser Daten wird ein auf maschinellem Lernen (ML) basierendes Modell implementiert, um die Wahrscheinlichkeit einer bevorstehenden Notfallsituation zu schätzen. Nach der Vorhersage einer bevorstehenden Notfallsituation kann ein Experte für das Fahren im Gelände dem Fahrer des Host-Fahrzeugs Fernunterstützung in Form von Fahrtechniken für das Fahren im Gelände bieten, um die Situation zu verbessern. Der erfahrene Fernassistent kann aus einer oder mehreren Datenquellen detaillierte topografische 3D-Netze des Geländes unter dem Fahrzeug und um das Fahrzeug herum erhalten. Um die Situation zu vermeiden oder zu verbessern, kann der Fernassistent dem Benutzer live Anweisungen geben oder das Fahrzeug aus der Ferne ohne Eingaben des Fahrers steuern.
Zu den Vorteilen, die zumindest einige der vorgestellten Konzepte mit sich bringen, gehören intelligente Fahrzeugnavigationssysteme, die Fahrunfälle im Gelände genau vorhersagen, z. B. eine Panne oder einen Überschlag auf einer unbefestigten Strecke oder einer abgelegenen Straße. Zur Erleichterung der Vorhersage von Fahrunfällen und zur Minimierung von Fehlalarmen kann eine 3D-Netzdarstellung der Topografie der Oberfläche unter dem Host-Fahrzeug in Echtzeit mit Hilfe von Kamera- und Ultraschallsensordaten des Fahrzeugs erstellt werden. Viele moderne Fahrzeuge mit fortschrittlichen Fahrerassistenzsystemen (ADAS) und autonomen Fahrfunktionen sind mit vorderen, hinteren und seitlichen Kameras ausgestattet. Um jedoch eine automatische Vorhersage bevorstehender Probleme im Gelände zu ermöglichen, können offengelegte Host-Fahrzeuge eine vernetzte Sensoranordnung mit einer speziellen Unterbodenkamera verwenden, um Echtzeitbilder des Fahrzeugunterbodens zu erfassen. Neben der genauen Vorhersage von Zwischenfällen werden auch Funktionen zur Lösung von Notfällen im Gelände mit Hilfe eines fachkundigen Fernassistenten oder eines intelligenten virtuellen Assistenten offengelegt.
Aspekte dieser Offenbarung beziehen sich auf Systemsteuerungslogik, Rückkopplungssteuerungstechniken und computerlesbare Medien (CRM) für die Herstellung und/oder den Betrieb eines der offengelegten Fahrzeugsensornetzwerke, Navigationssysteme und/oder Host-Fahrzeuge. In einem Beispiel wird ein Verfahren zur Steuerung des Betriebs eines Kraftfahrzeugs vorgestellt, das mit einer Sensoranordnung ausgestattet ist, die ein Netzwerk von Kameras umfasst, die an diskreten Stellen des Fahrzeugs angebracht sind. Dieses repräsentative Verfahren umfasst in beliebiger Reihenfolge und in beliebiger Kombination mit einer der oben und unten offengelegten Optionen und Merkmale: Empfangen, z. B. über eine ortsfeste oder entfernte Systemsteuerung über eine drahtgebundene/drahtlose Kommunikationsvorrichtung von einer fahrzeuginternen Telematikeinheit, einem Smartphone oder einem GPS-basierten Satellitendienst, von Geolokalisierungsdaten des Fahrzeugs, die anzeigen, dass sich das Kraftfahrzeug in einem Gelände befindet oder in ein Gelände einfährt; Empfangen, z. B., über die Systemsteuerung von der Sensoranordnung, die auf das Einfahren/Fahren des Fahrzeugs in das Gelände reagiert, Kameradaten, die auf kameragestützte Bilder hinweisen, die von den Kameras aufgenommen wurden und eines oder mehrere der Antriebsräder des Kraftfahrzeugs und/oder die Geländeoberfläche des Geländes enthalten; Empfangen, z. B., über die Steuereinheit vom CAN-Bus (Controller Area Network) des Fahrzeugs Fahrzeugbetriebsdaten und Fahrzeugdynamikdaten für das Kraftfahrzeug; Verarbeiten der Kameradaten, der Fahrzeugbetriebsdaten und der Fahrzeugdynamikdaten über einen CNN-Backbone (Convolutional Neural Network), um das Auftreten eines Fahrvorfalls auf dem Gelände innerhalb eines Vorhersagezeithorizonts vorherzusagen; und Übertragen eines oder mehrerer Befehlssignale über die Systemsteuereinheit an ein oder mehrere residente Fahrzeugsysteme, um eine oder mehrere Steueroperationen in Reaktion auf das vorhergesagte Auftreten des Fahrvorfalls auszuführen.
Ebenfalls vorgestellt werden nichttransitorische CRM, die Befehle speichern, die von einem oder mehreren Prozessoren eines Systemcontrollers ausgeführt werden können, der zur Steuerung eines Kraftfahrzeugs dient. Das Fahrzeug enthält eine Sensoranordnung mit einem Netzwerk von Kameras, die an diskreten Stellen der Fahrzeugkarosserie angebracht sind. Diese Anweisungen, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, veranlassen das Steuergerät, Vorgänge auszuführen, einschließlich: Empfangen von Fahrzeug-Geolokalisierungsdaten über eine drahtlose Kommunikationsvorrichtung, die anzeigen, dass sich das Kraftfahrzeug in einem Gelände befindet oder in ein Gelände einfährt; Empfangen von Kameradaten von der Sensoranordnung, die kamerabedingte Bilder anzeigen, die von den Kameras aufgenommen wurden und jeweils ein Fahrzeugantriebsrad und/oder eine Geländeoberfläche enthalten; Empfangen von Fahrzeugbetriebskenndaten und Fahrzeugdynamikdaten für das Kraftfahrzeug von einem CAN-Bus des Kraftfahrzeugs; Verarbeiten der Kameradaten, der Fahrzeugbetriebscharakteristikdaten und der Fahrzeugdynamikdaten über ein CNN-Backbone, um vorherzusagen, ob ein Fahrvorfall auf dem Gelände innerhalb eines Vorhersagezeithorizonts auftreten wird oder nicht; und Übertragen eines Befehlssignals an ein residentes Fahrzeugsystem, um eine Steueroperation in Reaktion auf die Vorhersage des Auftretens eines Fahrvorfalls auszuführen.
Weitere Aspekte dieser Offenbarung beziehen sich auf intelligente Fahrzeugnavigationssysteme, die Navigations- und Notfalldienste für Kraftfahrzeuge bereitstellen. Wie hierin verwendet, können die Begriffe „Fahrzeug“ und „Kraftfahrzeug“ austauschbar und synonym verwendet werden, um jede relevante Fahrzeugplattform einzuschließen, wie z. B. Personenkraftwagen (ICE, HEV, FEV, Brennstoffzelle, voll- und teilautonome Fahrzeuge usw.), Nutzfahrzeuge, Industriefahrzeuge, Raupenfahrzeuge, Geländewagen und All-Terrain-Fahrzeuge (ATV), Motorräder, landwirtschaftliche Geräte usw. In einem Beispiel umfasst ein Kraftfahrzeug eine Karosserie mit mehreren Rädern, einen Fahrgastraum und andere Standardausrüstungen. Eine Antriebsmaschine, z. B. ein elektrischer Fahrmotor und/oder eine Verbrennungsmotorbaugruppe, treibt eines oder mehrere der Räder an, um das Fahrzeug anzutreiben. An dem Fahrzeug ist auch eine Sensoranordnung angebracht, die ein Netzwerk von Kameras umfasst, die an verschiedenen Stellen der Fahrzeugkarosserie angebracht sind (z. B. Front-, Heck-, Backbord-, Steuerbord- und Unterbodenkameras).
Um mit der Diskussion des obigen Beispiels fortzufahren, empfangen ein oder mehrere stationäre oder entfernte elektronische Steuergeräte über ein verdrahtetes oder drahtloses Kommunikationsgerät Geolokalisierungsdaten des Fahrzeugs, die anzeigen, dass sich das Fahrzeug im Gelände befindet oder in ein Gelände einfährt. Als Reaktion auf die Geolokalisierungsdaten, die anzeigen, dass sich das Fahrzeug in einem Gelände befindet oder in ein Gelände einfährt, kommunizieren die Steuergeräte mit der Fahrzeugsensoranordnung, um Kameradaten zu empfangen, die auf von den Kameras aufgenommene kameragestützte Bilder hinweisen. Jedes von der Kamera erzeugte Bild enthält mindestens eines der Antriebsräder des Kraftfahrzeugs und/oder die Oberfläche des Geländes. Die Systemsteuerung(en) kommunizieren auch mit einem CAN-Bus des Fahrzeugs, um Daten über die Betriebseigenschaften des Fahrzeugs und die Fahrdynamik des Kraftfahrzeugs zu erhalten. Ein CNN-Backbone verarbeitet die Kameradaten, die Daten zu den Betriebseigenschaften des Fahrzeugs und die Daten zur Fahrzeugdynamik, um das Auftreten eines Fahrvorfalls auf dem Gelände innerhalb eines Vorhersagezeithorizonts vorherzusagen. Wenn der Systemcontroller das Auftreten eines Fahrvorfalls vorhersagt, überträgt er mindestens ein Befehlssignal an mindestens ein residentes Fahrzeugsystem, um mindestens einen Steuerungsvorgang in Reaktion auf das vorhergesagte Auftreten des Fahrvorfalls auszuführen.
Für jedes der offengelegten Fahrzeuge, Systeme und Verfahren wird für jede Kamera ein Interessenbereich (ROI) definiert, der ROI wird in eine vordefinierte Position einer Kameraansicht der Kamera eingefügt und dort fixiert. In diesem Fall werden beschnittene Kamerabilder erzeugt, indem jedes von einer Kamera erzeugte Bild beschnitten wird, um Bilddaten außerhalb des ROI zu entfernen. Der CNN-Backbone kann die beschnittenen Bilder analysieren, um eine oder mehrere Radcharakteristiken für ein oder mehrere Antriebsräder des Fahrzeugs zu bestimmen. Die Radcharakteristik kann einen Verlust des Bodenkontakts, ein Hängenbleiben im Schlamm, Sand, Wasser und/oder einen anderen Hindernisstatus und/oder einen Verlust des Reifenprofils, des Reifendrucks, der Traktion und/oder einen anderen Status der normalen Betriebsmerkmale umfassen. Die Vorhersage des Auftretens einer Fahrstörung kann zumindest teilweise auf der/den Radeigenschaft(en) für das/die Antriebsrad(e) basieren.
Bei allen offengelegten Fahrzeugen, Systemen und Verfahren kann das CNN-Backbone die zugeschnittenen Bilder analysieren, um eine oder mehrere Geländemerkmale für die Geländeoberfläche des Geländes zu bestimmen. Die Geländemerkmale können einen Geländetyp (z. B. Sand, Schlamm, Asphalt, Felsen usw.) und/oder einen Geländezustand (z. B. nass, trocken, eisig, schneebedeckt, locker/gefüllt usw.) umfassen. Als weitere Option kann das CNN-Backbone die zugeschnittenen Bilder analysieren, um ein oder mehrere Hindernismerkmale für ein Hindernis zu bestimmen, das den Weg des Kraftfahrzeugs versperrt. Das Hindernismerkmal kann eine Hindernishöhe relativ zu einer Radhöhe der Antriebsräder und/oder einer Karosseriehöhe des Fahrzeugaufbaus umfassen. Die Vorhersage des Auftretens eines Fahrereignisses kann zumindest teilweise auf der/den Geländecharakteristik(en) des Geländes und/oder der/den Hindernischarakteristik(en) des Hindernisses basieren.
Für jedes der offengelegten Fahrzeuge, Systeme und Verfahren kann die Verarbeitung von Kameradaten Folgendes umfassen: Analysieren eines Einzelbildes des ROI für jedes von der Kamera erzeugte Bild unabhängig von den anderen Bildern, um dem Antriebsrad und/oder der Geländeoberfläche, die in dem Bild enthalten sind, ein Merkmal zuzuordnen; und Erzeugen eines Situationshinweises über das CNN-Backbone unter Verwendung mehrerer Task-Heads auf der Grundlage der ROI-Analyse, der auf das Merkmal hinweist und über ein Situationsklassifizierungsmodul ausgewertet werden kann, das zur Vorhersage des Auftretens eines Fahrvorfalls dient. Als weitere Option kann die Verarbeitung von Kameradaten Folgendes umfassen: Analysieren aufeinanderfolgender Bilder des ROI über das CNN-Backbone für alle von der Kamera erzeugten Bilder, um im Bild enthaltene Merkmale des Antriebsrads und/oder der Geländeoberfläche zu extrahieren; Verknüpfen der von der Kamera erzeugten Bilder in einer Serie oder Kette unter Verwendung eines Verkettungsmoduls; und Extrahieren zeitlicher Informationen für jedes der von der Kamera erzeugten Bilder über ein rekursives neuronales Netz (RNN).
Bei allen offengelegten Fahrzeugen, Systemen und Verfahren kann das Kameranetz eine Unterbodenkamera umfassen, die an der Fahrzeugkarosserie in der Nähe eines Fahrgestells des Fahrzeugs angebracht ist. Diese Unterbodenkamera kann so betrieben werden, dass sie nach außen gerichtete, nach unten gerichtete Ansichten der Fahrzeugkarosserie erfasst und entsprechende Signale erzeugt. Als weitere Option können die vom CAN-Bus abgerufenen Fahrzeugdynamikdaten Fahrzeugrolldaten, Fahrzeugnickdaten, Fahrzeuggierdaten, Fahrzeugquer- und - längsgeschwindigkeitsdaten, Fahrzeugquer- und -längsbeschleunigungsdaten, Raddrehzahldaten, Lenkwinkeldaten usw. umfassen. In diesem Zusammenhang können die vom CAN-Bus abgerufenen Daten über die Betriebseigenschaften des Fahrzeugs Daten über die Drosselklappenstellung, die Bremskraft, den Status der Feststellbremse, die Betriebsart des Antriebsstrangs, die Aufhängungshöhe usw. enthalten.
Bei allen offengelegten Fahrzeugen, Systemen und Verfahren umfasst das von der Systemsteuerung befehligte System des Fahrzeugs ein Modul für die autonome Fahrsteuerung (ADC), das zur Automatisierung des Fahrens des Kraftfahrzeugs eingesetzt werden kann. In diesem Fall kann der Steuerungsvorgang die Automatisierung eines oder mehrerer Fahrmanöver des Kraftfahrzeugs umfassen, die zumindest teilweise auf dem vorhergesagten Auftreten des Fahrvorfalls basieren. Eine weitere Möglichkeit ist, dass das Fahrzeugsystem ein Fahrzeuglenksystem, ein Fahrzeugbremssystem und/oder einen Fahrzeugantriebsstrang umfasst. In diesem Fall kann der Steuerungsvorgang einen virtuellen oder menschlichen Assistenten umfassen, der ein Lenkmanöver, einen Bremsvorgang und/oder eine Drehmomentausgabe des Antriebsstrangs zumindest teilweise auf der Grundlage des vorhergesagten Auftretens des Fahrvorfalls steuert. Optional kann das Fahrzeugsystem ein Fahrzeugnavigationssystem mit einer Anzeigevorrichtung umfassen. In diesem Fall kann das Anzeigegerät des Navigationssystems eine Warnung mit einem korrigierenden Fahrmanöver anzeigen, um das Auftreten der Fahrstörung zu verhindern.
Die obige Zusammenfassung soll nicht jede Ausführungsform oder jeden Aspekt der vorliegenden Offenbarung darstellen. Vielmehr stellt die vorstehende Zusammenfassung lediglich eine beispielhafte Darstellung einiger der hier dargelegten neuen Konzepte und Merkmale dar. Die obigen Merkmale und Vorteile sowie andere Merkmale und damit verbundene Vorteile dieser Offenbarung werden aus der folgenden detaillierten Beschreibung der abgebildeten Beispiele und repräsentativen Modi zur Ausführung der vorliegenden Offenbarung in Verbindung mit den beigefügten Zeichnungen und den beigefügten Ansprüchen leicht ersichtlich. Darüber hinaus schließt diese Offenbarung ausdrücklich alle Kombinationen und Unterkombinationen der oben und unten dargestellten Elemente und Merkmale ein.
Figurenliste

1 ist eine teilweise schematische Seitenansicht eines repräsentativen Kraftfahrzeugs mit einem Netzwerk aus fahrzeuginternen Steuergeräten, Sensorvorrichtungen und Kommunikationsvorrichtungen zum Austausch von Daten mit einem intelligenten Fahrzeugnavigationssystem für die Vorhersage von Fahrunfällen in Geländebereichen gemäß den Aspekten der vorliegenden Offenbarung.
2 zeigt nach vorne, zur Seite und nach unten gerichtete perspektivische Ansichten eines Kraftfahrzeugs, die von Front-, Links-, Rechts- und Unterbodenkameras an der Karosserie in Übereinstimmung mit den Aspekten der vorliegenden Offenbarung aufgenommen wurden.
3 ist ein schematisches Diagramm, das ein repräsentatives intelligentes Fahrzeugnavigationssystem zeigt, das eine Vorhersage von Zwischenfällen im Gelände und eine Unterstützung für Kraftfahrzeuge in Übereinstimmung mit den Aspekten der offenbarten Konzepte bietet.
4 ist ein Flussdiagramm, das ein repräsentatives Protokoll zur Vorhersage von Fahrereignissen (Bildklassifikator + Situationsklassifikator) für Kraftfahrzeuge darstellt, das gespeicherten Anweisungen entsprechen kann, die von einem stationären oder entfernten Steuergerät, einer Steuerlogikschaltung, einer programmierbaren Steuereinheit oder einer anderen integrierten Schaltung (IC) oder einem Netzwerk von Geräten in Übereinstimmung mit Aspekten der offenbarten Konzepte ausgeführt werden können.
5 ist ein Flussdiagramm, das ein weiteres repräsentatives Protokoll zur Vorhersage von Fahrereignissen (End-to-End-Training) für Kraftfahrzeuge zeigt, das gespeicherten Anweisungen entsprechen kann, die von einem stationären oder entfernten Steuergerät, einer Steuerlogikschaltung, einer programmierbaren Steuereinheit oder einer anderen integrierten Schaltung (IC) oder einem Netzwerk von Geräten in Übereinstimmung mit Aspekten der offenbarten Konzepte ausgeführt werden können.

Die vorliegende Offenbarung ist für verschiedene Modifikationen und alternative Formen zugänglich, und einige repräsentative Ausführungsformen sind beispielhaft in den Zeichnungen dargestellt und werden hier im Detail beschrieben. Es sollte jedoch verstanden werden, dass die neuen Aspekte dieser Offenbarung nicht auf die besonderen Formen beschränkt sind, die in den oben aufgezählten Zeichnungen dargestellt sind. Vielmehr soll die Offenbarung alle Modifikationen, Äquivalente, Kombinationen, Unterkombinationen, Permutationen, Gruppierungen und Alternativen abdecken, die in den Anwendungsbereich dieser Offenbarung fallen, wie sie zum Beispiel von den beigefügten Ansprüchen umfasst werden.
DETAILLIERTE BESCHREIBUNG
Diese Offenbarung kann in vielen verschiedenen Formen verwirklicht werden. Repräsentative Ausführungsformen der Offenbarung sind in den Zeichnungen dargestellt und werden hier im Detail beschrieben, wobei davon ausgegangen wird, dass diese Ausführungsformen als Beispiel für die offengelegten Prinzipien dienen und keine Einschränkungen der allgemeinen Aspekte der Offenbarung darstellen. Insofern sollten Elemente und Beschränkungen, die z. B. in den Abschnitten „Zusammenfassung“, „Einleitung“, „Zusammenfassung“ und „Detaillierte Beschreibung“ beschrieben, aber nicht ausdrücklich in den Ansprüchen dargelegt sind, nicht in die Ansprüche aufgenommen werden, weder einzeln noch insgesamt, weder durch Implikation noch durch Schlussfolgerung noch auf andere Weise.
Für die Zwecke der vorliegenden detaillierten Beschreibung gilt, sofern nicht ausdrücklich ausgeschlossen: Der Singular schließt den Plural ein und umgekehrt; die Wörter „und“ und „oder“ gelten sowohl im Konjunktiv als auch im Disjunktiv; die Wörter „jeder“ und „alle“ bedeuten „jeder und alle“; und die Wörter „einschließlich“, „enthaltend“, „umfassend“, „mit“ und dergleichen bedeuten jeweils „einschließlich ohne Einschränkung“. Darüber hinaus können Wörter der Annäherung wie „ungefähr“, „fast“, „im Wesentlichen“, „im Allgemeinen“, „ungefähr“ und dergleichen hier im Sinne von „bei, nahe oder fast bei“ oder „innerhalb von 0-5 % von“ oder „innerhalb akzeptabler Herstellungstoleranzen“ oder einer beliebigen logischen Kombination davon verwendet werden. Schließlich können sich richtungsbezogene Adjektive und Adverbien wie vorwärts, achtern, innen, außen, steuerbord, backbord, vertikal, horizontal, aufwärts, abwärts, vorne, hinten, links, rechts usw. auf ein Kraftfahrzeug beziehen, z. B. auf die Vorwärtsfahrtrichtung eines Kraftfahrzeugs, wenn das Fahrzeug auf einer horizontalen Fahrfläche betrieben wird.
Unter Bezugnahme auf die Zeichnungen, in denen sich gleiche Referenznummern auf gleiche Merkmale in den verschiedenen Ansichten beziehen, ist in 1 ein repräsentatives Automobil dargestellt, das allgemein mit 10 bezeichnet und hier zu Diskussionszwecken als Limousine mit Elektroantrieb dargestellt wird. Das dargestellte Automobil 10 - hier auch kurz als „Kraftfahrzeug“ oder „Fahrzeug“ bezeichnet - ist lediglich eine beispielhafte Anwendung, mit der neue Aspekte dieser Offenbarung praktiziert werden können. In gleicher Weise sollte die Einbindung der vorliegenden Konzepte in einen vollelektrischen Fahrzeug-Antriebsstrang als eine nicht-begrenzende Umsetzung der offenbarten Merkmale verstanden werden. Es versteht sich von selbst, dass Aspekte und Merkmale dieser Offenbarung auch auf andere Antriebsstrangkonfigurationen angewendet werden können, für jeden logisch relevanten Fahrzeugtyp implementiert werden können und durch andere intelligente Systemarchitekturen bereitgestellt werden können. Darüber hinaus werden hier nur ausgewählte Komponenten der Kraftfahrzeuge und Fahrzeugsteuerungssysteme gezeigt und näher beschrieben. Nichtsdestotrotz können die im Folgenden beschriebenen Fahrzeuge und Fahrzeugsysteme zahlreiche zusätzliche und alternative Merkmale und andere verfügbare periphere Komponenten enthalten, um die verschiedenen Verfahren und Funktionen dieser Offenbarung auszuführen.
Das repräsentative Fahrzeug 10 von 1 ist ursprünglich mit einer Fahrzeugtelekommunikations- und -informationseinheit („Telematik“) 14 ausgestattet, die drahtlos, z. B. über Mobilfunkmasten, Basisstationen, mobile Vermittlungsstellen, Satellitendienste usw., mit einem entfernten oder „Off-Board“-Cloud-Computing-Hostdienst 24 (z. B. OnStar®) kommuniziert. Einige der anderen Fahrzeug-Hardwarekomponenten 16, die in 1 allgemein dargestellt sind, umfassen als nicht einschränkende Beispiele ein elektronisches Videoanzeigegerät 18, ein Mikrofon 28, Audio-Lautsprecher 30 und verschiedene Benutzereingabesteuerungen 32 (z. B. Tasten, Knöpfe, Pedale, Schalter, Touchpads, Joysticks, Touchscreens usw.). Diese Hardwarekomponenten 16 fungieren zum Teil als Mensch-Maschine-Schnittstelle (HMI), um dem Benutzer die Kommunikation mit der Telematikeinheit 14 und anderen Systemkomponenten im Fahrzeug 10 zu ermöglichen. Das Mikrofon 28 bietet einem Fahrzeuginsassen die Möglichkeit, verbale oder andere akustische Befehle einzugeben; das Fahrzeug 10 kann mit einer integrierten Sprachverarbeitungseinheit ausgestattet sein, die Audiofilter-, -bearbeitungs- und -analysemodule verwendet. Umgekehrt liefern die Lautsprecher 30 eine akustische Ausgabe für einen Fahrzeuginsassen und können entweder ein eigenständiger Lautsprecher sein, der für die Verwendung mit der Telematikeinheit 14 bestimmt ist, oder sie können Teil eines Audiosystems 22 sein. Das Audiosystem 22 ist operativ mit einer Netzwerkverbindungsschnittstelle 34 und einem Audiobus 20 verbunden, um analoge Informationen zu empfangen und sie über eine oder mehrere Lautsprecherkomponenten als Ton wiederzugeben.
Mit der Telematikeinheit 14 kommunikativ gekoppelt ist eine Netzwerkverbindungsschnittstelle 34, zu deren geeigneten Beispielen Twisted-Pair-/Glasfaser-Ethernet-Switches, parallele/serielle Kommunikationsbusse, LAN-Schnittstellen (Local Area Network), CAN-Schnittstellen (Controller Area Network), MOST-Schnittstellen (Media-Oriented System Transfer), LIN-Schnittstellen (Local Interconnection Network) und dergleichen gehören. Andere geeignete Kommunikationsschnittstellen können solche sein, die den ISO-, SAE- und/oder IEEE-Normen und -Spezifikationen entsprechen. Die Netzwerkverbindungsschnittstelle 34 ermöglicht es der Fahrzeughardware 16, Signale untereinander und mit verschiedenen Systemen und Subsystemen sowohl innerhalb der Fahrzeugkarosserie 12 als auch außerhalb der Fahrzeugkarosserie 12 zu senden und zu empfangen. Auf diese Weise kann das Fahrzeug 10 verschiedene Fahrzeugfunktionen ausführen, wie z. B. die Modulation der Antriebsstrangleistung, die Steuerung des Fahrzeuggetriebes, die selektive Aktivierung der Reibungs- und regenerativen Bremssysteme, die Steuerung der Fahrzeuglenkung, die Regelung der Ladung und Entladung der Fahrzeugbatteriemodule und andere automatisierte Fahrfunktionen. Die Telematikeinheit 14 empfängt und sendet beispielsweise Signale und Daten an/von einem Antriebsstrang-Steuermodul (PCM) 52, einem ADAS-Modul (Advanced Driver Assistance System) 54, einem elektronischen Batteriesteuermodul (EBCM) 56, einem Lenkungssteuermodul (SCM) 58, einem Bremssystem-Steuermodul (BSCM) 60 und verschiedenen anderen Steuergeräten des Fahrzeugs, wie z. B. einem Getriebesteuermodul (TCM), einem Motorsteuermodul (ECM), einem Sensorsystem-Schnittstellenmodul (SSIM), usw.
Wie in 1 dargestellt, ist die Telematikeinheit 14 eine fahrzeuginterne Recheneinheit, die sowohl einzeln als auch über ihre Kommunikation mit anderen vernetzten Geräten eine Reihe von Diensten bereitstellt. Diese Telematikeinheit 14 besteht im Allgemeinen aus einem oder mehreren Prozessoren 40, von denen jeder als diskreter Mikroprozessor, als anwendungsspezifischer integrierter Schaltkreis (ASIC) oder als spezielles Steuermodul ausgeführt sein kann. Das Fahrzeug 10 kann eine zentrale Fahrzeugsteuerung über eine zentrale Verarbeitungseinheit (CPU) 36 bieten, die mit einer Echtzeituhr (RTC) 42 und einem oder mehreren elektronischen Speichergeräten 38 verbunden ist, die jeweils die Form einer CD-ROM, einer Magnetplatte, eines IC-Geräts, eines Flash-Speichers, eines Halbleiterspeichers (z. B. verschiedene Arten von RAM oder ROM) usw. haben können.
Fahrzeugkommunikationsfähigkeiten mit großer Reichweite zu entfernten, vernetzten Geräten außerhalb des Fahrzeugs können über einen oder mehrere oder alle Chipsätze/Komponenten für Mobilfunk, Chipsätze/Komponenten für Navigation und Ortung (z. B. GPS-Sender/Empfänger) oder ein drahtloses Modem bereitgestellt werden, die alle zusammen unter 44 dargestellt sind. Die drahtlose Verbindung im Nahbereich kann über ein drahtloses Kurzstrecken-Kommunikationsgerät 46 (z. B. eine Bluetooth®-Einheit oder einen NFC-Sender/Empfänger), eine DSRC-Komponente (dedicated short-range communications) 48 und/oder eine Doppelantenne 50 erfolgen. Es versteht sich von selbst, dass das Fahrzeug 10 ohne eine oder mehrere der oben aufgeführten Komponenten implementiert werden kann oder optional zusätzliche Komponenten und Funktionen enthalten kann, wie für eine bestimmte Endanwendung gewünscht. Die verschiedenen oben beschriebenen Kommunikationsvorrichtungen können so konfiguriert sein, dass sie Daten als Teil einer periodischen Übertragung in einem Fahrzeug-zu-Fahrzeug (V2V)-Kommunikationssystem oder einem Fahrzeug-zu-Alles (V2X)-Kommunikationssystem austauschen, z.B. Fahrzeug-zu-Infrastruktur (V2I), Fahrzeug-zu-Fußgänger (V2P), Fahrzeug-zu-Gerät (V2D), usw.
Die CPU 36 empfängt Sensordaten von einer oder mehreren Erfassungsvorrichtungen, die z. B. Fotodetektion, Radar, Laser, Ultraschall, Optik, Infrarot oder andere geeignete Technologien, einschließlich Kurzstreckenkommunikationstechnologien (z. B. DSRC) oder Ultra-Wide-Band (UWB)-Funktechnologien, verwenden, um einen automatisierten Fahrbetrieb oder einen Fahrzeugnavigationsdienst auszuführen. Gemäß dem gezeigten Beispiel kann das Fahrzeug 10 mit einer oder mehreren Digitalkameras 62, einem oder mehreren Entfernungssensoren 64, einem oder mehreren Fahrzeuggeschwindigkeitssensoren 66, einem oder mehreren Fahrzeugdynamiksensoren 68 und der erforderlichen Filter-, Klassifizierungs-, Fusions- und Analysehardware und -software zur Verarbeitung von Sensorrohdaten ausgestattet sein. Die Art, Platzierung, Anzahl und Interoperabilität der verteilten Anordnung von Fahrzeugsensoren kann einzeln oder gemeinsam an eine bestimmte Fahrzeugplattform angepasst werden, um ein gewünschtes Niveau des autonomen Fahrzeugbetriebs zu erreichen.
Die digitale(n) Kamera(s) 62 kann/können einen ladungsgekoppelten Sensor (CCD-Sensor) oder einen anderen geeigneten optischen Sensor verwenden, um Bilder zu erzeugen, die ein Sichtfeld des Fahrzeugs 10 anzeigen, und kann/können für eine kontinuierliche Bilderzeugung konfiguriert werden, z. B. für mindestens etwa 35+ Bilder pro Sekunde. Zum Vergleich: Der/die Entfernungssensor(en) 64 kann/können reflektierte Funk-, Infrarot-, Licht- oder andere elektromagnetische Signale (z. B. Kurzstreckenradar, Langstreckenradar, induktive EM-Sensorik, Light Detection and Ranging (LIDAR) usw.) aussenden und erfassen, um z. B. das Vorhandensein, die geometrischen Abmessungen und/oder die Nähe eines Zielobjekts zu erkennen. Der/die Fahrzeuggeschwindigkeitssensor(en) 66 kann/können verschiedene Formen annehmen, einschließlich Raddrehzahlsensoren, die die Raddrehzahlen messen, die dann zur Bestimmung der Fahrzeuggeschwindigkeit in Echtzeit verwendet werden. Darüber hinaus kann es sich bei dem/den Fahrzeugdynamiksensor(en) 68 um einen ein- oder dreiachsigen Beschleunigungssensor, einen Drehratensensor, einen Neigungssensor usw. zur Erfassung von Längs- und Querbeschleunigung, Gier-, Roll- und/oder Nickraten oder anderen dynamikbezogenen Parametern handeln. Anhand der Daten von den Sensorvorrichtungen 62, 64, 66, 68 identifiziert die CPU 36 die Fahrbedingungen in der Umgebung, bestimmt die Fahrbahneigenschaften und die Oberflächenbeschaffenheit, identifiziert Zielobjekte innerhalb eines Erfassungsbereichs des Fahrzeugs, bestimmt Attribute des Zielobjekts, wie Größe, relative Position, Ausrichtung, Abstand, Annäherungswinkel, relative Geschwindigkeit usw., und führt auf der Grundlage dieser ausgeführten Operationen automatische Steuermanöver aus.
Diese Sensoren können über das gesamte Kraftfahrzeug 10 verteilt sein, und zwar in funktionsfähigen, ungehinderten Positionen in Bezug auf die Sicht nach vorn oder nach hinten oder auf der Backbord- oder Steuerbordseite des Fahrzeugs. Jeder Sensor erzeugt elektrische Signale, die ein Merkmal oder einen Zustand des Basisfahrzeugs oder eines oder mehrerer Zielobjekte anzeigen, im Allgemeinen als Schätzwert mit einer entsprechenden Standardabweichung. Die Betriebscharakteristiken dieser Sensoren sind im Allgemeinen komplementär, aber einige sind bei der Schätzung bestimmter Parameter zuverlässiger als andere. Die meisten Sensoren haben unterschiedliche Reichweiten und Erfassungsbereiche und sind in der Lage, verschiedene Parameter innerhalb ihres Arbeitsbereichs zu erfassen. Ein radargestützter Sensor kann beispielsweise die Reichweite, die Entfernungsrate und die Azimutposition eines Objekts schätzen, ist aber nicht unbedingt zuverlässig bei der Schätzung der Ausdehnung eines erkannten Objekts. Kameras mit optischer Verarbeitung hingegen können die Form und die Azimutposition eines Objekts besser einschätzen, sind aber weniger effizient bei der Schätzung der Reichweite und der Entfernungsrate eines Zielobjekts. Ein LIDAR-Sensor mit Abtastung kann bei der Schätzung von Entfernung und Azimutposition effizient und genau arbeiten, ist aber möglicherweise nicht in der Lage, die Entfernungsrate genau zu schätzen, und kann daher bei der Erfassung/Erkennung neuer Objekte nicht genau sein. Ultraschallsensoren hingegen können zwar die Reichweite abschätzen, sind aber im Allgemeinen nicht in der Lage, die Entfernungsrate und die Azimutposition genau zu bestimmen. Außerdem kann die Leistung vieler Sensortechnologien durch unterschiedliche Umgebungsbedingungen beeinflusst werden. Folglich weisen die Sensoren im Allgemeinen parametrische Abweichungen auf, deren Überschneidungen Möglichkeiten für eine Sensorfusion bieten.
Ein Sensorfusions-Steuermodul kann einen Fusionsalgorithmus in Verbindung mit zugehörigen gespeicherten Kalibrierungsinformationen ausführen, um Sensordaten von verfügbaren Sensoren zu empfangen, die Daten in brauchbare Schätzungen und Messungen zu gruppieren und die gruppierten Beobachtungen zu fusionieren, um beispielsweise die Fahrspurgeometrie und relative Zielpositionsschätzungen zu bestimmen. Der Fusionsalgorithmus kann jede geeignete Sensorfusionsmethode verwenden, wie z. B. Kalman-Filtering (KF)-Fusionsanwendungen. Eine KF-Anwendung kann verwendet werden, um korrelative Merkmale jedes Ziels entlang einer zeitlichen Achse zu untersuchen (z. B. unter der Annahme, dass sich ein verfolgtes Ziel über einen vordefinierten Zeitraum gleichmäßig bewegt). Ebenso kann eine KF-Anwendung räumliche Korrelationen erfassen, nämlich die relative Position jedes Zielobjekts zum Basisfahrzeug, wie sie von mehreren Sensoren beobachtet wird. Weitere Informationen zur Sensordatenfusion finden sich im US-Patent Nr. 7.460.951 B2 von Osman D. Altan et al., auf das hier in vollem Umfang und für alle Zwecke Bezug genommen wird.
Um das elektrisch angetriebene Fahrzeug 10 anzutreiben, ist ein elektrifizierter Antriebsstrang in der Lage, ein Zugmoment zu erzeugen und an ein oder mehrere Räder 26 des Fahrzeugs zu übertragen. Der Antriebsstrang wird in 1 im Allgemeinen durch ein wiederaufladbares Energiespeichersystem (RESS) dargestellt, das in Form eines am Fahrgestell montierten Traktionsbatteriepakets 70 vorliegen kann, das mit einem elektrischen Traktionsmotor 78 verbunden ist. Das Traktionsbatteriepaket 70 besteht im Allgemeinen aus einem oder mehreren Batteriemodulen 72, die jeweils einen Stapel von Batteriezellen 74 aufweisen, z. B. Lithium-Ionen-, Lithium-Polymer- oder Nickel-Metallhydrid-Batteriezellen des Beutel-, Dosen- oder prismatischen Typs. Eine oder mehrere elektrische Maschinen, wie z. B. Fahrmotor-/Generatoreinheiten (M) 78, nehmen elektrische Energie aus dem RESS-Batteriesatz 70 auf und liefern optional elektrische Energie an diesen. Ein spezielles Wechselrichtermodul (PIM) 80 verbindet den Batteriesatz 70 elektrisch mit der/den Motor-/Generatoreinheit(en) 78 und moduliert die Übertragung des elektrischen Stroms zwischen diesen Einheiten. Die vorgestellten Konzepte sind in ähnlicher Weise auf HEV- und ICE-basierte Antriebsstrangarchitekturen anwendbar.
Der Batteriesatz 70 kann so konfiguriert werden, dass die Funktionen für die Modulverwaltung, die Zellenerfassung und die Kommunikation von Modul zu Modul oder von Modul zu Host direkt in jedes Batteriemodul 72 integriert sind und drahtlos über eine drahtlos arbeitende Zellenüberwachungseinheit (CMU) 76 erfolgen. Bei der CMLJ 76 kann es sich um eine Mikrocontroller-basierte, auf einer Leiterplatte (PCB) montierte Sensoranordnung handeln. Jede CMU 76 kann über einen GPS-Transceiver und RF-Fähigkeiten verfügen und kann auf oder in einem Batteriemodulgehäuse untergebracht sein. Die Batteriemodulzellen 74, die CMU 76, das Gehäuse, die Kühlmittelleitungen, die Stromschienen usw. bilden zusammen die Zellmodulbaugruppe.
Wie oben erwähnt, kann das Kraftfahrzeug 10 von 1 mit einer am Körper angebrachten Sensoranordnung ausgestattet sein, die kontinuierlich „Echtzeit“-Sensordaten zur Durchführung von unterstützten oder automatisierten Fahrzeugfunktionen ausgibt. Als nicht einschränkendes Beispiel kann die digitale(n) Kamera(s) 62 von 1 als ein verteiltes Netzwerk von digitalen Videokameras 102 (hier auch als „Kamera-Sensor-System“ oder „CSS“ bezeichnet) ausgeführt sein, die um den Umfang der Fahrzeugkarosserie 12 herum angebracht sind. In Übereinstimmung mit dem dargestellten Beispiel wird das Netzwerk von Kameras 102 mit einer vorderen (ersten) Kamera 120 dargestellt, die in der Nähe eines vorderen Endes der Fahrzeugkarosserie 12 (z. B. an einer vorderen Kühlergrillabdeckung) angebracht ist, und einer hinteren (zweiten) Kamera, die in der Nähe eines hinteren Endes der Fahrzeugkarosserie (z. B. an einer hinteren Hecktür, Heckklappe oder einem Kofferraumdeckel) angebracht ist. Das Fahrzeugkamerasensorsystem 102 kann auch eine Backbordkamera (dritte Kamera) 122, die in der Nähe einer linken Seite der Fahrzeugkarosserie 12 (z. B. integriert in eine Rückspiegelbaugruppe auf der Fahrerseite) angebracht ist, und eine Steuerbordkamera (vierte Kamera) 124, die in der Nähe einer rechten Seite der Fahrzeugkarosserie 12 (z. B. integriert in eine Rückspiegelbaugruppe auf der Beifahrerseite) angebracht ist, verwenden.
Eine Unterbodenkamera (fünfte Kamera) 126 wird in der Nähe eines Unterbodens der Fahrzeugkarosserie 12 (z. B. an einem Seitenholm oder Querträger des Fahrgestells) angebracht. Die Kameras 102 von 2 können aus einer beliebigen Anzahl, Art und Anordnung von Bilderfassungsvorrichtungen bestehen, von denen jede mit einem CMOS-Sensor (Complementary Metal-Oxide-Semiconductor), einem CCD-Sensor (Charge-Coupled Device) oder einem anderen geeigneten APS-Sensor (Active-Pixel-Sensor) hergestellt werden kann. Art, Anordnung, Anzahl und Interoperabilität der verteilten Anordnung von Fahrzeugsensoren können einzeln oder gemeinsam an eine bestimmte Fahrzeugplattform angepasst werden, um ein gewünschtes Maß an Genauigkeit bei der Erfassung von Zielobjekten, der Erkennung von Gefahren am Unterboden oder dem autonomen Betrieb des Fahrzeugs zu erreichen.
Unter weiterer Bezugnahme auf das in 2 dargestellte Beispiel erfasst die Frontkamera 120 nach vorne gerichtete Echtzeitansichten des Fahrzeugs (z. B. ein nach außen gerichtetes Sichtfeld vor einer vorderen Stoßfängerbaugruppe), während die Heckkamera nach hinten gerichtete Echtzeitansichten des Fahrzeugs erfasst (z. B. ein nach außen gerichtetes Sichtfeld hinter einer hinteren Stoßfängerbaugruppe). In gleicher Weise erfasst die linke Seitenkamera 122 in Echtzeit Ansichten der Backbordseite des Fahrzeugs 10 (z. B. ein nach außen gerichtetes Sichtfeld quer zu einer fahrerseitigen Türbaugruppe), während die rechte Seitenkamera 124 in Echtzeit Ansichten der Steuerbordseite des Fahrzeugs erfasst (z. B. ein nach außen gerichtetes Sichtfeld quer zu einer beifahrerseitigen Türbaugruppe). Die Unterbodenkamera 126 erfasst in Echtzeit nach unten gerichtete Ansichten der Fahrbahnoberfläche und eines oder mehrerer Antriebsräder 26 (z. B. ein außen liegendes Sichtfeld vom Fahrzeugunterboden). Jede Kamera erzeugt und gibt Signale aus, die ihre jeweilige Ansicht anzeigen. Diese Signale können direkt von den Kameras oder von einer Speichervorrichtung abgerufen werden, die für den Empfang, die Sortierung und die Speicherung solcher Daten zuständig ist.
Innerhalb der jeweiligen Kameraansicht jeder Kamera 120, 122, 124, 126 ist ein fester Interessenbereich (ROI) definiert, der zur verbesserten Erkennung von Gefahren am Unterboden und zur Vorhersage von Fahrereignissen verwendet wird. Ein ROI kann als ein abgegrenzter Kamerarahmenbereich bezeichnet werden, der in eine der von der Kamera erzeugten Ansichten des Fahrzeugs eingefügt und an einer vordefinierten Stelle innerhalb dieser Kameraansicht fixiert ist. Als Beispiel und ohne Einschränkung wird ein nach vorne gerichteter (erster) ROI 121 in die nach vorne gerichtete Fahrzeugansicht eingefügt, die von der Frontkamera 120 erfasst wird, während ein linksseitiger (zweiter) ROI 123 in die nach links gerichtete Fahrzeugansicht eingefügt wird, die von der Backbordkamera 122 erfasst wird. Im Vergleich dazu wird ein rechtsseitiger (dritter) ROI 125 in die nach rechts gerichtete Fahrzeugansicht eingefügt, die von der Steuerbordkamera 124 erfasst wird, während ein unterirdischer (vierter) ROI 127 in die nach unten gerichtete Fahrzeugansicht eingefügt wird, die von der Unterbodenkamera 126 erfasst wird. Bei diesen ROIs kann es sich um fahrzeugkalibrierte Merkmale handeln, die speziell für ein bestimmtes Host-Fahrzeug definiert sind. Die ROIs können beispielsweise auf der Marke/dem Modell/der Ausstattung des Fahrzeugs, den jeweiligen Montageorten der Kameras, dem Sichtbereich/-winkel jeder Kamera und/oder einem vordefinierten Schutzbereich um das Fahrzeug (z. B. einem Geofence, der 20 cm von allen Außenflächen entfernt ist) basieren. Ein ROI kann „definiert“ werden, indem der Parameter aus einer im internen Speicher gespeicherten Nachschlagetabelle abgerufen wird, indem der Parameter während der anfänglichen Kalibrierung des Fahrzeugs berechnet wird, indem der Parameter durch verfügbare modellbasierte Techniken geschätzt wird oder durch andere geeignete Bestimmungsverfahren.
3 zeigt ein schematisches Diagramm eines beispielhaften intelligenten Fahrzeugnavigationssystems (IVN) 200 zur Bereitstellung von Navigations- und Notfalldiensten für ein verteiltes Netzwerk von Fahrzeugen, neben anderen Funktionen. Obwohl ein einzelnes Cloud-Computing-Host-Service-System 224 dargestellt ist, das mit einem einzelnen Kraftfahrzeug 210 und einem einzelnen Fernassistenten 250 kommuniziert, ist vorgesehen, dass eine beliebige Anzahl von Host-Computing-Diensten (z. B. Cloud-, Edge-, verteilte, serverlose Dienste usw.) mit einer beliebigen Anzahl von Fahrzeugen und einer beliebigen Anzahl von Drittparteien zusammen mit ihren zugehörigen Rechenknoten, die für den drahtlosen Datenaustausch geeignet sind, kommunizieren kann. Obwohl sie sich in ihrer Erscheinung unterscheiden, ist vorgesehen, dass alle oben unter Bezugnahme auf das Fahrzeug 10 und den Host-Dienst 24 von 1 beschriebenen Merkmale und Optionen einzeln oder in beliebiger Kombination in das Host-Fahrzeug 210 und den Cloud-Computing-Host-Dienst 224 von 3 integriert werden können und umgekehrt.
Der Cloud-Computing-Hostdienst 224 von 3 ist über ein drahtloses Kommunikationsnetz 252 mit jedem Kraftfahrzeug 210 und jeder Drittpartei 250 kommunikativ verbunden (z. B. wie oben in Bezug auf die Telematikeinheit 14 von 1 beschrieben). Bei dem Netzwerk 252 kann es sich um jede verfügbare Art von Netzwerk handeln, einschließlich einer Kombination aus öffentlichen verteilten Computernetzwerken (z. B. Internet) und gesicherten privaten Netzwerken (z. B. lokales Netzwerk, Weitverkehrsnetzwerk, virtuelles privates Netzwerk). Es kann auch drahtlose und drahtgebundene Übertragungssysteme umfassen (z. B. Satelliten, Mobilfunknetze, terrestrische Netze usw.). Der drahtlose Datenaustausch zwischen dem Fahrzeug 210 und dem Host-Dienst 224 kann direkt erfolgen - in Konfigurationen, in denen das Fahrzeug 210 als eigenständiges drahtloses Gerät ausgestattet ist - oder indirekt - durch Koppeln und Huckepackmachen des Fahrzeugs 210 mit einem drahtlosfähigen Gerät, wie einem Smartphone, einer Smartwatch, einem tragbaren GPS-Sender/Empfänger, einem Laptop usw. Es ist auch denkbar, dass der Host-Dienst 224 direkt mit einem persönlichen Computergerät eines Fahrers oder Insassen des Fahrzeugs 210 kommuniziert und somit auf die direkte Kommunikation mit dem Fahrzeug 210 verzichtet oder diese ergänzt. Eine weitere Option ist, dass viele der vom Host-Dienst 224 bereitgestellten Dienste in das Kraftfahrzeug 210 integriert werden können, und umgekehrt.
Unter weiterer Bezugnahme auf 3 kann das System des Cloud-Computing-Host-Dienstes 224 durch ein Hochgeschwindigkeits-Rechengerät der Serverklasse 254 oder einen Großrechner implementiert werden, der in der Lage ist, Massendatenverarbeitung, Ressourcenplanung und Transaktionsverarbeitung zu handhaben. Beispielsweise kann der Host-Dienst 224 als Host in einer Client-Server-Schnittstelle zur Durchführung des erforderlichen Datenaustauschs und der Kommunikation mit einem oder mehreren Servern oder Geräten von „Dritten“ fungieren, um eine bestimmte Transaktion abzuschließen. Alternativ kann der Cloud-Computing-Hostdienst 224 als Middleware für IoT- (Internet der Dinge), WoT- (Web der Dinge), Vehicle-to-Everything- (V2X) und/oder M2M- (Machine-to-Machine-) Dienste fungieren, z. B. zur Verbindung einer Reihe von Geräten mit einer serviceorientierten Architektur (SOA). Beispielsweise kann der Host-Dienst 224 als Middleware-Knoten implementiert werden, um verschiedene Funktionen für das dynamische Einbinden von Geräten, das Multiplexen von Daten von jedem Gerät und das Weiterleiten der Daten durch eine rekonfigurierbare Verarbeitungslogik zur Verarbeitung und Übertragung an eine oder mehrere Zielanwendungen bereitzustellen.
Das IVN-System 200 bietet Vorhersage und Unterstützung für ein oder mehrere Fahrzeuge 210 bei Fahrszenarien im Gelände. Die Vorhersage des Auftretens eines Unfalls im Gelände erfolgt durch einen KI-gesteuerten Modelllernprozess, der selbstüberwacht ist und mit Daten von teilnehmenden Fahrzeugen, die im Gelände fahren, trainiert wird. Der Host-Server 254 oder ein residentes Fahrzeugsteuermodul kann das Modell ausführen - in 3 dargestellt durch Novel Classifier 258 - während eine Back-Office-Datenbank (DB) 256 Daten von Kundenfahrzeugen sammelt und kommentiert, um das Modell kontinuierlich zu verbessern/trainieren. Während der Fahrt im Gelände kann das Host-Fahrzeug alle N-Sekunden Daten aufzeichnen und diese an eine zentrale Datenbank übermitteln, wenn kein Zwischenfall eingetreten ist (No-Emergency Samples). Wird dagegen über das Infotainmentsystem des Fahrzeugs ein Notruf an eine Notrufnummer abgesetzt, kann das Fahrzeug Daten über den Vorfall aufzeichnen und an eine zentrale Datenbank übermitteln (Notrufstichproben). Wird über das Infotainment-System des Fahrzeugs ein Notruf abgesetzt und das Wort „stecken bleiben“ oder „Hilfe“ gesagt (oder ein beliebiges Wort aus einem vordefinierten Wörterbuch, das auf einen Fahrunfall hindeutet), kann das Fahrzeug Unfalldaten aufzeichnen und an eine zentrale Datenbank übermitteln. Die „No-Emergency Samples“ und „Emergency Samples“ werden zusammen mit den entsprechenden Verhaltensdaten in 3 als „End Off-Road Trip data 201“ dargestellt.
Das Modell lernt, einen Verkehrsunfall, einschließlich Notfällen und Nicht-Notfällen, vorherzusagen, bevor er eintritt, und hilft dabei, Maßnahmen zu ergreifen, um den Unfall innerhalb eines vorhergesagten Zeithorizonts zu vermeiden. Wie nachstehend bei der Erörterung der in den 4 und 5 dargestellten MI,-Techniken erläutert wird, können die Modelleingaben Folgendes umfassen (1) serielle (CAN-)Daten: Gas, Bremskraft, Feststellbremse, Fahrzeugdynamik (Roll-, Nick-, Gier-, Quer-/Längsgeschwindigkeit, Quer-/Längsbeschleunigung), Raddrehzahl, Fahrzeuglast, Aufhängungshöhe, Lenkwinkel usw.; (2) Kameradaten: Quer-, Längs- und Unterbodenbilder, 360°-Ansicht° usw.; (3) Daten aus der Fahrergeschichte: Fahrverhalten in Geländeszenarien, Tendenz zur Überschreitung der Geländefähigkeiten usw.; (4) Daten von Entfernungssensoren: RADAR-, LiDAR- und/oder Ultraschallsensordaten; und (5) andere Daten: Telemetrie, Wetter, topografische Karte, ortsbezogene Historie (Wahrscheinlichkeit eines Zwischenfalls in relevanten Koordinaten) usw. In 3 können diese Eingaben gemeinsam als heruntergeladene Reisedaten 203 (z. B. vor der Geländefahrt auf das Fahrzeug heruntergeladen), Online-Reisedaten 205 (z. B. während der Geländefahrt gesammelt), DB-Daten, die von der Host-Service-Datenbank 256 abgerufen wurden, und Fahrzeug-Fahrdaten, die vom Fahrerverhaltensmodul 260 gesammelt wurden, dargestellt werden. Aus diesen Eingaben kann ein tief lernendes neuronales Netzwerk innerhalb des Modells Folgendes ableiten: (1) Art der Geländeoberfläche: Sand, Schlamm, Asphalt, Felsen, Wasser usw.; (2) Zustand der Geländeoberfläche: nass, verschneit, trocken, eisig, lose/gepackt usw.; (3) Reifenzustand: Reifen eingegraben, was zu einem Kontakt zwischen Rahmen und Boden führt, Reifen vom Boden abgehoben usw.; und (4) Reifenzustand: voll mit Schlamm oder anderen Hindernissen, niedriges Reifenprofil, niedriger Luftdruck, Verlust anderer normaler Betriebsmerkmale usw. Es ist denkbar, dass mehr, weniger oder andere Eingaben und Ausgaben in den Modelllernprozess der 3-5 einbezogen werden.
Nach der Analyse der Eingabedaten und der daraus abgeleiteten Daten durch den ML-basierten Vorhersager für Unfälle im Gelände kann er eine Bewertung für Unfälle im Straßenverkehr ausgeben, die die Wahrscheinlichkeit eines Unfalls im Straßenverkehr angibt. Bei der Unfallvorhersage kann ein binäres Modell nur eine Ja- oder Nein-Antwort ausgeben, z. B. eine Systemwarnung mit dem Hinweis auf einen künftigen Notfall oder ein Erinnerungsflag mit dem Hinweis auf keinen Notfall. Wenn ein Unfall prognostiziert wird, kann der Fahrer aufgefordert werden, eine Reihe von Maßnahmen zu ergreifen, um den prognostizierten Unfall zu verhindern. Wenn diese Maßnahmen bereits vom System erlernt wurden (Entscheidungsblock 207 = JA), können die Maßnahmen aus dem internen Speicher abgerufen und dem Fahrer über die Mensch-Maschine-Schnittstelle 262 oder automatisch durch ein fahrzeuginternes ADAS- oder ADC-Modul angezeigt werden. Wenn diese Maßnahmen nicht bereits vom System erlernt wurden (Entscheidungsblock 207=NEIN), können die Abhilfemaßnahmen durch den Host-Dienst 224 oder den Fernassistenten 250 bereitgestellt werden. Alternativ kann ein entfernter Dritter - sei es ein virtueller oder ein menschlicher Assistent - vorübergehend den Betrieb des Fahrzeugs übernehmen oder dem Fahrzeug computerausführbare Anweisungen für unterstützte oder autonome Abhilfemaßnahmen geben.
Zur Erleichterung der fachkundigen Fernunterstützung können dem Fernassistenten 250 Telemetriedaten, Kameradaten, Topographiedaten (z. B. 3D-Vernetzung der Oberfläche unter dem Host-Fahrzeug 210) usw. zur Verfügung gestellt werden, die über das Uplink-Datenpaket 209 an den Fernassistenten 250 hochgeladen werden. Die Oberflächentopografie kann als eine kartografische Darstellung der relativen Verteilung und der dreidimensionalen (3D) Merkmale natürlicher und künstlicher Merkmale eines bestimmten Oberflächenbereichs bezeichnet werden. Solche Topographiedaten können für zuvor kartierte Gebiete aus dem internen oder externen Speicher abgerufen werden oder für zuvor nicht kartierte Gebiete in Echtzeit generiert werden. Beispielsweise kann eine Anwendung zur simultanen Lokalisierung und Kartierung (SLAM) eingesetzt werden, um in überschaubarer Zeit eine 3D-Karte (z. B. ein topologisches Modell, ein digitales Höhenmodell oder ein Netzmodell) einer Umgebung zusammen mit Geolokalisierungsinformationen zu erstellen, wobei Algorithmen der Computergeometrie und Computer-Vision-Daten verwendet werden. Die Kameradaten, die dem Fernassistenten 250 zur Verfügung gestellt werden, können Einzelbilder, aufeinanderfolgende Bilder, sphärische Kameraansichten oder andere hier beschriebene Kameradaten enthalten. Bei einem Host-Fahrzeug 10 (1) mit einem Mehrgeräte-Kamera-Sensor-System 102 (2) können sich beispielsweise die Sichtfelder der Kameras überschneiden; diese Kameraansichten können aggregiert, vorverarbeitet, zusammengefügt, korrigiert und als eine einzige „sphärische Ansicht“ rekonstruiert werden, die das Sichtfeld aller verfügbaren Kameras abdeckt. Im gezeigten Beispiel kann die kugelförmige Ansicht eine halbkugelförmige 360-Grad-Ebene abdecken, die Front-, Seiten-, Heck- und Unterbodenansichten enthält.
Unter Bezugnahme auf die Flussdiagramme von 4 und 5 werden verbesserte Verfahren oder Steuerstrategien für die ML-basierte Erkennung von Fahrvorfällen für ein Host-Fahrzeug, wie z. B. das Fahrzeug 10 von 1, unter Verwendung einer verteilten Anordnung von Sensoren, wie z. B. CSS 102 von 2, und eines intelligenten Navigationssystems, wie z. B. IVN-System 200 von 3, im Allgemeinen bei 300 und 400 in Übereinstimmung mit Aspekten der vorliegenden Offenbarung beschrieben. Einige oder alle der in den 4 und 5 dargestellten und nachstehend näher beschriebenen Vorgänge können Algorithmen darstellen, die prozessorausführbaren Anweisungen entsprechen, die beispielsweise im Haupt- oder Hilfs- oder Fernspeicher (z. B, (z. B. Speichervorrichtung 38 von 1 und/oder Datenbank 256 von 3) gespeichert sind und z. B. von einem elektronischen Controller, einer Verarbeitungseinheit, einer Logikschaltung oder einem anderen Modul oder einer Vorrichtung oder einem Netzwerk von Modulen/Geräten (z. B. CPU 36 und/oder Cloud-Computing-Dienst 224) ausgeführt werden, um eine oder alle der oben und unten beschriebenen Funktionen auszuführen, die mit den offenbarten Konzepten verbunden sind. Es sollte anerkannt werden, dass die Reihenfolge der Ausführung der dargestellten Operationsblöcke geändert werden kann, zusätzliche Operationsblöcke können hinzugefügt werden, und einige der beschriebenen Operationen können modifiziert, kombiniert oder eliminiert werden.
Die Verfahren 300 und 400 beginnen an den Startklemmenblöcken 301 bzw. 401 mit im Speicher abgelegten, prozessorausführbaren Anweisungen für ein programmierbares Steuergerät oder ein Steuermodul oder einen ähnlich geeigneten Prozessor, um eine Initialisierungsprozedur für ein Protokoll zur Vorhersage von Notfällen abseits der Straße aufzurufen. Diese Routine kann in Echtzeit, nahezu in Echtzeit, kontinuierlich, systematisch, sporadisch und/oder in regelmäßigen Abständen ausgeführt werden, beispielsweise alle 10 oder 100 Millisekunden während des normalen und laufenden Betriebs des Kraftfahrzeugs 10. Als weitere Option kann der Terminalblock 301 als Reaktion auf eine Benutzerbefehlseingabe, eine Eingabeaufforderung durch ein residentes Fahrzeugsteuergerät oder ein Broadcast-Eingabesignal initialisiert werden, das von einem zentralisierten „Off-Board“-Fahrzeugdienstsystem (z. B. Host-Cloud computing service 24) empfangen wird. Beispielsweise können die Verfahren 300, 400 automatisch initialisiert werden, wenn ein elektronisches Systemsteuergerät Geolokalisierungsdaten des Fahrzeugs empfängt, die anzeigen, dass das betreffende Host-Fahrzeug im Begriff ist, ein Gelände zu befahren oder sich gerade im Gelände befindet. Nach Abschluss der in den 4 und 5 dargestellten Steuervorgänge können die Verfahren 300, 400 zu den Endklemmenblöcken 315 bzw. 415 weitergehen und vorübergehend beendet werden oder optional zu den Klemmenblöcken 301, 401 zurückkehren und in einer Dauerschleife laufen.
Das Verfahren 300 von 4 geht vom Anschlussblock 301 zum Sensordateneingabeblock 303 über, um Bilddaten von einer oder mehreren oder allen fahrzeugseitigen Sensorvorrichtungen eines Host-Fahrzeugs zu erfassen. Unter nochmaliger Bezugnahme auf die Beispiele in 1 und 2 kann die Fahrzeug-CPU 36 das CSS 102 auffordern, die Abfrage der Kameras 120, 122, 124, 126 zu starten, um Echtzeit-Bilddaten für ihr jeweiliges Sichtfeld zu erfassen und entsprechende Signale zu übertragen. Jedes Kamerabild kann eines oder mehrere der Antriebsräder des Fahrzeugs (z. B. die Straßenräder 26), eine Oberflächenansicht des darunter liegenden Geländes, eine perspektivische Ansicht eines behindernden Zielobjekts (z. B. Felsbrocken, Baumstamm, Schlammpfütze usw.) und/oder einen anderen gewünschten Inhalt enthalten.
Nach dem Sammeln aller erforderlichen Sensordaten im Sensordaten-Eingabeblock 303 führt das Verfahren 300 ein computerautomatisiertes Bildbeschneidungsverfahren 305 aus, z. B. um überflüssige oder unwesentliche Objekte aus einem von einer Kamera erzeugten Bild zu entfernen. Wie oben in Bezug auf die Erörterung von 2 erwähnt, kann CSS 102 aktiv eine Region von Interesse 121, 123, 125, 127 definieren oder passiv identifizieren, die in eine vordefinierte Position des Sichtfelds jeder Kamera 120, 122, 124, 126 eingefügt und dort fixiert ist. Jedes Kamerabild kann dann beschnitten werden, um Bilddaten außerhalb des ROI zu entfernen und dadurch beschnittene Kamerabilder zu erzeugen. 4 zeigt zwei repräsentative beschnittene Kamerabilder: ein Bild 305a des vorderen Antriebsrads auf der Fahrerseite und der Kontaktfläche sowie ein Bild 305b des vorderen Antriebsrads auf der Beifahrerseite und der Kontaktfläche. Ebenfalls ausgewertet wird ein nicht beschnittenes Unterboden-Kamerabild 305c einer Vorderachse, der vorderen Antriebsräder und des darunter liegenden Geländes.
Das Verfahren 300 geht von der Bildbeschneidungsprozedur 305 zu einem Bildklassifizierungsmodul 307 über, das ein konvolutionales neuronales Netzwerk (Convolutional Neural Network, CNN)-Backbone implementiert, um Fahrzeugsensordaten zu analysieren und daraus ein oder mehrere Situationsmerkmale für ein Offroad-Fahrszenario eines Host-Fahrzeugs abzuleiten. Der Begriff „Backbone“ kann so definiert werden, dass er ein vortrainiertes neuronales Netzwerk mit tiefem Lernvermögen umfasst, das die Aufgabe hat, ausgewählte Bilddaten als Eingabe zu verwenden und daraus eine Merkmalskarte zu extrahieren, auf der der Rest des Netzwerks basiert. Bei einem DeepLab-Modell für die Computervision berechnet das Merkmalsextraktionsnetz vordefinierte Merkmale aus den eingegebenen Bilddaten und führt dann ein „Upsampling“ dieser Merkmale durch ein einfaches Decodermodul durch, um segmentierte Masken zur Klassifizierung von Bildern zu erzeugen. Das Bildklassifizierungsmodul 307 kann ein einzelnes, gemeinsames Backbone (z. B. Resnet CNN-Backbone) und mehrere Task-Heads zur Durchführung von Bildklassifizierungsaufgaben verwenden. Die Implementierung mehrerer Ausgänge in einem einzigen Backbone-Netzwerk hilft dem ML-Trainingsprozess, sich auf Merkmale zu konzentrieren, die erkennbar „starke visuelle“ Informationen enthalten, anstatt das Modell einfach zu stark an den Trainingsdatensatz anzupassen. Die Architektur des Netzes kann sich aus dem CNN-Backbone, der allgemeine Merkmale extrahiert, und den CNN-Köpfen zusammensetzen, die Klassifizierungsaufgaben durchführen (z. B. klassifiziert jeder Kopf eine andere Kategorie). Das CNN-Backbone kann zu Beginn des Netzes eine Reihe von Schichten enthalten; die Architektur des Backbone kann als offene Frage konstruiert werden, die für die Bildklassifizierungsaufgabe gut geeignet ist. Kamerabilder können unabhängig voneinander für den ROI jedes Rads und für das gesamte Unterbodenbild analysiert werden (z. B. kann ein Bildklassifizierer ein einzelnes Bild als Eingabe nehmen und die Situation für dieses Bild mit Hilfe des CNN-Backbone und mehrerer Aufgabenköpfe charakterisieren); die resultierenden Daten werden dann als Anhaltspunkte für die Situationsklassifizierung weitergegeben.
Mit weiterem Bezug auf 4 gibt das Bildklassifizierungsmodul 307 situative Hinweise 309 an ein Situationsklassifizierungsmodul 311 aus, das darauf trainiert ist, vorherzusagen, ob ein Fahrvorfall innerhalb eines Vorhersagezeithorizonts auftreten wird oder nicht. Wie oben in der Diskussion von 3 erläutert, implementiert das Bildklassifizierungsmodul 307 das CNN-Backbone, um Folgendes abzuleiten: eine oder mehrere Antriebsradcharakteristiken für das (die) Antriebsrad (-räder) des Host-Fahrzeugs (z. B. Radhöhe über dem Boden Kopf 309b, Radlenkwinkelkopf 309e usw.), eine oder mehrere Geländecharakteristiken ), eine oder mehrere Geländemerkmale für das zu bewertende Gelände (z. B. Geländetyp Kopf 309a, Schlamm-/Wasserhöhe relativ zum Rad Kopf 309d) und/oder ein oder mehrere Hindernismerkmale für ein Hindernis, das die Bewegung des Host-Fahrzeugs behindert (z. B. Hindernishöhe relativ zum Rad Kopf 309c). Andere Eingaben, die vom Situationsklassifizierungsmodul 311 für die Vorhersage von Fahrereignissen verwendet werden, können andere Fahrzeugsensordaten 309f und serielle (CAN) Daten 309g umfassen. Im Befehlsaufforderungsblock 313 gibt das Verfahren 300 eine künftige Notfall/Nicht-Notfall-Bestimmung 313a und für einen vorhergesagten Fahrvorfall eine oder mehrere „optimale“ Aktionen 313b aus, um den Fahrvorfall zu verhindern (z. B. Lenkwinkel, Gaspedaleingabe, Bremspedaleingabe usw.).
Im Gegensatz zu dem in 4 dargestellten MI,-Verfahren (Image Classifier + Situation Classifier) kann das Verfahren 400 ein MI,-Verfahren mit End-to-End-Training darstellen, bei dem das MI,basierte NN-System z. B. mit aufeinanderfolgenden Bildern aller verfügbaren Daten trainiert wird. Insbesondere können die Fahrzeugkameras einen Strom zeitlicher Daten erzeugen; diese zeitlichen Daten umfassen aufeinanderfolgende Bildrahmen und aufeinanderfolgende serielle (CAN) Daten. Jedes Kamerabild aller verfügbaren Kameras kann durch ein neuronales Faltungsnetzwerk als Grundlage für die Merkmalsextraktion geleitet werden. Unter Verwendung eines rekursiven neuronalen Netzes (RNN) 411 behält das System die Zustandsinformationen bei und aktualisiert sie, während es nacheinander neue Bild- und Seriendaten annimmt. Ähnlich wie bei der Methode 300 in 4 wird bei dem Verfahren 400 in 5 ein CNN-Backbone verwendet, um Merkmale aus den Kamerabildern zu extrahieren; das RNN empfängt und analysiert diesen Datensatz zur Vorhersage von Ereignissen. In diesem Fall bedeutet das Training des „vollständigen Systems von Anfang bis Ende“ jedoch, dass das CNN-Backbone nicht für eine andere Aufgabe vortrainiert und eingefroren wird; vielmehr werden ein Trainingssatz und stochastischer Gradientenabstieg verwendet, um das CNN-Backbone 407 und das RNN 411 gemeinsam zu trainieren.
Nach der Initialisierung des Protokolls für die Notfallvorhersage im Gelände am Startterminal 401 führt das Verfahren 400 ein Modul 405 zur Merkmalsextraktion aus, wobei zunächst Sensordaten vom Fahrzeug CSS 102 am Sensordateneingangsblock 403 empfangen werden (z. B. wie oben in Bezug auf den Sensordateneingangsblock 303 beschrieben). Die empfangenen Kamerasensordaten werden Bild für Bild durch ein CNN-Backbone 407 geleitet. Da jedes Bild als „sehr hochdimensional“ angesehen werden kann (z. B. hat ein 3-Megapixel-Bild 3 Millionen Werte), von denen ein Bruchteil „bedeutungsvolle Informationen“ enthalten kann, versucht der Klassifikator, nur die bedeutungsvollen Informationen zu isolieren, während der Rest als „Rauschen“ außer Acht gelassen wird. „Das CNN-Backbone 407 extrahiert mithilfe eines selbstlernenden neuronalen Netzes informative Merkmale aus jedem Bild.
Das Verfahren 400 geht weiter zu einem Verkettungsmodul 409, um die von Kameras erzeugten Bilder in einer Reihe oder Kette zu verknüpfen, so dass das RNN 411 zeitliche Informationen für jedes von einer Kamera erzeugte Bild extrahieren kann. Die Ausgabe des CNN-Backbone 407 für die von der CSS 102 kommenden Bilder kann durch eine Kamera j mit einem zugehörigen Vektor der Größe N [cj1, cj2, cj3, ..., cjN] dargestellt werden, während die seriellen CAN-Daten ein Vektor der Größe M [s1, a2, s3, ..., sM] sind. Bei der Verkettung fügt das Modul 409 die Vektoren zu einem einzigen langen Vektor zusammen. Wenn wir K Kameras haben, ist das Ergebnis der Verkettung ein einziger Vektor der Größe (K*N) + M, gebildet als [cl 1, c12,...,clN, c21, c22, ..., c2N, ..., cK1, cK2, ..., cKN, s1, s2, ..., sM]. Im Befehlsaufforderungsblock 413 gibt das Verfahren 400 in Block 413a entweder einen Indikator für einen künftigen Notfall oder einen Indikator für einen nicht erkannten Notfall aus. Wenn das System vorhersagt, dass innerhalb des vorhergesagten Zeithorizonts (z. B. in den nächsten 5 bis 8 Sekunden) ein Verkehrsunfall eintreten wird, kann das Verfahren 300 eine oder mehrere „optimale“ Maßnahmen 413b bestimmen, die dazu beitragen, den Verkehrsunfall zu verhindern.
Aspekte dieser Offenbarung können in einigen Ausführungsformen durch ein computerausführbares Programm von Anweisungen, wie z. B. Programmmodulen, implementiert werden, die allgemein als Softwareanwendungen oder Anwendungsprogramme bezeichnet werden und von einem beliebigen Steuergerät oder den hier beschriebenen Steuerungsvarianten ausgeführt werden. Software kann, in nicht einschränkenden Beispielen, Routinen, Programme, Objekte, Komponenten und Datenstrukturen umfassen, die bestimmte Aufgaben ausführen oder bestimmte Datentypen implementieren. Die Software kann eine Schnittstelle bilden, die es dem Computer ermöglicht, entsprechend einer Eingabequelle zu reagieren. Die Software kann auch mit anderen Codesegmenten zusammenarbeiten, um als Reaktion auf empfangene Daten in Verbindung mit der Quelle der empfangenen Daten eine Vielzahl von Aufgaben auszulösen. Die Software kann auf einer Vielzahl von Speichermedien wie CD-ROM, Magnetplatte und Halbleiterspeicher (z. B. verschiedene Arten von RAM oder ROM) gespeichert werden.
Darüber hinaus können Aspekte der vorliegenden Offenbarung mit einer Vielzahl von Computersystem- und Computernetzkonfigurationen praktiziert werden, einschließlich Multiprozessorsystemen, mikroprozessorbasierter oder programmierbarer Unterhaltungselektronik, Minicomputern, Großrechnern und dergleichen. Darüber hinaus können Aspekte der vorliegenden Offenbarung in verteilten Computerumgebungen angewandt werden, in denen Aufgaben von stationären und entfernten Verarbeitungsgeräten ausgeführt werden, die über ein Kommunikationsnetz verbunden sind. In einer Umgebung mit verteilter Datenverarbeitung können sich Programmmodule sowohl in lokalen als auch in entfernten Computerspeichermedien, einschließlich Speichergeräten, befinden. Aspekte der vorliegenden Offenbarung können daher in Verbindung mit verschiedener Hardware, Software oder einer Kombination davon in einem Computersystem oder einem anderen Verarbeitungssystem implementiert werden.
Jedes der hier beschriebenen Verfahren kann maschinenlesbare Anweisungen zur Ausführung durch (a) einen Prozessor, (b) eine Steuerung und/oder (c) eine andere geeignete Verarbeitungsvorrichtung enthalten: (a) einem Prozessor, (b) einem Steuergerät und/oder (c) jeder anderen geeigneten Verarbeitungsvorrichtung. Jeder hier offengelegte Algorithmus, jede Software, Steuerlogik, jedes Protokoll oder Verfahren kann als Software verkörpert sein, die auf einem greifbaren Medium gespeichert ist, wie z. B. einem Flash-Speicher, einem Solid-State-Drive-Speicher (SSD), einem Festplattenspeicher (HDD), einer CD-ROM, einer Digital Versatile Disk (DVD) oder anderen Speichergeräten. Der gesamte Algorithmus, die Steuerlogik, das Protokoll oder das Verfahren und/oder Teile davon können alternativ von einem anderen Gerät als einem Controller ausgeführt werden und/oder in Firmware oder dedizierter Hardware in einer verfügbaren Art und Weise verkörpert sein (z. B. implementiert durch eine anwendungsspezifische integrierte Schaltung (ASIC), ein programmierbares Logikgerät (PLD), ein feldprogrammierbares Logikgerät (FPLD), diskrete Logik usw.). Obwohl spezifische Algorithmen unter Bezugnahme auf die hier dargestellten Flussdiagramme und/oder Arbeitsablaufdiagramme beschrieben werden können, können alternativ auch viele andere Verfahren zur Implementierung der beispielhaften maschinenlesbaren Anweisungen verwendet werden.
Aspekte der vorliegenden Offenbarung wurden ausführlich unter Bezugnahme auf die abgebildeten Ausführungsformen beschrieben; der Fachmann wird jedoch erkennen, dass viele Modifikationen daran vorgenommen werden können, ohne vom Umfang der vorliegenden Offenbarung abzuweichen. Die vorliegende Offenbarung ist nicht auf die genaue Konstruktion und die hierin offengelegten Zusammensetzungen beschränkt; alle Modifikationen, Änderungen und Variationen, die aus den vorstehenden Beschreibungen ersichtlich sind, liegen im Rahmen der Offenbarung, wie sie durch die beigefügten Ansprüche definiert ist. Darüber hinaus schließen die vorliegenden Konzepte ausdrücklich alle Kombinationen und Unterkombinationen der vorangehenden Elemente und Merkmale ein.
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 7460951 B2 [0027]

Claims

Ein Verfahren zur Steuerung des Betriebs eines Kraftfahrzeugs mit einer Sensoranordnung, die ein Netzwerk von Kameras umfasst, die an diskreten Stellen des Kraftfahrzeugs angebracht sind, das Verfahren aufweisend: Empfangen von Fahrzeug-Geolokalisierungsdaten, die anzeigen, dass sich das Kraftfahrzeug in einem Gelände befindet oder in ein solches einfährt, über eine elektronische Systemsteuerung mittels einer drahtlosen Kommunikationsvorrichtung; Empfangen von Kameradaten über den Systemcontroller von der Sensoranordnung als Reaktion auf die Fahrzeug-Geolokalisierungsdaten, die auf Bilder hinweisen, die von den Kameras aufgenommen wurden und ein Antriebsrad des Kraftfahrzeugs und eine Geländeoberfläche des Off-Road-Geländes enthalten; Empfangen von Fahrzeugbetriebsdaten und Fahrzeugdynamikdaten für das Kraftfahrzeug über die Systemsteuerung von einem Controller Area Network (CAN)-Bus; Verarbeiten der Kameradaten, der Fahrzeugbetriebscharakteristikdaten und der Fahrzeugdynamikdaten über ein konvolutionales Netzwerk (CNN)-Backbone, um das Auftreten eines Fahrvorfalls auf dem Gelände innerhalb eines Vorhersagezeithorizonts vorherzusagen; und Übertragen eines Befehlssignals über die Systemsteuerung an ein residentes Fahrzeugsystem, um einen Steuervorgang als Reaktion auf das vorhergesagte Auftreten des Fahrvorfalls auszuführen.
Verfahren nach Anspruch 1, ferner aufweisend: Bestimmen eines Bereichs von Interesse (ROI), der in eine vordefinierte Stelle einer Kameraansicht jeder der Kameras eingefügt und dort fixiert ist; und Erzeugen von beschnittenen Kamerabildern durch Beschneiden jedes der von der Kamera erzeugten Bilder, um Bilddaten außerhalb des ROI zu entfernen.
Verfahren nach Anspruch 2, wobei die Verarbeitung der Kameradaten umfasst, dass das CNN-Backbone die ausgeschnittenen Bilder analysiert, um eine Radcharakteristik für das Antriebsrad des Kraftfahrzeugs zu bestimmen, wobei die Vorhersage des Auftretens des Fahrvorfalls auf der Radcharakteristik für das Antriebsrad basiert.
Verfahren nach Anspruch 3, bei dem die Radeigenschaft einen Verlust des Bodenkontakts, einen Zustand des Aussetzens des Hindernisses und/oder einen Verlust der normalen Betriebseigenschaften umfasst.
Verfahren nach Anspruch 2, wobei die Verarbeitung der Kameradaten einschließt, dass das CNN-Backbone die ausgeschnittenen Bilder analysiert, um eine Geländecharakteristik für die Geländeoberfläche des Geländes zu bestimmen, wobei die Vorhersage des Auftretens des Fahrvorfalls auf der Geländecharakteristik für die Geländeoberfläche basiert.
Verfahren nach Anspruch 5, wobei die Geländemerkmale einen Geländetyp und/oder einen Geländezustand umfassen.
Verfahren nach Anspruch 2, wobei die Verarbeitung der Kameradaten einschließt, dass das CNN-Backbone die zugeschnittenen Bilder analysiert, um ein Hindernismerkmal für ein Hindernis zu bestimmen, das das Fahren des Kraftfahrzeugs behindert, wobei die Vorhersage des Auftretens des Fahrvorfalls auf dem Hindernismerkmal für das Hindernis basiert.
Verfahren nach Anspruch 7, wobei das Hindernismerkmal eine Hindernishöhe relativ zu einer Radhöhe des Antriebsrads und/oder einer Karosseriehöhe einer Fahrzeugkarosserie des Kraftfahrzeugs umfasst.
Verfahren nach Anspruch 2, wobei die Verarbeitung der Kameradaten aufweist: Analysieren eines Einzelbildes des ROI für jedes der kameraerzeugten Bilder unabhängig voneinander, um dem Antriebsrad und/oder der Geländeoberfläche, die in dem kameraerzeugten Bild enthalten sind, eine Eigenschaft zuzuordnen; und Erzeugen, über das CNN-Backbone unter Verwendung mehrerer Aufgabenstellungen auf der Grundlage der ROI-Analyse, eines Situationshinweises, der auf das Merkmal hinweist und über ein Situationsklassifizierungsmodul ausgewertet werden kann, das das Auftreten des Fahrvorfalls vorhersagen kann.
Verfahren nach Anspruch 2, wobei die Verarbeitung der Kameradaten umfasst: Analyse von aufeinanderfolgenden Bildern der ROI über das CNN-Backbone für alle von der Kamera erzeugten Bilder, um Merkmale des Antriebsrads und/oder der Geländeoberfläche zu extrahieren, die in dem von der Kamera erzeugten Bild enthalten sind; Verknüpfung der von der Kamera erzeugten Bilder über ein Verkettungsmodul zu einer Serie oder Kette; und Extraktion der zeitlichen Informationen für jedes der von der Kamera erzeugten Bilder über ein rekursives neuronales Netz (RNN).