System and method for maintenance of sensor data for a vehicle

Abstract

A computer-implemented method, when executed by data processing hardware, causes the data processing hardware to perform operations. The operations include establishing a map of one or more supporting vehicles adjacent to the host vehicle, determining available sensor supports of the one or more supporting vehicles, storing the available sensor supports in memory hardware connected to the host vehicle, determining whether a gear state of the host vehicle has changed, and transmitting the determined gear state to the host vehicle. The sensor data is received from the one or more supporting vehicles, and the sensor data of the host vehicle is maintained using the sensor data of the one or more supporting vehicles based on the gear state of the host vehicle.

Description

Technical Field

[0001] The information provided in this section is for the purpose of presenting the context of the present disclosure generally. The work of the presently named inventors, to the extent it is described in this section, and aspects that may not be eligible as prior art at the time of filing, are not, either expressly or implicitly, admitted as prior art against the present disclosure.

[0002] The present disclosure generally relates to a system and method for maintaining sensor data of a vehicle, and more particularly, to a system and method for maintaining sensor data of a host vehicle using sensor data of one or more supporting vehicles. Background Art

[0003] Existing vehicles are equipped with sensor systems that provide data to one or more operating systems of the vehicle. These sensor systems typically include one or more sensors configured inside and outside the vehicle. Objects such as buildings, signs, or other vehicles may obstruct one or more sensors of the vehicle and affect their ability to provide the information that the operating system or the operator of the vehicle may expect. These drawbacks of existing vehicles can be addressed by maintaining the sensor data of the host vehicle using sensor data of one or more supporting vehicles located within the operating area of the host vehicle. Summary of the Invention

[0004] In one configuration, a computer-implemented method is provided that, when executed by data processing hardware, causes the data processing hardware to perform operations. The operations include establishing a map of one or more supporting vehicles adjacent to the host vehicle, determining available sensor support of the one or more supporting vehicles, storing the available sensor support in a memory hardware connected to the host vehicle, determining whether the gear state of the host vehicle has changed, receiving sensor data from the one or more supporting vehicles, and maintaining the sensor data of the host vehicle using the sensor data of the one or more supporting vehicles based on the gear state of the host vehicle.

[0005] The method may include one or more of the following optional aspects or steps. For example, establishing a map of one or more support vehicles may include querying one or more support vehicles using one or more vehicle communication networks. Determining available sensor support for one or more support vehicles may include identifying the heading of each of one or more support vehicles, determining the camera viewpoints of each of one or more support vehicles, and determining the radar coverage of each of one or more support vehicles. Establishing a map of one or more support vehicles may include calculating the angle between the heading of the host vehicle and the heading of each of one or more support vehicles to determine the relative position of each of one or more support vehicles with respect to the host vehicle. The memory hardware connected to the host vehicle may be a cloud-based memory system. The method may further include the steps of maintaining a connection with one or more support vehicles and waking up one or more support vehicles from a sleep mode when the gear state of the host vehicle changes. Maintaining sensor data of the host vehicle may include continuously receiving data from one or more support vehicles when the host vehicle changes position relative to one or more support vehicles.

[0006] In another configuration, a system is provided that includes data processing hardware and memory hardware communicatively coupled to the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include establishing a map of one or more support vehicles adjacent to a host vehicle, determining available sensor support for one or more support vehicles, storing the available sensor support in memory hardware connected to the host vehicle, determining whether the gear state of the host vehicle has changed, receiving sensor data from one or more support vehicles, and maintaining sensor data of the host vehicle using the sensor data of one or more support vehicles based on the gear state of the host vehicle.

[0007] The system may include one or more of the following optional aspects. For example, establishing a map of one or more support vehicles may include querying one or more support vehicles using one or more vehicle communication networks. Determining the available sensor support of one or more support vehicles may include identifying the heading of each of the one or more support vehicles, determining the camera viewpoints of each of the one or more support vehicles, and determining the radar coverage of each of the one or more support vehicles. Establishing a map of one or more support vehicles may include calculating the angle between the heading of the host vehicle and the heading of each of the one or more support vehicles to determine the relative position of each of the one or more support vehicles with respect to the host vehicle. The memory hardware connected to the host vehicle may be a cloud-based memory system. The system may also include the steps of maintaining a connection with one or more support vehicles and waking up the one or more support vehicles from a sleep mode when the gear state of the host vehicle changes. Maintaining the sensor data of the host vehicle may include continuously receiving data from one or more support vehicles when the host vehicle changes position relative to the one or more support vehicles.

[0008] In another configuration, a vehicle management system is provided, and the vehicle management system includes a communication system, data processing hardware, and memory hardware in communication with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include establishing a map of one or more support vehicles adjacent to a host vehicle, determining the available sensor support of the one or more support vehicles, storing the available sensor support in memory hardware connected to the host vehicle, determining whether the gear state of the host vehicle has changed, receiving sensor data from the one or more support vehicles, and maintaining the sensor data of the host vehicle using the sensor data of the one or more support vehicles based on the gear state of the host vehicle.

[0009] A vehicle management system may include one or more of the following optional aspects. Determining the available sensors of one or more support vehicles may include identifying the heading of each of the one or more support vehicles, determining the camera viewpoints of each of the one or more support vehicles, and determining the radar coverage of each of the one or more support vehicles. Establishing a map of one or more support vehicles may include calculating the angle between the heading of the host vehicle and the heading of each of the one or more support vehicles to determine the relative position of each of the one or more support vehicles with respect to the host vehicle. The memory hardware connected to the host vehicle may be a cloud-based memory system. The vehicle management system may further include the steps of maintaining a connection with one or more support vehicles and waking up the one or more support vehicles from a sleep mode when the gear state of the host vehicle changes. Maintaining the sensor data of the host vehicle may include continuously receiving data from one or more support vehicles when the host vehicle changes its position relative to the one or more support vehicles. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The drawings described herein are for illustrative purposes only for the selected configurations and are not intended to limit the scope of the present disclosure.

[0011] Figure 1 is a schematic diagram of a vehicle environment including a host vehicle and one or more support vehicles in accordance with the principles of the present disclosure;

[0012] Figure 2 is a schematic diagram of a host vehicle having an on-vehicle controller, sensing devices, and a network of communication devices for communicating with one or more support vehicles in accordance with an aspect of the present disclosure;

[0013] Figure 3 is a schematic diagram of the sensing area of an existing vehicle;

[0014] Figure 4 is a schematic diagram of the sensing area of a host vehicle in accordance with an aspect of the present disclosure;

[0015] Figure 5 is a schematic diagram of one or more support vehicles within the operating area of a host vehicle in accordance with an aspect of the present disclosure; and

[0016] Figure 6 is a flowchart detailing a method of maintaining the sensor data of a host vehicle using the sensor data of one or more support vehicles.

[0017] In all the drawings, corresponding reference numerals represent corresponding components. DETAILED DESCRIPTION

[0018] Example configurations will now be described more fully with reference to the accompanying drawings. The example configurations are provided so that this disclosure will be thorough and will fully convey the scope of the disclosure to those of ordinary skill in the art. Specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the configurations of this disclosure. It will be apparent to those of ordinary skill in the art that specific details need not be employed, that the example configurations may be embodied in many different forms, and that the specific details and example configurations should not be construed as limiting the scope of this disclosure.

[0019] The terminology used herein is for the purpose of describing particular example configurations only and is not intended to be limiting. As used herein, the singular articles "a", "an", and "the" may also be intended to include the plural forms, unless the context clearly dictates otherwise. The terms "comprising", "including", "containing", and "having" are inclusive and thus specify the presence of stated features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. The method steps, processes, and operations described herein should not be construed as necessarily requiring them to be performed in the particular order discussed or illustrated, unless specifically identified as an order of performance. Additional or alternative steps may be employed.

[0020] When an element or layer is referred to as being "on", "engaged to", "connected to", "attached to", or "coupled to" another element or layer, it may be directly on, engaged, connected, attached, or coupled to the other element or layer, or intervening elements or layers may be present. In contrast, when an element is referred to as being "directly on", "directly engaged to", "directly connected to", "directly attached to", or "directly coupled to" another element or layer, intervening elements or layers may not be present. Other words used to describe the relationship between elements should be interpreted in a like fashion (e.g., "between" versus "directly between", "adjacent" versus "directly adjacent", etc.). As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0021] The terms "first", "second", "third", etc. may be used herein to describe various elements, components, regions, layers, and / or sections. These elements, components, regions, layers, and / or sections should not be limited by these terms. These terms may be used only to distinguish one element, component, region, layer, or section from another. Unless the context clearly indicates otherwise, terms such as "first", "second", and other numerical terms do not imply an order or sequence. Thus, a first element, component, region, layer, or section discussed below may be termed a second element, component, region, layer, or section without departing from the teachings of the example configurations.

[0022] In this application, including the following definitions, the term "module" may be replaced by the term "circuit". The term "module" may refer to an application specific integrated circuit (ASIC), be part of or include it; digital, analog or mixed analog / digital discrete circuits; digital, analog or mixed analog / digital integrated circuits; combinational logic circuits; field programmable gate arrays (FPGAs); processors (shared, dedicated or grouped) that execute code; memories (shared, dedicated or grouped) that store code executed by the processors; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system-on-chip.

[0023] As used above, the term "code" may include software, firmware and / or microcode, and may refer to programs, routines, functions, classes and / or objects. The term "shared processor" includes a single processor that executes some or all of the code from multiple modules. The term "group processor" includes a processor that, in combination with additional processors, executes some or all of the code from one or more modules. The term "shared memory" encompasses a single memory that stores some or all of the code from multiple modules. The term "group memory" includes a memory that, in combination with additional memories, stores some or all of the code from one or more modules. The term "memory" may be a subset of the term "computer-readable medium". The term "computer-readable medium" does not include transient electrical and electromagnetic signals propagated through a medium, and thus may be considered tangible and non-transient memory. Non-limiting examples of non-transitory memory include tangible computer-readable media that include non-volatile memory, magnetic memory, and optical memory.

[0024] The devices and methods described in this application may be implemented in part or in whole by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer programs may also include and / or rely on stored data.

[0025] A software application (i.e., a software resource) may refer to computer software that causes a computing device to perform tasks. Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0026] A non-transitory memory can be a physical device for temporarily or permanently storing programs (e.g., sequences of instructions) or data (e.g., program state information) for use by a computing device. The non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware such as a boot program). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and magnetic disks or tapes.

[0027] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in high-level procedural and / or object-oriented programming languages and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., a magnetic disk, an optical disk, a memory, a programmable logic device (PLD)) that provides machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal that provides machine instructions and / or data to a programmable processor.

[0028] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuits, integrated circuits, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementations in one or more computer programs executable and / or interpretable on a programmable system including at least one programmable processor, which can be special purpose or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0029] The processes and logical flows described in this specification can be performed by one or more programmable processors (also referred to as data processing hardware) that execute one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be performed by special purpose logic circuitry, such as an FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit). As an example, processors suitable for the execution of a computer program include both general and special purpose microprocessors, as well as any one or more processors of any type of digital computer. In general, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. In general, a computer will also include one or more mass storage devices (such as magnetic disks, magneto - optical disks, or optical disks) for storing data, or operatively coupled to receive data therefrom or transfer data thereto or both. However, a computer need not have such devices. Computer - readable media suitable for storing computer program instructions and data include all forms of non - volatile memory, media, and memory devices, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto - optical disks; and CD ROM and DVD - ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0030] To provide for interaction with a user, one or more aspects of the present disclosure can be implemented on a computer having a display device (such as a CRT (Cathode Ray Tube), LCD (Liquid Crystal Display) monitor, or touch screen) for displaying information to the user and, optionally, a keyboard and a pointing device (such as a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can also be used to provide for interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. Additionally, a computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a web page to a web browser on a client device of the user in response to a request received from the web browser.

[0031] Reference Figure 1, an exemplary vehicle operating environment 10 is provided for illustrative purposes of the principles of the present disclosure. The vehicle operating environment 10 includes a host vehicle 100A, one or more support vehicles 100B, and a vehicle monitoring center 12. The host vehicle 100A and the one or more support vehicles 100B include bodies 102A and 102B, respectively. For illustrative purposes, the vehicle operating environment 10 is shown as including a single vehicle monitoring center 12. However, in other examples, the vehicle operating environment 10 may include multiple vehicle monitoring centers 12 that communicate with the vehicles 100 via a network 14 (e.g., the Internet, a cellular network). The vehicle monitoring center 12 may include a remote facility or system that receives and monitors diagnostic data and sensor data from the host vehicle 100A and the one or more support vehicles 100B to determine one or more vehicle operating conditions.

[0032] Reference Figure 2 , the host vehicle 100A may be equipped with a vehicle management system 16, and the vehicle management system 16 includes a communication system 18 that wirelessly communicates (e.g., via a cellular tower, a base station, and / or a mobile switching center, etc.) with a remote location or a non-vehicle-mounted cloud computing system 20 ( Figure 1 ). For the purposes of this application, the one or more support vehicles 100B may also be equipped with the same or a similar vehicle management system 16, which is described in more detail below with respect to the host vehicle 100A.

[0033] Some other components of the vehicle management system 16 are generally shown in Figure 2 and, by way of non-limiting example, include a display device 22, a driver interface device 24, a microphone 26, a speaker 28, and input controls 30 (e.g., buttons, knobs, switches, touchpads, keyboards, touchscreens, etc.). The components of the vehicle management system 16 enable a user to communicate with the vehicle management system 16 and other systems and system components within the host vehicle 100A. The driver interface device 24 may include a mechanical parking pawl or an electronic shifter including buttons or dials such that an operator can change the gear state of the host vehicle 100A, for example, between park, reverse, neutral, drive, or low speed. The microphone 26 provides a way for vehicle occupants to input verbal or other audible commands; the host vehicle 100A may be equipped with an embedded voice processing unit that utilizes human-machine (HMI) technology. The speaker 28 provides an audible output to vehicle occupants and may be a standalone speaker dedicated to use with the vehicle management system 16 or may be part of an audio system 32. The audio system 32 is operatively connected to a network connection interface 34 and an audio bus 36 to receive analog information via one or more speaker components and present it as sound.

[0034] The network connection interface 34 can be communicatively coupled to the vehicle management system 16. Some examples of the network connection interface 34 can include twisted pair / fiber optic Ethernet switches, internal / external parallel communication buses, local area network (LAN) interfaces, controller area network (CAN), media oriented system transport (MOST), local interconnect network (LIN) interfaces, etc. Other communication interfaces can also include those that comply with ISO, SAE, and IEEE standards and specifications. The network connection interface 34 enables components of the vehicle management system 16 to send and receive signals to and from each other and to various systems and subsystems that are "resident" within or "remote" from the vehicle body 102A. This allows the host vehicle 100A to perform various vehicle functions, such as communicating with one or more support vehicles 100B to maintain data on the host vehicle 100A. For example, the vehicle management system 16 receives data from and / or sends data to the electronic control unit (ECU) 38, engine control module (ECM) 40, powertrain control module (PCM) 42, (one or more) sensor interface modules 44, transmission control module 46, and various other vehicle ECUs (such as a brake system control module (BSCM), climate control module (CCM), etc.). In this illustrative configuration, the driver interface device 24 is shown coupled to the communication device 18, which can communicate (i.e., send data to and / or receive data from) with one or more of the aforementioned modules and units 38, 40, 42, 44, 46 of the host vehicle 100A. However, note that the driver interface device 24 can additionally or alternatively be directly coupled to the network connection interface 34 together with one or more of the modules and units 38, 40, 42, 44, 46.

[0035] Continue to refer to Figure 2, the communication system 18 is an in-vehicle computing device that provides several functions both individually and through its communication with other networked devices. The communication system 18 generally consists of data processing hardware 48, each of which can be embodied as a discrete microprocessor, an application-specific integrated circuit (ASIC), or a dedicated control module. The host vehicle 100A can provide centralized vehicle control via a central processing unit (CPU) 50 and a real-time clock (RTC) 54 operably coupled to memory hardware 52, each of which can take the form of a CD-ROM, a disk, an IC device, a semiconductor memory (e.g., various types of RAM or ROM), etc. Remote vehicle communication capabilities with long-range off-vehicle networked devices can be provided via one or more or all of a cellular chipset / component, a navigation and location chipset / component (e.g., a global positioning system (GPS)), or a wireless modem, such as a global network satellite system (GNSS), all of which are collectively shown at 56. Short-range wireless connectivity can be provided via a short-range wireless communication device 58 (e.g., a cell or a near-field communication (NFC) transceiver), a dedicated short-range communication (DSRC) component 60, and / or a dual antenna 62. It should be understood that the host vehicle 100A supporting any one of the vehicles 100B can be implemented without one or more of the components and functions listed above, as desired for a specific end use. The various communication devices described above can be configured to exchange data as part of a periodic broadcast in a vehicle-to-vehicle (V2V) communication system or a vehicle-to-everything (V2X) communication system (e.g., vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and / or vehicle-to-device (V2D)).

[0036] The CPU 50 can receive data from one or more sensing devices that use, for example, optical detection, radar, lidar, ultrasonic, optical, infrared, or other suitable techniques for object detection, including short-range communication techniques such as DRC or ultra-wideband (UWB). According to this illustrative configuration, the host vehicle 100A can be equipped with one or more digital cameras 64, one or more distance sensors 66, one or more vehicle speed sensors 68, one or more vehicle dynamics sensors 70, and any necessary hardware and software for processing raw sensor data for filtering, classification, fusion, and analysis. The digital camera 64 can use a charge-coupled device (CCD) sensor or other suitable optical sensor to generate images indicative of the field of view of the host vehicle 100A and can be configured for continuous image generation (e.g., generating at least about 35 images per second). The distance sensor 66 can emit and detect reflected radio, electromagnetic, or light-based waves (e.g., radar, EM induction, light detection and ranging (LIDAR), etc.) to detect, for example, the presence, geometric dimensions, and / or proximity of objects. The vehicle speed sensor 68 can include, for example, a wheel speed sensor that measures the wheel speed, which is then used to determine the real-time vehicle speed. Additionally, the vehicle dynamics sensor 70 can be in the nature of a single-axis or tri-axis accelerometer, angular rate sensor, inclinometer, etc., for detecting longitudinal and lateral accelerations, yaw, roll, and / or pitch rates or other dynamics-related parameters. Using data from the sensing devices 64, 66, 68, 70, the CPU 50 identifies objects within the detectable range of the host vehicle 100A and determines the attributes of the target objects, such as size, relative position, approach angle, relative speed, etc.

[0037] These sensors are distributed throughout the vehicle 10 and are operably unobstructed with respect to a corresponding view of the front or rear or vehicle lateral of the host vehicle 100A. Each sensor generates an electrical signal indicative of the characteristics or conditions of a target object, typically as an estimate with a corresponding standard deviation. Although the operating characteristics of these sensors are generally complementary, some sensors are more reliable than others in estimating certain parameters. Most sensors have different operating ranges and coverage areas and are capable of detecting different parameters within their operating ranges. For example, radar-based sensors can estimate the distance, rate of change of distance, and azimuthal position of an object, but may not be robust in estimating the range of the detected object. On the other hand, cameras with optical processing may be more robust in estimating the shape and azimuthal position of an object, but may be less efficient in estimating the distance and rate of change of distance of an object. Scanning LIDAR-based sensors can perform effectively and accurately with respect to estimating range and azimuthal position, but may not be able to accurately estimate the rate of change of range and, therefore, may not be accurate in acquiring / identifying new objects. In contrast, ultrasonic sensors are capable of estimating range but generally cannot accurately estimate range rate and azimuthal position. Additionally, the performance of many sensor technologies may be affected by different environmental conditions. Thus, sensors typically exhibit parameter variance, and their operational overlap provides an opportunity for sensor fusion.

[0038] During operation, when sensors 64, 66, 68, 70 collect sensor data 72 within the vehicle operating environment 10, the communication system 18 may be configured to store, process, and / or transmit the sensor data 72 within the vehicle operating environment 10. The data processing hardware 48 may be configured to execute instructions stored in the memory hardware 52 to perform computational tasks related to the operation and management of the host vehicle 100A. Generally, the communication system 18 may refer to one or more locations of the data processing hardware and the memory hardware. For example, in some examples, the communication system is a local system located on the host vehicle 100A, as Figure 2 shown. When located on the host vehicle 100A, the communication system may be centralized (i.e., in a single location / area on the host vehicle 100A, e.g., within the vehicle management system 16), decentralized (i.e., located at various locations around the host vehicle 100A), or a hybrid combination of both (e.g., having mostly centralized hardware and a few decentralized hardware).

[0039] Additionally or alternatively, the communication system 18 includes computing resources located remote from the host vehicle 100A. For example, the vehicle management system 16 may communicate via the network 14 with a remote vehicle computing system 20 (e.g., a remote computer / server or cloud-based environment). Very similar to the vehicle management system 16, the remote vehicle computing system 20 includes computing resources such as remote data processing hardware 74 and remote memory hardware 76. Here, sensor data 72 or other processed data (e.g., data locally processed by the vehicle management system 16) may be stored in the remote vehicle computing system 20 and may be accessed by the vehicle management system 16.

[0040] Now referring to Figure 3 , an illustration of an existing vehicle 200 including a sensing system is provided. In this example, the vehicle 200 is backing up and reversing out of a parking space that has a vehicle positioned laterally to the vehicle 200. Triangles are arranged behind the vehicle 200 to illustratively depict a sensing area 204 of the sensing system of the vehicle 200. As shown, a pedestrian 206 is approaching the vehicle 200, but the sensing system cannot detect the pedestrian 206 because the pedestrian 206 is outside the sensing area 204.

[0041] Referring to Figure 4 , the host vehicle 100A is in the same manner as Figure 3A scenario similar to that of vehicle 200 in [reference] is shown, where pedestrian 106 is approaching. However, contrary to vehicle 200, the host vehicle 100A of the present disclosure is configured to utilize sensor data from one or more support vehicles 100B to maintain its sensor data, thereby expanding the sensing area 104 of the host vehicle 100A to include the sensing areas 104 of one or more support vehicles 100B. In this example, the headings 108B of one or more support vehicles 100B are aligned with the heading 108A of the host vehicle 100A and in the same direction as the heading 108A of the host vehicle 100A. When the host vehicle 100A backs out of a parking space, the relevant sensor data from one or more support vehicles 100B may include sensor data associated with the rear sensors of any one of the one or more support vehicles 100B. Thus, when the operator of the host vehicle 100A changes the gear state from park to reverse, the host vehicle 100A may request rear sensor data from one or more support vehicles 100B, or the host vehicle 100A may maintain its sensor data together with all the sensor data of one or more support vehicles 100B and determine which data is desired based on the gear state. However, note that the host vehicle 100A and one or more support vehicles 100B may also transmit sensor data and requests for sensor data in other ways. In doing so, the host vehicle 100A is able to detect pedestrian 106 earlier by utilizing the sensor data received from one or more support vehicles 100B than on its own.

[0042] Reference Figure 5 , a schematic diagram showing the host vehicle 100A surrounded by one or more support vehicles 100B is provided. Generally, the host vehicle 100A is configured to communicate with one or more support vehicles 100B to send and receive data identifying the positions of the one or more support vehicles 100B within the operating area 110A of the host vehicle 100A. The operating area 110A is merely representative and is included to show an example of nearby vehicles within the scope to communicate with the host vehicle 100A and / or provide desired sensor data for supplementing or maintaining the sensor data of the host vehicle 100A. The operating range 110A may be made smaller to include fewer support vehicles, or larger to include more support vehicles, such as 20, 50, or n support vehicles.

[0043] As will be discussed below, for example, a Global Navigation Satellite System (GNSS), Vehicle-to-Everything (V2X), and / or Ultra-Wideband (UWB) can be used to map one or more support vehicles 100B. As described above, each support vehicle 100B can be identified by a heading 108B that represents the front of one of the one or more support vehicles 100B. The heading 108B can be used to calculate the angle between the heading 108A of the host vehicle 100A and the heading 108B of each of the one or more support vehicles 100B to determine the relative position of each of the one or more support vehicles 100B with respect to the host vehicle 100A. When a support vehicle 100B enters and / or leaves the operating area 110A of the host vehicle 100A, the map of the one or more support vehicles 100B can be continuously updated.

[0044] Continuing to refer Figure 6 , among other conditions, the gear state of the host vehicle 100A can be utilized to determine which support vehicles 100B should be warned or awakened from the sleep mode to help maintain the sensor data of the host vehicle 100A. For example, if the gear state of the host vehicle 100A is reverse, drive, or low speed, the host vehicle 100A can awaken the support vehicles 100B in regions I, III, and IV and receive sensor data from them simultaneously. More specifically, when the gear state of the host vehicle 100A is drive or low speed, the host vehicle 100A can utilize the sensor data of the rear sensors of the support vehicles 100B in region I and the sensor data of the front sensors of the support vehicles 100B in regions III and IV to supplement or maintain its sensor data. If the gear state of the host vehicle 100A is reverse, the host vehicle 100A can awaken the support vehicles in regions II, III, and IV and receive sensor data from them simultaneously. More specifically, when the gear state of the host vehicle 100A is reverse, the host vehicle 100A can utilize the sensor data of the rear sensors of the support vehicles 100B in regions III and IV and the sensor data of the front sensors of the support vehicles 100B in region II to supplement or maintain its sensor data.

[0045] Referring Figure 6 , a method for maintaining the sensor data of the host vehicle 100A by using the sensor data of one of the one or more support vehicles 100B is provided. At a first step 302, method 300 is initiated. In fact, method 300 can be initiated at step 304 when the vehicle operator powers on the host vehicle 100A. At step 306, the vehicle management system 16 begins to query one or more support vehicles 100B, which can include using one or more wireless communication technologies, such as Global Navigation Satellite System (GNSS), Vehicle-to-Everything (V2X), and / or Ultra-Wideband (UWB), etc.

[0046] At step 308, a map of one or more support vehicles 100B adjacent to or within the operating area of the host vehicle 100A is established.

[0047] At step 310, determine the available sensor support for one or more support vehicles 100B. Determining the available sensor support for one or more support vehicles 100B can include identifying the heading 108B of each of the one or more support vehicles, determining the camera viewpoints of each of the one or more support vehicles, and determining the radar coverage of each of the one or more support vehicles.

[0048] At step 312, data regarding one or more support vehicles 100B can be stored in the memory hardware 52 on the host vehicle 100A and / or in the remote memory hardware 76 of the off-vehicle cloud computing system 20.

[0049] At step 314, the communication system 18 determines whether the gear state of the host vehicle 100A has changed. Alternatively, if the driver interface device 24 is coupled to the network connection interface 34, a signal can be sent from the driver interface device 24 to the communication device 18 when, for example, the operator changes the gear from park to reverse. On the other hand, if the communication device 18 does not receive a signal indicating that the driver has shifted gears, whether directly from the driver interface device 24 or from the network connection interface 34, the method 300 returns to step 306 and queries one or more support vehicles adjacent to or within the operating range of the host vehicle 100A. In fact, when the host vehicle 100A is parked, the host vehicle 100A can maintain a connection with one or more support vehicles 100B that have been mapped in step 308, while also supplementing the vehicle map with new and / or replacement support vehicles entering an area adjacent to or within the operating range 110A of the host vehicle 100A.

[0050] At step 316, the host vehicle 100A communicates with one or more support vehicles 100B to wake up one or more support vehicles 100A from the sleep mode.

[0051] At step 318, depending on the gear state of the host vehicle (i.e., park, reverse, neutral, drive, low speed), the host vehicle 100A can request sensor-specific data from one or more support vehicles 100B to maintain the sensor data of the host vehicle 100A, as described above with respect to Figure 5 In addition, the host vehicle 100A can continuously receive any and all sensor data from all of the support vehicles among one or more support vehicles and maintain its sensor data according to the gear state of the host vehicle 100A.

[0052] At step 320, when the host vehicle 100A begins to change position (e.g., backing out of a parking space), one or more support vehicles 100B continue to transmit and / or send data received at the host vehicle 100A.

[0053] At step 322, once the host vehicle 100A has stopped changing position, one or more support vehicles 100B will stop sending sensor data to the host vehicle 100A. However, when the host vehicle 100A remains in motion, method 300 will return to step 320.

[0054] At step 324, once the host vehicle 100A has stopped changing position, the host vehicle 100A will disconnect from one or more support vehicles 100B.

[0055] At step 326, data collected from one or more support vehicles 100B can be deleted from either the on-vehicle or off-vehicle memory hardware 52, 76 of the host vehicle 100A.

[0056] Finally, method 300 ends at step 328.

[0057] Numerous embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of the present disclosure. Accordingly, other embodiments are within the scope of the appended claims.

[0058] The foregoing description has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the present disclosure. The individual elements or features of a particular configuration are generally not limited to that particular configuration, but are interchangeable and can be used in a selected configuration, even if not specifically shown or described. It can also vary in many ways. Such variations should not be regarded as a departure from the present disclosure, and all such modifications are intended to be included within the scope of the present disclosure.

Claims

1. A computer-implemented method that, when executed by data processing hardware, causes the data processing hardware to perform operations, the operations including: Establishing a map of one or more support vehicles adjacent to a host vehicle; Determining available sensor support of the one or more support vehicles; Storing the available sensor support in memory hardware connected to the host vehicle; Determining whether a gear state of the host vehicle has changed; Receiving sensor data from the one or more support vehicles; And Based on the gear state of the host vehicle, using the sensor data of the one or more support vehicles to maintain the sensor data of the host vehicle.

2. The method according to claim 1, wherein, Establishing the map of the one or more support vehicles includes querying the one or more support vehicles using one or more vehicle communication networks.

3. The method according to claim 1, wherein, Determining the available sensor support of the one or more support vehicles includes: Identifying the heading of each of the one or more support vehicles; Determining the camera viewpoints of each of the one or more support vehicles; and Determining the radar coverage of each of the one or more support vehicles.

4. The method according to claim 3, wherein establishing the map of the one or more support vehicles includes calculating an angle between the heading of the host vehicle and the heading of each of the one or more support vehicles to determine a relative position of each of the one or more support vehicles with respect to the host vehicle.

5. The method according to claim 1, wherein the memory hardware connected to the host vehicle is a cloud-based memory system.

6. The method according to claim 1, further comprising the steps of: Maintaining a connection with the one or more support vehicles; and When the gear state of the host vehicle changes, waking up the one or more support vehicles from a sleep mode.

7. The method according to claim 6, further comprising determining which of the support vehicles should be woken up from the sleep mode based on the gear state.

8. The method according to claim 7, further comprising: When the gear state is one of reverse, drive, or low speed, waking up the support vehicle in one of a first area, a second area, a third area, or a fourth area.

9. The method according to claim 1, wherein Maintaining the sensor data of the host vehicle includes: continuously receiving data from the one or more support vehicles when the host vehicle changes position relative to the one or more support vehicles.

10. The method according to claim 1, further comprising starting the method when powering on the host vehicle.

Images