DE102018119110A1

DE102018119110A1 - Verfahren und vorrichtung für weitergeleitetes lokalisiertes video-sharing bei bedarf

Info

Publication number: DE102018119110A1
Application number: DE102018119110.3A
Authority: DE
Inventors: Michael McQuillen; Daniel A. Makled; Gopichandra Surnilla
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-08-08
Filing date: 2018-08-06
Publication date: 2019-02-14
Also published as: CN109391920A; US11589080B2; US20190052915A1

Abstract

Ein System beinhaltet einen Prozessor, der dazu konfiguriert ist, ein Anforderung von einem Host-Fahrzeug nach einem Video bezüglich eines in der Anforderung festgelegten Standorts zu empfangen. Der Prozessor ist zudem dazu konfiguriert zu bestimmen, ob ein Kandidat-Fahrzeug, das die Anforderung empfängt, das angeforderte Video bereitstellen kann, wenn die Anforderung empfangen wird. Der Prozessor ist ferner dazu konfiguriert, die Anforderung an einen Transceiver in drahtloser Kommunikation mit dem Kandidat-Fahrzeug weiterzuleiten, falls das Kandidat-Fahrzeug das angeforderte Video nicht bereitstellen kann, anderenfalls das angeforderte Video aufzuzeichnen und zu übertragen.

Description

TECHNISCHES GEBIET
Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen Verfahren und Vorrichtungen für weitergeleitetes lokalisiertes Video-Sharing bei Bedarf.
ALLGEMEINER STAND DER TECHNIK
Streckenplanung und Kartierung haben sich in den letzten Jahren deutlich verbessert. Kunden nutzen häufig Dienste, die Bilder eines konkreten Standorts bereitstellen, um sie zu einem Zielort zu führen oder sich mit einem Gebiet vertraut zu machen. Leider sind diese Bilder häufig statisch, sodass sie Punkte zu Zeiten darstellen, als die Kartierung erfolgte. Seit autonome Fahrzeuge, Fahrgemeinschaftsdienste und verbundene Autos immer beliebter werden, besteht ein erhöhter Wunsch danach, interessierende Gebiete in Echtzeit zu sehen.
Wenn derzeit ein Verkehrsstau einige Meilen voraus auftritt oder ein Baustellenbereich auf einer digitalen Karte erscheint, hat ein Benutzer fast keine Informationen über die Stockung zur Verfügung. Einige Kartendaten können erwartete Geschwindigkeitsbegrenzungen oder Verzögerungen angeben, aber häufig wird der Benutzer überhaupt nicht über die Art, Länge und Dauer der Verzögerung informiert.
Eine derzeitige Option ist, eine lokale Radiostation einzuschalten und eine Orientierung über die Art des Verkehrsproblems zu empfangen. Natürlich stellen nur sehr wenige lokale Radiostationen ständige Verkehrsaktualisierungen bereit, sodass der Fahrer eventuell fast eine Stunde warten muss, bevor er nützliche Informationen empfangen kann. Der Fahrer kann immer versuchen, ein Problem zu umfahren oder das Problem zu vermeiden, aber dadurch könnte der Fahrer viel Zeit vergeuden, um etwas zu vermeiden, was am Ende ein ziemlich kleines Problem war. Da die Informationen des Fahrers möglicherweise auf eine Karte begrenzt waren, die das Vorhandensein einer Stockung darstellt, hatte der Fahrer keine Möglichkeit zu wissen, wie schwer das Problem war.
KURZDARSTELLUNG
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, eine Anforderung von einem Host-Fahrzeug nach einem Video bezüglich eines in der Anforderung festgelegten Standorts zu empfangen. Der Prozessor ist zudem dazu konfiguriert zu bestimmen, ob ein Kandidat-Fahrzeug, das die Anforderung empfängt, das angeforderte Video bereitstellen kann, wenn die Anforderung empfangen wird. Der Prozessor ist ferner dazu konfiguriert, die Anforderung an einen Transceiver in drahtloser Kommunikation mit dem Kandidat-Fahrzeug weiterzuleiten, falls das Kandidat-Fahrzeug das angeforderte Video nicht bereitstellen kann, anderenfalls das angeforderte Video aufzuzeichnen und zu übertragen.
In einer zweiten veranschaulichten Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, eine Videoanforderung, einschließlich eines Standorts, von einem Host-Fahrzeug zu empfangen. Der Prozessor ist zudem dazu konfiguriert, auf eine Aufzeichnung von aktuellen Standorten eines Kandidat-Fahrzeugs zuzugreifen. Der Prozessor ist ferner dazu konfiguriert, ein Kandidat-Fahrzeug innerhalb einer vordefinierten Schwellenentfernung vom Standort auf Grundlage der Standorte des Kandidat-Fahrzeugs zu bestimmen. Der Prozessor ist zusätzlich dazu konfiguriert, eine Anweisung an das Kandidat-Fahrzeug zu senden, ein Video aufzuzeichnen. Der Prozessor ist ferner dazu konfiguriert, ein aufgezeichnetes Video von dem Kandidat-Fahrzeug zu empfangen und das aufgezeichnete Video an das Host-Fahrzeug zu senden.
In einer dritten Ausführungsform beinhaltet ein computerimplementiertes Verfahren Aufzeichnen eines Videos eines interessierenden Gebiets (area-of-interest - AOI) unter Verwendung einer Kamera eines Kandidat-Fahrzeugs als Reaktion auf eine Anforderung von einem Host-Fahrzeug, die durch drahtlose Übertragung an einem Kandidat-Fahrzeug, das die Kamera beinhaltet und die Aufzeichnung durchführt, empfangen wird. Das Verfahren beinhaltet zudem Übertragen des aufgezeichneten Videos an eine Vielzahl von Transceivern, die drahtlos mit dem Kandidat-Fahrzeug verbunden ist, und Übertragen der Anforderung an die Vielzahl von Transceivern als Reaktion auf Bestimmen, dass die Kamera des Kandidat-Fahrzeugs das AOI nicht länger sehen kann.
Figurenliste

1 zeigt ein veranschaulichendes Fahrzeugrechensystem;
2 zeigt einen veranschaulichenden Prozess zum Anfordern und Empfangen eines Videos auf Anfrage;
3 zeigt einen veranschaulichenden Prozess zur Quellfahrzeugauswahl;
4 zeigt einen veranschaulichenden Prozess zur Anforderungsbeendigung; und
5 zeigt einen veranschaulichenden Prozess zur Anforderungsaufrechterhaltung.

DETAILLIERTE BESCHREIBUNG
Wie erforderlich werden hierin ausführliche Ausführungsformen offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein veranschaulichender Natur sind und in verschiedenen und alternativen Formen ausgeführt werden können. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Einzelheiten bestimmter Komponenten zu zeigen. Dementsprechend sind hierin offenbarte konkrete strukturelle und funktionelle Einzelheiten nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um einen Fachmann eine vielfältige Ausführung des beanspruchten Gegenstands zu lehren.
1 veranschaulicht eine beispielhafte Blockstruktur für ein fahrzeugbasiertes Rechensystem 1 (Vehicle Based Computing System - VCS) für ein Fahrzeug 31. Ein Beispiel für ein derartiges fahrzeugbasiertes Rechensystem 1 ist das SYNC-System, hergestellt durch THE FORD MOTOR COMPANY. Ein mit einem fahrzeugbasierten Rechensystem ausgestattetes Fahrzeug kann eine visuelle Front-End-Schnittstelle 4 enthalten, welche im Fahrzeug positioniert ist. Der Benutzer kann zudem in der Lage sein, mit der Schnittstelle zu interagieren, wenn diese beispielsweise mit einem berührungsempfindlichen Bildschirm bereitgestellt ist. Bei einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch das Betätigen von Tasten, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
Bei der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 zumindest einen Teil des Betriebs des fahrzeugbasierten Rechensystems. Der in dem Fahrzeug bereitgestellte Prozessor ermöglicht die fahrzeuginterne Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nichtdauerhaftem Speicher 5 als auch dauerhaftem Speicher 7 verbunden. Bei dieser veranschaulichenden Ausführungsform handelt es sich bei dem nichtdauerhaften Speicher um einen Direktzugriffsspeicher (Random Access Memory - RAM) und bei dem dauerhaften Speicher um einen Festplattenspeicher (Hard Disk Drive - HDD) oder Flash-Speicher. Im Allgemeinen kann der dauerhafte (nichtflüchtige) Speicher alle Speicherformen beinhalten, die Daten behalten, wenn ein Computer oder eine andere Vorrichtung abgeschaltet wird. Diese beinhalten unter anderem HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und eine beliebige andere geeignete Form von dauerhaftem Speicher.
Der Prozessor ist zudem mit einer Reihe unterschiedlicher Eingänge versehen, die es dem Benutzer ermöglichen, über eine Schnittstelle mit dem Prozessor zu interagieren. Bei dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, Bildschirm 4, der eine Touchscreen-Anzeige sein kann, und ein BLUETOOTH-Eingang 15 bereitgestellt. Eine Eingangswähleinheit 51 ist ebenfalls bereitgestellt, damit ein Benutzer zwischen verschiedenen Eingängen wechseln kann. Eingaben sowohl an das Mikrofon als auch den Hilfsanschluss werden durch einen Wandler 27 von analog zu digital umgewandelt, bevor sie zum Prozessor weitergeleitet werden. Wenngleich nicht gezeigt, können viele der Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS in Kommunikation stehen, ein Fahrzeugnetzwerk (wie etwa unter anderem einen CAN-Bus) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) weiterzuleiten.
Ausgänge zum System können unter anderem eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Wandler 9 vom Prozessor 3. Eine Ausgabe kann zudem zu einer entfernten BLUETOOTH-Vorrichtung erfolgen, wie etwa PND 54 oder einer USB-Vorrichtung, wie etwa der Fahrzeugnavigationsvorrichtung 60, entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind.
Bei einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Transceiver 15, um (bei 17) mit der Mobilvorrichtung 53 eines Benutzers zu kommunizieren (z. B. einem Mobiltelefon, Smartphone, PDA oder einer beliebigen anderen WLAN-fähigen Vorrichtung). Die Mobilvorrichtung kann anschließend verwendet werden, um beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren (bei 59). Bei einigen Ausführungsformen kann es sich bei dem Mast 57 um einen WiFi-Zugangspunkt handeln.
Eine beispielhafte Kommunikation zwischen der Mobilvorrichtung und dem BLUETOOTH-Transceiver wird durch das Signal 14 wiedergegeben.
Das Koppeln einer Mobilvorrichtung 53 mit dem BLUETOOTH-Transceiver 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der fahrzeuginterne BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einer Mobilvorrichtung gekoppelt wird.
Zwischen der CPU 3 und dem Netzwerk 61 können Daten beispielsweise durch Verwendung eines Datentarifs, Daten über Sprache oder DTMF-Töne kommuniziert werden, die der Mobilvorrichtung 53 zugeordnet sind. Alternativ kann es wünschenswert sein, ein fahrzeuginternes Modem 63 einzubeziehen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren (bei 16). Die Mobilvorrichtung 53 kann anschließend verwendet werden, um beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren (bei 59). Bei einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 herstellen, um mit dem Netzwerk 61 zu kommunizieren. Als nicht einschränkendes Beispiel kann es sich bei dem Modem 63 um ein USB-Mobilfunkmodem und bei der Kommunikation 20 um eine Mobilfunkkommunikation handeln.
Bei einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API zum Kommunizieren mit einer Modemanwendungssoftware beinhaltet. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine Firmware auf dem BLUETOOTH-Transceiver zugreifen, um die drahtlose Kommunikation mit einem entfernten BLUETOOTH-Transceiver (wie etwa dem in einer Mobilvorrichtung) abzuschließen. Bei BLUETOOTH handelt es sich um eine Teilmenge der IEEE 802 PAN(Personal Area Network)-Protokolle. IEEE-802-LAN(Local Area Network)-Protokolle schließen WiFi ein und haben eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN. Beide eignen sich für die drahtlose Kommunikation in einem Fahrzeug. Ein weiteres Kommunikationsmittel, welches in diesem Bereich eingesetzt werden kann, ist die optische Freiraumkommunikation (wie etwa IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
In einer anderen Ausführungsform beinhaltet die Mobilvorrichtung 53 ein Modem zur Sprachband- oder Breitbanddatenkommunikation. Bei der Daten-über-Sprache-Ausführungsform kann eine Technik umgesetzt werden, welche als Frequenzmultiplexverfahren bekannt ist, wenn der Besitzer der Mobilvorrichtung bei gleichzeitiger Datenübertragung über die Vorrichtung sprechen kann. Zu anderen Zeitpunkten, wenn der Besitzer die Vorrichtung nicht verwendet, kann die gesamte Bandbreite (300 Hz bis 3,4 kHz bei einem Beispiel) für die Datenübertragung verwendet werden. Während das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet geläufig sein kann und nach wie vor verwendet wird, wurde es größtenteils durch Hybriden von Codemultiplexverfahren (CDMA), Zeitmultiplexverfahren (TDMA), Raummultiplexverfahren (SDMA) für digitale Mobilfunkkommunikation ersetzt. Ist die Mobilvorrichtung des Benutzers einem Datentarif zugeordnet, besteht die Möglichkeit, dass der Datentarif eine Breitbandübertragung ermöglicht, und das System könnte eine wesentlich größere Bandbreite nutzen (wodurch sich die Datenübertragungsgeschwindigkeit erhöht). Bei noch einer anderen Ausführungsform wird die Mobilvorrichtung 53 durch eine Mobilfunkkommunikationsvorrichtung (nicht gezeigt) ersetzt, welche im Fahrzeug 31 verbaut ist. Bei noch einer weiteren Ausführungsform kann die Mobilvorrichtung (Nomadic Device - ND) 53 eine Vorrichtung eines drahtlosen lokalen Netzwerks (LAN) sein, die beispielsweise (und ohne Einschränkung) über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk kommunizieren kann.
Bei einer Ausführungsform können ankommende Daten über Daten-über-Sprache oder einen Datentarif durch die Mobilvorrichtung, durch den fahrzeuginternen BLUETOOTH-Transceiver und in den internen Prozessor 3 des Fahrzeugs weitergeleitet werden. Im Falle bestimmter temporärer Daten können die Daten beispielsweise auf dem HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, welche eine Verbindung mit dem Fahrzeug herstellen können, sind eine persönliche Navigationsvorrichtung 54, beispielsweise mit einem USB-Anschluss 56 und/oder einer Antenne 58, eine Fahrzeugnavigationsvorrichtung 60 mit einem USB- 62 oder einem anderen Anschluss, eine fahrzeuginterne GPS-Vorrichtung 24 oder ein entferntes Navigationssystem (nicht gezeigt) mit Konnektivität zum Netzwerk 61. Bei USB handelt es sich um eines einer Klasse serieller Netzwerkprotokolle. Die seriellen Protokolle IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Gerät-zu-Gerät-Standards. Die Mehrheit der Protokolle kann entweder für elektrische oder optische Kommunikation umgesetzt werden.
Ferner könnte die CPU mit einer Vielfalt von anderen Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können über eine drahtlose 67 oder drahtgebundene 69 Verbindung verbunden sein. Die Hilfsvorrichtungen 65 können unter anderem persönliche Medienwiedergabevorrichtungen, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen beinhalten.
Zudem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, beispielsweise unter Verwendung eines WLAN-(IEEE 803.11)-Transceivers 71. Dies könnte es der CPU ermöglichen, sich mit Fernnetzwerken in Reichweite des lokalen Routers 73 zu verbinden.
Zusätzlich zur Ausführung beispielhafter Prozesse durch ein sich in einem Fahrzeug befindendes Fahrzeugrechensystem können die beispielhaften Prozesse bei bestimmten Ausführungsformen durch ein Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Kommunikation steht. Ein derartiges System kann unter anderem eine drahtlose Vorrichtung (z. B. unter anderem ein Mobiltelefon) oder ein entferntes Rechensystem (z. B. unter anderem einen Server) beinhalten, welches über die drahtlose Vorrichtung verbunden ist. Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Rechensysteme (Vehicle Associated Computing Systems - VACS) bezeichnet werden. Bei bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Prozesses ausführen, wobei dies von der konkreten Umsetzung des Systems abhängt. Wenn ein Prozess beispielsweise unter anderem einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, dann ist es wahrscheinlich, dass die drahtlose Vorrichtung diesen Teil des Prozesses nicht durchführt, da die drahtlose Vorrichtung Informationen nicht sich selbst bzw. von sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann versteht, wann es unangemessen ist, ein bestimmtes Rechensystem für eine gegebene Lösung anzuwenden.
Bei jeder der hier erörterten veranschaulichenden Ausführungsformen wird ein beispielhaftes, nicht einschränkendes Beispiel eines Prozesses gezeigt, der durch ein Rechensystem durchgeführt werden kann. In Bezug auf den jeweiligen Prozess kann das Rechensystem, das den Prozess ausführt, für den beschränkten Zweck der Ausführung des Prozesses als Spezialprozessor zum Durchführen des Prozesses konfiguriert sein. Alle Prozesse müssen nicht in ihrer Gesamtheit durchgeführt werden und sind als Beispiele von Prozesstypen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu verwirklichen. Zusätzliche Schritte können nach Bedarf zu den beispielhaften Prozessen hinzugefügt oder daraus entfernt werden.
In Bezug auf die veranschaulichenden Ausführungsformen, die in den veranschaulichende Prozessabläufe zeigenden Figuren beschrieben sind, ist anzumerken, dass ein Universalprozessor vorübergehend als Spezialprozessor zum Zwecke des Ausführens einiger oder aller der in diesen Figuren gezeigten beispielhaften Verfahren aktiviert werden kann. Wenn Code ausgeführt wird, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor erneut vorübergehend als Spezialprozessor eingesetzt werden, und zwar so lange, bis das Verfahren abgeschlossen ist. Bei einem anderen Beispiel kann, bis zu einem angemessenen Grad, Firmware, die in Übereinstimmung mit einem vorkonfigurierten Prozessor handelt, bewirken, dass der Prozessor als Spezialprozessor handelt, der zum Zwecke des Durchführens des Verfahrens oder einer angemessenen Variation davon bereitgestellt ist.
Auch wenn Verkehrshubschrauber und Verkehrskameras gelegentlich Quellen für Live-Verkehrsinformationen darstellen, sind diese Systeme in der Regel sehr lokalisiert und häufig wenig von Nutzen im Hinblick auf mehr als 90 % der vorhandenen Verzögerungsbedingungen auf der Straße. Ferner kann ein Fahrer in der Regel nicht einfach auf einen Verkehrsfeed oder einen Fernsehkanal zugreifen und somit ist ein von diesen Quellen bereitgestelltes Livevideo für einen Fahrer auf der Straße praktisch nutzlos.
Eine sehr gute Quelle für ein Livevideo ist eine Person vor Ort bei einem Zwischenfall mit einer Kamera, aber dies ist wiederum im Wesentlichen nutzlos für die meisten Fahrer, da die Fahrer keine Möglichkeit haben, den Live-Kamerafeed zu empfangen. Das heißt, selbst wenn eine Person anhalten würde und beginnen würde, einen Zwischenfall zu filmen, wäre nahezu niemand auf der Straße in der Lage, auf das Video zuzugreifen.
Viele moderne Fahrzeuge sind als Teil der Fahrzeugerfassungseinrichtungen mit bordeigenen, nach außen blickenden Kameras ausgestattet. Diese Kameras können als Teil von Fahrerassistenzsystemen fungieren, aber die Kameras können auch einem wichtigen Zweck in dem obigen Modell dienen. Durch Aufzeichnen eines Videos eines andauernden Zwischenfalls stellt das Fahrzeug eine Feedquelle mit einem bekannten Standort und einen Teil eines Kommunikationsnetzwerks (durch Telematik) bereit.
Wenn ein Benutzer auf den Videofeed des Fahrzeugs zugreifen kann, dann kann der Benutzer sehen, was das Fahrzeug sieht. Da die meisten Originalausrüstungshersteller (OEM) mit Erlaubnis des Fahrers auf Daten in Fahrzeugen zugreifen können, kann der OEM punktuelle Videoquellen (Fahrzeuge auf der Straße) verwenden, um ein Video anderen Kunden anzubieten.
Natürlich erfordert ein Video ein großes Maß an Bandbreite und Datenspeicher, sodass es nicht allzu effizient wäre, dass jedes Fahrzeug auf der Straße ständig einen andauernden Videofeed aufzeichnet, überträgt und speichert. Ferner besteht in der Regel wenig Interesse an zufälligen Straßenstücken, an denen gerade keine Zwischenfälle auftreten. Durch Verwenden eines bedarfsgesteuerten Modells können Fahrzeuge jedoch ein Video als Reaktion auf Anforderungen aufzeichnen, wodurch ein gezieltes Video von interessierenden Gebieten (AOI) vor Ort bereitgestellt wird.
Eine Methode setzt die Fähigkeit eines Herstellers, Fahrzeuge als Datenlieferanten zu lokalisieren und zu rekrutieren, wirksam ein. In diesem Beispiel wählt der OEM als Reaktion auf eine Anforderung nach einem Video vor Ort ein oder mehrere das Video bereitstellende Kandidat-Fahrzeuge aus und fordert Livefeeds von diesen Fahrzeugen an. Einer oder mehrere der Livefeeds können dann an das anfordernde Fahrzeug ausgelagert werden, wodurch eine Live-Videoabdeckung eines AOI bei Bedarf bereitgestellt wird.
Eine weitere Option verwendet dedizierte Kurzreichweitenkommunikations (dedicated short range communication - DSRC)-Transceiver und andere Fahrzeuge, um ein mobiles Netz oder ein Ad-Hoc-Netzwerk zu bilden, das eine Anforderung die Straße entlang von Fahrzeug zu Fahrzeug, von Transceiver zu Fahrzeug, von Fahrzeug zu Transceiver oder von Transceiver zu Transceiver weiterleitet. Wenn ausreichend Fahrzeuge zusammengeschlossen werden, kann eine sehr lange Netzwerkkette eingerichtet werden und könnte eine Anforderung einfach Meilen entfernt von einem Fahrer zu einem Standort, an dem gerade ein Zwischenfall auftritt, befördert werden. Auf Grundlage eines Standorts oder Gebiets, der bzw. das in der Anforderung angegeben ist, beginnt/beginnen ein lokales Fahrzeug oder lokale Fahrzeuge, wenn die Anforderung das angegebene Gebiet erreicht, ein Video als Reaktion auf die Anforderung aufzuzeichnen. Das Video wird dann in gleicher Weise zurück an das anfordernde Fahrzeug weitergeleitet (oder direkt über Telematik gesendet, falls dies bevorzugt ist). Solange die Netzwerkkette nicht unterbrochen wird, erreicht das Video schließlich das Zielfahrzeug.
In Netzwerken wie diesem ist eine kontinuierliche Konnektivität nicht notwendig, sofern nicht eine kontinuierliche Datenkommunikation verwendet wird. Da Fahrzeuge die Pakete speichern können, bis ein nächster Sprung in einem Netzwerk erreicht werden kann, kann ein einzelnes Fahrzeug, das ein Netzwerk (Gruppe von Fahrzeugen und Transceivern) verlässt und 20 Meilen weiter auf der Straße zu einem nächsten Netzwerk (Gruppe von Fahrzeugen und Transceivern) fährt, wirksam eine Einweg-Brücke zwischen den Netzwerken bilden, sogar wenn keines der Netzwerkobjekte eine Kommunikationsreichweite von mehr als 1000 Fuß o.ä. aufweist. Das fahrende Fahrzeug speichert einfach alle Datenpakete, während es mit dem ersten Netzwerk in Verbindung steht, fährt zum zweiten Netzwerk und leitet alle gespeicherten Pakete weiter.
Auch wenn eine Lücke ein ununterbrochenes Streaming verhindert, wird ein Ad-Hoc-Netzwerk ermöglicht, um im Wesentlichen alle Straßennetzwerke des Landes abzudecken, ohne dass alle 100 oder 1000 Fuß Zugangspunkte oder Relais physisch bereitgestellt werden müssen. Sogar wenn die Daten nicht direkt live sind (d. h. das Video zeigt, was 5 Minuten vorher geschehen ist im Gegensatz zu derzeitig), sind die Daten im Endeffekt sogar in einem Worst-Case-Szenario „live genug“ und stellen somit einem anfordernden Fahrer weit mehr Informationen bereit, als von einer relativ statischen Karte zu erlangen wären. Wenn ein ununterbrochener Datenfluss vorliegt (Fahrzeuge und Transceiver in ausreichend großer Nähe zwischen einer Datenquelle und einem anfordernden Fahrzeug), könnten die Daten fast in Echtzeit an den Anfordernden zurückgeleitet werden.
2 zeigt einen veranschaulichenden Prozess zum Anfordern und Empfangen eines Videos bei Bedarf. In diesem Beispiel fordert ein Benutzerfahrzeug (Host) bei 201 ein Video von einem Ziel-Standort an. Der Benutzer kann den Standort festlegen, indem er eine Kartenstelle, ein Kartengebiet, einen Verkehrsvorfall oder eine Stockung, einen Point-of-Interest (POI) usw. auswählt. Das Gebiet wird hierin der Einfachheit halber als ein interessierendes Gebiet (AOI) bezeichnet, auch wenn es ein Einzelpunktstandort sein könnte.
Das Host-Fahrzeug sendet dann bei 203 eine Anforderung nach einem Video durch ein DSRC-Netzwerk oder unter Verwendung eines Telematiksystems aus. Beide Optionen könnten gleichzeitig verwendet werden oder das Fahrzeug könnte eine bevorzugte Option wählen. Die Anforderung kann beispielsweise eine Host-Kennung, einen Host-Standort und das angegebene AOI beinhalten. Während der Benutzer einen Punkt oder Bereich festlegen kann, kann der Prozess wirksam Fahrzeuge einsetzen, von denen angenommen wird, dass sie in Sichtweite des AOI sind, sodass ein Fahrzeug, das auf die Anforderung reagiert, nicht notwendigerweise physisch an dem AOI oder Standort sein muss, um die Anforderung zu bedienen. Ein Schwellenumkreis und eine Kameraausrichtung (was die Kamera sehen kann) können durch einen Bestimmungsprozess verwendet werden, um ein konkretes Kandidat-Fahrzeug auszuwählen.
In dem gezeigten Telematikbeispiel verwendet der Prozess bei 205 ein Mobilfunknetzwerk (LTE-Netzwerk), um die Anforderung zu bedienen. Das Host-Fahrzeug sendet die Anforderung an einen Cloud-Server, wobei der Cloud-Server bei 207 ein oder mehrere Fahrzeuge innerhalb einer Schwellenentfernung von dem festgelegten AOI bestimmt. Der Cloud-Server kann unter anderem einen Stau (der niedrig liegende Kameras blockieren kann) und/oder Fahrzeugausrichtung berücksichtigen, wenn Kandidat-Fahrzeuge ausgewählt werden.
Sobald der Cloud-Server ein Kandidat-Fahrzeug bestimmt hat, sendet der Cloud-Server bei 209 die Anforderung an das bestimmte Kandidat-Fahrzeug. Das Fahrzeug empfängt die Anforderung, die auch einen Satz von Parametern, wie etwa beispielsweise Aufzeichnungszeit, AOI-Koordinaten usw., beinhalten kann. Das Fahrzeug kann die Parameter verwenden, um die Eignung des ausgewählten Kandidat-Fahrzeugs zu bestätigen und kann bei 211 gegebenenfalls einen Live-Kamerafeed zurücksenden. Falls der ausgewählte Kandidat die Anforderung nicht bedienen kann oder einen Parameter nicht erfüllt, kann das Fahrzeug die Anforderung ablehnen und könnte der Cloud-Server ein anderes Kandidat-Fahrzeug auswählen.
Der Cloud-Server leitet bei 213 das Video vom Ziel-Fahrzeug zum Host-Fahrzeug weiter und das Host-Fahrzeug empfängt somit fast Livebildmaterial, das durch die Kamera des Ziel-Fahrzeugs aufgezeichnet wurde. Solange das Host-Fahrzeug weiterhin ein Video bei 215 anfordert, kann der Prozess weitergehen, entweder unter Verwendung des aktuellen Ziel-Fahrzeugs oder unter Verwendung eines neuen Ziel-Fahrzeugs, falls das vorherige Ziel-Fahrzeug die Anforderung aus irgendeinem Grund nicht bedienen kann.
In der veranschaulichenden Alternative, die ebenfalls in 2 gezeigt ist, verwendet der Prozess bei 217 ein Fahrzeug-zu-Fahrzeug (vehicle to vehicle - V2V) und/oder Fahrzeug-zu-Infrastruktur (vehicle to infrastructure - V2I) -Netzwerk, um die Anforderung springend zu einem oder mehreren Kandidat-Fahrzeugen weiterzuleiten. In diesem Beispiel empfängt ein gegebenes Fahrzeug bei 219 die Anforderung vom Host und bestimmt bei 221 selbst, ob das gegebene Fahrzeug Parameter im Zusammenhang mit der Anforderung erfüllt (z. B. unter anderem, ob das gegebene Fahrzeug sich innerhalb einer Schwellenentfernung vom AOI befindet, ob es die richtige Fahrtrichtung aufweist, ob der Verkehr zu dicht ist für nützliche Kameradaten usw.).
Falls das gegebene Fahrzeug bestimmt, dass es ungeeignet ist, um die Anforderung zu bedienen, kaskadiert das Fahrzeug bei 223 die Anforderung an mehrere Fahrzeuge oder Infrastruktur. In einem Modell kann dies das Senden der Anforderung an alle anderen Fahrzeuge und Transceiver in Kommunikation mit dem gegebenen Fahrzeug enthalten, auch wenn andere Modelle ebenfalls verwendet werden könnten, die das Kaskadieren begrenzen. Der Selbstbestimmungsprozess wiederholt sich in jedem Fahrzeug, das die Anforderung empfängt, bis ein Fahrzeug bestätigt, dass es die Anforderung bedienen kann.
Ein offensichtliches Problem bei dem Kaskadenmodell ist, dass Anforderungen im Wesentlichen über eine unbestimmte Zeitdauer zwischen Fahrzeugen hin- und herspringen würden, während ein gewisses Fahrzeug die Anforderung bereits bedient. Dies könnte zu einer größeren Anzahl von Kandidat-Fahrzeugen führen, die unnötigerweise versuchen, eine Anforderung zu bedienen, und somit zeigt 4 ein Beispiel, wie eine Anforderung beendet wird, sobald ein Kandidat-Fahrzeug ausgewählt ist. Eine weitere Option ist, einer Anforderung eine kurze Ablauffrist aufzuerlegen, sodass eine Anforderungskaskade innerhalb eines sinnvoll kurzen Zeitraums endet, und dann empfängt der Host den Feed, wenn ein oder mehrere Fahrzeuge die Anforderung bedienen, und falls der Host den Feed nicht innerhalb des Zeitraums empfangen hat, kann der Host die Anforderung erneut senden (da die springende Weiterleitung aufgrund der Zeitüberschreitung beendet wurde). Ein Zeitpuffer, um die Zeit, die das Video zum Zurückkehren zum Host benötigt, zu berücksichtigen, kann ebenfalls durch den Host eingebaut werden, bevor ein Neuversuch stattfindet, sodass der Host die Anforderung nicht erneut sendet, während der Videofeed gerade eingeht, den Host aber einfach noch nicht erreicht hat.
Sobald ein geeignetes Ziel-Fahrzeug die kaskadierende Anforderung empfängt, sendet das Fahrzeug den Videofeed des angeforderten AOI, der durch Kameras des Fahrzeugs aufgezeichnet wurde, bei 224 aus. Diese Nachricht wird bei 225 von anderen Fahrzeugen oder Infrastruktur zwischen dem Host-Fahrzeug und Ziel-Fahrzeug (Kandidat) empfangen. Jedes Fahrzeug, das den Feed empfängt, kann bei 227 selbst bestimmen, ob dieses Fahrzeug der Host ist, und falls nicht kaskadiert das Fahrzeug bei 229 den Videofeed in einer Weise, die ähnlich der Anforderungslieferung funktioniert. In diesem Modell könnte ein beliebiges konkretes Fahrzeug in der Kette ebenfalls wählen, mit dem Empfangen des Videos zu beginnen, wodurch Fahrer dazwischen mit Bildmaterial des Vorfalls eines interessierenden Gebiets versorgt würden, was nützlich sein könnte, falls das AOI ein Unfall oder eine andere Stockung ist, die diese Fahrer ebenfalls beeinträchtigen würden.
Sobald die Anforderung das Host-Fahrzeug erreicht, zeigt das Host-Fahrzeug bei 231 das Bildmaterial oder den Feed an (dies kann auf Grundlage von Netzwerknachhaltigkeit oder Benutzeranforderung variieren). Falls der Benutzer bei 233 zusätzliches Bildmaterial wünscht, oder dass ein Feed fortgesetzt wird, können die Anforderung und der Rücklaufprozess wiederholt werden.
3 zeigt einen veranschaulichenden Prozess zur Quellfahrzeugauswahl. In diesem Beispiel verwendet der Prozess durch die Anforderung festgelegte Parameter, um ein oder mehrere Kandidat-Fahrzeuge zur Anforderungsbedienung auszuwählen. Der Prozess empfängt bei 301 die Anforderung von dem Host-Fahrzeug und die Anforderung gibt zumindest ein interessierendes Gebiet an. Die Fahrtrichtung oder der Standort des Host-Fahrzeugs können ebenfalls beinhaltet sein, sodass in Fällen, in denen das AOI Verkehr betrifft und ein Stau auf einer gegenüberliegenden Seite der Straße vom Host-Fahrzeug aus ist, diese Daten nicht unbedingt relevant sind. Dies kann auch dazu beitragen zu verhindern, dass ungeeignete Kandidaten ausgewählt werden (die manchmal Fahrzeuge beinhalten können, die in die entgegengesetzte Richtung fahren). Gegenverkehr kann manchmal aus einer Aufzeichnungsperspektive nützlich sein, da dieser Verkehr in der Lage sein kann, schnell einen gesamten Stau zu erfassen, wenn er nicht durch den Stau beeinträchtigt ist, sodass in Gegenrichtung fahrende Fahrzeuge nicht immer ignoriert werden, aber in anderen Fällen können sich diese Fahrzeuge in einem richtigen AOI befinden, aber nicht so positioniert sein, dass sie viele interessierende Daten bereitstellen.
Der Cloud-Server, der die Anforderung empfängt, greift bei 303 auf eine Datenbank zu, die aktuelle Fahrzeugstandorte für eine Anzahl von möglichen Kandidat-Fahrzeugen beinhaltet. Beispielsweise kann der Cloud-Server einen vordefinierten Umkreis um ein AOI festsetzen und kann alle möglichen Fahrzeuge innerhalb dieses Umkreises prüfen. Der Umkreis kann darauf basieren, welche Fahrzeugkamerastandorte das angeforderte AOI sehen könnten, wie dicht Verkehr, Bäume, Gebäude usw. in dem Gebiet sind usw. Ein 50-Fuß-Umkreis um das AOI kann in einem Fall angemessen sein und ein 500-Fuß-Umkreis kann in einem anderen Fall angemessen sein.
Auf Grundlage einer vernünftigen Erwartung, dass eine gegebene Fahrzeugkamera das AOI sehen und aufzeichnen kann, kann der Prozess bei 305 ein oder mehrere Kandidat-Fahrzeuge zum Bedienen der Anforderung auswählen. Falls keine Kandidaten vorhanden sind, kann der Prozess bei 309 einen Fehler an das Host-Fahrzeug zurückmelden. In diesem Beispiel versucht der Prozess weiterhin, Kandidaten zu finden, bis das Host-Fahrzeug bei 311 den Ziel-Standort erreicht, auch wenn Zeitüberschreitungen und andere Beendigungsbedingungen ebenfalls berücksichtigt werden könnten. Sobald das Host-Fahrzeug den Ziel-Standort tatsächlich erreicht, endet der Prozess bei 313. Falls andererseits ein Kandidat gefunden wird, bevor der Host den Standort erreicht, wählt der Prozess den/die Kandidat(en) und fährt damit fort, die Anforderung an diese Fahrzeuge zu senden. Ein einzelner Kandidat kann ausreichend sein, um die meisten Anforderungen zu bedienen, aber mehrere Feeds von mehreren Kandidaten könnten ebenfalls verwendet werden, falls dies gewünscht ist.
4 zeigt einen veranschaulichenden Prozess zur Anforderungsbeendigung. In diesem Beispiel bewirkt der Prozess, dass eine aktuelle Anforderung auf Grundlage der Tatsache, dass ein gewisses Fahrzeug nun die Anforderung bedient, beendet wird. In dem Kaskadenmodell ist es nahezu unmöglich zu bestimmen, welche Fahrzeuge aktuell eine Anforderung halten und versuchen zu reagieren, sodass es für das bedienende Fahrzeug schwierig sein könnte, einfach alle anderen Kandidaten direkt zu kontaktieren und ihnen mitzuteilen, dass die Anforderung abgewickelt wurde. Stattdessen kann in diesem Beispiel das aktuelle Ziel-Fahrzeug (Kandidat), das die Aufzeichnung vornimmt, bei 401 eine Einstellungsanweisung an Fahrzeuge in der Umgebung aussenden. Dies kann beispielsweise das Senden einer Anforderungskennung beinhalten, sodass die Fahrzeuge in der Umgebung wissen, auf welche Anforderung sich die Einstellungsanweisung bezieht.
Die Fahrzeuge in der Umgebung, die die Einstellungsanweisung empfangen, können sowohl Versuche, die Anweisung zu bedienen, als auch das Weiterleiten der Anweisung beenden. Falls die Anforderungskennung beinhaltet ist, können diese Fahrzeuge auch eine weitere Übertragung der Anforderung an das Fahrzeug ignorieren. Dies kann eine Anforderung schnell beenden (da vermutlich die frühesten Sprünge der Einstellungskaskade an andere Kandidat-Fahrzeuge gehen, die sich in dem gleichen Gebiet wie das aktuelle Ziel-/Kandidat-Fahrzeug befinden) und kann dazu beitragen zu verhindern, dass das Host-Fahrzeug eine große Anzahl an Antwortvideofeeds von einer großen Anzahl von Ziel-Fahrzeugen empfängt. Das Fahrzeug kann die Anforderung als eine Kaskade bei 403 an lokale Fahrzeuge senden, um die Anforderung zu beenden, und das Ziel-Fahrzeug kann die Informationen des Host-Fahrzeugs verwenden, um bei 405 einen Beendigungsbefehl direkt an das Host-Fahrzeug zu senden, um ein erneutes Senden einer Anforderung (die nun durch das Ziel-Fahrzeug bedient wird) zu verhindern.
5 zeigt einen veranschaulichenden Prozess zur Anforderungsaufrechterhaltung. In diesem Beispiel hat ein Host-Benutzer möglicherweise einen fünfminütigen Videofeed angefordert oder kann eine Anforderung eine damit in Verbindung stehende fünfminütige Zeitüberschreitung aufweisen. Abhängig von den Fahrtbedingungen ist ein anfängliches Ziel-Fahrzeug möglicherweise nicht in der Lage, die Anforderung für den gesamten festgelegten Zeitraum zu bedienen. Anstatt den Host zu zwingen, die Anforderung erneut zu senden (was ebenfalls möglich ist), zeigt dieses Beispiel, wie das Ziel-Fahrzeug die Anforderung aufrechterhalten kann, falls das Ziel-Fahrzeug die Anforderung nicht länger bedienen kann.
In diesem Beispiel empfängt ein mögliches Ziel-Fahrzeug bei 501 die Anforderung und kann den Selbstauswahlprozess oder einen ähnlichen Prozess durchlaufen. Falls das Fahrzeug die Anforderung bei 503 nicht bedienen kann, kann das Fahrzeug bei 505 die Anforderung verwerfen (nachdem die Anforderung gegebenenfalls an andere Fahrzeuge weitergegeben wurde).
Falls das Ziel-Fahrzeug mit dem Aufzeichnen beginnt, kann sich der Prozess entweder auf beinhaltete AOI-Koordinaten beziehen oder, in anderen Fällen, wenn ein AOI auf Grundlage einer Vorfallgröße dynamisch ist, bei 507 auf Verkehrsdaten zugreifen, um bei 509 zu bestimmen, ob sich das Ziel-Fahrzeug immer noch innerhalb des angemessenen AOI befindet. Solange das Fahrzeug noch innerhalb des AOI ist, kann der Prozess weiterhin Kameradaten senden.
Sobald das Fahrzeug das AOI verlässt, bestimmt der Prozess, ob eine Anforderung geendet hat, was in diesem Beispiel Überprüfen einer Zeitdauer der ursprünglichen Anforderung bei 511 beinhaltet. Falls das Ziel-Fahrzeug beispielsweise nur in der Lage war, einige Sekunden des Verkehrs für eine 30-Sekunden-Anforderung zu erfassen, kann der Fahrer des Host-Fahrzeugs immer noch an zusätzlichen Daten interessiert sein. Anstatt den Host zu veranlassen, eine neue Anforderung zu senden, bestimmt das Ziel-Fahrzeug bei 511, ob die Zeit für die Anforderung abgelaufen ist. Falls die Anforderung nicht geendet hat, leitet das Ziel-Fahrzeug bei 515 die Anforderung weiter (zum Beispiel unter Verwendung des Kaskadenmodells). Das ursprüngliche Host-Fahrzeug ist noch in der Anforderung festgelegt, sodass die Daten zurück zum Host-Fahrzeug gelangen, falls ein anderes Ziel-Fahrzeug die Anforderung bedient. Anderenfalls beendet das Ziel-Fahrzeug einfach bei 513 die Übertragung (falls die Anforderungszeit abgelaufen ist).
Unter Verwendung der veranschaulichenden Beispiele können Fahrer Echtzeit- oder fast Echtzeit-Bildmaterial und Streamingdaten, die aktuelle Ereignisse in einem interessierenden Gebiet oder Punkt darstellen, erlangen. Dies kann dazu beitragen, einen Großteil der Unsicherheit im Hinblick auf Stockungen zu lösen und kann zudem fremde Fahrer mit einem Blick auf ein vorausliegendes Gebiet versorgen. Durch Verwendung anderer Fahrzeuge und Infrastruktur können die Daten angefordert und empfangen werden, ohne dass neue Systeme implementiert werden müssen, die ausdrücklich dazu konzipiert sind, speziell diese Daten zu erfassen.
Obwohl vorstehend beispielhafte Ausführungsformen beschrieben werden, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind beschreibende und keine einschränkenden Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne von Geist und Umfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener umsetzender Ausführungsformen auf logische Weise kombiniert werden, um situationsgerechte Variationen von hier beschriebenen Ausführungsformen zu bilden.

Claims

System, umfassend: einen Prozessor, der konfiguriert ist, um: eine Anforderung von einem Host-Fahrzeug nach einem Video bezüglich eines in der Anforderung festgelegten Standorts zu empfangen; zu bestimmen, ob ein Kandidat-Fahrzeug, das die Anforderung empfängt, das angeforderte Video bereitstellen kann, wenn die Anforderung empfangen wird; und die Anforderung an einen Transceiver in drahtloser Kommunikation mit dem Kandidat-Fahrzeug weiterzuleiten, falls das Kandidat-Fahrzeug das angeforderte Video nicht bereitstellen kann, anderenfalls das angeforderte Video aufzuzeichnen und zu übertragen.
System nach Anspruch 1, wobei die Anforderung eine Host-Kennung beinhaltet und wobei der Prozessor dazu konfiguriert ist, die Host-Kennung in die Übertragung des angeforderten Videos aufzunehmen.
System nach Anspruch 1, wobei der Transceiver ein Transceiver eines anderen Fahrzeugs ist.
System nach Anspruch 1, wobei der Transceiver ein Transceiver einer Infrastruktur ist.
System nach Anspruch 1, wobei der Prozessor dazu konfiguriert ist, das angeforderte Video über ein Mobilfunknetzwerk auf Grundlage der in der Anforderung beinhalteten Host-Fahrzeugkennung direkt zurück an das Host-Fahrzeug zu übertragen.
System nach Anspruch 1, wobei der Prozessor dazu konfiguriert ist, das angeforderte Video an einen Transceiver in drahtloser Kommunikation mit dem Kandidat-Fahrzeug zu übertragen.
System nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist, um: eine Videoübertragung am Kandidat-Fahrzeug von einem drahtlos verbundenen Fahrzeug, einschließlich einer Host-Kennung, zu empfangen; und die Videoübertragung auf Grundlage einer Bestimmung, dass das Kandidat-Fahrzeug der Host-Kennung entspricht, wiederzugeben.
System nach Anspruch 7, wobei der Prozessor ferner konfiguriert ist, um: die Videoübertragung zur Wiedergabe auf Grundlage einer Bestimmung, dass das Kandidat-Fahrzeug der Host-Kennung nicht entspricht, anzubieten; und die Videoübertragung an den Transceiver in drahtloser Kommunikation mit dem Kandidat-Fahrzeug weiterzuleiten.
System nach Anspruch 7, wobei das drahtlos verbundene Fahrzeug ein Fahrzeug ist, von dem das Video stammt.
System nach Anspruch 7, wobei das drahtlos verbunden Fahrzeug ein anderes Kandidat-Fahrzeug außer einem Fahrzeug, von dem das Video stammt, ist.
System, umfassend: einen Prozessor, der konfiguriert ist, um: eine Videoanforderung, einschließlich eines Standorts, von einem Host-Fahrzeug zu empfangen; auf eine Aufzeichnung von aktuellen Standorten eines Kandidat-Fahrzeugs zuzugreifen; ein Kandidat-Fahrzeug innerhalb einer vordefinierten Schwellenentfernung vom Standort auf Grundlage der Standorte des Kandidat-Fahrzeugs zu bestimmen; eine Anweisung an das Kandidat-Fahrzeug zu senden, ein Video aufzuzeichnen; das aufgezeichnete Video von dem Kandidat-Fahrzeug zu empfangen; und das aufgezeichnete Video an das Host-Fahrzeug zu senden.
System nach Anspruch 11, wobei die Aufzeichnung aktuelle Fahrtrichtungen des Kandidat-Fahrzeugs beinhaltet und wobei der Prozessor ferner dazu konfiguriert ist, das Kandidat-Fahrzeug auf Grundlage dessen, dass das Kandidat-Fahrzeug eine Fahrtrichtung angibt, die zumindest einer Fahrzeugkamera ermöglichen würde, den Standort zu sehen, zu bestimmen.
System nach Anspruch 11, wobei der Standort einen Satz von Koordinaten beinhaltet, der ein Gebiet definiert, und wobei die vordefinierte Schwellenentfernung in Bezug auf eine Außenbegrenzung des durch die Koordinaten definierten Gebiets berücksichtigt wird.
System nach Anspruch 11, wobei der Standort einen definierten Point-of-Interest beinhaltet.
System nach Anspruch 11, wobei der Prozessor ferner konfiguriert ist, um: eine Angabe zu empfangen, dass das Kandidaten-Video die Anforderung nicht bedienen kann; und den Prozess des Zugreifens auf die Aufzeichnung, des Bestimmens des Kandidat-Fahrzeugs und des Sendens der Anweisung zu wiederholen, bis ein Kandidat-Fahrzeug, das durch das Wiederholen ausgewählt wird, das aufgezeichnete Video sendet.