Patent ID: 12258023

DETAILED DESCRIPTION

Rubbernecking is the act of staring at something of interest, typically associated with one's curiosity for the happenings of another. When it comes to driving, rubbernecking is often the cause of traffic congestion. As drivers slow down to see something on the other side of a road or highway, often the scene of a collision, the drivers approaching the scene also have to slow down, creating a chain reaction of vehicles slowing down as they approach the scene, as illustrated among other things inFIG.4. In addition, sudden deceleration caused by rubbernecking may cause secondary collisions in the rubbernecking lane.

Intelligent vehicle features, such as autonomous driving, adaptive cruise control (ACC), and cooperative adaptive cruise control (CACC), allow a vehicle to navigate a road with minimal assistance from its driver. They may also allow the vehicle to coordinate its navigation with other vehicles on the road. If a vehicle with such features can detect or gather sufficient data to allow for the detection of increased traffic congestion due to rubbernecking, the vehicles can utilize these intelligent features to coordinate with other vehicles to thereby mitigate the effects of rubbernecking. For example, upon detection of increased traffic congestion due to rubbernecking, vehicles may activate ACC/CACC, as illustrated inFIG.4. Upon detection of increased traffic congestion due to rubbernecking, a vehicle may also move itself into another lane where there are fewer vehicles, as illustrated inFIG.8. A vehicle may also increase the level of autonomous driving to maintain proper driving while the driver is distracted. The systems may utilize vehicle-to-vehicle (V2V), vehicle-to-everything (V2X), or other forms of communications to facilitate such coordination. Accordingly, disclosed herein are alternative methods for preventing, in real-time, traffic congestion and potential collisions caused by rubbernecking.

Referring now toFIG.1, an example system100for controlling vehicle traffic is depicted. The system100may include a server102, a distracting event104, connected vehicles106, non-connected vehicles108, wireless connectivity110, a rubbernecking region112, and a congestion region114.

In some embodiments, the system100may utilize V2V communications, in which case the server102is not necessary. In other embodiments, the system100may utilize V2X communication, in which case the server102coordinates with the vehicles. In other embodiments, the system100may utilize some combination of V2V, V2X, or other forms of communications, in which case server102may assist the vehicles in coordinating with one another.

The server102is a computing device that may be positioned remotely from any roads and/or vehicles. The server102may be a moving server, such as another vehicle, a cloud-based server, or any other type of computing device. As illustrated, the server102is a cloud-based server. The server102may be communicatively coupled to the connected vehicles106via wireless connectivity110. In some embodiments, the server102may be a local server including, but not limited to, a roadside unit, an edge server, and the like.

Each of the connected vehicles106and the non-connected vehicles108may be a vehicle including an automobile or any other passenger or non-passenger vehicle such as, for example, a terrestrial, aquatic, and/or airborne vehicle. In some embodiments, one or more of the connected vehicles106and the non-connected vehicles108may be an unmanned aerial vehicle (UAV), commonly known as a drone.

Connected vehicles106are vehicles that contain one or more driving assist components (e.g., autonomous driving, CACC, etc.) and one or more radios to communicate with other vehicles and/or infrastructure. Connected vehicles106may establish wireless connectivity110with server102and/or with other connected vehicles106. Non-connected vehicles108may not have functionalities of communicating with the server102or other vehicles. The vehicles106and108may be unrelated to each other. That is, the owners and/or drivers of the vehicles106and108need not know each other or plan ahead to initiate communication. Additionally, the system100allows rubbernecking mitigation to be established at any time, even while vehicles106and108are driving. Furthermore, 6 connected vehicles106and many more non-connected vehicles108are shown. However, it should be understood that any number of connected and non-connected vehicles may be included.

The road of system100is a multi-directional roadway where one direction contains a distracting event104(e.g., collision, construction, etc.) and a congestion region114. Connected vehicles106within the congestion region114confirm that the distracting event104is indeed causing distraction to drivers. Another direction of the roadway contains a rubbernecking region112, where connected vehicles106monitor rubbernecking and the traffic condition of the rubbernecking region112. In some embodiments, the road of system100may not include the congestion region114, and the distracting event104may be on the shoulder of the rubbernecking region112or on the sidewalk next to the rubbernecking region112.

Referring now toFIG.2, a schematic diagram of an example system200is depicted. In particular, two connected vehicles106and a server102are depicted. The connected vehicle106may include a processor component208, a memory component210, a user gaze monitoring component212, a driving assist component214, a sensor component216, a vehicle connectivity component218, a network connectivity component220, a satellite component222, and an interface226. The connected vehicle106also may include a communication path224that communicatively connects the various components of the connected vehicle106.

The processor component208may include one or more processors that may be any device capable of executing machine readable and executable instructions. Accordingly, each of the one or more processors of the processor component208may be a controller, an integrated circuit, a microchip, or any other computing device. The processor component208is coupled to the communication path224that provides signal connectivity between the various components of the connected vehicle. Accordingly, the communication path224may communicatively couple any number of processors of the processor component208with one another and allow them to operate in a distributed computing environment. Specifically, each processor may operate as a node that may send and/or receive data. As used herein, the phrase “communicatively coupled” means that coupled components are capable of exchanging data signals with one another such as, e.g., electrical signals via a conductive medium, electromagnetic signals via air, optical signals via optical waveguides, and the like.

Accordingly, the communication path224may be formed from any medium that is capable of transmitting a signal such as, e.g., conductive wires, conductive traces, optical waveguides, and the like. In some embodiments, the communication path224may facilitate the transmission of wireless signals, such as Wi-Fi, Bluetooth®, Near-Field Communication (NFC), and the like. Moreover, the communication path224may be formed from a combination of mediums capable of transmitting signals. In one embodiment, the communication path224comprises a combination of conductive traces, conductive wires, connectors, and buses that cooperate to permit the transmission of electrical data signals to components such as processors, memories, sensors, input devices, output devices, and communication devices. Accordingly, the communication path224may comprise a vehicle bus, such as for example a LIN bus, a CAN bus, a VAN bus, and the like. Additionally, it is noted that the term “signal” means a waveform (e.g., electrical, optical, magnetic, mechanical, or electromagnetic), such as DC, AC, sinusoidal-wave, triangular-wave, square-wave, vibration, and the like, capable of traveling through a medium.

The memory component210is coupled to the communication path224and may contain one or more memory modules comprising RAM, ROM, flash memories, hard drives, or any device capable of storing machine readable and executable instructions such that the machine readable and executable instructions can be accessed by the processor component208. The machine readable and 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, e.g., machine language, that may be directly executed by the processor, or assembly language, object-oriented languages, scripting languages, microcode, and the like, that may be compiled or assembled into machine readable and executable instructions and stored on the memory component210. Alternatively, the machine readable and executable instructions may be written in a hardware description language (HDL), such as logic implemented via either a field-programmable gate array (FPGA) configuration or an application-specific integrated circuit (ASIC), or their equivalents. Accordingly, the methods described herein may be implemented on any conventional computer programming language, as pre-programmed hardware elements, or as a combination of hardware and software components.

The connected vehicle106may also include a user gaze monitoring component212. The gaze monitoring component212may include imaging sensors such as a camera or an infrared (IR) blaster. The data gathered by the gaze monitoring component212may be analyzed by the processor component208to determine whether the direction of the user's gaze is in the direction of the motion of the connected vehicle106or elsewhere. This analysis may be based on the user's head position, eye position, etc. In some embodiments, the connected vehicle106may transmit the data gathered by the gaze monitoring component212to the server102, and the processor230of the server102may analyze the data to determine whether the direction of the user's gaze is in the direction of the motion of the connected vehicle106or elsewhere.

The connected vehicle106may also include a driving assist component214, and the data gathered by the sensor component216may be used by the driving assist component214to assist the navigation of the vehicle. The data gathered by the sensor component216may also be used to perform various driving assistance including, but not limited to advanced driver-assistance systems (ADAS), adaptive cruise control (ACC), cooperative adaptive cruise control (CACC), lane change assistance, anti-lock braking systems (ABS), collision avoidance system, automotive head-up display, and the like. The information exchanged between vehicles may include information about a vehicle's speed, heading, acceleration, and other information related to a vehicle state.

The connected vehicle106also comprises the sensor component216. The sensor component216is coupled to the communication path224and communicatively coupled to the processor component208. The sensor component216may include, e.g., LiDAR sensors, RADAR sensors, optical sensors (e.g., cameras), laser sensors, proximity sensors, location sensors (e.g., GPS modules), and the like. In embodiments, the sensor component216may monitor the surroundings of the vehicle and may detect other vehicles and/or traffic infrastructure.

The connected vehicle106also comprises a network connectivity component220that includes network interface hardware for communicatively coupling the vehicle106to the server102. The network connectivity component220can be communicatively coupled to the communication path224and can be any device capable of transmitting and/or receiving data via a network or other communication mechanisms. Accordingly, the network connectivity component220can include a communication transceiver for sending and/or receiving any wired or wireless communication. For example, the network interface hardware of the network connectivity component220may include an antenna, a modem, a LAN port, a Wi-Fi card, a WiMAX card, a cellular modem, near-field communication hardware, satellite communication hardware, and/or any other wired or wireless hardware for communicating with other networks and/or devices.

The connected vehicle106also comprises a vehicle connectivity component218that includes network interface hardware for communicatively coupling the vehicle106to other connected vehicles. The vehicle connectivity component218can be communicatively coupled to the communication path224and can be any device capable of transmitting and/or receiving data via a network or other communication mechanisms. Accordingly, the vehicle connectivity component218can include a communication transceiver for sending and/or receiving any wired or wireless communication. For example, the network interface hardware of the vehicle connectivity component218may include an antenna, a modem, a LAN port, a Wi-Fi card, a WiMAX card, a cellular modem, near-field communication hardware, satellite communication hardware, and/or any other wired or wireless hardware for communicating with other networks and/or devices.

The connected vehicle106may connect with one or more other connected vehicles and/or external processing devices (e.g., the server102) via a direct connection. The direct connection may be a vehicle-to-vehicle connection (“V2V connection”) or a vehicle-to-everything connection (“V2X connection”). The V2V or V2X connection may be established using any suitable wireless communication protocols discussed above. A connection between vehicles may utilize sessions that are time and/or location-based. In embodiments, a connection between vehicles or between a vehicle and an infrastructure may utilize one or more networks to connect which may be in lieu of, or in addition to, a direct connection (such as V2V or V2X) between the vehicles or between a vehicle and an infrastructure. By way of a non-limiting example, vehicles may function as infrastructure nodes to form a mesh network and connect dynamically/ad-hoc. In this way, vehicles may enter/leave the network at will such that the mesh network may self-organize and self-modify over time. Other non-limiting examples include vehicles forming peer-to-peer networks with other vehicles or utilizing centralized networks that rely upon certain vehicles and/or infrastructure. Still other examples include networks using centralized servers and other central computing devices to store and/or relay information between vehicles.

A satellite component222is coupled to the communication path224such that the communication path224communicatively couples the satellite component222to other modules of the connected vehicle106. The satellite component222may comprise one or more antennas configured to receive signals from global positioning system satellites. Specifically, in one embodiment, the satellite component222includes one or more conductive elements that interact with electromagnetic signals transmitted by global positioning system satellites. The received signal is transformed into a data signal indicative of the location (e.g., latitude and longitude) of the satellite component222, and consequently, the connected vehicle106.

The connected vehicle106may also include a data storage component that may be included in the memory component210. The data storage component may store data used by various components of the connected vehicle106. In addition, the data storage component may store data gathered by the sensor component216, received from the server102, and/or received from other vehicles.

The connected vehicle106may also include an interface226. The interface226may allow for data to be presented to a human driver and for data to be received from the driver. For example, the interface226may include a screen to display information to a driver, speakers to present audio information to the driver, and a touch screen that may be used by the driver to input information. In other examples, the connected vehicle106may include other types of interfaces226. The interface may output information that the connected vehicle106received from the server102. For example, the interface226may display instructions to turn on CACC from the server102such that the driver of the connected vehicle106understands that CACC is turned on per the instructions from the server102.

In some embodiments, the connected vehicle106may be communicatively coupled to the server102by a network. The network may be a wide area network, a local area network, a personal area network, a cellular network, a satellite network, and the like.

Another vehicle107may comprise the same or similar components as connected vehicle106. The other vehicle107may include a processor component209, a memory component211, a user gaze monitoring component213, a driving assist component215, a sensor component217, a vehicle connectivity component219, a network connectivity component221, a satellite component223, a user interface component227, and a communication path225. The other connected vehicle107may be communicatively connected to the server102by a network as well as to other connected vehicles such as the connected vehicle106. Multiple connected vehicles106and107can combine to form an ad hoc network with peer-to-peer information sharing abilities. This would obviate the use of a server102to externally manage autonomous path planning and thus keep calculations local and between the connected vehicles106and107.

In scenarios such asFIG.4below, a connected vehicle106may share information about itself and its surroundings (including surrounding vehicles) to other connected vehicles, such as the connected vehicle107. A connected vehicle106may also aggregate information about other vehicles and their surroundings to process locally or to send to a server102for processing.

The server102comprises a processor230, a memory component232, a network connectivity component234, a data storage component236, and a communication path228. Each server component is similar in features to its connected vehicle counterpart, described in detail above.

Referring now toFIG.3, a flowchart of an example method for autonomous path planning300is depicted. The flowchart300is described by referring toFIG.2. At step302, the gaze directions of drivers of connected vehicles106in the rubbernecking region is obtained. Gaze direction may be determined via the gaze monitoring component212of connected vehicles106. The gaze direction may be stored in the data component of the connected vehicle106that made the determination or in the data storage component236of the server102.

At step304, the average speed of vehicles in the rubbernecking region112is determined and compared against a predetermined speed. In one example, the predetermined speed may be a speed lower than a normal speed on the road. For example, if the average speed of the vehicles on the road without traffic is 40 miles per hour, the predetermined speed may be set as 35 miles, 30 miles, or less. In another example, the predetermined speed may be set as a speed lower than the speed limit of the load by a certain amount. For example, if the speed limit is 50 miles per hour, the predetermined speed may be set as 35 miles per hour. In another example, the predetermined speed is a lower speed limit of the road. For example, if the upper speed limit is 65 miles per hour and the lower speed limit is 40 miles per hour, the predetermined speed may be set as 40 miles per hour.

Vehicle speed can be determined by the sensor component216of the connected vehicles106. The speed data can be stored and/or shared between the connected vehicles106and/or the server102. The connected vehicles106and/or server102having the speed data can then calculate the average speed of the connected vehicles106. The average speed is compared against the predetermined speed of the road, which may have been stored on the connected vehicle106and/or server102in advance or determined on the fly by the sensor component216of the connected vehicle106.

At step306, the condition of whether the gaze directions of the drivers of connected vehicles106are deviating from the moving direction of traffic is evaluated. This may be based on a pre-determined threshold or ratio of drivers in the rubbernecking region112. This condition may also be based on a dynamically determined threshold or ratio of drivers in the rubbernecking region112that is itself based on traffic conditions, such as, e.g., the density of congestion. If the number of drivers that are deviating their gaze is not above the threshold, then the process goes back to step302. If the number of drivers that are deviating their gaze is above the threshold, then the process goes to step308.

At step308, the condition of whether the average speed of the drivers in the rubbernecking region112are slower than the predetermined speed is evaluated. If the average speed is not below the predetermined speed, then the process goes back to step302. If the average speed is below the predetermined speed, then the process goes to step310. Some embodiments may require a threshold amount difference between the predetermined speed and the average speed for the process to proceed.

At step310, a command is issued to the connected vehicles106to control their mobility. The command may be any command that controls the mobility of the connected vehicles106such as modifying the level of autonomous driving, activating ACC/CACC, changing lanes, etc. to keep the flow of traffic moving, despite the rubbernecking drivers.

The command may be issued by the server102or by a connected vehicle106in the rubbernecking region112. A command issued by the server102operates on a client-server model where a command originates from the server and may go directly to each connected vehicle in the rubbernecking region112. A command issued by a connected vehicle106may be issued by the vehicle connectivity component218of a connected vehicle106to another connected vehicle107in V2V communication. A command issued by a connected vehicle106may operate on a peer-to-peer model such that the command is shared among connected vehicles106who will share with other connected vehicles107in the rubbernecking region112.

Referring now toFIG.4, a scenario400where a connected vehicle reports traffic conditions and a server directs connected vehicles in a rubbernecking region to activate CACC/ACC is depicted. Particularly,FIG.4illustrates a bidirectional roadway where one direction of traffic contains a distracting event104resulting in several drivers of the opposing direction with gazes that deviate402towards the event104. This further results in a speed calculation406of less than the roadway's predetermined speed408. A speed calculation406may be a calculation of the average speed in a rubbernecking region112as calculated by one or more connected vehicles106. This calculation may be performed in ways such as vehicles monitoring the speed of surrounding vehicles, gathering speed information reported by other connected vehicles106via their vehicle connectivity component218, requesting speed information from traffic infrastructure monitoring vehicle speed, etc.

Connected vehicles106in the congestion region114may determine whether there is non-recurring congestion, monitor the traffic condition, and activate the system. Connected vehicles106in the rubbernecking region112may report their gaze status to one another or may report it to the server102directly. Connected vehicles106in the rubbernecking region112may report their speed and the predetermined speed408to one another or may report it to the server102directly. In some embodiments, the server102may already know the predetermined speed based on the connected vehicle's106location.

InFIG.4, the connected vehicles106in the congestion region114determined there is a non-recurring congestion, thereby triggering the activation of the system. Non-recurring congestion is a form of congestion that occurs due to an irregular event (e.g., accidents, construction, emergencies, etc.), as opposed to recurring congestion, commonly known as “rush hour” traffic. Once the system is activated, each of the connected vehicles106in the rubbernecking region112may determine their speed and driver gaze status. Each of the connected vehicles106may report this information to each other and/or to the server102.

One or more of the connected vehicles106may gather the speed data of the other connected vehicles106in the rubbernecking region112and perform a speed calculation406to find the average speed, which is 40 miles per hour in this case. One or more of the connected vehicles106with the gaze and average speed data send that data in the form of a status update410to the server102.

The server102evaluates the conditions of whether the number of drivers whose gaze direction is deviating from the moving direction of their vehicles is beyond a threshold value and whether the average speed is less than a predetermined speed and decides to issue a vehicle command412to the connected vehicles106in the rubbernecking region112. In some embodiments, one or more of the connected vehicles106in the rubbernecking region112may evaluate the conditions and issue the appropriate command themselves via V2V communication. The connected vehicles106in the rubbernecking region112respond to the vehicle command412accordingly. Connected vehicles106outside of the rubbernecking region112are unaffected.

Referring now toFIG.5, a flowchart500of continuing or terminating an example method is depicted. After a command (e.g., CACC activation command) has been issued to control the mobility of connected vehicles106to mitigate traffic congestion created by rubbernecking, the method may determine whether the traffic congestion has in fact been mitigated. The flowchart is described by referring toFIG.4.

At step502, one or more commands have been issued to control the mobility of the connected vehicles106in the rubbernecking region112. In embodiments, the command is issued to the connected vehicles106to control their mobility. The command may be issued by the server102or by one of the connected vehicles106in the rubbernecking region112. The command may be any command that controls the mobility of the connected vehicles106such as modifying the level of autonomous driving, activating ACC/CACC, changing lanes, etc. to keep the flow of traffic moving, despite the rubbernecking drivers.

At step504, it is determined whether a time period longer than a predetermined time period has passed. When a command is issued to activate mobility control, the issuer (e.g., server102, connected vehicle106, etc.) may begin a timer for a time period. For example, previously at step310, the server102may have issued a command such as the vehicle command412to activate CACC/ACC. Based on the status update410, the server102calculates that this command should remain in effect for 15 minutes, after such time the status of the rubbernecking region112may be re-evaluated.

Additionally or alternatively, the command itself may have a lifespan timer. This way, when the command is issued to each connected vehicle106, each connected vehicle knows how long to follow the command. For example, previously at step310, a connected vehicle106may have determined that the conditions in steps306and308are satisfied such that a command should be issued to the other connected vehicles106. However, the connected vehicle106the command originates from may no longer be in the rubbernecking region after the timer is over, and thus would not be able to have further communications with the vehicles in the rubbernecking region112. Therefore, the command may have a lifespan timer of a length of time based on the traffic conditions of the rubbernecking region112, so that when the lifespan timer of the command is done another connected vehicle106in the rubbernecking region112may re-evaluate the traffic conditions.

The time period for the timer or lifespan may be fixed or it may be dynamic based on factors such as estimated duration of traffic congestion. Once the timer has ended, the process may move to step506.

Still at step504, if it is determined the time that has passed is not longer than the predetermined time period, then the process goes back to step502. If it is determined the time that has passed is longer than the predetermined time period, then the process goes to step506and the connected vehicles106in the rubbernecking region112keep operating according to the issued mobility control command. For example, if the server102set a timer for 15 minutes after issuing a vehicle command412at step310, the server will not re-evaluate traffic conditions in step506until the timer is done. If there is no server102and a command with a lifespan timer of 15 minutes has previously been issued, a connected vehicle106in the rubbernecking region112will not re-evaluate traffic conditions in step506until the command's lifespan timer is done.

At step506, the condition of whether the average speed has been restored to the predetermined speed or faster is evaluated. In one example, the predetermined speed may be a speed lower than a normal speed on the road. In another example, the predetermined speed may be set as a speed lower than the speed limit of the load by a certain amount. In another example, the predetermined speed is a lower speed limit of the road. If the traffic conditions have not restored to the predetermined speed or faster, then the process moves to step508where the rubbernecking region is expanded. If the traffic conditions have restored to the predetermined speed or faster, then the process moves to step510where a command to deactivate mobility control or shrink the rubbernecking region112is issued to the connected vehicles106in the rubbernecking region112. For example, previously at step310, the server102may have issued a command such as412to activate CACC/ACC. Based on the status update410, the server102calculates that this command should remain in effect for 15 minutes. After 15 minutes have passed, the server may request more information from the connected vehicles106in the rubbernecking region112to compare to the predetermined speed. If the traffic conditions have not restored to the predetermined speed, then the server102may take further measures to improve congestion in the rubbernecking region112such as expanding the rubbernecking region112so that more cars are affected by the server's commands and/or issuing new/continuing commands to the connected vehicles106of the rubbernecking region112. New actions may be accompanied with a reset timer to check the efficacy of the new actions in the future.

Referring now toFIG.6, a scenario600where a connected vehicle106reports traffic conditions and a server102expands the rubbernecking zone accordingly is depicted. The situation depicted is similar to that ofFIG.4; however, a vehicle command has been issued, yet traffic congestion has not improved neither has the degree of rubbernecking taking place in the rubbernecking region112. Also like the scenario depicted inFIG.4, connected vehicles106in the rubbernecking region112may report their gaze status to one another or may report it to the server102directly. Connected vehicles106in the rubbernecking region112may report their speed and the predetermined speed408to one another or may report it to the server102directly. In some embodiments, the server102may already know the predetermined speed based on the connected vehicle's106location. In some embodiments, the server102may perform the calculations discussed with the information reported from the connected vehicles106.

In scenario600, one of the connected vehicles106in the rubbernecking region calculated the average speed of the vehicles in the rubbernecking region112, which is 35 miles per hour in this case. One or more connected vehicles106may contain the gaze data of the connected vehicles106and average speed of the rubbernecking region112. Additionally, one or more connected vehicles106may send that data in the form of a status update604to the server102.

The server102determines whether the appropriate time period has passed and determines an area of an expanded rubbernecking region602. In some embodiments, one or more of the connected vehicles106in the rubbernecking region112may evaluate the conditions and determine the expanded rubbernecking region602themselves via V2V communication. The expanded rubbernecking region602may be a region of a predefined size.

For example, the initial rubbernecking region112may be 1 mile long and an expanded rubbernecking region602and subsequent expansions may be in ¼ mile increments. The expanded rubbernecking region602may alternatively be the distance between the last connected vehicle106of a rubbernecking region112and the next connected vehicle106outside of the rubbernecking region112. For example, the initial rubbernecking region112is 1 mile long and the next connected vehicle106is 1 mile behind the rubbernecking region112. In this case, the expanded rubbernecking region602would be 1 mile to include the next connected vehicle106, for a total length of 2 miles for rubbernecking region112. A cap value may be utilized to prevent the rubbernecking region112from expanding to unworkable distances.

The connected vehicles106in the rubbernecking region112may be unaffected since they already are in the rubbernecking region. Connected vehicles106outside of the rubbernecking region112are now affected by prior and/or subsequent mobility control commands because they are now in the rubbernecking region112.

Referring now toFIG.7, a scenario700where a connected vehicle reports traffic conditions and a server shrinks the rubbernecking zone accordingly is depicted. The situation depicted is similar to that of scenario600; however, a vehicle command has been issued and traffic congestion has improved as has the degree of rubbernecking taking place in the rubbernecking region112. Also like the scenario600, connected vehicles106in the rubbernecking region112may report their gaze status to one another or may report it to the server102directly. Connected vehicles106in the rubbernecking region112may report their speed and the predetermined speed408to one another or may report it to the server102directly. In some embodiments, the server102may already know the predetermined speed based on the connected vehicle's106location. In some embodiments, the server102may perform the calculations discussed with the information reported from the connected vehicles106.

In scenario700, one of the connected vehicles106calculated the average speed of the rubbernecking region112, which is 60 miles per hour in this case. One or more of the connected vehicles106with the gaze data of the connected vehicles106and average speed data send that data as a status update702to the server102.

The server102determines whether the appropriate time period has passed and determines an area of a shrunk rubbernecking region704. In some embodiments, one or more of the connected vehicles106in the rubbernecking region704may evaluate the conditions and determine the shrunk rubbernecking region704themselves via V2V communication. Connected vehicles106in the rubbernecking region704are now unaffected by prior and subsequent mobility control commands because they are no longer in the rubbernecking region112.

For example, the initial/current rubbernecking region112is 1 mile long and a shrunk rubbernecking region704and subsequent shrinking may be in ¼ mile increments. The shrunk rubbernecking region704may also be the distance between the last connected vehicle106of a rubbernecking region112and the next connected vehicle106inside of the rubbernecking region112. For example, the initial rubbernecking region112is 2 miles long and the next connected vehicle106is 1 mile ahead of the end of the rubbernecking region112, in which case the shrunk rubbernecking region704would be 1 mile.

Referring now toFIG.8, a scenario800where a connected vehicle reports traffic conditions and a server directs connected vehicles in a rubbernecking region to change lanes is depicted. Particularly,FIG.8illustrates a bidirectional roadway where one direction of traffic contains a distracting event104resulting in drivers of the opposing direction with gazes that deviate402towards the event104. Connected vehicles106in the rubbernecking region112may report their gaze status to one another or may report it to the server102directly. Connected vehicles106in the rubbernecking region112may report open lanes around them to one another or may report it to the server102directly.

In scenario800, one or more of the connected vehicles106determine that the right lane has less congestion than the left lane. One or more connected vehicles106may contain the gaze data of the connected vehicles106and lane congestion data of the rubbernecking region. Additionally, one or more connected vehicles106may send that data in the form of a status update802to the server102.

The server102evaluates the conditions of whether number of drivers whose gaze direction is deviating from the moving direction of their vehicles is beyond a threshold value and whether the average speed is less than a predetermined speed and decides to issue a vehicle command804to the connected vehicles106in the rubbernecking region112, in this case to change lanes into the less congested lane. In some embodiments one or more of the connected vehicles106in the rubbernecking region112may evaluate the conditions and issue the appropriate command themselves via V2V communication. The connected vehicles106in the congested left lane respond to the vehicle command804accordingly and move to the right lane. A connected vehicle106outside of the rubbernecking region112is unaffected.

It should now be understood that embodiments described herein are directed to methods and systems for autonomous path planning triggered by freeway rubbernecking. Connected vehicles in a rubbernecking region of a roadway nearing a distracting event monitor the gaze of the drivers and surrounding traffic conditions. If the amount of rubbernecking is significant and traffic condition is degrading, then a server may direct the connected vehicles in the rubbernecking region to activate intelligent vehicle systems to maintain the flow of traffic. This may cause the vehicles to activate autonomous driving capabilities, ACC/CACC capabilities, lane change capabilities, and the like.

After a period of time has passed, if the amount of rubbernecking or the traffic conditions have not improved, the system may direct the rubbernecking region to expand to potentially include more connected vehicles. If, however, the amount of rubbernecking or the traffic conditions have improved, the system may direct the rubbernecking region to shrink to potentially include fewer connected vehicles. The system may also direct connected vehicles in the rubbernecking region to resume normal operation.

It is noted that the terms “substantially” and “about” may be utilized herein to represent the inherent degree of uncertainty that may be attributed to any quantitative comparison, value, measurement, or other representation. These terms are also utilized herein to represent the degree by which a quantitative representation may vary from a stated reference without resulting in a change in the basic function of the subject matter at issue.

While particular embodiments have been illustrated and described herein, it should be understood that various other changes and modifications may be made without departing from the spirit and scope of the claimed subject matter. Moreover, although various aspects of the claimed subject matter have been described herein, such aspects need not be utilized in combination. It is therefore intended that the appended claims cover all such changes and modifications that are within the scope of the claimed subject matter.