VEHICLE SYSTEM FOR PROVIDING OPTIMAL SPATIAL AND TEMPORAL RECOMMENDATIONS FOR ENTERING LANES

Abstract

Vehicle system (100) for providing a recommendation of an optimal road segment to perform a desired lane change for a vehicle (102), wherein the vehicle system (100) comprises: a control module (116) configured to: identify, based on crowdsourced data from a multitude of vehicles that have traveled through a defined area of ​​a road over a specified period, a multitude of road segments in the defined area of ​​a first lane to merge into a second lane, wherein the crowdsourced data includes the frequency with which each vehicle of the multitude of vehicles has traveled through the defined area of ​​the road;Determine one or more reliability scores for each road segment in the defined area of ​​the road based on the frequency with which each vehicle of the multitude of vehicles has entered the defined area of ​​the road, each reliability score for each road segment being specific to a different driving condition; select the road segment of the road segments with the highest reliability score that exhibits the driving condition corresponding to a current driving condition assigned to the vehicle (102); and identify a portion of the selected road segment that is optimal for merging from the first to the second lane based on a probability that a period for changing lanes exists and a difference in vehicle speeds between the first and second lanes;and a display module (106) that is connected to the control module (116), wherein the display module (106) is configured to output a visual representation of the selected road segment, including the identified segment, which is highlighted to indicate a recommendation as to where to merge from the first lane into the second lane.

Description

INTRODUCTION

[0001] The information in this section serves to present the general context of the disclosure. Works of the inventors mentioned herein, insofar as they are described in this section, as well as aspects of the description that may not have been prior art at the time of filing, are neither expressly nor implicitly admitted as prior art against the present disclosure.

[0002] The present disclosure relates to vehicle systems and methods for providing optimal spatial and temporal recommendations for merging into exit lanes, and in particular for providing optimal recommendations for merging into exit lanes, which are partly based on crowdsourced telemetry data.

[0003] Vehicles are often equipped with navigation systems that track the vehicle and provide instructions for upcoming maneuvers to reach the desired destination. In such cases, the instructions can be made available to the vehicle's driver or used for vehicle control in autonomous driving applications. In some scenarios, the navigation systems may rely on crowdsourced data from other vehicles to generate the instructions. SUMMARY

[0004] A vehicle system for providing a recommendation of the optimal road segment for a desired lane change comprises a control module and a display module that communicates with the control module. The control module is configured to identify, based on crowdsourced data from a multitude of vehicles that have traveled a defined area of ​​a road over a specific period, a multitude of road segments within that defined area from a first lane to a second lane. The crowdsourced data includes the frequency with which each vehicle in the multitude traversed the defined area of ​​the road.The control module is further configured to: determine one or more reliability scores for each road segment in the defined area of ​​the road based on the frequency with which each vehicle of the multitude of vehicles has entered the defined area of ​​the road, each reliability score for each road segment being specific to a different driving condition; select the road segment of the road segments with the highest reliability score that exhibits the driving condition corresponding to a current driving condition assigned to the vehicle; and identify a portion of the selected road segment that is optimal for merging from the first to the second lane, based on a probability that a period for changing lanes exists and a difference in vehicle speeds between the first and second lanes.The display module is configured to output a visual representation of the selected road segment, with the identified section highlighted to indicate a recommendation on where to merge from the first lane into the second lane.

[0005] Other features of the vehicle system include a vehicle control module connected to the control module. The vehicle control module is configured to control at least one operation of the vehicle based on the identified section of the selected road segment.

[0006] In other characteristics, the multitude of road segments in the defined area corresponds to a set of road segments that are most frequently used by the multitude of vehicles to enter the second lane.

[0007] In other features, the control module is configured to determine familiarity rating numbers for the multitude of vehicles in each road segment, based on the frequency with which the multitude of vehicles have traveled through the defined area of ​​the road.

[0008] In other features, the control module is configured to determine one or more reliability rating numbers for each road segment based on the familiarity rating numbers for that road segment.

[0009] In other characteristics, the driving condition includes at least one of the following elements: a different time of day, a different road condition, or a different weather condition.

[0010] Other features of the crowdsourced data include the frequency of braking events for the large number of vehicles in the defined area of ​​the road.

[0011] In other features, the control module is configured to change one or more reliability rating numbers for each road segment based on the frequency of braking events.

[0012] In other features, the control module is configured to modify the probability of a period of time for a lane change based on the cognitive state of the vehicle's driver.

[0013] In other features, the control module is configured to modify the probability of a period for a lane change based on road conditions.

[0014] A vehicle system for providing a recommendation of the optimal road segment for a desired lane change comprises a control module and a vehicle control module that communicates with the control module. The control module is configured to identify, based on crowdsourced data from a multitude of vehicles that have traveled a defined area of ​​a road over a specific period, a multitude of road segments within that defined area from a first lane to a second lane. The crowdsourced data includes the frequency with which each vehicle in the multitude of vehicles traversed the defined area of ​​the road.The control module is further configured to: determine one or more reliability scores for each road segment in the defined area of ​​the road based on the frequency with which each vehicle of the multitude of vehicles has entered the defined area of ​​the road, each reliability score for each road segment being specific to a different driving condition; select the road segment of the road segments with the highest reliability score whose driving condition corresponds to the current driving condition of the vehicle; and identify the portion of the selected road segment that is optimal for merging from the first to the second lane, based on a probability that a period of time for changing lanes exists and a difference in vehicle speeds between the first and second lanes.The vehicle control module is configured to control the vehicle so that it enters the second lane in the identified section of the selected road segment.

[0015] In other characteristics, the multitude of road segments in the defined area corresponds to a set of road segments that are most frequently used by the multitude of vehicles to enter the second lane.

[0016] In other features, the control module is configured to determine familiarity rating numbers for the multitude of vehicles in each road segment, based on the frequency with which the multitude of vehicles have traveled through the defined area of ​​the road.

[0017] In other features, the control module is configured to determine one or more reliability rating numbers for each road segment based on the familiarity rating numbers for that road segment.

[0018] In other characteristics, the driving condition includes at least one of the following elements: a different time of day, a different road condition, or a different weather condition.

[0019] Other features of the crowdsourced data include the frequency of braking events for the large number of vehicles in the defined area of ​​the road.

[0020] In other features, the control module is configured to change one or more reliability rating numbers for each road segment based on the frequency of braking events.

[0021] In other features, the control module is configured to modify the probability of a period of time for a lane change based on the cognitive state of the vehicle's driver.

[0022] In other features, the control module is configured to modify the probability of a period for a lane change based on road conditions.

[0023] A vehicle control procedure for providing a recommendation of an optimal road segment for a vehicle to perform a desired lane change includes: identifying, based on crowdsourced data from a multitude of vehicles that have traversed a defined area of ​​a road over a specified period, a multitude of road segments within the defined area of ​​a first lane for merging into a second lane. The crowdsourced data includes the frequency with which each vehicle in the multitude traversed the defined area of ​​the road. The vehicle control procedure further includes: determining one or more reliability scores for each road segment in the defined area of ​​the road based on the frequency with which each vehicle in the multitude traversed the defined area of ​​the road.where each reliability rating for each road segment is specific to a different driving condition, selecting the road segment of the road segments with the highest reliability rating that exhibits the driving condition corresponding to a current driving condition assigned to the vehicle, identifying a portion of the selected road segment that is optimal for merging from the first to the second lane based on the probability that a period for changing lanes exists and the difference in vehicle speeds between the first and second lanes, and outputting a visual representation of the selected road segment, including the identified portion highlighted to indicate a recommendation on where to merge from the first to the second lane.

[0024] In other features, the vehicle control procedure also includes controlling the vehicle to change to the second lane on the identified section of the selected road segment.

[0025] In other features, the vehicle control procedure also includes at least one of the following features: modifying the one or more reliability rating numbers for each road segment based on a frequency of braking events for the multitude of vehicles in the defined area of ​​the road, modifying the probability of having a period for changing lanes based on the cognitive status of the driver of the vehicle, and modifying the probability of having a period for changing lanes based on the road condition.

[0026] Further applications of this disclosure will become apparent from the detailed description, the claims, and the drawings. The detailed description and specific examples serve only for illustration and are not intended to limit the scope of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The present disclosure will become more fully apparent from the detailed description and the accompanying drawings, whereby the following applies: Fig. Figure 1 is a block diagram of an exemplary vehicle system for providing recommendations for entering a lane according to the present disclosure; Fig. 2 is a map showing road segments and clustered location data generated by the vehicle system of Fig. 1 were identified according to the present disclosure; Fig. 3 is a visual representation of a map with a selected road section, the sections of which are highlighted in accordance with the present disclosure; Fig. Figures 4-6 are exemplary visual representations of selected road sections with highlighted sections according to the present disclosure; Fig. Figures 7-8 are exemplary visual representations with notifications prompting a driver to merge, according to the present disclosure; Fig. Figure 9 is a flowchart of an exemplary control process for providing visual representations of recommendations for entering a lane according to the present disclosure; Fig. Figure 10 is a flowchart of an exemplary control process for controlling a vehicle to merge based on recommendations for entering a lane according to the present disclosure; Fig. Figure 11 is a flowchart of an exemplary tax process for determining familiarity rating scores in accordance with the present disclosure; and Fig. Figure 12 is a flowchart of an exemplary control process for determining reliability rating figures in accordance with the present disclosure.

[0028] Reference numbers can be reused in the drawings to designate similar and / or identical elements. DETAILED DESCRIPTION

[0029] Vehicles are equipped with navigation systems that provide instructions for upcoming driving maneuvers to reach desired destinations. To provide such instructions, current navigation systems can rely on street-level information (e.g., high-level maps) and crowdsourced data. However, these navigation systems lack knowledge of lane-level traffic information. This lack of knowledge can lead to missed exits (especially in automated vehicles) and / or cause concern when a vehicle needs to self-position or a driver needs to guide the vehicle into the correct lane for an upcoming maneuver.

[0030] The vehicle systems and vehicle control methods described in this disclosure offer solutions for acquiring knowledge about lane traffic to support convenient navigation and merging experiences. For example, using lane traffic statistics derived from crowdsourced telemetry data, the vehicle systems and methods can provide a vehicle with spatial and temporal lane recommendations to increase the likelihood that the vehicle will achieve its navigation goals (e.g., arrive at the exit / entry lane on time). Such lane recommendations can be integrated into a map for an in-vehicle display and / or used for route planning in autonomous driving applications.

[0031] A vehicle traveling on a road may need to take an exit to continue its route. In such cases, the road might be a highway, such as a multi-lane motorway, and the route might be dictated by a navigation system. In some scenarios, a traffic jam may occur at the exit due to congestion on the exit ramp or the secondary road connected to it. To navigate successfully, the driver may need to ensure sufficient time to maneuver into the exit lane. Otherwise, the driver will need to be redirected to the next exit. In this scenario, the decision of when and where to enter the exit lane must take into account the slow-moving and congested traffic ahead of the exit ramp in order to reach the next section of the route.The vehicle systems and control procedures described here can determine the feasibility of a lane change (or merging) based on the expected clear road ahead and, if desired, modify this feasibility based on data about hard braking, as further explained here. In such examples, the vehicle systems and control procedures allow a display to assist the driver in performing the required lane change and / or enable the vehicle control system to execute the required lane change with sufficient time to reach the navigation destinations.

[0032] In Fig. Figure 1 shows a block diagram of an example vehicle system 100 that provides lane recommendations to a vehicle 102 entering a lane of a road. As in Fig. As shown in Figure 1, the vehicle system 100 generally comprises a control module 104 installed in the vehicle 102, a display module 106, a vehicle control module 108 for controlling at least one function or operation of the vehicle 102, and several on-board sensors 110, 112, 114. Although in Fig. 1. While the vehicle system 100 is represented with special modules, one or more other modules can also be used if desired. For example, any combination of modules (e.g., the control module 104, the display module 106, the vehicle control module 108, etc.) and / or their functionality can be integrated into a single module or several different modules. Although in Fig. As three onboard sensors 110, 112, 114 are shown, the vehicle 102 can be equipped with any number of sensors upon request.

[0033] The vehicle system 100 of Fig. 1 can be used in any suitable vehicle, e.g., in an autonomous vehicle, a semi-autonomous vehicle, etc. Furthermore, the vehicle system 100 can be used for both electric vehicles (e.g., a pure electric vehicle, a plug-in hybrid electric vehicle, etc.) and vehicles with internal combustion engines (ICE). In the example of Fig. 1. The vehicle system 100 is used in the vehicle 102 (e.g., an autonomous vehicle).

[0034] In the example of Fig. In example 1, the on-board sensors 110, 112, 114, the display module 106, and the vehicle control module 108 are connected to the control module 104. In such examples, the modules and sensors of the vehicle system 100 can exchange parameters and signals via a network, e.g., a Controller Area Network (CAN). Fig. For example, the control module 104 receives signals representing data from the sensors 110, 112, 114 and sends signals to the display module 106 to display lane recommendations and to the vehicle control module 108 to control vehicle operation.

[0035] In various embodiments, and as further explained herein, aspects of generating lane recommendations can be implemented on board the vehicle 102 itself and / or outside the vehicle 102. For example, the control module 104 can perform functions for generating spatial and temporal recommendations for merging into lanes. In other examples, the vehicle system 100 can include an optional control module 116 outside the vehicle 102 that communicates with the control module 104 on board the vehicle 102. In such examples, the control module 116 can perform some or all of the functions described herein for generating spatial and temporal lane recommendations. For example, as further explained herein, the external (or remote) control module 116 can generally receive crowdsourced data and, based on this data, generate lane segment recommendations for merging from one lane to another (e.g.,(e.g., an exit lane) and determine reliability scores for the road segments. Then, control module 104 can generally select one of the road segments and identify a portion of that segment for merging. The control functions for generating lane merging recommendations are explained below for both control modules 104 and 116, although each control module can also implement these functions separately.

[0036] In the example of Fig. 1. The control module 104 can receive one or more onboard inputs. For example, the onboard sensors 110, 112, 114 can detect one or more features and provide the control module 104 with one or more onboard inputs, such as vehicle acceleration, environmental data (e.g., features of other vehicles, road conditions, weather conditions, etc.) from outside the vehicle 102, driver characteristics (e.g., driver attention, driver stress, driver drowsiness, etc.), etc. In such examples, the onboard sensors 110, 112, 114 can include, for example, external cameras (e.g., front camera modules, side camera modules, etc.), accelerometers, internal cameras (e.g., eye trackers, etc.), and / or other suitable sensors. In some examples, the control module 104 can receive vehicle-side inputs from automated driving systems, computer vision systems, etc.In various embodiments, some or all of the inputs received by the onboard sensors 110, 112, 114 or otherwise can be transmitted to the control module 116.

[0037] Additionally, the control module 104 can receive one or more external or off-board inputs. Such off-board inputs can include, for example, data from one or more road databases, location data (e.g., from a global positioning system), and / or messages from vehicle-to-everything (V2X) systems, dedicated short-range communications (DSRC) systems, cellular systems, etc. In such examples, some or all of the off-board inputs can be provided by the control module 116. In particular, some or all of the off-board inputs can be provided via one or more signals 118.

[0038] With continued reference to Fig. 1. Control module 116 receives crowdsourced data from vehicles, including possibly vehicle 102, that have traveled on the road over a specific period. In such examples, the data may be telemetry data relating to vehicle characteristics. The crowdsourced data may include, for example, data on vehicle speeds, acceleration, deceleration, location, number of vehicles, trip frequency, etc. In some examples, the location data may include latitude and longitude, directions, travel directions, and corresponding timestamps. In such examples, information can be extracted from the crowdsourced data, such as the frequency (e.g., daily, weekly, etc.) with which a vehicle has traveled a specific section of the road, the frequency or number of braking events for vehicles in that specific section of the road, etc.

[0039] Subsequently, the control module 116 identifies road segments along the road, based on the crowdsourced data, that are intended for merging from one lane to another. For example, the control module 116 can use parts (e.g., location data, vehicle counts, etc.) of the crowdsourced data that are specific to a particular area of ​​the road to identify the road segments most frequently used by the vehicles (providing the crowdsourced data) to merge into another lane (e.g., an exit lane). In such examples, the defined area might be a region of interest on the road near an exit. The defined area could, for example, be between the point where an exit lane becomes available (e.g., appears, dashed road lines, etc.) and the point where the exit lane is no longer available (e.g., begins to veer off from the road, solid road lines, etc.).), lay.

[0040] In Fig. Figure 2, for example, shows a map of 200 with identified road segments. Fig. In example 2, map 200 contains, in particular, a road 202 and an exit 204. In such examples, the control module 116 can bundle or cluster data (represented by circles) in a defined area 216 relating to where vehicles have entered or merged from lane 206 of road 202 onto lane 208 of exit 204. The control module 116 can then identify a road segment 210, 212, 214 that belongs to the respective clusters. In other words, the clusters represent the road segments 210, 212, 214 where most vehicles turn onto or merge into exit lane 208. Although the example in Fig. 2. Three road sections are shown; more or fewer road sections can also be identified if desired and / or based on the clustered data, the defined area, etc.

[0041] With further reference to Fig. 1-2 The control module 116 then determines reliability rating numbers for road segments 210, 212, and 214 within the defined area 216 of road 202. In such examples, the reliability rating numbers can be determined based on the aggregated location data of the vehicles that provide the crowdsourced data and that have traveled within the defined area 216 of road 202. For example, the control module 116 can determine a reliability rating number for each road segment 210, 212, and 214 based on the frequency with which each vehicle has traveled within the defined area 216 of road 202. Thus, each reliability rating number generally represents a degree of reliability associated with the crowdsourced data.

[0042] In various embodiments, the control module 116 can determine one or more reliability rating numbers for each road segment 210, 212, 214. For example, each reliability rating number can be determined for a road segment that relates to a specific driving situation or condition, such as morning, afternoon, night, bad weather, etc. In such examples, the control module 116 can create multiple clusters based on the location data specific to each driving condition and then determine a reliability rating number for each road segment and each driving condition. In such examples, the driving condition can be a different time of day (e.g., 7:30 a.m., morning, morning rush hour, afternoon, evening rush hour, after dark, etc.), a different day (e.g., Monday, Friday, Sunday, weekday, weekend, etc.), a road condition (e.g., icy, wet, dry, etc.).), a weather condition (e.g. foggy, rainy, snowy, etc.) etc.

[0043] In some examples, the control module 116 can determine each reliability rating based on the area knowledge of road 202 and / or exit 204 of the vehicles providing the crowdsourced data. For example, the control module 116 can determine familiarity ratings for the vehicles in each road segment 210, 212, 214 based on the frequency with which the vehicles have traveled through the defined area 216 of road 202, and then determine the reliability ratings for the road segments based on these familiarity ratings.

[0044] For example, a reliability rating for a road segment can be determined according to the following equation (1), where the number of vehicles (V) is divided based on the vehicles' familiarity with the location. In this example, the familiarity rating is calculated by multiplying the number of vehicles (V) for different levels of familiarity by a corresponding weighting value (ω) and then adding the results. The number of vehicles can be obtained from the crowdsourced data. RScore=∑[ωHV1+ωMV2+ωLV3+ω0V4]

[0045] In equation (1) above, V1 represents the number of vehicles (or a vehicle count) that pass through exit 204 daily (e.g., every day of the week), V2 represents the number of vehicles that pass through exit 204 at least once a week, V3 represents the number of vehicles that pass through exit 204 a few times (e.g., less than once a week, etc.), and V4 represents the number of vehicles that are new to exit 204 (e.g., have never passed through exit 204 before). Furthermore, equation (1) contains ω H for a high weighting of the reliability / trustworthiness rating, ω M for a medium weighting of the reliability / trustworthiness rating, ω Lω₁ represents a low weighting of the reliability / familiarity rating, and ω₀ represents a zero weighting of the reliability / familiarity rating. In such examples, the high weighting of the reliability / familiarity rating is the largest value (e.g., the highest weighting), while the low weighting of the reliability / familiarity rating is the lowest value (e.g., the smallest weighting). The corresponding weighting values ​​(ω) for each number of vehicles can be set and adjusted as desired. For example: ω₁ H can 0.8, ω M can 0.5, ω L can be 0.2 and ω0 can be zero.

[0046] In some examples, some or all reliability scores can be changed once or several times, if desired. For example, control module 116 can change one or more reliability scores for each road segment 210, 212, 214 based on the frequency of braking events in that segment. In such examples, control module 116 can determine the number of hard braking events in a road segment from crowdsourced telemetry data and then change a reliability score accordingly. In this example, hard braking can be defined as a deceleration greater than or equal to a certain threshold (e.g., 20 kilometers per hour per second, etc.). For example, control module 116 can modify a reliability score (R) Score-mod ) according to the following equation (2). RScore−mod=RScore−∑αiδi

[0047] In equation (2) i represents the number of braking events (e.g., hard braking) and alpha (∝) a weighting based on braking intensity, delta (δ) is a fixed value for the reduction of the reliability rating per hard braking event, and R Score stands for the original reliability rating number.

[0048] Furthermore, in some embodiments, the control module 116 can modify one or more reliability rating numbers for each road segment 210, 212, 214 based on the total time all vehicles require to merge onto that road segment. For example, the control module 116 can modify a reliability rating number (R) Score-mod2 ) according to the following equation (3). In equation (3), j represents the number of vehicles entering exit lane 208 at a given time. Fig. 2 are established, beta (β) is a scaling parameter, t jt0 represents the time at which the vehicle in question departs, t0 represents a specific time of departure, and R Score-mod represents the previously modified reliability rating number in equation (2). In other examples, R can be used in equation (3). Score (the original reliability rating number) instead of R Score-mod be used. RScore−mod2=RScore−mod−∑jβj(tj−t0)

[0049] In various embodiments, the control module 116 can store each of the determined reliability rating numbers in a database. The stored reliability rating numbers may or may not be modified, as explained above. In such examples, the database may contain section information relating to road sections 210, 212, 214 that correspond to the reliability rating numbers, driving conditions that correspond to the reliability rating numbers, and so on. This database (or the data it contains) can be accessed and / or made available to the control module 104 to generate recommendations for merging into lanes.

[0050] With continued reference to Fig. 1. The control module 104 selects one of the road segments 210, 212, or 214 with the highest reliability score for use in generating lane-merging recommendations. In some examples, if the reliability scores are generated according to different driving conditions, the control module 104 can select the road segment 210, 212, or 214 with the highest reliability score that exhibits a driving condition corresponding to a current driving state associated with the vehicle 102. For example, the control module 104 can determine the current driving state (e.g., morning, afternoon, night, bad weather, etc.) based on inputs from sensors 110, 112, or 114, inputs from other onboard sensors, and / or inputs from external sources.Then, based on the current driving condition, the control module 104 can select the road segment 210, 212, 214 with the highest reliability rating for that corresponding driving condition.

[0051] The control module 104 then identifies a portion of the selected road segment that is optimal for merging from one lane (e.g., lane 206) into another (e.g., lane 208). For example, the control module 104 can divide the selected road segment into multiple sections (or subsections). In such examples, the section of the selected road segment can be identified, for example, based on the probability of a lane change time and the difference in vehicle speeds between the adjacent lanes (e.g., lanes 206 and 208), as explained below.

[0052] For example, road section 212 can be made of Fig. 2 may have a higher reliability rating than road segments 210 and 214 at a specific time or under different driving conditions. In this example, control module 104 selects road segment 212 and divides it into several sub-segments (e.g., two or more sub-segments). Control module 104 can then determine, for each sub-segment, the probability of a lane change within a given timeframe and a probability-based feasibility of the lane change. As further explained here, the merging feasibility for each sub-segment can be determined, for example, based on the number of vehicles, the expected distance to the vehicle ahead, the vehicle speed, and the speed difference to the vehicles in the adjacent lanes 206 and 208.

[0053] In various embodiments, the control module 104 can determine the probability of a lane-change time period and the feasibility of the lane change for each segment of the selected road segment (e.g., road segment 212) according to the following equations (4)-(8). In such examples, the control module 104 can apply a probabilistic model to estimate the probability of a successful lane change, based on the assumption that the position of a global positioning system (GPS), the telemetry of a distance to the vehicle ahead, the determination of the main lane, and the vehicle positions per lane follow a Poisson point process of the expected travel path. Here, the Poisson point process represents randomly arranged points.Such data can be collected from a dataset of a sample for the distance to the vehicle ahead, which includes latitude, longitude, heading, distance to the vehicle ahead, and timestamp data. In such examples, distance to the vehicle ahead is a measure of the time interval between two vehicles (e.g., vehicle 102 and another vehicle). For instance, distance to the vehicle ahead could be the time elapsed between the arrival of a preceding vehicle at a particular test point and the arrival of a following vehicle at the same test point. Distance to the vehicle ahead can generally be expressed in seconds per vehicle.

[0054] For example, an expected distance to the vehicle ahead (λ) can be defined according to equation (4) below. Here, the average distance to the vehicle ahead can be determined from a sample (e.g., a specific distance H to the vehicle ahead) from the crowdsourced telemetry data. λ=avg(H)

[0055] Then, taking into account a virtual road segment (S0) and the expected distance (λ) to the vehicle ahead, the number of vehicles (V) in this virtual road segment (S0) can be determined according to equation (5). In such examples, the virtual road segment (S0) can correspond to the length of one of the segments in the selected road sections, and the expected distance (λ) to the vehicle ahead can be determined using equation (4) above. V=S0λ

[0056] Then the control module 104 can determine the time for a safe lane change according to equation (6) below. Assuming an approaching vehicle is moving at a speed (v) and a safe lane change requires a vehicle distance (d0), the time (t) can be o ) for a safe lane change can be estimated using the equation (6) below. t0=d0v

[0057] The control module 104 can then determine the probability that there is a period of time to change lanes in a specific section of the selected road segment, according to the following equation (7). For example, in equation (7) the probability that a random time (t) is greater than the time (t) o ), to carry out a safe lane change, calculated on the basis of the expected distance (λ) to the vehicle in front determined above. P(t>t0)=e−λt

[0058] Since vehicle 102 is changing from lane 206 to lane 208, it may be desirable to consider the difference in vehicle speeds between the adjacent lanes 206 and 208. If the speed difference between the lanes is too large, a lane change is considered unsafe. In such examples, a defined threshold Δv0 for the speed difference between the adjacent lanes 206 and 208 can be applied to modify the lane-change probability (determined in equation (7) above) for a given portion of the selected road segment. This modified probability is called the feasibility of merging (or changing lanes) and is determined according to equation (8) below. In equation (8), µ represents a constant scaling factor, and Δv represents a speed difference between the adjacent lanes 206 and 208 (e.g.,an average speed difference of the vehicles in the adjacent lanes (206, 208), and f0 for a minimum value for the feasibility of a lane change, required for a safe lane change. In such examples, the constant scaling factor (µ) can be greater than 0 and less than or equal to 1 (e.g., 0 < µ ≤ 1). Furthermore, the value of the constant scaling factor (µ) decreases with increasing value of the speed difference (Δv). LMF=μP(t>t0)−(1−μ)Δv≥f0 if Δv≥Δv0

[0059] In various embodiments, it may be desirable to modify the feasibility of the lane change for each segment of the selected road section, e.g., based on driver characteristics, road conditions, etc. For example, the control module 104 can change the probability of a lane change within a given time period based on the cognitive state of the driver of vehicle 102, which in turn alters the feasibility of the lane change. The driver's cognitive state may relate to, for example, their age, stress level, attention, etc. In such examples, the required vehicle distance (d0) can be increased proportionally to the driver's cognitive state, which can be derived from their driving behavior, provided via user input, etc. Thus, for example, a modified required vehicle distance (d) m) according to equation (9) below. In equation (9), d0 represents the originally required vehicle distance and delta (δ) is a scaling factor determined based on the intensity of the driver's cognitive state. In such examples, the scaling factor may be larger for older drivers, higher stress levels, etc. This modified required vehicle distance (d) m ) can be used instead of the required vehicle distance (d0) in the above equation (6), which in turn changes the time (t o ) for a safe lane change, the probability of a lane change and the feasibility of a lane change of the above equations (6)-(8). dm=d0+δd0

[0060] Furthermore, in some examples, control module 104 can modify the probability of a lane change time period based on road conditions, which in turn also changes the feasibility of the lane change. For example, road conditions can vary depending on weather and / or other external factors. In such examples, poor road conditions (e.g., icy, snow-covered, covered with packed snow, slushy, wet, etc.) may require a greater required vehicle distance than generally good conditions (e.g., dry, etc.). Thus, the required vehicle distance (d0) can be increased proportionally to the road conditions, which can be determined from sensor inputs. In such examples, equation (9) can be used to calculate a modified required vehicle distance (d0). m) to determine, where the scaling factor (δ) represents a degree of road condition. For example, an icy road may have a higher scaling factor than a wet road.

[0061] In various embodiments, the speed (v) of an approaching vehicle can also be changed depending on the road conditions and / or the cognitive state of the driver. For example, taking the road conditions into account, a changed speed (v) can be implemented. m ) according to equation (10) below. In equation (10), v represents the original speed of an approaching vehicle (from equation (6) above) and delta (δ) is a scaling factor which, as explained above, is determined based on the road conditions. This changed speed (v m ) can be used instead of the velocity (v) in equation (6) above, which in turn allows the time (t) to be changed. o) for a safe lane change, the probability of a lane change and the feasibility of a lane change in equations (6)-(8) above are adjusted. vm=v−δv

[0062] Once the feasibility of changing lanes is known for each section of the selected road segment, the control module 104 can determine the section best suited for changing from one lane to another. For example, the optimal section for merging onto exit lane 208 in Fig. 2 is the section with the highest feasibility of a lane change.

[0063] In various embodiments, the vehicle system 100 can perform one or more actions based on the feasibility of a lane change. In some examples, the vehicle system 100 can control one or more vehicle functions of the vehicle 102 based on the identified section of the selected road segment. For example, the control module 104 of Fig. 1. Send one or more signals representative of the identified section to the vehicle control module 108. The vehicle control module 108 can then control at least one operation of the vehicle 102 based on the identified section. For example, the vehicle control module 108 can generate a control signal to direct the vehicle 102 to enter exit lane 208 (from lane 206) when the vehicle 102 is in the identified section of the selected road segment.

[0064] Additionally, the vehicle system 100 can display the selected road segment, highlighting the identified segment to indicate a recommendation for where to turn from lane 206 onto exit lane 208. In such examples, the control module 104 can transmit one or more signals to the display module 106 representing the selected road segment, its sub-segments, the feasibility of a lane change, the identified segment, and so on. The display module 106 can then output a visual representation of the selected road segment, with some or all of the sub-segments highlighted for the driver's view. In various embodiments, the visual representation may include only the highlighted portion. In other examples, the visual representation may highlight each portion (including the identified portion) in a different way (e.g., in a different color).

[0065] Fig. Figure 3, for example, shows a map 300 with a visual representation of a selected road segment, the parts or sections of which are highlighted for the driver. As shown, map 300 includes road 202 and exit 204 from Fig. 2 with lanes 206, 208. In this example, a selected road segment comprises 302 (e.g., road segment 212 in Fig. 2) Three sections 312, 314, 316. As shown, each section 312, 314, 316 is highlighted in a different way to indicate an optimal way for vehicle 102 to merge into lanes and other (e.g., less optimal) ways for vehicle 102 to merge into lanes. In Fig. In Figure 3, section 316 is represented by diagonal lines representing the color green, section 314 by crossed lines representing the color yellow, and section 312 by vertical lines representing the color red. In this example, section 316 is identified (by control module 104) as the optimal lane merging route for vehicle 102, based on the probability of a timeframe for changing lanes (merging into lane 208) and a speed difference between the vehicles (e.g., vehicles 304, 306, 308, 310, etc.) in lanes 206 and 208.

[0066] In the Fig. Figures 4-8 show further examples of visual representations 400, 500, 600, 700, 800 that can be provided by the display module 106, e.g. via a head-up display in the vehicle 102. Fig. For example, visual representation 400 contains a selected road segment 402 with sections 412, 414, and 416. In this example, section 416 is highlighted in green, indicating the most optimal way for vehicle 102 to merge into lanes; section 414 is highlighted in yellow; and section 412 is highlighted in red, indicating less optimal ways for vehicle 102 to merge into lanes.

[0067] In Fig. Visual representation 500 contains a selected road segment 502 with sections 512 and 514. In this example, section 512 is highlighted in green, indicating the optimal merging route for vehicle 102, and section 514 is highlighted in red, indicating a less optimal merging route for vehicle 102. Visual representation 500 also contains... Fig. 5 arrows 520 instructing the driver of vehicle 102 to enter section 512.

[0068] In Fig. Figure 6 contains the visual representation 600, a selected road segment 602 with sections 612 and 614. In this example, section 614 is highlighted in green, indicating the most optimal way for vehicle 102 to merge into lanes, and section 612 is highlighted in red, indicating a less optimal way for vehicle 102 to merge into lanes. As in Fig. 5 contains the visual representation 600 of Fig. 6 arrows 620 instructing the driver of vehicle 102 to enter section 614.

[0069] In the Fig. Figures 7-8 show visual representations 700 and 800 examples of notifications that instruct the driver to “Merge to exit lane now!!” or “Enter the exit lane now!”.

[0070] Fig. Figures 9-12 show exemplary control processes 900, 1000, 1100, 1200, which control the vehicle system 100 of Fig. 1 can be used. Although the exemplary control processes 900, 1000, 1100, 1200 with respect to the vehicle system 100 of Fig. 1 including the control module 104, the display module 106, the vehicle control module 108 and / or the control module 116, each of the control processes 900, 1000, 1100, 1200 can be used by another suitable system and / or other suitable modules if desired.

[0071] The 900 control process is implemented to provide visual representations of recommendations for merging into lanes. As in Fig. As shown in Figure 9, the control process 900 begins at 902 with the identification of road segments in a defined area for merging from one lane to another, e.g., from lane 206 to exit lane 208. Fig. 2. In such examples, the control module 116 of Fig. 1. Identify such road segments based on crowdsourced data. As explained above, control module 116 can, for example, cluster location data (from the crowdsourced data) within the defined area relating to where vehicles transitioned from lane 206 to lane 208, and then identify road segments associated with each cluster. Control process 900 then proceeds to 904.

[0072] At 904, control module 116 determines one or more reliability scores for each road segment under various driving conditions. As explained above, control module 116 might, for example, determine the reliability score(s) based on the frequency with which vehicles have traveled on road 202 at exit 204. In such examples, control module 116 might determine familiarity scores for the vehicles and then determine the reliability scores for the road segments based on those familiarity scores, as explained above. Control process 900 then proceeds to 906.

[0073] At 906, control module 116 optionally modifies the reliability rating numbers based on one or more conditions. As explained above, control module 116 can, for example, change the reliability rating numbers based on the frequency of braking events, the total time all vehicles take to merge, and so on. Control process 900 then proceeds to 908.

[0074] At 908, the control unit determines whether the vehicle 102 is approaching an area with a desired lane junction. For example, the control module 104 of Fig. 1. This determination is made based on input from a navigation system (e.g., a mapping system) that monitors and provides instructions for upcoming maneuvers to reach a desired location. If the answer at step 908 is "yes," the control process 900 proceeds to step 910. Otherwise, if the answer at step 908 is "no," the control process 900 returns to step 908. In other examples, the control process 900 can return to another appropriate step (e.g., 902, etc.) if desired.

[0075] At 910, the control module 104 determines the current driving state of the vehicle 102. For example, as explained above, the control module 104 can determine the current driving state based on inputs from sensors 110, 112, 114, inputs from other onboard sensors, and / or inputs from external sources. The control process 900 then proceeds to 912, where the control module 104 selects a road segment from the identified road segments with the highest reliability rating that corresponds to the current driving state. The control process 900 then proceeds to 914.

[0076] In case 914, the control module 104 identifies a portion of the selected road segment that is optimal for merging from lane 206 to lane 208. In such examples, the control module 104 can identify this segment based on the probability of a lane-change timeframe and a difference in vehicle speeds between lanes 206 and 208 (e.g., the feasibility of the lane change). As explained above, the control module 104 can, for example, divide the selected road segment into several segments, determine a probability of a lane-change timeframe for each segment, and then establish a lane-change feasibility based on the probability and a difference in vehicle speeds for each segment.Then, control module 104 can identify the section of the selected road segment with the highest feasibility of the lane change as optimal for the lane change. Control process 900 then proceeds to 916.

[0077] At 916, the display module 106 outputs a visual representation of the selected road segment, with some or all segments (including the identified segment) highlighted for the driver, as explained above. The control process 900 then ends as described in Fig. 9 is shown. Alternatively, the control process 900 can return to another step, e.g. to 908, if desired.

[0078] The tax process 1000 of Fig. 10 is implemented for controlling a vehicle to merge based on lane recommendations during merging. Fig. The tax process 1000 is similar to the tax process 900. Fig. 9, but contains an alternative step. As in Fig. As shown in Figure 10, the control process 1000, for example, comprises steps 902, 904, 906, 908, 910, 912, 914 of Fig. 9, as explained above, and then proceeds to 1016. At 1016, the vehicle control module 108 controls at least one operation of the vehicle 102 based on the identified section (starting from 914). As explained above, the vehicle control module 108 can, for example, generate a control signal to direct the vehicle 102 to enter exit lane 208 (from lane 206) when the vehicle 102 is in the identified section of the selected road segment. The control process 1000 then ends as in Fig. 10 is shown. Alternatively, the control process 1000 can return to another step, e.g. to 908, if desired.

[0079] The tax processes 1100, 1200 of Fig. 11 and Fig. 12 are used to determine trustworthiness or reliability rating figures. In Fig. At 1102, the control process 1100 begins at 1102 and 1104. At 1102, the control module 116 receives crowdsourced telemetry data (as explained above). At 1104, the control module 116 receives street-level map data (e.g., an open-source road map (OSM), etc.). The control process 1100 then returns to 1106. At 1106, the control module 116 performs a map matching process to coordinate the crowdsourced telemetry data and the street-level map data. The control process 1100 then proceeds to 1108.

[0080] At 1108, control module 116 receives lane-level map data. This lane-level map data can contain detailed information (e.g., lane-level details) such as lane boundaries, associated timestamps, etc. Control process 1100 then proceeds to 1110, where control module 116 determines whether a lane change / merging has been detected. In such examples, this determination can be based on coordinated crowdsourced telemetry data, road-level map data, and lane-level map data. If the answer at 1110 is "yes," control process 1100 continues to 1112 and 1114. If the answer at 1110 is "no," control process 1100 returns to 1102 and 1104.

[0081] At 1112, control module 116 aggregates location data from the crowdsourced telemetry data. Subsequently, at 1114, control module 116 aggregates the vehicle IDs associated with this location data. For example, control module 116 can aggregate specific location data relating to a particular region at the point of lane change / merging and the vehicle IDs of the vehicles providing this location data. Control process 1100 then proceeds to 1116.

[0082] At 1116, control module 116 determines a cumulative frequency for the vehicles based on their vehicle IDs. For example, control module 116 can identify each vehicle (based on its vehicle ID) that has passed through exit 204 and differentiate the occurrences of the vehicles based on their familiarity with the area. In such examples, the occurrences of vehicles for different familiarity levels can be aggregated into several distinct vehicle counts. In this example, each vehicle count can represent the number of vehicles that pass through exit 204 within a specific time period (e.g., daily, weekly, etc.). Each vehicle count can refer to a frequency with which the vehicles have traveled through the defined area. Control process 1100 then proceeds to 1118.

[0083] At 1118, control module 116 determines familiarity ratings for the vehicles in each road segment based on the cumulative frequency of 1116 and weighted values. As explained above, control module 116 can, for example, determine familiarity ratings by multiplying each vehicle count for a different level of familiarity by an appropriate weighting value. The control process 1100 then ends as in Fig. 11 shown.

[0084] In Fig. The tax process begins on 1200 at 902. Fig. 9, where the control module 116 identifies road segments in a defined area for merging from one lane to another, e.g. from lane 206 to exit lane 208 from Fig. 2. Tax process 1200 then continues to 1204.

[0085] At 1204, control module 116 determines familiarity rating scores for the vehicles in the road segments. Control module 116 can, for example, control process 1100 from Fig. 11 implements the determination of the familiarity rating numbers. Control process 1200 then proceeds to 1206, where control module 116 determines a reliability rating number for each road segment. For example, as explained above, control module 116 can determine such reliability ratings according to equation (1). Control process 1200 then proceeds to 1208, where control module 116 can optionally determine reliability ratings for each road segment for different driving conditions (as explained above). Control process 1200 then proceeds to 1210.

[0086] At step 1210, control module 116 determines whether changes to the reliability rating figures are desired. This can be determined based on user input, recorded driving characteristics of other vehicles, etc. If step 1210 answers "yes," control process 1200 continues with step 1212. If step 1210 answers "no," control process 1200 continues with step 1214.

[0087] At 1212, control module 116 modifies the reliability rating numbers based on one or more conditions. As explained above, control module 116 can, for example, modify the reliability rating numbers based on the frequency of braking events, the total time all vehicles take to merge, and so on. Control process 1200 then proceeds to 1214.

[0088] In the 1214, control module 116 stores information for each road segment in a database. As explained above, control module 116 can, for example, store the determined (modified or unchanged) reliability rating numbers for the various road segments, along with the driving conditions corresponding to those reliability rating numbers. This database (or the data it contains) can be accessed and / or provided to control module 104 to generate lane-merging recommendations, as explained above.

[0089] The foregoing description is merely explanatory and is not intended to limit the disclosure, its application, or use. The comprehensive teachings of the disclosure can be implemented in a multitude of forms. Although this disclosure contains certain examples, the true scope of the disclosure should therefore not be so limited, since other modifications are evident upon study of the drawings, the description, and the following claims. It is understood that one or more steps within a process may be carried out in a different order (or simultaneously) without altering the principles of the present disclosure.Although each of the embodiments above is described with specific features, any one or more of these features described in relation to any embodiment of the disclosure can be implemented in one of the other embodiments and / or combined with features of another embodiment, even if this combination is not explicitly described. In other words, the described embodiments are not mutually exclusive, and permutations of one or more embodiments with each other remain within the scope of this disclosure.

[0090] Spatial and functional relationships between elements (e.g., between modules, circuit elements, semiconductor layers, etc.) are described using various terms, such as "connected," "interlocking," "coupled," "adjacent," "next to," "on," "above," "below," and "arranged." If a relationship between a first and a second element is not explicitly described as "direct" in the above disclosure, this relationship may be a direct relationship in which no other intervening elements exist between the first and the second element, or it may be an indirect relationship in which one or more intervening elements (either spatial or functional) exist between the first and the second element.As used herein, the phrase “at least one of A, B and C” should be interpreted as a logical (A OR B OR C) using a non-exclusive logical OR and not as “at least one of A, at least one of B and at least one of C”.

[0091] In the diagrams, the direction of an arrow, as indicated by the arrowhead, generally shows the flow of information (e.g., data or instructions) that is relevant to the illustration. For example, if Element A and Element B exchange a variety of information, but the information transferred from Element A to Element B is relevant to the illustration, the arrow may point from Element A to Element B. This unidirectional arrow does not imply that no further information is transferred from Element B to Element A. Furthermore, Element B may send requests for or acknowledgments of information to Element A in return for information sent from Element A to Element B.

[0092] In this application, including the definitions below, the term "module" or the term "controller" may be replaced by the term "circuit". The term "module" may refer to, be part of, or include: an application-specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinational logic circuit; a field-programmable gate array (FPGA); a processor circuit (common, dedicated, or group) that executes code; a memory circuit (common, dedicated, or group) that stores the code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, e.g., in a system-on-a-chip.

[0093] The module may contain one or more interface circuits. In some examples, the interface circuits may include wired or wireless interfaces connected to a local area network (LAN), the internet, a wide area network (WAN), or combinations thereof. The functionality of any module of this disclosure may be distributed across multiple modules connected via interface circuits. For example, multiple modules may enable load balancing. In another example, a server module (also called a remote or cloud module) may perform some functions on behalf of a client module.

[0094] The term "code," as used above, can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, data structures, and / or objects. The term "shared processor circuit" refers to a single processor circuit that executes some or all of the code of multiple modules. The term "group processor circuit" refers to a processor circuit that, in combination with other processor circuits, executes some or all of the code of one or more modules. References to "multiple processor circuits" include multiple processor circuits on discrete chips, multiple processor circuits on a single chip, multiple cores of a single processor circuit, multiple threads of a single processor circuit, or a combination of the above.The term "shared memory circuit" refers to a single memory circuit that stores some or all of the code from multiple modules. The term "group memory circuit" refers to a memory circuit that, in combination with other memory devices, stores some or all of the code from one or more modules.

[0095] The term "memory circuit" is a subset of the term "computer-readable medium." The term "computer-readable medium," as used here, does not include transitory electrical or electromagnetic signals that propagate through a medium (e.g., on a carrier wave); the term "computer-readable medium" can therefore be considered tangible / material and non-transient. Non-restrictive examples of a non-transient, tangible, computer-readable medium are non-volatile memory circuits (e.g., a flash memory circuit, a erasable programmable read-only memory circuit, or a mask read-only memory circuit), volatile memory circuits (e.g., a static random-access memory circuit or a dynamic random-access memory circuit), magnetic storage media (e.g., an analog or digital magnetic tape or a hard disk drive), and optical storage media (e.g.,a CD, a DVD or a Blu-ray Disc).

[0096] The devices and methods described in this application can be implemented partially or completely by a specialized computer formed by configuring a general-purpose computer to perform one or more specific functions embodied in computer programs. The functional blocks, flowchart components, and other elements described above serve as software specifications that can be translated into computer programs through the routine work of an experienced technician or programmer.

[0097] The computer programs contain processor-executable instructions stored on at least one non-transient, tangible, machine-readable medium. The computer programs may also contain or access stored data. The computer programs may include a basic input / output system (BIOS) that interacts with the hardware of the specialized computer, device drivers that interact with specific devices of the specialized computer, one or more operating systems, user applications, background services, background applications, etc.

[0098] The computer programs can contain: (i) descriptive text to be parsed, e.g., HTML (Hypertext Markup Language), XML (Extensible Markup Language), or JSON (JavaScript Object Notation); (ii) assembly code; (iii) object code generated from the source code by a compiler; (iv) source code for execution by an interpreter; (v) source code for compilation and execution by a just-in-time compiler, etc. The source code can, for example, use the syntax of languages ​​such as C, C++, C#, Objective-C, Swift, Haskell, Go, SQL, R, Lisp, Java®, Fortran, Perl, Pascal, Curl, OCaml, Javascript®, HTML5 (Hypertext Markup Language 5th revision), Ada, ASP (Active Server Pages), PHP (PHP: Hypertext Preprocessor), Scala, Eiffel, Smalltalk, Erlang, Ruby, Flash®, Visual Basic®, Lua, MATLAB, Simulink, and others. It must be written in Python®.

Images