Intersection collision avoidance system and method

Abstract

The intersection collision avoidance may use a cellular transceiver for a cellular network and a processor disposed in a cellular access point for multi-access edge computing. The processor includes a shared world model and a potential collision detection module. The shared world model is configured to receive, by the cellular transceiver, signals associated with at least two road users proximate an intersection in the vehicular traffic network, the at least two road users including an ego vehicle, and the signals conform to a standards-based communication protocol. The potential collision detection module is configured to receive object information from the shared world model, determine a potential future collision between the ego vehicle and another of the at least two road users, and transmit a notification of the potential future collision to the ego vehicle via the cellular network.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE This application relates to navigating intersections, and more particularly, to systems and methods for intersection collision avoidance. [Background technology]

[0002] Transportation network data from and related to the transportation network and users of the transportation network and those proximate thereto is available from sensors on vehicles traveling the transportation network and infrastructure sensors proximate thereto. For example, transportation network data can be received or obtained from fixed infrastructure such as traffic cameras and induction loop traffic sensors, self-reported positions, and status information from connected road users and connected vehicle mounted sensors. Processing the collected transportation network data to provide meaningful insights into road user behavior is difficult. Summary of the Invention

[0003] Disclosed herein are aspects, features, elements, and implementations for intersection collision avoidance.

[0004] One aspect of the disclosed implementation is a system for intersection collision avoidance, including a cellular transceiver for a cellular network and a processor disposed in a cellular access point for multi-access edge computing. The processor includes (e.g., implements, processes) a shared world model configured to receive, by the cellular transceiver, signals associated with at least two road users proximate an intersection in a vehicular traffic network. The at least two road users include an ego vehicle, and the signals conform to a standards-based communication protocol. The processor also includes a potential collision detection module configured to receive object information from the shared world model, determine a potential future collision between the ego vehicle and another of the at least two road users, and transmit a notification of the potential future collision to the ego vehicle via the cellular network.

[0005] One aspect of a disclosed implementation is a method for intersection collision avoidance, comprising receiving, by a cellular transceiver for a cellular network, signals in a shared world model associated with at least two road users proximate an intersection in a vehicular traffic network, the at least two road users including an ego vehicle, the signals conforming to a standards-based communication protocol, receiving object information from the shared world model at a potential collision detection module, determining, by the potential collision detection module, a potential future collision between the ego vehicle and another of the at least two road users, and transmitting, by the potential collision detection module, a notification of the potential future collision to the ego vehicle via the cellular network. The shared world model and the potential collision detection module are implemented by a processor located at a cellular access point for multi-access edge computing.

[0006] These and other features of the present disclosure are set forth in the following detailed description of implementations, the appended claims and the accompanying drawings. [Brief description of the drawings]

[0007] The technology of the present disclosure is best understood from the following detailed description when read in conjunction with the accompanying drawings. It is emphasized that, according to common practice, the various features of the drawings are not to scale. To the contrary, dimensions of the various features have been arbitrarily expanded or reduced for clarity. Moreover, unless otherwise noted, the same reference numerals refer to the same elements throughout the drawings.

[0008] [Figure 1] 1 is an exemplary drawing of a portion of a vehicle in which aspects, features, and elements disclosed herein may be implemented.

[0009] [Diagram 2] FIG. 1 is an example diagram of a portion of a vehicle traffic and communication system in which aspects, features, and elements disclosed herein may be implemented.

[0010] [Diagram 3] FIG. 1 is a diagram of a system for intersection collision avoidance in accordance with an implementation of the present disclosure.

[0011] [Figure 4] FIG. 4 is a diagram of an example of communication between a vehicle and the system of FIG.

[0012] [Diagram 5] FIG. 1 is a diagram of a system for generating a shared world model for intersection collision avoidance according to an implementation of the present disclosure.

[0013] [Figure 6] 4 is a flow chart of a method for determining vehicle intent.

[0014] [Figure 7] FIG. 1 is a diagram of a hazard zone at an intersection.

[0015] [Figure 8] FIG. 8 is a diagram of a three-way intersection in which the hazard zones according to FIG. 7 are used to determine potential collisions.

[0016] [Figure 9] FIG. 2 illustrates the intended paths of two vehicles and the distance between the two vehicles at a future time used to determine a potential collision at an intersection.

[0017] [Figure 10] FIG. 1 is a diagram of a four-way intersection used to explain how to generate a target warning in response to a potential collision detection.

[0018] [Figure 11] FIG. 1 is a diagram of a four-way intersection used to explain how potential collision detection is performed in the presence of occluded road users.

[0019] [Figure 12A] 1 is an example of a notification issued to a connected vehicle from a potential collision detection in accordance with the teachings herein.

[0020] [Figure 12B] 1 is another example of a notification issued to a connected vehicle from a potential collision detection in accordance with the teachings herein.

[0021] [Figure 12C] 1 is an example of a notification issued to a pedestrian from a potential collision detection in accordance with the teachings herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] A vehicle may travel through a portion of a vehicular network. The vehicular network may include one or more non-operable areas, such as buildings, one or more partially operable areas, such as parking areas (e.g., parking lots, parking spaces, etc.), one or more operable areas of a road (including lanes, medians, intersections, etc.), or combinations thereof. The vehicle may use native sensors to generate or capture data corresponding to the vehicle's operating environment or portions thereof while the vehicle travels through the vehicular network. The vehicle may use this data to identify potential collisions or hazards (e.g., other road users), which may be used to notify an operator, provide input to a safety system, provide input to an advanced driver assistance system (ADAS), or a combination thereof.

[0023] As mentioned above, other data can also be used to identify potential conflicts or hazards. Processing traffic network data collected from vehicle sensors and from other vehicle and infrastructure sensors is complicated by its volume. Large amounts of data tend to increase latency in providing insight into future operations. Furthermore, data related to a single road user (e.g., from different sources) may be inconsistent and potentially conflicting at any given time. Large amounts of data may also result in unnecessary notifications to certain road users, such as the vehicle of interest, also referred to as the ego vehicle. These problems are particularly acute when the ego vehicle is approaching or within an intersection, which is the most complex and dangerous area of ​​the traffic network.

[0024] Various solutions described herein include improving the operation of an ego vehicle approaching an intersection, navigating an intersection, etc., reducing latency over conventional data processing techniques, resolving road user data from different sources, effectively targeting road users for notifications to avoid collisions, or combinations thereof. To describe in more detail some implementations of intersection collision avoidance according to the teachings herein, reference is first made to an environment in which this disclosure may be implemented.

[0025] FIG. 1 is an example diagram of a portion of a vehicle 100 in which aspects, features, and elements disclosed herein may be implemented. The vehicle 100 may include a chassis 102, a powertrain 104, a controller 114, wheels 132 / 134 / 136 / 138, or any other element or combination of elements of a vehicle. For simplicity, the vehicle 100 is shown as including four wheels 132 / 134 / 136 / 138, but any other propulsion device, such as one or more propellers or treads, may be used. In FIG. 1, lines interconnecting elements, such as the powertrain 104, the controller 114, and the wheels 132 / 134 / 136 / 138, indicate that information, such as data or control signals, forces, such as power or torque, or both information and power, may be transferred between each element. For example, the controller 114 may receive power from the powertrain 104 and communicate with the powertrain 104, the wheels 132 / 134 / 136 / 138, or both, to control the vehicle 100, which may include accelerating, decelerating, steering, or otherwise controlling the vehicle 100.

[0026] Powertrain 104 includes power source 106, transmission 108, steering device 110, vehicle actuators 112, and may include any other element or combination of elements of a powertrain, such as a suspension, drive shaft, axles, or exhaust system. Although shown separately, wheels 132 / 134 / 136 / 138 may also be included in powertrain 104.

[0027] The power source 106 may be any device or combination of devices that operates to provide energy, such as electrical energy, thermal energy, or kinetic energy. For example, the power source 106 may include an engine, such as an internal combustion engine, an electric motor, or a combination of an internal combustion engine and an electric motor, that operates (or is configured) to provide kinetic energy as a driving force to one or more of the wheels 132 / 134 / 136 / 138. In some embodiments, the power source 106 includes a potential energy device, such as one or more dry batteries, such as nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), solar cells, fuel cells, or any other device capable of providing energy.

[0028] The transmission 108 receives energy, such as kinetic energy, from the power source 106 and sends the energy to the wheels 132 / 134 / 136 / 138 to provide motive power. The transmission 108 may be controlled by the controller 114, the vehicle actuators 112, or both. The steering device 110 is controlled by the controller 114, the vehicle actuators 112, or both and controls the wheels 132 / 134 / 136 / 138 to steer the vehicle. The vehicle actuators 112 may receive signals from the controller 114 and may operate or control the power source 106, the transmission 108, the steering device 110, or any combination thereof to operate the vehicle 100.

[0029] In the illustrated embodiment, the controller 114 includes a positioning device 116, an electronic communication device 118, a processor 120, a memory 122, a user interface 124, a sensor 126, and an electronic communication interface 128. Although shown as a single device, any one or more elements of the controller 114 may be incorporated into any number of separate physical devices. For example, the user interface 124 and the processor 120 may be incorporated into a first physical device and the memory 122 may be incorporated into a second physical device. Although not shown in FIG. 1, the controller 114 may include a power source 1210, such as a battery. Although shown as separate elements, the positioning device 116, the electronic communication device 118, the processor 120, the memory 122, the user interface 124, the sensor 126, the electronic communication interface 128, or any combination thereof, may be incorporated into one or more electronic devices, circuits, or chips.

[0030] In some embodiments, the processor 120 includes any existing or later developed device or combination of devices capable of manipulating or processing signals or other information, such as an optical processor, a quantum processor, a molecular processor, or a combination thereof. For example, the processor 120 may include one or more special purpose processors, one or more digital signal processors, one or more microprocessors, one or more controllers, one or more microcontrollers, one or more integrated circuits, one or more application specific integrated circuits, one or more field programmable gate arrays, one or more programmable logic arrays, one or more programmable logic controllers, one or more state machines, or any combination thereof. The processor 120 may be operatively coupled to the positioning device 116, the memory 122, the electronic communication interface 128, the electronic communication device 118, the user interface 124, the sensor 126, the powertrain 104, or any combination thereof. For example, the processor may be operatively coupled to the memory 122 via a communication bus 130.

[0031] The processor 120 may be configured to execute instructions. Such instructions may include instructions for remote operation that may be used to operate the vehicle 100 from a remote location, including an operations center. The instructions for remote operation may be stored on the vehicle 100 or received from an external source, such as a traffic management center or a server computing device, including a cloud-based server computing device. The processor 120 may implement some or all of the preventative risk mitigation described herein.

[0032] Memory 122 may include any tangible, non-transitory computer usable or computer readable medium capable of, for example, holding, storing, transmitting, or carrying machine-readable instructions, or any information associated therewith, for use by or in connection with processor 120. Memory 122 may include, for example, one or more solid-state drives, one or more memory cards, one or more removable media, one or more read-only memories (ROMs), one or more random access memories (RAMs), one or more registries, one or more low power double data rate (LPDDR) memories, one or more cache memories, one or more disks (including hard disks, floppy disks, or optical disks), magnetic or optical cards, or any type of non-transitory medium suitable for storing electronic information, or any combination thereof.

[0033] The electronic communication interface 128 may be a wireless antenna as shown, a wired communication port, an optical communication port, or any other wired or wireless device capable of interfacing with a wired or wireless electronic communication medium 140 .

[0034] The electronic communication device 118 may be configured to transmit or receive signals over a wired or wireless electronic communication medium 140, such as via an electronic communication interface 128. Although not explicitly shown in FIG. 1, the electronic communication unit 118 is configured to transmit, receive, or both over any wired or wireless communication medium, such as radio frequency (RF), ultraviolet (UV), visible light, fiber optics, wired, or a combination thereof. Although FIG. 1 shows a single electronic communication device 118 and a single electronic communication interface 128, any number of communication devices and any number of communication interfaces may be used. In some embodiments, the electronic communication device 118 may include a dedicated short-range communication (DSRC) device, a wireless secure unit (WSU), an IEEE (Institute of Electrical and Electronics Engineers) 802.11p (WiFi-P), or a combination thereof.

[0035] The positioning device 116 may determine geographic information including, but not limited to, the longitude, latitude, altitude, heading, or speed of the vehicle 100. For example, the positioning device may include a Global Positioning System (GPS) device, such as a Wide Area Augmentation System (WAAS)-enabled National Marine Electronics Association (NMEA) device, a radio triangulation device, or a combination thereof. The positioning device 116 may be used to obtain information representing, for example, the current heading of the vehicle 100, the current location of the vehicle 100 in two or three dimensions, the current angular heading of the vehicle 100, or a combination thereof.

[0036] The user interface 124 may include any device capable of being used as an interface by a human, including any of a virtual keypad, a physical keypad, a touchpad, a display, a touch screen, a speaker, a microphone, a video camera, a sensor, and a printer. The user interface 124 may be operatively coupled to the processor 120 as shown, or to any other element of the controller 114. Although shown as a single device, the user interface 124 may include one or more physical devices. For example, the user interface 124 may include a voice interface for conducting voice communication with a person, and a touch display for conducting visual and touch-based communication with a person.

[0037] Sensors 126 may include one or more sensors, such as an array of sensors operable to provide information that can be used to control the vehicle. Sensors 126 may provide information about the current operating characteristics of the vehicle or its surroundings. Sensors 126 include, for example, speed sensors, acceleration sensors, steering angle sensors, traction-related sensors, brake-related sensors, or any sensor or combination of sensors operable to report information about some aspect of the current dynamic situation of vehicle 100.

[0038] In some embodiments, sensors 126 include sensors operable to obtain information about the physical environment surrounding vehicle 100. For example, one or more sensors detect road geometry and obstacles, such as fixed obstacles, vehicles, cyclists, and pedestrians. Sensors 126 may be or include one or more video cameras, laser sensing systems, infrared sensing systems, acoustic sensing systems, or any other suitable type of on-board environmental sensing device or combination of devices, now known or later developed. Sensors 126 and positioning device 116 may be combined.

[0039] Although not separately shown, the vehicle 100 may include a trajectory controller. For example, the controller 114 may include a trajectory controller. The trajectory controller may be operable to obtain information describing the current state of the vehicle 100 and a planned path for the vehicle 100, and to determine and optimize a trajectory for the vehicle 100 based on this information. In some embodiments, the trajectory controller outputs signals operable to control the vehicle 100 such that the vehicle 100 follows a trajectory determined by the trajectory controller. For example, the output of the trajectory controller may be an optimized trajectory that may be provided to the powertrain 104, the wheels 132 / 134 / 136 / 138, or both. The optimized trajectory may be a control input, such as a set of steering angles, where each steering angle corresponds to one time or position. The optimized trajectory may be one or more paths, lines, curves, or combinations thereof.

[0040] One or more of the wheels 132 / 134 / 136 / 138 may be steered wheels that are pivoted to a steering angle under the control of the steering device 110, driven wheels that are given a torque to propel the vehicle 100 under the control of the transmission 108, or steered and driven wheels that both steer and propel the vehicle 100.

[0041] The vehicle may include devices or elements not shown in FIG. 1 , such as an enclosure, a Bluetooth® module, a frequency modulation (FM) radio device, a near field communication (NFC) module, a liquid crystal display (LCD) display device, an organic light emitting diode (OLED) display device, a speaker, or any combination thereof.

[0042] A vehicle, such as vehicle 100, may be an autonomous vehicle or a semi-autonomous vehicle. For example, as used herein, an autonomous vehicle as used herein should be understood to encompass vehicles that include advanced driver assistance systems (ADAS). ADAS can automate, adapt, and / or enhance vehicle systems for safer and better driving, such as by avoiding or correcting driver errors.

[0043] FIG. 2 is an example diagram of a portion of a vehicle traffic and communication system 200 in which aspects, features, and elements disclosed herein may be implemented. The vehicle traffic and communication system 200 includes a vehicle 202, such as the vehicle 100 shown in FIG. 1, and one or more external objects, such as the vehicle 100 shown in FIG. 1, which may include any form of transportation such as pedestrians, cyclists, and the like, as well as any form of structure such as a building. The vehicle 202 may travel through one or more portions of a transportation network 208 and may communicate with the external object 206 through one or more electronic communication networks 212. Although not explicitly shown in FIG. 2, the vehicle may travel in areas not explicitly or completely included in the transportation network, such as off-road areas. In some embodiments, the transportation network 208 may include one or more vehicle detection sensors 210, such as induction loop sensors, which may be used to detect the movement of the vehicle in the transportation network 208.

[0044] The electronic communications network 212 may be a multiple access system providing communications, such as voice, data, video, messaging, or combinations thereof, between the vehicles 202, the external objects 206, and the operations center 230. For example, the vehicles 202 or the external objects 206 may receive information, such as information describing the transportation network 208, from the operations center 230 via the electronic communications network 212.

[0045] The operations center 230 includes a controller device 232 that includes some or all of the features of the controller 114 shown in FIG. 1. The controller device 232 may monitor and coordinate the movement of vehicles, including autonomous vehicles. The controller device 232 may monitor the state or status of vehicles, such as vehicle 202, and external objects, such as external object 206. The controller device 232 may receive vehicle and infrastructure data including any of vehicle speed, vehicle position, vehicle operating conditions, vehicle destination, vehicle path, vehicle sensor data, external object speed, external object position, external object operating conditions, external object destination, external object path, and external object sensor data.

[0046] Additionally, controller device 232 may establish remote control over one or more vehicles, such as vehicle 202, or external objects, such as external object 206. In this manner, controller device 232 may remotely operate vehicles or external objects from a remote location. Controller device 232 may exchange (send or receive) status data with vehicles, external objects, or computing devices, such as vehicle 202, external object 206, or server computing device 234, via a wireless communication link, such as wireless communication link 226, or a wired communication link, such as wired communication link 228.

[0047] Server computing device 234 may include one or more server computing devices that may exchange (send or receive) status signal data with one or more vehicles or computing devices, including vehicle 202, external object 206, or operations center 230, via electronic communications network 212.

[0048] In some embodiments, vehicle 202 or external object 206 may communicate via wired communication link 228, wireless communication link 214 / 216 / 224, or any number or type of combination of wired or wireless communication links. For example, as shown, vehicle 202 or external object 206 communicates via terrestrial wireless communication link 214, via non-terrestrial wireless communication link 216, or via a combination thereof. In some implementations, terrestrial wireless communication link 214 includes an Ethernet link, a serial link, a Bluetooth link, an infrared (IR) link, an ultraviolet (UV) link, or any link that enables electronic communications.

[0049] A vehicle, such as vehicle 202, or an external object, such as external object 206, may communicate with another vehicle, external object, or operations center 230. For example, a host or target vehicle 202 may receive one or more automated vehicle-to-vehicle messages, such as a basic safety message (BSM), from operations center 230 via direct communication link 224 or via electronic communication network 212. For example, operations center 230 may broadcast a message to host vehicles within a predefined broadcast range, such as 300 meters, or to a defined geographic area. In some embodiments, vehicle 202 receives the message via a third party, such as a signal repeater (not shown) or another remote vehicle (not shown). In some embodiments, vehicle 202 or external object 206 transmits one or more automated vehicle-to-vehicle messages periodically based on a predefined interval, such as 100 milliseconds.

[0050] The vehicle 202 can communicate with the electronic communication network 212 via an access point 218. The access point 218, which may include a computing device, is configured to communicate with the vehicle 202, the electronic communication network 212, the operation center 230, or a combination thereof, via wireless or wired communication links 214 / 220. For example, the access point 218 may be a base station, a base transceiver station (BTS), a Node-B, an enhanced Node-B (eNode-B), a Home Node-B (HNode-B), a wireless router, a wired router, a hub, a relay, a switch, or any similar wired or wireless device installed, for example, in a cell tower. Although shown as a single device, the access point may include any number of interconnecting elements. The access point 218 may be a cellular access point.

[0051] Vehicle 202 may communicate with electronic communications network 212 via satellite 222 or other non-terrestrial communications device. Satellite 222, which may include a computing device, may be configured to communicate with vehicle 202, electronic communications network 212, operations center 230, or combinations thereof, via one or more communications links 216 / 236. Although shown as a single device, the satellite may include any number of interconnecting elements.

[0052] The electronic communications network 212 may be any type of network configured to provide voice, data, or any other type of electronic communications. For example, the electronic communications network 212 includes a local area network (LAN), a wide area network (WAN), a virtual private network (VPN), a mobile or cellular telephone network, the Internet, or any other electronic communications system. The electronic communications network 212 may use communications protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Protocol (IP), Real-time Transport Protocol (RTP), Hypertext Transport Protocol (HTTP), or combinations thereof. Although shown as a single device, the electronic communications network may include any number of interconnected elements.

[0053] In some embodiments, vehicle 202 communicates with operations center 230 via electronic communications network 212, access point 218, or satellite 222. Operations center 230 may include one or more computing devices that may exchange (send or receive) data from vehicles, such as vehicle 202, from external objects, such as external object 206, or from a computing device, such as server computing device 234.

[0054] In some embodiments, the vehicle 202 identifies a portion or condition of the transportation network 208. For example, the vehicle 202 may include one or more on-board sensors 204, such as sensors 126 shown in FIG. 1 , including speed sensors, wheel speed sensors, cameras, gyroscopes, optical sensors, laser sensors, radar sensors, acoustic sensors, or any other sensor or device capable of determining or identifying a portion or condition of the transportation network 208, or a combination thereof.

[0055] The vehicle 202 may navigate one or more portions of the transportation network 208 using information communicated over the electronic communications network 212, such as information representative of the transportation network 208, one or more on-board sensors 204, or a combination thereof. The external objects 206 may be capable of all or some of the communications and actions described above with respect to the vehicle 202.

[0056] For simplicity, Figure 2 illustrates a vehicle 202 as a host vehicle, an external object 206, a traffic network 208, an electronic communication network 212, and an operations center 230. However, any number of vehicles, networks, or computer devices may be used. In some embodiments, the vehicle traffic and communication system 200 includes devices, units, or elements not illustrated in Figure 2.

[0057] Although the vehicles 202 are shown communicating with the operations center 230 via an electronic communications network 212, the vehicles 202 (and external objects 206) may communicate with the operations center 230 via any number of direct or indirect communications links. For example, the vehicles 202 or external objects 206 may communicate with the operations center 230 via a direct communications link, such as a Bluetooth communications link. For simplicity, FIG. 2 shows one transportation network 208 and one electronic communications network 212, although any number of networks or communications devices may be used.

[0058] The external object 206 is shown in FIG. 2 as a second remote vehicle. The external object is not limited to other vehicles. The external object may be any infrastructure element, such as a fence, a sign, a building, etc., that has the capability to transmit data to the operations center 230. The data may be, for example, sensor data from the infrastructure element.

[0059] As briefly mentioned above, the large amount of traffic network data collected from vehicles, infrastructure, etc. can complicate its processing and usefulness, especially at intersections within a vehicular traffic network. The systems and methods described herein reduce the latency and / or complexity associated with predicting future behavior, address data inconsistencies, minimize notifications, or some combination thereof.

[0060] FIG. 3 is a diagram of a system 300 for intersection collision avoidance according to an implementation of the present disclosure. The system 300 may be implemented in a traffic and communication system of a vehicle 302, such as the vehicle traffic and communication system 200, as described in more detail below. Although described with respect to a vehicle 302 moving in a vehicle traffic network, such as the vehicle traffic network 208, the teachings herein may be used in any area operable by a vehicle. As used herein, an intersection in a vehicle traffic network includes paths on which vehicles may travel that intersect with one another, including entrances and exits to parking lots / garages, as well as paths within parking lots (e.g., between parking spaces in a parking lot). Other examples of the system 300 may include more, fewer, or other components. In some examples, the components may be combined. In other examples, the components may be split into more than one component.

[0061] In general, FIG. 3 illustrates a multi-tier architecture that uses multi-access edge computing (MEC) to process Cooperative Driving Automation (CDA) messages sent from vehicle and infrastructure sensors. The MEC then sends notifications back to vehicles and other road users (e.g., Vulnerable Road Users (VRUs), such as pedestrians or cyclists) to avoid collisions. These other road users may each be referred to herein as non-motorized road users. As shown, the system 300 desirably uses standards-based communications (e.g., standards-based communications protocols) that eliminate the requirement for direct vehicle-to-vehicle (V2V) or vehicle-to-pedestrian (V2P) communications. In the illustrated example, a cellular vehicle-to-vehicle (C-V2X) network (also referred to as Network C-V2X) is used for data / message exchange. The standards-based communications are based on the Society of Automotive Engineers (SAE) J3216 cooperative driving standard, although any suitable communications protocol capable of wireless communication using cellular technology may be used.

[0062] The system 300 receives respective signals 302a from one or more connected vehicles 302, which may be vehicles 100, 202. The signals 302a may include a position, a speed, or any other information. The signals 302a may include a BSM (e.g., an SAE2735 BSM). In some embodiments, described in more detail below, an intent signal INTENT may be transmitted from the connected vehicles 302.

[0063] The system 300 receives respective signals 304a from one or more VRUs, such as pedestrians 304. The signals 304a may include location, speed, or any other information. The signals 304a may include a personal safety message (PSM) (e.g., SAE2735 BSM). The VRUs or non-motorized road users carry communication devices, such as cellular devices, to transmit PSMs and, optionally, receive notifications, as described in more detail below. The cellular devices, also referred to as cellular-enabled devices, may be held by the road users in any suitable manner.

[0064] The system 300 receives respective signals 306a from one or more infrastructure sensors, such as infrastructure cameras 306. The infrastructure sensors may be associated with infrastructure in a vehicular traffic network. The infrastructure sensors monitor at least a portion of an intersection. The infrastructure sensors may be incorporated in a stand-alone roadside unit (RSU) or may be mounted on a building, a traffic light, a street light, etc. The infrastructure cameras 306 may transmit signals 306a that include information about what is detected, e.g., a vehicle, a VRU, an autonomous vehicle (AV). The signals 306a may include a position, a speed, or any other information. The signals 306a may include a BSM if a vehicle is detected and a PSM if a VRU is detected.

[0065] The signals 302a, 304a, and 306a are received at a cellular interface 308, which may include a wireless cellular transceiver (or a combination of a wireless receiver and a wireless transmitter) or an access point such as the access point 218 located at a cell tower. Processing of the received data may be performed at the MEC 310. The MEC 310 includes a signal interface 312, a system for generating a shared world model (SWM) 314, and a collision probability detection module 316. The MEC 310 is located at the edge of a mobile network such as the network 212 (as opposed to a cloud service on the public Internet). As such, the MEC 310 provides low latency for this application. Furthermore, because the computations are performed on the cloud, for example using the server computing device 234, the MEC 310 is highly scalable compared to performing the computations only in the vehicle, for example using V2V communications.

[0066] In the illustrated implementation, messages based on the SAE standard are transmitted from vehicle 302 to MEC 310 using network C-V2X over a cellular network from pedestrians 304, infrastructure cameras 306, or other VRUs, or combinations thereof. Further details of the communication system of MEC 310, including signal interface 312, may be understood by reference to Figure 4, which is a diagram 400 of one example of communication between a vehicle, such as vehicle 302, and system 300 of Figure 3.

[0067] As shown in FIG. 4, a vehicle, such as vehicle 100, 202, includes an interface 402. The interface 402 may be implemented, at least in part, by a processor, such as processor 120. In this example, the vehicle 302 is a connected vehicle, but not an autonomous vehicle. A connected vehicle is a vehicle that is connected to a cellular network, either directly or by an operator's cellular equipment. The interface 402 uses the vehicle's (e.g., its operator's) intent 404 as input. The vehicle's 302 intent 404 may be determined in any manner, such as by detecting a turn signal. Intent 404 may be input as a Robot Operating System (ROS) message in some implementations. Particularly useful optional techniques for determining the vehicle's intent 404 are described below.

[0068] The intent signal 404, also referred to herein as signal INTENT, goes through a data type conversion 406. The converted signal may be a JavaScript Object Notation (JSON) string 408. The JSON string 408 is converted to bytes 410 for input to an encoding mechanism 412. The encoding mechanism 412 encodes the bytes 410 and other sensor data (e.g., GPS) into an encoded signal in a format suitable for device-to-device communication over a cellular network. In one example, the encoding mechanism 412 encodes the data into JavaScript Object Notation (MQTT), a lightweight publish-and-subscribe network protocol that transfers messages between devices. The message 422 is transmitted over a cellular network, such as a mobile network of a particular cellular provider, to a cellular interface, such as cellular interface 308. The message 422 may be transmitted over a 4G network, a Long Term Evolution (LTE) network, such as 4G LTE, a 5G network, or any other cellular network now known or later developed. In some implementations, the message 422 may be transmitted using the electronic communication unit 118 .

[0069] The cellular interface 308 receives the encoded messages 422 and distributes them to one or more signal interfaces 312 for the MEC 310. That is, the MEC 310 is scalable as described above. Thus, the signal interfaces 312 may be replicated with subsequent components of the MEC 310 to accommodate different portions of the transportation network, larger amounts of data, etc. Thus, the cellular interface 308 may act as a broker of messages to determine which MEC 310 should process the incoming message. The encoded messages 422 are transmitted to the appropriate signal interface 312 over a network, such as a LAN 424. The signal interface 312 converts the messages back to ROS or another format for use by the remaining components of the system 300, i.e., the SWM 314 and the potential collision detection module 316.

[0070] As will be apparent from this description, the interface 402 and the signal interface 312 include hardware that collectively act as a gateway between the cellular network and the messages used by the SWM 314 and the potential collision detection module 316. In this example, the interfaces each convert data into MQTT format, publish the data, and then upon receipt, the MQTT messages are converted back to another format (e.g., the native format of the SWM 314 and the potential collision detection module 316) and used to determine potential collisions / collisions, as described in more detail below.

[0071] Interface 402 receives and encodes signal INTENT, although this is not required. The use of intent in the process of FIG. 3 is optional. For example, interface 402 may include only an encoding mechanism 412 to encode vehicle sensor data such as latitude, longitude, attitude, speed, or any combination thereof (e.g., BSM). FIG. 4 illustrates interface 402 implemented in a vehicle such as connected vehicle 302. A similar interface may be incorporated in an infrastructure sensor such as infrastructure camera 306 to encode and transmit detected signals such as signal 306a. Such an interface may include or omit hardware / software to determine and include vehicle intent when the vehicle is a detected object. An interface similar to interface 402 with an encoding mechanism may be included in a cellular-enabled device (e.g., a mobile phone) of a VRU to encode sensor data such as latitude, longitude, attitude, speed, or any combination thereof (e.g., PSM).

[0072] Referring again to FIG. 3, the MEC 310 uses object fusion to generate a shared world model (SWM 314) that can be used for prediction and potential collision detection. As seen above, the MEC 310 may receive data from multiple sources for the same object. For example, at an intersection, the MEC 310 may receive a signal 302a related to the connected vehicle 302's position, etc., and may receive a signal 302a including information regarding the connected vehicle 302's position, etc. Similarly, the MEC 310 may receive a signal 304a related to the VRU's (e.g., pedestrian 304) position, etc., and may receive a signal 304a including information regarding the VRU's position, etc. The SWM 314 receives the signals 302a, 304a, 306a, determines (e.g., transforms, detects, etc.) objects from the sensor data, fuses objects detected by multiple sources (if present), and generates a single world view of the road user and its surroundings.

[0073] As shown in FIG. 3, the SWM 314 includes an object association 314a and an object fusion 314b. In some implementations, the object association 314a may determine objects (e.g., road users) from the received signals 302a, 304a, 306a, e.g., BSM and PSM messages. For example, the object association 314a may associate the location information in each message with a respective road user, e.g., a connected vehicle in a vehicular traffic network, a VRU (e.g., a pedestrian or a non-motorized vehicle), or an autonomous vehicle. The object association 314a may generate or maintain at least some state of the determined objects, such as speed, pose, shape (width, height, depth, etc.), classification (e.g., bicycle, large truck, pedestrian, road sign, etc.), location, or some combination thereof.

[0074] Object fusion 314b may receive sensed objects over time in addition to signals 302a, 304a, 306a, e.g., BSM and PSM messages. For example, data such as heading and speed information may be used to fuse sensed objects accordingly. That is, data associated with each object may be compared to determine whether each object identified by separate messages may be the same object. Any technique for comparing data for each sensed object may be used. The more similar the data, the more likely the two objects are the same. Data for objects determined to be the same object is fused to generate tracked objects at their locations over time. That fused trajectory (e.g., based on a combination of heading, attitude, and speed) may be used in potential collision detection module 316. That is, at the output of SWM 314, each road user is a separate tracked object with its own trajectory or intended path, which is provided to potential collision detection module 316 for use therein.

[0075] Although described as a separate component of SWM 314, the shared world model used in MEC 310 may require many overlapping detections to produce a result, i.e., object association and fusion are combined and performed iteratively. Any implementation of this shared world model may be used in MEC 310, but a particularly preferred implementation of SWM 314 is described in more detail below.

[0076] The potential collision detection module 316 receives the tracked objects and their respective trajectories. The potential collision detection module 316 uses this information to predict potential collisions at intersections between connected vehicles, such as connected vehicle 302, and nearby vehicles or VRUs, such as pedestrians 304. In some implementations, the potential collision detection module 316 does this by using the trajectories over the look-ahead period to determine where each road user is at any point in time within the look-ahead period.

[0077] In some examples herein, infrastructure sensors of the RSU may detect non-connected road users (e.g., pedestrians) and connect them to connected road users (such as connected vehicles). For non-connected road users, predictions may be made by measurements (e.g., speed and direction) from infrastructure sensors over time. For connected road users, the intended path may be predicted from such measurements as well. However, at intersections, there may be changes such as turns that are not discernible from the measurements, so the measurements may not provide the best indication of the intended path. Thus, in some implementations, the signal INTENT may be used to determine the intended path of the connected vehicle, as described in more detail below. The predicted / intended trajectories of the road users may then be compared to determine whether a possible collision occurs.

[0078] To detect a possible collision between a non-connected road user (e.g., a pedestrian or a non-connected vehicle) and a connected vehicle, a location at a time or step within the look-ahead period that the non-connected user may reach is determined, e.g., using a predicted / intended path and speed, as in the case of a connected vehicle. The distance between the paths at future time steps may be calculated. A collision may then be detected if the distance between the paths is less than a threshold. In other words, if two or more road users are within a defined proximity of each other at a particular time, the possible collision detection module 316 may identify a potential collision and, optionally, send a notification to the connected vehicle and any other affected road users.

[0079] This is one technique for detecting a potential collision between two paths at some point in the future, however other techniques are possible and are described below by way of examples. Notification is also described in more detail below.

[0080] In some implementations, the potential collision detection may use the intent of the connected vehicle operator to determine the route of the connected vehicle for at least a portion of the look-ahead period, which in some implementations is the signal INTENT received from the connected vehicle 302 along with the signal 302a. The signal INTENT may be used to share the operator's intent for cooperative driving. Conventional safety systems may not consider intent that is not indicated by attitude, heading, speed, etc., and therefore may be overly reliant on the proximity of the connected vehicle to other vehicles or VRUs near the intersection.

[0081] In the above example, the turn indicators may be used to determine operator intent for use by the potential collision detection module 316. For example, the turn indicators may indicate that the connected vehicle 302 is to turn right at a four-way intersection. Together with other information received from road users near the intersection, the potential collision detection module 316 may issue a notification that is the result of a more accurate prediction than relying solely on BSM and PSM messages. Specific examples of the signal INTENT are described further below.

[0082] When a connected autonomous vehicle (CAV) is at or near an intersection where a connected vehicle or VRU is approaching or operating, the CAV's decision making can be improved using the teachings herein. In FIG. 3, the CAV 320 is conventionally shown as including sensor inputs to a fusion unit 324. The hardware sensors shown include a camera and a LiDAR (Light Detections and Ranging) sensor. Other sensors conventionally found on an autonomous vehicle may include GPS and a RADAR (radio detection and ranging) sensor. The fusion unit 324 receives signals and fuses objects identified by the sensors into tracked objects for inclusion in a shared world model executed by a processor of the CAV 320, such as the processor 120 of FIG. 1.

[0083] An autonomous vehicle such as the CAV 320 conventionally has a shared world model. According to implementations of the present disclosure, the shared world model of the CAV 320 may also receive BSM and PSM messages from the cellular interface 308 to refine the shared world model. That is, the CAV 320 may include another instance of the SWM 314 executed by a processor of the CAV 320, such as the processor 120 of FIG. 1, to generate tracked objects and their respective trajectories, in addition to adjusting its own sensor values ​​to identify objects using the fusion unit 324. The shared world model of the CAV 320 may differ (i.e., may operate differently) from the SWM 314 in some implementations. In any case, the tracked objects and their respective trajectories are transmitted to the decision-making module 326. The decision-making module 326 may be a conventional module for decision-making that already addresses collision detection and resolution, so the CAV 320 does not need a separate collision likelihood detection module, such as the collision likelihood detection module 316.

[0084] As described above, the shared world model may be used in a system for intersection collision avoidance, whether the system is located in the vehicle or at a remote computing location. In general, it is desirable to combine object detections from multiple sensors to avoid confusing the system. For example, multiple sensors may detect a pedestrian at different locations when only one pedestrian is present. Without using the shared world model, the ego vehicle may attempt to avoid multiple pedestrian detections rather than a single pedestrian.

[0085] In some implementations of a shared world model that can be used as SWM 314, the time to combine object detections from multiple sources may be determined by the slowest sensor because the shared world model may require duplicate detections that perform repeated object association and fusion. Results may take up to seconds to be generated. This situation is further exacerbated when communication delays are added. For example, in system 300, communication delays may occur when transmitting information from connected sensors over a cellular network. Receiving and analyzing sensor data in a timely manner is important for safety-critical maneuvers, such as activating automatic emergency braking (AEB) or making sudden steering turns.

[0086] An example of a particularly desirable system 500 for generating a shared world model is shown in FIG. 5. System 500 addresses some of the latency issues discussed above by separating the object association and object fusion steps and combining object detection from different sensors. The resulting shared world model may be used as SWM 314 of FIG. 3. The resulting shared world model may be used for intersection collision avoidance in accordance with implementations of the present disclosure. The proposed architecture of system 500 allows for faster action than conventional techniques and is limited only by the fastest sensor, not the slowest (e.g., most delayed) sensor. Although particularly useful for connected autonomous vehicles such as MEC 310 and, optionally, CAV 320, system 500 may be used in any autonomous vehicle that receives external sensor data (i.e., sensor data from sensors other than the autonomous vehicle's sensors).

[0087] As seen in FIG. 5, inputs 502 are received from sensors numbered 1, 2, ... N. The inputs 502 may correspond to a BSM from a connected vehicle, a PSM from a VRU, a PSM from a connected vehicle occupant, a PSM from an infrastructure sensor, a BSM from an infrastructure sensor, or some combination thereof as described above with respect to FIG. 3. At least some of these inputs 502 are asynchronous signals or messages. That is, each sensor has its own characteristics, such as sampling rate. Furthermore, the amount of time required for each sensor to communicate with the SWM 314 (e.g., to the cellular interface 308 of FIG. 3) may be different. Thus, each signal may be transmitted at a different time and / or received at a different time.

[0088] The inputs 502 are received at respective perception and filter modules 504. The perception and filter modules 504 may partially implement the object association 314a. The perception and filter modules 504 generate, determine, perceive, or otherwise identify objects (e.g., road users) from the respective inputs. Any technique may be used to identify objects from the inputs, including, but not limited to, pattern matching, comparison to a library of data, etc. As shown by the dashed lines in FIG. 5, the detection of perceived objects from different sensors is sent immediately to downstream decision making (e.g., the object fusion and prediction module 610 described below), while object association continues in parallel at the interpolator 606. These detections may be referred to as asynchronous detectors.

[0089] A master clock, which may be referenced to various timing sources, provides a synchronized output to the interpolators 506. The perceived objects are also provided to the interpolators 506 as described above. The perceived objects are provided with the time points at which they are perceived, which are asynchronous. Each of the interpolators 506 for each perceived object may be used to interpolate the perceived object with synchronized timing based on a signal from the master clock. That is, based on the asynchronous detection and other data from the input 502 (e.g. speed, heading, etc.), the position of the perceived object at the synchronized time point indicated by the master block is determined.

[0090] Each of the interpolators 506 outputs two signals based on the perceived object positions at the synchronized time points. The first signal is called the synchronization tracklet. The synchronization tracklet is the perceived object position at each time point indicated by the master clock. These tracklets are provided to the track association and calibration module 608 and the object fusion and prediction module 510. The second signal is called the synchronization detection. These synchronization detections are provided to the track association and calibration module 508 and the object fusion and prediction module 510.

[0091] The track association and calibration module 508 receives the synchronized tracklets and the synchronized detections and associates the synchronized time signals with their respective objects over time. Object association is the matching of an object perceived by one sensor with an object perceived by another sensor, possibly from a different perspective (e.g., infrastructure camera observations of a pedestrian with a GPS location of the pedestrian reported from a mobile phone). The track association and calibration module 508 may also calculate external relative sensor calibration. The object association and sensor calibration are sent to the object fusion and prediction module 510.

[0092] The object fusion and prediction module 510 fuses the overlap detections in a shared world model, including, for example, objects and their predicted paths. The shared world model is sent for decision making 512. For example, connected road users (vehicles, pedestrians, etc.) may rely on cloud potential collision detection decision making, such as in potential collision detection module 316, to send timely warnings of detected hazards. An autonomous vehicle initially relies on its own sensors for decision making, but can augment its world model with (delayed) detections from connected sensors outside the vehicle, when available, such as in decision making module 326.

[0093] Sensor calibration aids in object fusion and can be retained to speed up future associations.

[0094] In addition to reducing latency relative to competing techniques for generating shared world models, system 500 may generate more accurate shared world models, i.e., performing object fusion with incorrectly associated objects introduces errors that are difficult to correct. The delay in object fusion caused by decoupling object fusion from object associations reduces the likelihood of such errors.

[0095] As mentioned with respect to the description of FIG. 3, the intent of the vehicle (e.g., the intent of the vehicle operator) can be useful in detecting a collision or potential collision. The probability of a collision between a vehicle (e.g., a connected vehicle) and another vehicle or VRU can be predicted with greater accuracy if the intended path of each vehicle is known for the next few seconds. For example, if a right turn signal is on, it may not be clear from the direction or speed alone whether a vehicle is going to turn right, pass a vehicle, or change lanes.

[0096] In general, the technology proposed herein may use high definition maps (HD maps) along with either a destination or turn signals entered into a navigation system to predict the connected vehicle's future route. FIG. 6 is a flow chart of a method 600 for determining the intent of a connected vehicle. The method 600 may be performed by a processor of the connected vehicle, such as a processor of the connected vehicle 302. The processor of the connected vehicle may be a stand-alone processor, a processor of an in-vehicle navigation system, or a processor integrated into the connected vehicle's cellular interface, such as interface 402.

[0097] In step 602, a destination message may be determined or received for a connected vehicle of interest (e.g., a vehicle entering, crossing, approaching, etc. an intersection). The destination message may be determined or received from the vehicle's on-board navigation system if one exists (e.g., if one is established for the vehicle). In step 604, a turn indicator direction message for the vehicle may be determined or received. The turn indicator direction may be referred to as the turn indicator direction or simply as direction herein. The turn indicator direction may be determined periodically when the vehicle is within a defined distance from the intersection and / or when the vehicle generates a turn indicator change message in response to an operator action to activate or deactivate the turn indicator. When the turn indicator is off, the direction is straight ahead.

[0098] The HD map is used as input in step 606. That is, the HD map may provide input in step 606 to calculate a potential intended route for the vehicle using the destination (e.g., destination message) in step 612. For example, the potential intended route may be or include a lane-wise route to the destination. Because the HD map provides speed limits and other road features such as stop lines and crosswalks, this information may be used to define multiple waypoints along the route with information such as the type of waypoint and the speed limit for the next few seconds, such as 10-15 seconds (also referred to as a driving target).

[0099] Alternatively, or in addition, the HD map may provide input in step 606 to calculate potential intended routes for the vehicle using the turn signal direction in step 614. The HD map's speed limits and other road features, such as stop lines and crosswalks, may provide input in step 606 to define multiple waypoints along the route, using information such as the waypoint type and the speed limit for the next few seconds, taking into account, for example, whether the turn signal direction is indicating a right turn, left turn, or off (e.g., when entering an intersection or after a turn or lane change is completed).

[0100] Once a potential intended route is calculated in step 612, 614, or both, method 600 proceeds to determine which potential intended route is the most accurate prediction. If there is a destination available in step 602 and a potential intended route is calculated in step 612, method 600 queries whether a turn signal direction is available in step 622. If not, method 600 uses the potential intended route calculated from the destination as an indication of the vehicle's intent in step 632. In contrast, if there is a turn signal direction available in step 604 and an intended route is calculated in step 614, method 600 queries whether there is a destination available in step 624. If not, method 600 uses the potential intended route calculated from the turn signal direction as an indication of the vehicle's intent in step 634.

[0101] If there is a turn signal direction in step 622 and a destination in step 624, the method 600 determines in step 630 whether the turn signal direction matches the potential intended route calculated in step 612. For example, the method 600 determines whether the intended route includes a right turn or, if the turn signal changes to a right turn, a change to the right lane. If they match in step 630, the method 600 uses the intended route calculated from the destination as an indication of the vehicle's intent in step 632. If not, the method 600 uses the intended route calculated from the turn signal as an indication of the vehicle's intent in step 634. These choices reflect two considerations. First, the turn signal alone is not the most accurate measure of the driver's intent. Second, if both the turn signal and the destination are available, the turn signal may improve the measure of the driver's intent. For example, turn signals that conflict with the intended route determined in step 612 likely indicate that the vehicle operator has decided to change the most likely route generated using the destination.

[0102] In either case, the travel objectives help determine when and where the vehicle is predicted to be at a particular time within the next few seconds. This information may be used along with the presence, intent, or both of other road users (e.g., vehicles, VRUs, etc.) to predict the probability of a collision or possible collision. For example, points along each of the road users' predicted paths at intersections may be used to identify potential collisions when no action is taken as described above with respect to the possible collision detection module 316.

[0103] In some implementations, the intended path determined by repeatedly executing method 600 may be used to generate a signal INTENT indicating the intent of the connected vehicle (e.g., of an operator of the connected vehicle), as described with respect to Figure 3. When used in the implementation of Figure 3, the signal INTENT may be used as an input to potential collision detection module 316.

[0104] In one example, once a destination is set in the navigation system, in step 612, a route to the destination is generated using an HD map. This provides a list of lane segments from the vehicle's current position to the destination. In generating the intent, only a portion of the route ahead where the vehicle will travel for a defined amount of time or a defined distance may be considered. For example, only the portion of the route for the next 15 seconds or 500 meters, whichever is greater, is considered. This limits the amount of data that needs to be transmitted for the intent. A list of driving objectives (e.g., waypoints, time points, time steps) is generated from the lane segment where the vehicle is located to the end of the selected route (e.g., to the end of the portion of the route). Each driving objective may include information such as speed limit, type of objective (e.g., stop, crosswalk, etc.). An example of the format of the intent message (e.g., signal INTENT) is shown below. [Table 1]

[0105] The list of travel goals in the intent message may be a separate travel goal message. An example of the format of the travel goals included in the intent message is shown below. [Table 2]

[0106] When the turn signal is used, the path ahead (lane segments) is queried from the HD map. If another intersection comes after the last turn, an intended path may be generated only up to the new intersection. After that, a new intended path may be generated for the next intersection.

[0107] In accordance with the teachings herein, the use of HD maps along with either the destination or the turn indicators (or both) allows for a more accurate prediction of what the connected vehicle is doing than using speed and turn indicators. For example, this technology provides the intended speed as well as the intent at different points along the route. Additionally, this technology allows the vehicle to determine which lane to follow for the next few seconds. This is useful in safety applications to notify the driver of an impending collision.

[0108] For non-connected vehicles and VRUs, the heading and trajectory may be used to determine a predicted path for a look-ahead period (15 seconds or 500 meters in this example), as briefly described above with respect to FIG. 3. In some implementations, at least a portion of the method 600 may be performed by a processor in an RSU (e.g., the infrastructure sensor is housed in the RSU) that supports an infrastructure sensor, such as the infrastructure camera 306. For example, the RSU may determine a turn signal change message for the non-connected vehicle in step 604. The turn signal change message, if present, may be detected from an image received by the infrastructure sensor. From there, in step 614, an intended path may be calculated and used as a signal INTENT for potential collision detection, such as by the potential collision detection module 316 or a processor in the RSU, in step 734.

[0109] As can be appreciated from the above discussion, there may be uncertainties in the intended or predicted path due to, for example, technical limitations of infrastructure sensors, imperfections in predictive models, and unknown intent of road users, particularly VRUs. To address some of these uncertainties and improve detection of potential collision possibilities, such as in collision possibility detection module 316, the techniques described herein describe collision possibility or hazard zones where a VRU may collide with a vehicle. This technique may be described with reference to FIG. 7, which is a diagram of an intersection 700.

[0110] FIG. 7 is a three-way intersection 700, where a street 702 has a road median 704. In some implementations, zones may be predefined for the intersection based on potential locations where a VRU will cross the road, such as where collisions are likely. The size of the zones may be determined based on statistics of VRU (e.g., pedestrian) accidents, such as the potential extent to which a VRU will move in different locations and at different speeds within the intersection. FIG. 7 shows five zones 706 as an example. Default zone sizes may be defined. In some implementations, the zone size may be determined upon detection of the VRU based on the location of the VRU relative to the intersection, and optionally the type of VRU and / or the speed of the VRU (e.g., a bicycle will have a wider zone than a pedestrian).

[0111] During operation, a processor associated with the RSU (e.g., associated with the infrastructure sensors of the RSU) or a processor associated with a shared world model such as SWM 314 may identify the location of the VRU over time (as a non-connected road user). Once identified, a zone may be defined for the VRU. The zone may be a predefined zone at the detected location, a default zone size arranged according to the location, or a zone size determined as described above arranged according to the location. Measurements so made may be used to generate a predicted path, as described above with reference to an example of the potential collision detection module 316.

[0112] Instead of restricting road users to predicted paths to detect potential collisions in an intersection, zones may be used for collision possibility detection where at least one of the road users is a VRU. In an example where a vehicle is approaching an intersection where a VRU is also present, the predicted trajectory may be used to determine the time when the VRU is crossing a zone, such as one of the zones 706. The time when the vehicle is crossing a zone may be determined according to a predicted path (e.g., when there is no signal INTENT) or an intended path (e.g., when signal INTENT is used). As mentioned above, this may be performed at a time step or point in time relative to the look-ahead period. Once the point in time is known, a potential collision possibility is identified if the intended path of the vehicle and the predicted path of the VRU cross the zone at the same time.

[0113] For example, FIG. 8 illustrates a three-way intersection 800 similar to the intersection 700 illustrated in FIG. 7, except that the median strip 704 is not present. Thus, three zones may be defined for the intersection. In FIG. 8, an ego (e.g., connected) vehicle 802 is traveling in a first direction along a street 810. An arrow 804 indicates the intended path of the vehicle 802. A (e.g., non-connected) vehicle 806 is traveling in the opposite direction along the street 810. A pedestrian 808 (such as a VRU) has a predicted path that crosses a zone 820. A potential collision is detected based on when the vehicle 802 crosses the zone 820 relative to the pedestrian 808. A notification 830 may then be issued, such as from the collision potential detection module 316, to the ego vehicle 802. If a collision potential is detected, a level of collision potential may be calculated based on the level of deceleration required to avoid the collision. In some implementations, the level of deceleration may be compared to a maximum deceleration such that a notification is not issued until the level of deceleration approaches the maximum deceleration.

[0114] As described above with respect to the potential collision detection module 316, to detect a potential collision between vehicles, whether connected or not, a predicted path of each vehicle may be determined. That is, the path and speed of each vehicle may be used to compare the future positions of the vehicles. With reference to FIG. 9, for example, a first vehicle 902 may have a predicted path 912 at a defined time step 906, while a second vehicle 904 may have a predicted path 914 at the same defined time step 906. That is, the path and speed of the vehicles are used to calculate the future positions of each. The distance between the paths 912, 914 at the future time step 906 may be calculated. In FIG. 9, the distance d 1 is the first distance between the paths 912 and 914, and the distance d 2 is a second distance between paths 912, 914. The paths 912, 914 converge to a potential collision in step 920. If the distance between paths 912, 914 is less than a threshold at some point before step 920, a potential collision may be identified and a notification may be issued. If at least one of the vehicles is a connected vehicle, the associated path 912 or 914 may be an intended path (i.e., one that takes into account the intent of the vehicle, such as signal INTENT).

[0115] Although zones may be used for collision probability / detection in the case of VRUs as described above, zones may be used for other non-connected road users as well, such as non-connected vehicles.

[0116] Regardless of the type of road user approaching the intersection, potential collision detection may be performed by a processor of the RSU instead of or in addition to the potential collision detection module 316. To do so, the RSU may host a shared world model consistent with the potential collision detection module 316 and SWM 314 of the MEC 310, which receives signals from the cellular interface 308 in a manner similar to how the signal interface 322 receives signals. Alternatively, the RSU may host a potential collision detection module similar to the potential collision detection module 316, which receives objects and trajectories from the SWM 314 (e.g., via a wireless cellular network), performs potential collision detection, and issues notifications as needed. In another implementation, the intended path of the connected vehicle may be received at the RSU.

[0117] Collision warning at intersections can reduce the risk of collisions for VRUs and other road users. Useful early warnings for possible collisions need to be not only accurate and precise, but also targeted. Warnings should be given to the vehicle operator when they are really needed. Giving warnings for every detected collision may not actually help the operator to prevent collisions. Too many warnings can overwhelm the operator and distract the operator from serious possible collisions. On the other hand, complex traffic situations can distract the vehicle operator from situations that may be safety-critical for the VRU.

[0118] Next, we describe techniques that may be used to identify or model which driving conditions (e.g., routes through intersections) are more critical for safety warnings or notifications than other routes. Knowing this, targeted warnings or notifications can be delivered to (e.g., connected) vehicles, while avoiding or minimizing less useful warnings. This technique may use a database that contains routes through intersections that have been identified as more critical than others. The database may be stored in a storage or memory located in the MEC 310 or in a storage or memory of the RSU for a given intersection.

[0119] An example of identifying routes and database contents that are more critical may be described with reference to a four-way intersection 1000 in FIG. 10. In general, the identified routes are those where the operator tends to divert attention from the VRU in favor of other road users. In such cases, special attention by the operator may be desirable. In a normal intersection where the vehicle travels in the right lane, such as the intersection 1000, the operator may miss the VRU (e.g., a non-motorized driver) while making an (e.g., unprotected) left turn maneuver because he is paying more attention to the traffic on the other side. FIG. 10 shows the vehicle's travel direction in the intersection lane with solid lines. As shown by the dashed lines in FIG. 10, there are four left turns that the vehicle may travel through the intersection 1000. Thus, the four potential routes through the intersection 1000 where the vehicle may turn left are as shown in Table I below.

[0120] [Table 3]

[0121] In this implementation, these paths are more important than the four straight path through the intersection 1000 from lane 4 to lane 1, lane 2 to lane 7, lane 8 to lane 5, and lane 6 to lane 3, and more important than the four right turn paths through the intersection 1000 from lane 4 to lane 3, lane 2 to lane 1, lane 8 to lane 7, and lane 6 to lane 5. In other implementations, the right turn paths may be considered more important than the four straight path.

[0122] In operation, an intended path for a connected vehicle, such as connected vehicle 302, may be received. As described above, the intended path may be generated using signal INTENT. In some implementations, a predicted path may be received instead of the intended path. As described above, the predicted path may be generated using continuous signals including position, heading, etc. from connected vehicle 302, from infrastructure sensors, such as infrastructure camera 306, or both (e.g., optionally combined into a shared world model, such as SWM 314). The intended path determines (defines, identifies) both the oncoming and offgoing lanes for the vehicle. The combination of the oncoming and offgoing lanes of the intersection may then be compared to the intended path to determine whether the path is in the database as being a path that requires additional driver or operator attention.

[0123] If the combination is in the database, then the path may be labeled or otherwise identified for further consideration in a potential collision detection process, such as the process performed by potential collision detection module 316. In Figure 10, for example, if the vehicle is taking a path from lane 2 to lane 5, the path is labeled because this path is located in the database as shown in Table I. In contrast, if the vehicle is taking a path from lane 2 to lane 7, the path is not labeled.

[0124] Once a route is identified for a potential collision detection process, the route is given additional consideration; i.e., the route uses a different notification process than the standard notification process. For example, the notification threshold may be modified such that the potential collision detection module 316 provides an earlier notification of the presence of a VRU to the connected vehicle operator than the potential collision detection module 316 does for other routes. In some implementations, this may be accomplished by decreasing the maximum deceleration value discussed above. In other implementations, the additional consideration given to the route may correspond to providing a notification based on the VRU being within a defined distance from the connected vehicle, regardless of whether a potential collision exists or does not exist as a result of the potential collision detection.

[0125] Figure 10 and Table I show an intersection as an example. Referring back to Figure 8, an example of a three-way intersection 800 is shown. In this example, there is one unprotected left turn because there is a stop sign on the street where a pedestrian 808 is crossing (as seen by the stop line). Thus, the database contains one entry. A vehicle 802 is turning left as indicated by arrow 804, which corresponds to a path identified in the database for the intersection 800. The potential collision detection process issues a targeted warning or notification 830 based on criteria for the path in the database that differs from the criteria used for either the straight path of the vehicle 802 or vehicles approaching the stop line in the other direction.

[0126] It is not necessary to detect potential collisions or possible collisions and send warnings for all routes through an intersection. All such warnings or notifications may overwhelm or distract the operator. According to the teachings herein, the driver attention model (e.g., using a database) includes routes that may distract the operator from the VRU for other road users. Routes of connected vehicles that are so included are identified so that the operator can pay additional attention to the VRU. The attention model is easy to build and maintain, and therefore easily adapted to different intersections. Moreover, the model can be easily adjusted based on the statistics of accidents at the intersection, making the system flexible and robust.

[0127] In the above description, road users that are relatively easy to detect are described. Some road users, especially VRUs, may be difficult to detect. This makes it difficult to accurately target notifications.

[0128] For example, occlusion is important for the safety of VRUs at intersections. A VRU that cannot be easily seen by an operator or detected by an on-board sensor may increase the risk of a collision at an intersection. A technique for detecting whether a VRU is occluded to a vehicle and sending an early warning to the vehicle to reduce the risk of a collision between the vehicle and the occluded VRU at an intersection is now described with reference to FIG. 11, which shows an intersection integrated with system 300. However, this technique may be used only by the RSU for a given intersection.

[0129] In general, in an RSU, infrastructure sensors such as infrastructure cameras 306 may detect the positions of all road users, including dynamic connected road users and non-connected road users, at an intersection on a two-dimensional (2D) plane, such as the example intersection 1100 shown in FIG. 11. Road users may include pedestrians, cyclists, cars, trucks, etc., also called dynamic obstacles. The RSU may recognize the environment around the intersection, such as static obstacles (buildings, infrastructure, parked vehicles), in addition to dynamic obstacles. As described earlier, this may include information such as the position, shape, and dimensions of each obstacle.

[0130] In general, if the obstacles and positions are known, it can be determined whether an occlusion exists between two objects by checking whether the line of sight between the two objects is blocked by a static or dynamic obstacle. Collision warnings can then be targeted to the occluded road users.

[0131] Specifically, referring to the example of FIG. 11, the road users include a connected vehicle 302 and a pedestrian 304 as moving obstacles. Another road user is a parked vehicle 1102. The intended path of the connected vehicle 302 is indicated by a waypoint 1104. The intended path may be determined using the signal INTENT, as described above. To check whether a road user is occluded to the other road user, the respective positions are identified. Then, a straight line segment between the two positions is calculated. In FIG. 11, the straight line segment 1106 extends beyond the two initial positions of the connected vehicle 302 and the pedestrian 304 for clarity.

[0132] Whether a road user is occluded to other road users is determined depending on whether the calculated line segment, such as line segment 1106 in this example, intersects with other moving or stationary obstacles at the intersection. For example, in Figure 11, pedestrian 304 is labeled as occluded to connected vehicle 302 because there is an intersection between stationary (parked) vehicle 1102 and line segment 1106. Targeted notifications can then be issued to connected vehicle 302, pedestrian 304, or both. This process can be repeated over time using updated positions of road users and line segments.

[0133] To minimize notifications, notifications may be omitted if there is a clear line of sight (e.g., no line segments intersect with obstacles). In some implementations, notifications may be issued as described above if the target deceleration is exceeded when a potential collision occurs. Using this occlusion model, potential collision warnings can be better targeted to occluded road users. These targeted warnings can increase the usefulness of the potential collision warning system.

[0134] 12A-12C show examples of notifications that may be issued when a potential collision is detected, such as by a potential collision detection module or a processor of an RSU. In the example of FIG. 11, either the potential collision detection module 316 or the processor of the RSU may determine that there is a potential collision between the connected vehicle 302 and the pedestrian 304 in an intersection 1100. In each of these examples, the connected vehicle 302 is predicted to make a right turn at the intersection, and the pedestrian 304 is on a sidewalk adjacent to the road or crossing the road after the right turn.

[0135] FIG. 12A is an example of a notification such as notification 302b issued from the potential collision detection module 315 of FIG. 3 to a connected vehicle. The notification is a map display notification showing a potential path through the intersection and the relationship of the pedestrian to that path on the left, and a notification showing the presence of a pedestrian ahead on the right. FIG. 12B is another example of a notification for the same condition using a head-up display. Each of these notifications may be issued to the operator of the connected vehicle using a cellular network. The third example of FIG. 12C uses a cellular network connection between the MEC 310 and a mobile phone. The example of FIG. 12C can be used to provide notification 302b to the connected vehicle 302. However, this is less desirable than using the examples of FIG. 12A and FIG. 12B to notify the connected vehicle 302. The example of FIG. 12C is preferably used to issue notifications such as notification 304b to the pedestrian 304 from the potential collision detection module 315 of FIG. 3.

[0136] The technique shown in FIG. 11 does not rely on sensory data from vehicles, although such sensory data may be used as described above with respect to MEC 310. Instead, the occlusion model may use only detections from infrastructure sensors such as RSUs along with basic geometry / physics. Thus, the technique may be generally applied to all road users. In some implementations, non-occluded road users may be filtered before determining potential collision possibilities between road users. Such filtering may reduce the computation required to check for collision possibilities between road users.

[0137] In the above description, the viewing angle from a road user of interest (e.g., an ego vehicle such as connected vehicle 302) is unlimited. In general, occlusion is determined when the line of sight is blocked by an obstacle. Rather than simply assuming unlimited viewing angles from the vehicle, in some implementations the line of sight may be further limited to a certain range of angles. For example, the range of angles may depend on a model of the viewing angle of a human driver. The range of angles may be limited to +60 degrees to -60 degrees from the vehicle's heading direction.

[0138] In implementations where line of sight is limited, the human driver's viewing angle can be more accurately determined using line of sight tracking sensors. If line of sight can be tracked by an on-board sensor and shared with the RSU or MEC 310, occlusion detection can be more accurate. As an example, the direction of the operator's line of sight relative to the vehicle's heading may be measured and transmitted using wireless communication, such as cellular communication. The RSU or MEC 310 processor may infer the range of angles relative to the line of sight depending on the vehicle's relative angle and heading angle. In some implementations, eye tracking may continuously or periodically sense the direction of gaze relative to the vehicle's heading, and the inference of the range of angles may be updated in the same manner.

[0139] In some implementations, the human viewing angle model may be omitted or supplemented. That is, the above relies on the ability to infer line of sight based on a (e.g., world) model using observations made by infrastructure sensor(s) at the intersection. In practice, the technical limitations of the sensor(s) may result in an insufficient model to detect all occlusions or filter out non-occlusions. Instead of or in addition to sensor data, what the human driver or operator can see may be based on on-board sensor perception data. If the vehicle has on-board sensors and can share perception data from the on-board sensors, occlusion detection can be further improved with more accurate viewing angles from the vehicle by integrating observations from the on-board sensors.

[0140] Although occlusion detection has been described to target warnings to vehicle operators, occlusion detection may also be useful to autonomous vehicles to increase situational awareness around or within an intersection.

[0141] According to some aspects of the teachings herein, a system for intersection collision avoidance may include a processor. The processor may include a shared world model configured to receive signals from at least two road users proximate an intersection in a vehicle traffic network, the at least two road users including an ego vehicle, and the shared world model is an output of a shared world model generation system. The shared world model generation system includes an object association module that associates position information in each message forming the signal with a respective sensed object over time, and an object fusion module that is configured to integrate data of the at least two sensed objects to identify a position of the same road user when the at least two sensed objects correspond to the same road user. Processing by the object association module is separated from processing by the object fusion module such that a generation rate of the shared world model is limited by the fastest sensor providing a signal as opposed to the slowest sensor providing a signal. The processor may also include a potential collision detection module that receives object information from the shared world model, detects a potential future collision between the ego vehicle and another of the at least two road users, and sends a notification of the potential future collision to the ego vehicle.

[0142] In one particular variation of this system, the signals from the at least two road users include asynchronous signals received at a perception and filter module of the shared world model generation system, which generates an asynchronous detection of the object from the asynchronous signal and transmits the asynchronous detection to an interpolator of the shared world model generation system while simultaneously transmitting the asynchronous detection to an object fusion module, which uses the asynchronous detection to generate synchronous outputs of the respective objects for each of the object association module and object fusion module.

[0143] In one variation of this system, the signals from the ego vehicle include an intent signal including a set of driving objectives, the intent signal being generated based on at least one of a state of a turn indicator of the ego vehicle or a destination setting of the ego vehicle.

[0144] In one variation of the system, a potential collision detection module receives the intent signal and uses the intent signal to detect a potential future collision.

[0145] According to some aspects of the teachings herein, a system for intersection collision avoidance may include a processor that may be configured to: receive a first signal identifying a location of a first road user proximate an intersection in a vehicle traffic network, the first road user being an ego vehicle connected to a cellular network; receive a second signal identifying a location of a second road user proximate the intersection, the second road user being a non-motorized road user; receive at least one of a state of a turn indicator of the ego vehicle or a destination setting of the ego vehicle; define a potential collision zone of the intersection, the potential collision zone being an area of ​​the intersection where a non-motorized road user is likely to collide with a motorized road user; generate an intended path for the ego vehicle to traverse the zone using the first signal and at least one of the state of the turn indicator of the ego vehicle or the destination setting of the ego vehicle; detect a potential future collision between the ego vehicle and the non-motorized road user based on the ego vehicle and the non-motorized road user simultaneously traversing any point of the zone within a look ahead period; and transmit a notification of the potential future collision to the ego vehicle via the cellular network.

[0146] In certain variations of this system, the non-motorized road users are pedestrians.

[0147] In certain variations of this system, the processor may be configured to enable notification of a potential upcoming collision to be sent to non-motorized road users.

[0148] In certain variations of this system, the processor may be configured to receive a third signal identifying a location of a third road user proximate the intersection, the third road user being a motorized road user not connected to the cellular network, use the third signal to generate a predicted route for the third road user to cross the zone, and detect whether the third road user crosses the zone at a same look ahead period time as the ego vehicle and the non-motorized road user.

[0149] According to some aspects of the teachings herein, a system for intersection collision avoidance may include a processor that may be configured to receive a first signal identifying a route through an intersection in a vehicle traffic network for a first road user, the first road user being an ego vehicle connected to a cellular network, compare a combination of oncoming and offgoing lanes of the route to a database storing combinations of oncoming and offgoing lanes of the intersection, identify the route as a route requiring a notification process different from a standard notification process based on a combination of the route matching the combination of the intersection, receive a second signal identifying a location of a second road user proximate to the intersection, the second road user being a non-motorized road user, and transmit a notification of the presence of the second road user to the ego vehicle via the cellular network according to the notification process and the location of the second road user.

[0150] In certain variations of this system, the non-motorized road users are pedestrians.

[0151] In certain variations of this system, the system includes a roadside unit that supports the infrastructure sensors and houses a processor.

[0152] In certain variations of this system, the route is an intended route based on at least one of a turn signal or a destination of the first road user.

[0153] According to some aspects of the teachings herein, a system for intersection collision avoidance may include a processor configured to: receive a first signal identifying a location of a first road user proximate an intersection in a vehicle traffic network, the first road user being an ego vehicle connected to a cellular network, receive a second signal identifying a location of a second road user proximate the intersection, define a line segment between the first road user and the second road user in a two-dimensional plane, determine whether the line segment intersects with an obstacle between the first road user and the second road user, and if the line segment intersects with the obstacle, transmit a notification of the presence of the second road user as an occlusion to the first road user via the cellular network.

[0154] In one variation of this system, the system includes a roadside unit including an infrastructure sensor, the processor is coupled to the infrastructure sensor, and the first signal and the second signal are generated by the infrastructure sensor.

[0155] In one variation of this system, the processor transmits, via the cellular network, a notification of the presence of the second road user as an occlusion to the second road user if the line segment intersects with an obstacle.

[0156] As used herein, the terms "passenger," "driver," or "operator" may be used interchangeably. As used herein, the terms "processor," "computer," or "computing device" include any unit or combination of units, or any portion or portions thereof, that can perform any of the methods disclosed herein.

[0157] As used herein, the term "instructions" may include instructions or expressions for performing any method disclosed herein, or any part or parts thereof, and may be implemented in hardware, software, or any combination thereof. For example, instructions may be implemented as information, such as a computer program stored in a memory, that may be executed by a processor to perform any of the methods, algorithms, aspects, or combinations thereof described herein. In some implementations, instructions or portions thereof may be implemented as a dedicated processor or circuitry, which may include dedicated hardware for performing any of the methods, algorithms, aspects, or combinations thereof described herein. In some implementations, portions of instructions may be distributed across multiple devices or multiple processors on a single device, which may communicate directly or over a network, such as a local area network, a wide area network, the Internet, or combinations thereof.

[0158] As used herein, the terms "example," "embodiment," "implementation," "aspect," "feature," or "element" indicate that they serve as an example, example, or illustration. Unless otherwise specified, any example, embodiment, implementation, aspect, feature, or element is independent of each other example, embodiment, implementation, aspect, feature, or element and may be used in combination with any other example, embodiment, implementation, aspect, feature, or element.

[0159] As used herein, the terms "determining" and "identifying" or any variation thereof includes selecting, ascertaining, calculating, retrieving, receiving, determining, establishing, obtaining, or otherwise identifying or determining in any manner using one or more of the devices shown and described herein.

[0160] As used herein, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless otherwise specified or otherwise indicated by the context, "X includes A or B" is intended to indicate any naturally inclusive permutation thereof. If X includes A, X includes B, or X includes both A and B, then "X includes A or B" is satisfied by any of the above examples. Furthermore, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more," unless the context clearly indicates otherwise in the singular.

[0161] Furthermore, although for brevity of explanation, the figures and descriptions herein may include a series of acts or steps or sequences, elements of the methods disclosed herein may occur in various orders or simultaneously. Moreover, elements of the methods disclosed herein may occur with other elements not explicitly shown and disclosed herein. Moreover, not all elements of the methods described herein are required to implement a method according to the present disclosure. Although aspects, features and elements are described herein in certain combinations, each aspect, feature or element may be used independently or in various combinations with or without other aspects, features and / or elements.

[0162] While the disclosed technology has been described in connection with certain embodiments, the disclosed technology is not intended to be limited to such, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims, which scope is to be accorded the broadest interpretation allowable under law.

Claims

1. 1. A system for intersection collision avoidance, comprising: a cellular transceiver for a cellular network; a processor disposed in a cellular access point for multi-access edge computing; The processor, a shared world model configured to receive, by the cellular transceiver, signals associated with at least two road users proximate an intersection in a vehicular traffic network, the at least two road users including an ego vehicle, the signals conforming to a standards-based communication protocol; and a potential collision detection module configured to receive object information from the shared world model, determine a potential future collision between the ego vehicle and another of the at least two road users, and send a notification of the potential future collision to the ego vehicle via the cellular network. A system comprising:

2. The system of claim 1 , wherein the standards-based communication protocol includes SAE2735.

3. The other road user is a non-motorized road user, and the collision likelihood detection module further comprises: transmitting a notification of said potential future collision via said cellular network to a cellular enabled device carried by said other road user. The system of claim 1 configured to:

4. 2. The system of claim 1, wherein the signal is transmitted to the cellular transceiver using SAE2735, and the signal includes an intent signal including at least one of a direction indicated by a turn indicator of the ego vehicle or a destination setting of the ego vehicle.

5. The intent signal is received as a coded signal converted from a JSON string generated by the ego vehicle, and the system: A signal interface that receives the encoded signals from the cellular transceiver and converts the encoded signals into a format usable by the processor. The system of claim 4 , comprising:

6. the signals include an intent signal including at least one of a direction indicated by a turn indicator of the ego vehicle or a destination setting of the ego vehicle; The system of claim 1 , wherein the shared world model is configured to determine an intended path for the ego vehicle and to provide the intended path as part of the object information to the potential collision detection module.

7. The shared world model is if the turn signal direction is received, generating potential intended paths for the ego vehicle relative to the intersection using a high definition map and the direction indicated by the turn signal; generating potential intended routes for the ego vehicle relative to the intersection using the high definition map and the destination setting when the destination setting is received; When the direction indicated by the turn indicator and the destination setting are received, comparing the direction indicated by the turn indicator with potential intended routes generated using the high definition map and the destination setting; and selecting an intended route for the ego vehicle as either the potential intended route generated using the high definition map and the destination setting, or the potential intended route generated using the high definition map and a direction indicated by the turn indicator, based on a result of the comparison; and transmitting a set of driving objectives for the ego vehicle relative to the intersections that fit the intended route to the collision potential detection module; The system of claim 6 , configured to:

8. Selecting the intended path comprises: selecting the potential intended route generated using the high definition map and the destination setting as an intended route for the ego vehicle if the direction matches the potential intended route generated using the high definition map and the destination setting; and selecting the potential intended route generated using the high definition map and the direction as the intended route for the ego vehicle if the direction does not match the potential intended route generated using the high definition map and the destination. The system of claim 7 , comprising:

9. The processor, selecting the potential intended route generated using the high definition map and the directions as the intended route for the ego vehicle when the direction indicated by the turn indicator is received and the destination setting is not received; and selecting the potential intended route generated using the high definition map and the destination setting as an intended route for the ego vehicle if the turn signal direction is not received and the destination setting is received. The system of claim 7 configured to:

10. the shared world model is configured to determine an intended path for the ego vehicle and provide the intended path along with the object information to the collision potential detection module as a set of travel objectives; The system of claim 1 , wherein the potential collision detection module receives the set of driving targets and determines the potential future collision using the set of driving targets.

11. the shared world model is configured to receive, at the cellular transceiver, signals from infrastructure sensors monitoring at least a portion of the intersection; The system of claim 1 , wherein signals from the infrastructure sensors conform to a communication protocol based on the standard.

12. the shared world model is configured to determine, during a look-ahead period, a predicted route for each of the at least two road users using signals associated with the at least two road users; The system of claim 11 , wherein the signals associated with the at least two road users include a signal received from the ego vehicle and a signal from the infrastructure sensor.

13. 2. The system of claim 1, wherein the processor is configured to control the cellular transceiver to transmit signals associated with the at least two road users over the cellular network to a shared world model of an autonomous vehicle proximate to the intersection.

14. the shared world model is configured to determine a predicted path for the ego vehicle using at least a portion of the signals; the predicted route passes through the intersection; the signal identifies a location of a non-motorized road user of the at least two road users; and The collision possibility detection module includes: comparing the combination of oncoming and offgoing lanes of the predicted route to a database of combinations of oncoming and offgoing lanes of the intersection; identifying whether the predicted route is a route that requires a notification process different from a standard notification process based on the combination of the predicted route that matches the combination of intersections; if the predicted route is a route that requires a different notification process than the standard notification process, sending a notification of the presence of the non-motorized road user to the ego vehicle according to the notification process and the location of the non-motorized road user; and Otherwise, the standard notification process determines whether to indicate to the ego vehicle a notification of the presence of the non-motorized road user according to the location of the non-motorized road user. The system of claim 1 configured to:

15. The non-motorized roadway user carries a cellular device, and the collision likelihood detection module includes: transmitting a notification of the presence of the ego vehicle to the non-motorized on-road user via the cellular network and to the cellular device according to the location of the non-motorized on-road user; The system of claim 14 configured to:

16. 1. A method for intersection collision avoidance, comprising: receiving, by a cellular transceiver for a cellular network, a signal in a shared world model associated with at least two road users proximate an intersection in a vehicular traffic network, the at least two road users including an ego vehicle, the signal conforming to a standards-based communication protocol; receiving object information from the shared world model at a potential collision detection module; determining, by the collision likelihood detection module, a potential future collision between the ego vehicle and another of the at least two road users; and sending, by the collision likelihood detection module, a notification of the potential future collision to the ego vehicle over the cellular network, wherein the shared world model and the collision likelihood detection module are implemented by a processor located at a cellular access point for multi-access edge computing. A method comprising:

17. Receiving the signal includes: receiving a first signal identifying a location of the ego vehicle; and receiving a second signal identifying a location of the other road user, the other road user being a non-motorized road user; said method comprising: generating the object information by the shared world model, generating a predicted path for the ego vehicle using the first signal; and generating a predicted route for the other road user using the second signal; containing, defining, by the potential collision detection module, a hazard zone at the intersection, the hazard zone being an area of ​​the intersection where non-motorized road users are likely to collide with motorized road users; and determining the potential future collision between the ego vehicle and the other road user includes determining the potential future collision based on the predicted path of the ego vehicle and the predicted path of the other road user simultaneously crossing any point of the hazard zone during a look-ahead period.

17. The method of claim 16, comprising:

18. the other road user is a non-motorized road user, and the method further comprises: transmitting a notification of said potential future collision via said cellular network to a cellular enabled device carried by said other road user.

17. The method of claim 16, comprising:

19. The method of claim 16 , wherein receiving the signal includes receiving sensor data from an infrastructure sensor monitoring at least a portion of the intersection, the infrastructure sensor being housed by a roadside unit.

20. Receiving the signal includes: receiving a signal identifying a location of the ego vehicle from at least one of infrastructure sensors monitoring the ego vehicle or at least a portion of the intersection; and receiving a signal from at least one of the infrastructure sensors or a cellular device carried by a non-motorized road user of the at least two road users, the signal identifying a location of the non-motorized road user; said method comprising: defining a line segment on a two dimensional plane between the ego vehicle and the non-motorized road user using the position of the ego vehicle and the position of the non-motorized road user; determining that the line segment intersects an obstacle between the ego vehicle and the non-motorized road user; and transmitting a notification to the ego vehicle in response to the determining that the non-motorized road user is occluded.

17. The method of claim 16, comprising:

Images