Lane selection using connected vehicle data including lane connectivity and input uncertainty information

Abstract

To provide a method which may include generating a dynamic lane-level forward graph including a plurality of nodes for a road.SOLUTION: The method may include computing weights for each action of a vehicle traveling from one node to a next node. The method may include determining values of different actions for the vehicle on the basis of the dynamic lane-level forward graph starting from a node of the vehicle to a node of destination and the weights for each action of the vehicle. The method may include selecting an action among the different actions on the basis of a comparison of the values of the different actions. The method may include instructing the vehicle to execute the selected action for the vehicle.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] The present specification relates to traffic monitoring, and more particularly to lane selection using connected vehicle data including lane connectivity and input uncertainty information. [Background technology]

[0002] Vehicle lane selection can be difficult to determine. For example, a vehicle may have limited field of view when changing lanes, and individual vehicle sensors may have limited capabilities. Downstream events may affect lane change execution and selection. Selecting a lane without knowledge of downstream events may lead to suboptimal performance in terms of efficiency and comfort. Even if a vehicle receives downstream data, finding the best lane can be difficult. Vehicle systems may utilize high-definition maps and high-precision GPS sensors to locate the vehicle and identify lanes, but high-definition maps and high-precision GPS sensors are not available in most vehicles. Furthermore, such requirements may be cost-prohibitive, and high-definition maps may require frequent updates. Therefore, a need exists for a method of lane selection using connected vehicle data that includes lane connectivity and input uncertainty information. Summary of the Invention

[0003] In an embodiment, a method may include generating a dynamic lane-level forward graph including a plurality of nodes for a road. The method may include calculating a weight for each vehicle action moving from one node to the next node. The method may include determining values ​​for various actions for the vehicle based on the dynamic lane-level forward graph starting from the vehicle's node toward a destination node and the weight for each vehicle action. The method may include selecting an action from among the various actions based on a comparison of the values ​​for the various actions. The method may include commanding the vehicle to perform the selected action for the vehicle.

[0004] In another embodiment, the system may include one or more processors programmed to generate a dynamic lane-level forward graph including a plurality of nodes for a road. The one or more processors may be programmed to calculate a weight for each maneuver of a vehicle moving from one node to the next. The one or more processors may be programmed to determine values ​​for various maneuvers for the vehicle based on the dynamic lane-level forward graph starting from the vehicle's node toward a destination node and the weight for each maneuver of the vehicle. The one or more processors may be programmed to select an action from among the various maneuvers based on a comparison of the values ​​of the various maneuvers. The one or more processors may be programmed to instruct the vehicle to perform the selected maneuver for the vehicle. [Brief explanation of the drawings]

[0005] The embodiments set forth in the drawings are illustrative and exemplary in nature and are not intended to limit the present disclosure. The following detailed description of illustrative embodiments can be understood when read in conjunction with the following drawings, in which like structure is designated with like reference numerals and in which:

[0006] [Figure 1] FIG. 1 schematically depicts a system for lane selection using connected vehicle data including lane connectivity and input uncertainty information according to one or more embodiments shown and described herein. [Figure 2A] FIG. 2A depicts an example of static node allocation according to one or more embodiments shown and described herein. [Figure 2B] FIG. 2B depicts an example of static node to marker node assignment according to one or more embodiments shown and described herein. [Figure 3A] FIG. 3A depicts an example of semi-static event allocation according to one or more embodiments shown and described herein. [Figure 3B]FIG. 3B depicts an example of semi-static node allocation according to one or more embodiments shown and described herein. [Figure 4A] FIG. 4A depicts an example of dynamic event allocation according to one or more embodiments shown and described herein. [Figure 4B] FIG. 4B depicts an example of dynamic node assignment to dynamic events according to one or more embodiments shown and described herein. [Figure 5] FIG. 5 depicts an example of neighboring node detection according to one or more embodiments shown and described herein. [Figure 6] FIG. 6 depicts example steps for determining vehicle behavior with respect to lane behavior under uncertainty as performed by the server of FIG. 1 according to one or more embodiments shown and described herein. [Figure 7] FIG. 7 depicts an example of depth selection based on a distance threshold according to one or more embodiments shown and described herein. [Figure 8A] FIG. 8A depicts motion space selection based on a set of motions according to one or more embodiments shown and described herein. [Figure 8B] FIG. 8B depicts motion space selection based on another set of motions according to one or more embodiments shown and described herein. [Figure 9A] FIG. 9A depicts an example of weight calculation for operation based on positive lane identifiers according to one or more embodiments shown and described herein. [Figure 9B] FIG. 9B depicts an example of weight calculation for action based on uncertain lane identifiers according to one or more embodiments shown and described herein. [Figure 10] FIG. 10 depicts an estimation of usefulness at maximum depth for various nodes according to one or more embodiments shown and described herein. [Figure 11] FIG. 11 depicts a flowchart of a method that may be performed by the server of FIG. 1 according to one or more embodiments shown and described herein. DETAILED DESCRIPTION OF THE INVENTION

[0007] Embodiments disclosed herein include methods and systems for lane selection using connected vehicle data, including lane connectivity and input uncertainty information. Selecting the best lane for a highway can be difficult. The driver, or even the vehicle itself, may have limited field of view, and individual vehicle sensors may have limited capabilities. Events occurring downstream to lane selection discrimination can affect vehicle performance. Examples of downstream events may include congested exit lanes, slow-moving trucks, and vehicle accidents.

[0008] In particular, selecting the best lane for a vehicle to change to may require input information that may be uncertain. For example, the vehicle's lane identifier may be an input. On multi-lane highways, vehicle systems may utilize high-definition maps and high-precision GPS to locate the vehicle and thereby determine the lane the vehicle is in. However, these capabilities are not available on most vehicles. Furthermore, such requirements may be expensive, and high-definition maps may require frequent updates, disadvantageously leading to unnecessary computational processing.

[0009] As further disclosed below, systems and methods herein provide a distributed lane selection technique that utilizes uncertain inputs via a server and is configured to plan vehicle operations based on uncertainty while taking lane connectivity information into account. By generating a dynamic graph, the server can be configured to select lanes and instruct vehicles to select the lanes, taking into account uncertainty in the ego-vehicle's lane identifiers, taking into account uncertainty in transitions from one lane to another, pruning the search graph to reduce the computational complexity of lane selection, and calculating weights using metrics such as marginal contribution to congestion.

[0010] FIG. 1 schematically depicts a system for lane selection using connected vehicle data according to one or more embodiments. The system includes a server 100 and a connected vehicle system 120. The server 100 may be an edge server, a roadside unit, or a cloud server. The server 100 may include one or more processors 102, memory 104, network interface hardware 106, and communication paths 108. While FIG. 1 shows a single example of components of the server 100, it is understood that the server 100 may include any number of these components.

[0011] The one or more processors 102 may be a controller, integrated circuit, microchip, computer, or any other computing device. Memory 104 may comprise RAM, ROM, flash memory, a hard drive, or any device capable of storing machine-readable executable instructions such that the instructions can be accessed by the one or more processors 102. In particular embodiments, memory 104 may be configured to include any number of program modules in the form of operating systems, application program modules, and other program modules stored in one or more memory modules. Such program modules may include, but are not limited to, routines, subroutines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular data types, as described below.

[0012] Network interface hardware 106 may be any device that can be communicatively coupled to communication path 108 and capable of transmitting and / or receiving data over a network. Thus, network interface hardware 106 may include a communications transceiver that transmits and / or receives any wired or wireless communications. For example, network interface hardware 106 may include an antenna, a modem, a LAN port, a Wi-Fi card, a WiMax card, mobile communications hardware, short-range communications hardware, satellite communications hardware, and / or any wired or wireless hardware that communicates with other networks and / or devices. Network interface hardware 106 may transmit and receive data to and from any number of connected vehicles.

[0013] The memory 104, which may include one or more memory modules, may be configured to store computer-executable instructions that, when executed by the one or more processors 102, cause the processors 102 to generate a dynamic, lane-level forward graph including a plurality of nodes for the road, such as the graph shown in FIG. 5. By way of example, the plurality of nodes may comprise one or more static nodes, one or more semi-static nodes, one or more dynamic nodes, or any combination thereof. In certain embodiments, any of the plurality of nodes may be assigned based on map data. For example, the one or more processors 102 may be configured to assign one or more of the static nodes based on map data including one or more lane markers.

[0014] The one or more processors 102 may be configured to calculate a weight for each vehicle movement from one node to the next. For example, the weight may be calculated based on a utility estimate that takes into account vehicle movement, lane changes, and traffic congestion on the link. In particular embodiments, movement on a link may include a weighted sum of the longitudinal costs of the travel lanes. For example, if a vehicle changes from a first lane to a second lane, the average longitudinal cost for the first and second lanes may be considered the movement cost. For a lane change, this may be an inconvenience. The level of inconvenience for a lane change may depend on one or more factors, including, but not limited to, the distance available for the lane change, the density of the target lane, driver characteristics, or any combination thereof. For congestion, adding a vehicle to a lane with a given density may increase the congestion level of that link by a marginal amount. The marginal cost of adding a vehicle to the target lane may be used as the congestion cost.

[0015] The one or more processors 102 may be configured to determine various operational values ​​for the vehicle based on a dynamic lane-level forward graph starting from the vehicle's node toward the destination node and a weight for each vehicle operation. In certain embodiments, the various operational values ​​for the vehicle may be further determined based on a probability that the vehicle is in each of the road's lanes. By way of example, the probability that the vehicle is in each of the road's lanes may be calculated based on image data captured by the vehicle.

[0016] The one or more processors 102 may be configured to select an action among the various actions based on a comparison of the values ​​of the various actions.

[0017] The one or more processors 102 may be configured to instruct the vehicle to perform a selected action for the vehicle. As an example, the selected action may include going straight. In another example, the selected action may include changing lanes to the left. In yet another example, the selected action may include changing lanes to the right.

[0018] In particular embodiments, the one or more processors 102 may be configured to identify one or more lane-level conditions. For example, the one or more lane-level conditions may include traffic congestion, potholes, collision risk, road surface, comfort level, one or more vehicle accidents, or any combination thereof. In particular embodiments, these one or more lane-level conditions may be semi-static, e.g., potholes that do not change over a short period of time. One or more lane-level conditions may be dynamic, e.g., traffic congestion that is dynamic and may change over a short period of time. The one or more lane-level conditions may be identified based on data received from connected vehicles operating on the corresponding road, e.g., image data captured by sensors in the connected vehicles, driving data including speed, acceleration, lane-changing behavior, and the like.

[0019] In particular embodiments, the one or more processors 102 may be configured to add one or more static events, one or more semi-static events, one or more dynamic events, or any combination thereof to the dynamic lane-level forward graph, where the locations of the one or more static events, one or more semi-static events, one or more dynamic events, or any combination thereof determine the addition of one or more nodes at the beginning and end of one or more lanes. For example, the one or more processors 102 may be configured to prohibit the addition of one or more nodes to the dynamic lane-level forward graph based on a predetermined threshold distance to the one or more static events, one or more semi-static events, one or more dynamic events, or any combination thereof.

[0020] Connected vehicle system 120 may be included within a vehicle, such as connected vehicle 200 in Figure 2A. The vehicle may be an automobile or any other passenger or non-passenger vehicle, for example, a land vehicle, an underwater vehicle, and / or an air vehicle. In some embodiments, the vehicle is an autonomous vehicle that navigates its environment with limited or no human input.

[0021] The first connected vehicle system 120 includes one or more processors 222. Each of the one or more processors 222 may be any device capable of executing machine-readable executable instructions. Accordingly, each of the one or more processors 222 may be a controller, an integrated circuit, a microchip, a computer, or any other computing device. The one or more processors 222 are connected to communication paths 224 that provide signal interconnections between various modules of the system. Thus, the communication paths 224 may communicatively connect any number of processors 222 to each other, enabling the modules connected to the communication paths 224 to operate in a distributed computing environment. Specifically, each of the modules may operate as a node that can send and / or receive data. As used herein, the term "communicatively connected" means that the connected components are capable of exchanging data signals with each other, such as, for example, electrical signals over conductive media, electromagnetic signals over air, optical signals over optical waveguides, and the like.

[0022] Thus, communication path 224 may be formed of any medium capable of transmitting a signal, such as, for example, a conductive wire, a conductive trace, an optical waveguide, or the like. In some embodiments, communication path 224 may facilitate the transmission of wireless signals, such as WiFi, Bluetooth, near field communication (NFC), and the like. Furthermore, communication path 224 may be formed of a combination of media capable of transmitting a signal. In one embodiment, communication path 224 comprises a combination of conductive traces, conductive wires, connectors, and buses that cooperate to enable the transmission of electrical data signals to components such as processors, memories, sensors, input devices, output devices, and communication devices. Thus, communication path 224 may comprise, for example, a vehicle bus, such as a LIN bus, a CAN bus, a VAN bus, and the like. Furthermore, it should be noted that the term “signal” refers to a waveform (e.g., an electrical waveform, an optical waveform, a magnetic waveform, a mechanical waveform, or an electromagnetic waveform), such as DC, AC, a sine wave, a triangular wave, a square wave, a vibration, and the like, that is capable of traveling through a medium.

[0023] The first connected vehicle system 120 includes one or more memory modules 226 coupled to the communication path 224. The one or more memory modules 226 may comprise RAM, ROM, flash memory, a hard drive, or any device capable of storing machine-readable executable instructions such that the machine-readable executable instructions can be accessed by the one or more processors 222. The machine-readable executable instructions may comprise logic or algorithms written in any programming language of any generation (e.g., 1GL, 2GL, 3GL, 4GL, or 5GL), such as a machine language that can be executed directly by a processor, or logic or algorithms written in assembly language, object-oriented programming (OOP), scripting language, microcode, or the like that can be compiled or assembled into machine-readable executable instructions and stored in the one or more memory modules 226. Alternatively, the machine-readable executable instructions may be written in a hardware description language (HDL), such as logic implemented via a field programmable gate array (FPGA) configuration or an application-specific integrated circuit (ASIC), or equivalent. Thus, the methods described herein may be implemented in any conventional computer programming language, as pre-programmed hardware elements, or as a combination of hardware and software components.

[0024] The one or more memory modules 226 may include machine-readable instructions that, when executed by the one or more processors 222, generate a dynamic lane-level forward graph including a plurality of nodes for the road, calculate a weight for each vehicle action moving from one node to the next node, determine values ​​for various actions for the vehicle based on the dynamic lane-level forward graph starting from the vehicle's node toward the destination node and the weight for each vehicle action, select an action from among the various actions based on a comparison of the values ​​for the various actions, and command the vehicle to perform the selected action for the vehicle.

[0025] Still referring to FIG. 1 , first connected vehicle system 120 includes one or more sensors 228. One or more sensors 228 may be any device having an array of sensing devices capable of detecting radiation in the ultraviolet, visible, or infrared wavelength bands. One or more sensors 228 may have any resolution. In some embodiments, one or more optical components, such as mirrors, fisheye lenses, or any other type of lens, may be optically coupled to one or more sensors 228. In some embodiments, one or more sensors 228 may also provide navigation support. That is, data captured by one or more sensors 228 may be used to navigate connected vehicle 200 autonomously or semi-autonomously.

[0026] In some embodiments, the one or more sensors 228 include one or more imaging sensors configured to operate in the visible and / or infrared spectrum to detect visible and / or infrared light. Furthermore, while certain embodiments described herein are described with reference to hardware that detects light in the visible and / or infrared spectrum, it should be understood that other types of sensors are contemplated. For example, the systems described herein may include one or more LIDAR, radar, sonar, or other types of sensors, the data of which may be incorporated into or supplement the data collection described herein to develop a more complete real-time traffic picture. A ranging sensor, such as radar, may be used to obtain rough depth and speed information about the field of view of the first connected vehicle system 120. The first connected vehicle system 120 may use one or more imaging sensors to capture road boundaries, lane markings, static objects, moving objects, and the like.

[0027] In operation, one or more sensors 228 capture image data and communicate the image data to one or more processors 222 and / or other systems communicatively connected to communication path 224. The image data may be received by one or more processors 222, which may process the image data using one or more image processing algorithms. Any known or undeveloped video and image processing algorithms may be applied to the image data to identify objects or situations. Exemplary video and image processing algorithms include, but are not limited to, kernel-based tracking (e.g., mean-shift tracking) and contour processing algorithms. Generally, video and image processing algorithms may detect objects and movement from sequential or individual frames of image data. One or more object recognition algorithms may be applied to the image data to extract objects and determine their relative locations to one another. Any known or undeveloped object recognition algorithms may be used to extract objects or even optically extract characters and images from the image data. Exemplary object recognition algorithms include, but are not limited to, scale invariant feature transform ("SIFT"), speedup of robust features ("SURF"), and edge detection algorithms.

[0028] First connected vehicle system 120 includes a satellite antenna 234 connected to communication path 224 such that communication path 224 communicatively connects satellite antenna 234 to other modules of first connected vehicle system 120. Satellite antenna 234 is configured to receive signals from Global Positioning System satellites. Specifically, in one embodiment, satellite antenna 234 includes one or more conductive elements that interact with electromagnetic signals transmitted by Global Positioning System satellites. The received signals are converted by one or more processors 222 into data signals indicative of the location (e.g., latitude and longitude) of satellite antenna 234 or objects located near satellite antenna 234.

[0029] The first connected vehicle system 120 includes one or more vehicle sensors 232. Each of the one or more vehicle sensors 232 is connected to the communication path 224 and communicatively coupled to the one or more processors 222. The one or more vehicle sensors 232 may include one or more motion sensors that detect and measure vehicle orientation, acceleration, motion, and changes in motion. The motion sensors may include an inertial measurement unit. Each of the one or more motion sensors may include one or more accelerometers and one or more gyroscopes. Each of the one or more motion sensors converts sensed physical vehicle movement into a signal indicative of the vehicle's orientation, rotation, speed, or acceleration. The one or more vehicle sensors 232 may include wheel sensors that detect wheel angle.

[0030] Still referring to FIG. 1 , the first connected vehicle system 120 includes network interface hardware 236 that communicatively couples the first connected vehicle system 120 to the server 100. The network interface hardware 236 may be any device that can be communicatively coupled to the communication path 224 and capable of transmitting and / or receiving data over a network. Thus, the network interface hardware 236 may include a communication transceiver that transmits and / or receives any wired or wireless communication. For example, the network interface hardware 236 may include an antenna, a modem, a LAN port, a Wi-Fi card, a WiMax card, mobile communication hardware, short-range communication hardware, satellite communication hardware, and / or any wired or wireless hardware that communicates with other networks and / or devices. In one embodiment, the network interface hardware 236 includes hardware configured to operate according to the Bluetooth® wireless communication protocol. The network interface hardware 236 of the first connected vehicle system 120 may transmit its data to the server 100. For example, the network interface hardware 236 of the first connected vehicle system 120 may transmit captured point clouds, vehicle data, location data, and the like generated by the first connected vehicle system 120 to other connected vehicles or the server 100.

[0031] First connected vehicle system 120 may connect with one or more external vehicles and / or external processing devices (e.g., server 100) via direct connections. The direct connections may be vehicle-to-vehicle (“V2V connection”) or vehicle-to-everything (“V2X connection”). The V2V or V2X connection may be established using any suitable wireless communication protocol described above. The connection between vehicles may utilize sessions that are time-based and / or location-based. In embodiments, the connection between vehicles or between vehicles and infrastructure elements may utilize one or more connecting networks (e.g., network 252), which may be instead of or in addition to direct connections (e.g., V2V or V2X) between vehicles or between vehicles and infrastructure. As a non-limiting example, vehicles may act as infrastructure nodes to form a mesh network and dynamically connect on an ad-hoc basis. In this manner, vehicles may freely enter and / or exit the network, allowing the mesh network to self-organize and self-modify over time. Other non-limiting network examples include vehicles forming peer-to-peer networks with other vehicles or utilizing centralized networks that rely on specific vehicle and / or infrastructure elements. Still other examples include networks that use centralized servers and other central computing devices to store and / or relay information between vehicles.

[0032] Still referring to FIG. 1 , the first connected vehicle system 120 may be communicatively coupled to the server 100 by a network 252. In one embodiment, the network 252 may include one or more computer networks (e.g., a personal area network, a local area network, or a wide area network), a cellular network, a satellite network, and / or a global positioning system, and combinations thereof. Thus, the first connected vehicle system 120 may be communicatively coupled to the network 252 via a wide area network, a local area network, a personal area network, a cellular network, a satellite network, etc. Suitable local area networks may include wired Ethernet and / or wireless technologies such as, for example, Wireless Fidelity (Wi-Fi). Suitable personal area networks may include wireless technologies such as, for example, IrDA, Bluetooth, Wireless USB, Z-Wave, ZigBee, and / or other short-range communication protocols. Suitable cellular networks include technologies such as, but are not limited to, LTE, WiMAX, UMTS, CDMA, and GSM.

[0033] 2A through 5 depict the generation of a dynamic lane-level forward graph according to one or more embodiments shown and described herein. Server 100 may generate the dynamic lane-level forward graph, which may be used to determine a driving action for vehicle 200, such as a lane-changing action, to reach a destination. As depicted schematically in FIG. 2A, one or more processors 102 of server 100 may be configured to add one or more static nodes. Vehicle 200 may include a connected vehicle, such as a connected ego-vehicle. It is understood that vehicle 200 may be driven autonomously or by an operator.

[0034] In this case, each link, where first, second, and third links 201, 202, and 203 exist, may be connected to another link through a node, such as node 204. The one or more processors 102 may add nodes between links based on map data including information about the links. As schematically depicted in FIG. 2B , the one or more processors 102 may be configured to use map data, such as lane markers 205, to assign virtual static nodes 206 at both ends of solid lane markers. In some embodiments, the server 100 may receive information about solid lane markers in real time from connected vehicles driving on link 202 and capturing images of the corresponding road. If the new virtual node is close to an existing node, the one or more processors 102 may be configured to maintain only the existing node.

[0035] As depicted generally in Figure 3A, the one or more processors 102 may be configured to add one or more semi-static events, such as holes 300 in the second link 202, based on map data or data collected from connected vehicles operating on the corresponding road. As depicted generally in Figure 3B, the one or more processors 102 may be configured to add new virtual nodes 302 at the beginning and end of each lane in a given link using the locations of sections of road having holes 300.

[0036] As depicted generally in FIG. 4A , the one or more processors 102 may be configured to add one or more dynamic nodes for dynamic events, including, but not limited to, a traffic jam 400, which may be dynamic in nature, such as on the second link 202. The server 100 may receive information about the dynamic event from connected vehicles operating on the second link 202. As depicted generally in FIG. 4B , the one or more processors 102 may be configured to add nodes 401 at the beginning and end of a dynamic event, such as the traffic jam 400. If the node is closer than an existing threshold distance, the one or more processors 102 may be configured not to add a new node.

[0037] 5, the one or more processors 102 may be configured to detect the neighborhood of each node using the map and lane marker data for each of the links. The one or more processors 102 may be configured to connect a lane node 500 to all next nodes 501 unless a restriction exists, such as the presence of solid lane markers.

[0038] 6 depicts example steps for determining vehicle behavior with respect to lane behavior under uncertainty as performed by the server of FIG. 1, according to one or more embodiments shown and described herein. Once the dynamic lane-level forward graph is generated, the server determines vehicle behavior using the dynamic lane-level forward graph.

[0039] One or more processors 102 of server 100 may be configured to determine lane behavior related to lane selection under uncertainty, via steps 610 through 650 of FIG. 6 . For example, at step 610 of FIG. 6 , one or more processors 102 may be configured to obtain map image data for vehicle 200 and lane markers for a predetermined period of time. The predetermined period may correspond to an observation period. It is understood that one or more processors may be configured to obtain other data from vehicle 200, including, but not limited to, vehicle data such as vehicle position, speed, and route, sensor data, and adjacent vehicle dynamics. One or more processors 102 may be configured to perform a map matching process to identify road link identifiers and matching positions of vehicle 200 in the map. Based on the position of vehicle 200, one or more processors 102 may obtain a dynamic lane-level forward graph including the position of vehicle 200 as a starting point for determining and then selecting vehicle behavior. In certain embodiments, the dynamic lane-level forward graph may refer to the dynamic lane-level forward graph as described above with respect to FIGS. 2A-5.

[0040] 6, the one or more processors 102 may be configured to verify marker indications, such as one or more right lane markers as indicated by dashed lines and / or one or more left lane markers as indicated by dashed lines, based on the map image data. It is understood that the one or more processors 102 may also be configured to verify solid lines for a given lane, and thus are not limited to only dashed lane markers.

[0041] Based on observing these marker indications, at step 630 of FIG. 6 , one or more processors 102 may be configured to determine a probability that vehicle 200 is located for any number of lanes on the road. In particular embodiments, this probability determination may be referred to as lane identifier confidence. In particular embodiments, for example, a lane identifier for vehicle 200 corresponding to a particular lane of a given number of lanes on the road may be estimated. The exact lane identifier for vehicle 200 may be uncertain due to uncertainties that may be introduced by factors such as a lack of high-resolution maps, low-accuracy GPS, and sensor errors. By way of example, and not by way of limitation, the number of lanes may include five lanes. In particular embodiments, one or more processors 102 may be configured to utilize sensor data to estimate the probability that ego-vehicle 200 is located in each of the lanes. As an example on a four-lane highway, one or more processors 102 may be configured to output [0.1, 0.3, 0.4, 0.2], where the probability that the host vehicle 200 is in the leftmost lane is 10%, the probability that the host vehicle 200 is in the second-to-left lane is 30%, the probability that the host vehicle 200 is in the second-to-right lane is 40%, and the probability that the host vehicle 200 is in the rightmost lane is 20%.

[0042] In response to determining the probability that vehicle 200 is in each lane of the road, at step 640 of FIG. 6 , one or more processors 102 may be configured to determine the utility of performing a particular vehicle action via an action value function and a dynamic lane-level forward graph. For example, one or more processors 102 may use the dynamic lane-level forward graph to calculate values ​​for each of actions including going straight, changing lanes to the left, and changing lanes to the right. For example, one or more processors 102 may be configured to build a model that takes historical data into account to estimate the transition probability that vehicle 200 will change lanes on the road. Due to static and semi-static events, each of the lanes may not be the optimal action for lane selection because the presence of these events in the respective lane (and the corresponding lane decision selection) may be costly in terms of adverse impacts on congestion, potential increased vehicle density in the target lane, or the like. Thus, one or more processors 102 may be configured to determine that there is less utility, e.g., lower operational values, in changing lanes to the left or right, as opposed to continuing straight, which is associated with higher utility, e.g., higher operational values. In particular embodiments, the longitudinal weight may be calculated based on the longitudinal weights of the graph. For example, if the position of vehicle 200 is in the center of a link, half the longitudinal vertices in the same lane may be assigned a longitudinal weight. Additionally, the lateral weight may be calculated based on one or more factors, such as the discomfort associated with changing lanes and the impact on traffic congestion.

[0043] In an embodiment, the one or more processors 102 calculate the values ​​of going straight, turning right, or turning left, taking into account the current position of the vehicle 200 or an unknown position of the vehicle 200. For example, by referring to FIG. 9A , if the vehicle's position 900 is known, the vehicle 200 cannot turn right. Therefore, the one or more processors 102 calculate the values ​​of going straight and turning right, taking into account longitudinal weighting and / or lateral weighting. If the vehicle's position is unknown, as shown in FIG. 9B , the one or more processors 102 calculate the values ​​of going straight, turning right, or turning left for each possible position of the vehicle 200. For example, the one or more processors 102 calculate the values ​​of going straight, turning right, or turning left, assuming that the vehicle 200 is in the left lane. Additionally, the one or more processors 102 calculate values ​​for going straight, turning right, or turning left, assuming that the vehicle 200 is in the center lane. Furthermore, the one or more processors 102 calculate values ​​for going straight, turning right, or turning left, assuming that the vehicle 200 is in the right lane. The one or more processors 102 then sum the values ​​for each action in the three different scenarios, taking into account the probability that the vehicle 200 is in each lane. Specifically, the one or more processors 102 calculate a weighted sum of the value for turning left when the vehicle is in the left lane, the value for turning left when the vehicle is in the center lane, and the value for turning left when the vehicle is in the right lane, where the weights are the probability that the vehicle 200 is in each lane. Similarly, the one or more processors 102 calculate a weighted sum of the value for going straight and the weighted sum of the value for turning right.

[0044] At step 650 of Figure 6, one or more processors 102 may be configured to determine a vehicle action based on the utility determination. The one or more processors 102 may select a vehicle action based on action values ​​of the possible actions, including going straight, turning left, and turning right. In particular, the one or more processors 102 may be configured to instruct the vehicle 200 to perform a selected action for the vehicle 200. As an example, the selected action may include going straight, as depicted by the arrow. However, it is understood that other selected actions, such as turning left or turning right, may be suggested by the one or more processors 102.

[0045] 6 , in certain embodiments, when a lane change command is transmitted to the driver of vehicle 200 or to vehicle 200 itself, the driver or vehicle 200 may execute a lane change in accordance with the lane change command, thereby complying with the lane change command. In other embodiments, due to one or more factors, such as behavioral characteristics, the density of vehicles 200 in the target lane, the distance to the exit, or any combination thereof, the driver or vehicle 200 may not comply with the lane change command, thereby rejecting the lane change command. For a given planning step of changing lanes, one or more processors 102 may be configured to estimate the probability of the transition using vehicle data. As an example, the probability of accepting the lane change command and changing lanes to the right may be 60%.

[0046] 7 illustrates an example of depth selection based on a distance threshold, according to one or more embodiments shown and described herein. Depth selection is the selection of the length of the dynamic lane-level forward graph.

[0047] In particular embodiments, the one or more processors 102 may be configured to determine the depth by utilizing ego-vehicle data, including the position of the ego-vehicle, along with the dynamic lane-level forward graph. For example, if the depth is too short, the lane selection suggestions may not be optimal. In another example, if the depth is too deep, the computational complexity of calculating the value of the vehicle's actions may be significant. Thus, the depth of the dynamic lane-level forward graph is important as far as the computational processing associated with the search for lane selection suggestions is concerned. In particular embodiments, the one or more processors 102 may be configured to determine the depth by a length threshold. By way of example and not by way of limitation, the one or more processors 102 may be configured to select all nodes closer than 2 km. In another example and not by way of limitation, the one or more processors 102 may be configured to set a limit on the depth, such as a depth equal to 5.

[0048] Further, the one or more processors 102 may be configured to prune the dynamic lane-level forward graph based on actions available at the nodes. By pruning the dynamic lane-level forward graph, the one or more processors 102 may be configured to reduce the depth based on actions available at the nodes. For example, if a portion of a road has only a single lane, vehicles 200 may not be able to change lanes and all vehicles 200 may need to traverse the single lane. The dynamic lane-level forward graph may be pruned by the one or more processors 102 by only searching to nodes that have a single lane.

[0049] As further depicted in FIG. 7 , the one or more processors 102 may be configured to select a depth based on a distance threshold 700 of 2 kilometers, resulting in a depth (d) of 7. In this case, four links are depicted in FIG. 7 , of which the second link (link 2) includes only one lane, and vehicle 200 cannot change lanes. To plan a lane change for vehicle 200, one or more processors 102 do not need to plan for the entire 2 kilometers at a depth of 7. Thus, one or more processors 102 may be configured to plan up to the second link, i.e., a depth of 3, so that a different horizon can be selected when vehicle 200 arrives at the second link. In this manner, one or more processors 102 may be configured to prune the dynamic lane-level forward graph to reduce the search space. By reducing the depth, the computational complexity associated with the search for lane selection may be reduced, and one or more processors 102 may be configured to identify optimal solutions, such as lane-change operations, more efficiently and faster.

[0050] As depicted in Figures 8A and 8B, the one or more processors 102 may further be configured to select an action space based on requirements and available resources. In particular embodiments, the one or more processors 102 may be configured to select any number of sets of actions. For example, as depicted generally in Figure 8A, a set of actions 800 may include a right turn, no lane change, and a left turn. For the set of actions, the ego vehicle 200 at each planning step may be configured to choose from three actions. The one or more processors 102 may be configured to modify the dynamic lane-level forward graph and add virtual nodes to ensure that the vehicle 200 can reach downstream nodes on its route.

[0051] As depicted schematically in FIG. 8B , another set of actions 801 may include lane changes to all lanes, including one right change, two right changes, three right changes, no lane change, one left change, two left changes, and three left changes. For example, the ego vehicle 200 may choose from actions defined by a function using the number of lanes minus 1, then multiplying by 2, and adding 1. As an example, for a four-lane road, there are seven actions. In this case, the one or more processors 102 do not need to modify the dynamic lane-level forward graph so that it can arrive at any downstream node.

[0052] The one or more processors 102 may be configured to create the search graph. As schematically depicted in FIG. 9A, a node 900 may be added at the location of the vehicle 200. For example, when the lane identifier is certain, a single node 900 may be added to the lane of the vehicle 200 by the one or more processors 102. When the lane identifier is uncertain, a node 901 may be added to all lanes at the location of the vehicle 200 by the one or more processors 102, as depicted in FIG. 9B. The one or more processors 102 may be configured to add a connection to the first downstream node, which may be based on the selected operation space.

[0053] The one or more processors 102 may then be configured to calculate connection weights. In particular embodiments, the longitudinal weights may be calculated based on the longitudinal weights of the graph. For example, if the position of vehicle 200 is at the center of a link, half the longitudinal vertices in the same lane may be assigned a longitudinal weight. In addition, the lateral weights may be calculated based on one or more factors, such as the discomfort associated with changing lanes and the impact on traffic congestion.

[0054] After creating the search graph, one or more processors 102 may be configured to select the optimal operation. In particular embodiments, one or more processors 102 may be configured to estimate utility at maximum depth. For example, one or more processors 102 may be configured to estimate the overall utility for each terminal node for the last node in the graph, such as at a depth of three, as shown in FIG. 10. If only one node is present, any number may be assumed. If two or more nodes are present, one or more processors 102 may be configured to estimate utility from each node using sampling techniques. More specifically, a search method may be selected by one or more processors 102 based on the degree of depth. For example, if the graph is shallow, a method such as forward search may be utilized. If the graph is deep, utilizing forward search may be computationally intensive, and therefore one or more processors 102 may instead utilize Monte Carlo tree search. These methods may be configured to find the optimal lane. For example, if the lane identifiers are uncertain, the shortest paths from all lanes may be identified by one or more processors 102, and then the one or more processors 102 may be configured to select the action with the highest reward at the lowest cost. Based on this information, the one or more processors 102 may be configured to calculate an optimal lane change action. In response, the vehicle 200 may be configured to apply the selected action, e.g., a change to the left, when commanded by the one or more processors 102. If the vehicle 200 reaches the destination, the process may end; otherwise, the process may be repeated at the next node.

[0055] Figure 11 depicts a flowchart of an example method 1100 that may be performed by a server, such as one or more processors 102 of Figure 1. Figure 11 may reference and incorporate any of the operations and components of server 100.

[0056] For example, method 1100 may include a method for performing a lane change for a vehicle. At step 1105, method 1100 may include generating a dynamic, lane-level forward graph including a plurality of nodes for the road. By way of example, the plurality of nodes may comprise one or more static nodes, one or more semi-static nodes, one or more dynamic nodes, or any combination thereof. In certain embodiments, any of the plurality of nodes may be assigned based on map data. For example, method 1100 may include assigning one or more of the static nodes based on map data including one or more lane markers.

[0057] At step 1110, method 1100 may include calculating a weight for each movement of a vehicle traveling from one node to the next. By way of example, the weight may be calculated based on an estimate of utility that takes into account vehicle movement, lane changes, and traffic congestion on the link.

[0058] In step 1115, method 1100 may include determining various action values ​​for the vehicle based on a dynamic lane-level forward graph starting from the vehicle's node toward the destination node and a weight for each vehicle action. In certain embodiments, the various action values ​​for the vehicle may be further determined based on a probability that the vehicle is in each of the road's lanes. By way of example, the probability that the vehicle is in each of the road's lanes may be calculated based on image data captured by the vehicle.

[0059] At step 1120, the method 1100 may include selecting an action among the various actions based on a comparison of the values ​​of the various actions.

[0060] At step 1125, method 1100 may include commanding the vehicle to perform a selected action for the vehicle. As an example, the selected action may include going straight. In another example, the selected action may include changing lanes to the left. In yet another example, the selected action may include changing lanes to the right.

[0061] In certain embodiments, the method 1100 may include identifying one or more lane-level conditions. For example, the one or more lane-level conditions may include traffic congestion, potholes, collision risk, road surface, comfort level, one or more vehicle accidents, or any combination thereof.

[0062] In particular embodiments, method 1100 may include adding one or more static events, one or more semi-static events, one or more dynamic events, or any combination thereof, to the dynamic lane-level forward graph, where the locations of the one or more static events, one or more semi-static events, one or more dynamic events, or any combination thereof determine the addition of one or more nodes at the beginning and end of one or more lanes. For example, method 1100 may include prohibiting the addition of one or more nodes to the dynamic lane-level forward graph based on a predetermined threshold distance to the one or more static events, one or more semi-static events, one or more dynamic events, or any combination thereof.

[0063] In certain embodiments, the method 1100 may include pruning the dynamic lane-level forward graph based on available actions at multiple nodes.

[0064] It should be appreciated that the embodiments described herein are directed to a system and method that provides a distributed lane selection technique that utilizes uncertain inputs via a server and plans vehicle operations based on uncertainty while taking lane connectivity information into account. By generating a dynamic graph, a server can be configured to select a lane and instruct a vehicle to select the lane, the server considers uncertainty in the host vehicle's lane identifier, considers uncertainty in transitions from one lane to another, prunes the search graph to reduce the computational complexity of lane selection, and calculates weights using metrics such as marginal contribution to congestion. In this way, downstream events are efficiently taken into account when a vehicle decides whether to select a lane to change to, and the graph is generated based on the addition of various types of nodes to downstream events, and then pruned based on decisions regarding available operations at the various types of nodes, thereby reducing computational processing in lane selection.

[0065] It should be noted that the terms "substantially" and "about" may be used herein to express the degree of inherent uncertainty that may result from any quantitative comparison, value, measurement, or other representation. These terms are also used herein to express the degree to which a quantitative representation may vary from the stated basis without resulting in a change in the basic functionality of the subject matter at issue.

[0066] While particular embodiments have been shown and described herein, it should be understood that various other changes and modifications can be made without departing from the spirit and scope of the claimed subject matter. Moreover, although various aspects of the claimed subject matter are described herein, such aspects need not be utilized in combination. Accordingly, the appended claims are intended to cover all such changes and modifications that are within the scope of the claimed subject matter.

Claims

1. 1. A method for performing a lane change in a vehicle, the method comprising: generating a dynamic lane-level forward graph including a plurality of nodes for the road; Calculating a weight for each movement of a vehicle from one node to the next; determining values ​​for various actions for the vehicle based on the dynamic lane-level forward graph starting from the vehicle's node towards a destination node and the weight for each action of the vehicle; selecting an action from among the various actions based on a comparison of the values ​​of the various actions; commanding the vehicle to perform the selected action on the vehicle; A method comprising:

2. The method of claim 1 , wherein the values ​​of various actions for the vehicle are further determined based on the probability that the vehicle is in each of the lanes of the road.

3. The method of claim 2 , wherein the probability that the vehicle is in each of the lanes of the road is calculated based on image data captured by the vehicle.

4. The method of claim 1 , wherein the plurality of nodes comprises one or more static nodes, one or more semi-static nodes, one or more dynamic nodes, or any combination thereof.

5. The method of claim 4 , further comprising assigning one or more of the static nodes based on map data including one or more lane markers.

6. 10. The method of claim 1, further comprising identifying one or more lane-level conditions, wherein the one or more lane-level conditions include traffic congestion, potholes, collision risk, road surface, comfort level, one or more vehicle accidents, or any combination thereof.

7. 10. The method of claim 1, further comprising adding one or more static events, one or more semi-static events, one or more dynamic events, or any combination thereof, to the dynamic lane-level forward graph, wherein the locations of the one or more static events, the one or more semi-static events, the one or more dynamic events, or any combination thereof determine the addition of one or more nodes at the beginning and end of one or more lanes.

8. 8. The method of claim 7, further comprising: prohibiting the addition of one or more nodes to the dynamic lane-level forward graph based on a predetermined threshold distance to the one or more static events, the one or more semi-static events, the one or more dynamic events, or any combination thereof.

9. The method of claim 1 , further comprising calculating the weights based on an estimate of utility that takes into account vehicle movement, lane changes, and traffic congestion on the links.

10. The method of claim 1 , further comprising pruning the dynamic lane-level forward graph based on available operations at the plurality of the nodes.

11. The method of claim 1 , wherein the selected action is to continue straight, change lane to the left, or change lane to the right.

12. 1. A system comprising one or more processors, The one or more processors: generating a dynamic lane-level forward graph including a plurality of nodes for the road; Calculating a weight for each movement of a vehicle from one node to the next; determining values ​​of various actions for the vehicle based on the dynamic lane-level forward graph starting from the vehicle's node towards a destination node and the weight for each action of the vehicle; selecting an action from among the various actions based on a comparison of the values ​​of the various actions; The system is programmed to instruct the vehicle to perform the selected action on the vehicle.

13. The system of claim 12 , wherein the values ​​of various actions for the vehicle are further determined based on a probability that the vehicle is in each of the lanes of the road.

14. The system of claim 13 , wherein the probability that the vehicle is in each of the lanes of the road is calculated based on image data captured by the vehicle.

15. The system of claim 12 , wherein the plurality of nodes comprises one or more static nodes, one or more semi-static nodes, one or more dynamic nodes, or any combination thereof.

16. 16. The system of claim 15, wherein the one or more processors are further programmed to assign one or more of the static nodes based on map data including one or more lane markers.

17. 13. The system of claim 12, wherein the one or more processors are further programmed to identify one or more lane-level conditions, the one or more lane-level conditions comprising traffic congestion, potholes, collision risk, road surface, comfort level, one or more vehicle accidents, or any combination thereof.

18. 13. The system of claim 12, wherein the one or more processors are further programmed to add one or more static events, one or more semi-static events, one or more dynamic events, or any combination thereof, to the dynamic lane-level forward graph, wherein the locations of the one or more static events, the one or more semi-static events, the one or more dynamic events, or any combination thereof determine the addition of one or more nodes at a beginning and an end of one or more lanes.

19. 20. The system of claim 18, wherein the one or more processors are further programmed to prohibit the addition of one or more nodes to the dynamic lane-level forward graph based on a predetermined threshold distance to the one or more static events, the one or more semi-static events, the one or more dynamic events, or any combination thereof.

20. The system of claim 12 , wherein the selected action is to continue straight, change lane to the left, or change lane to the right.

Images