The present disclosure generally relates to vehicles with cooperative adaptive cruise control and, more specifically, vehicle-to-vehicle cooperation to marshal traffic.
Traffic congestion occurs when one or more lanes of a multilane road are blocked, for example, because of a construction or an accident. The blocked lanes reduce the flow rate of vehicles through the section of the road with the blocked lanes. The reduced flow is compounded due to the psychology of human drivers who focus on their individual travel time preferences.
The appended claims define this application. The present disclosure summarizes aspects of the embodiments and should not be used to limit the claims. Other implementations are contemplated in accordance with the techniques described herein, as will be apparent to one having ordinary skill in the art upon examination of the following drawings and detailed description, and these implementations are intended to be within the scope of this application.
Example embodiments are disclosed for vehicle-to-vehicle cooperation to marshal traffic. An example disclosed cooperative vehicle includes an example vehicle-to-vehicle communication module and an example cooperative adaptive cruise control module. The example cooperative adaptive cruise control module determines a location of a traffic cataract. The example cooperative adaptive cruise control module also coordinates with other cooperative vehicles to form a platoon of standard vehicles. Additionally, the example cooperative adaptive cruise control module coordinates with the other cooperative vehicles to move the formed platoon through the traffic cataract at a constant speed.
An example method includes determining a location of a traffic cataract. The example method also includes coordinating, with a vehicle-to-vehicle communication module, with other cooperative vehicles to form a platoon of standard vehicles. Additionally, the example method includes coordinating with the other cooperative vehicles to move the formed platoon through the traffic cataract at a constant speed.
An example tangible computer readable medium comprising instructions that, when executed, cause a vehicle to determine a location of a traffic cataract. Additionally, the instructions cause the vehicle to coordinate with a vehicle-to-vehicle communication module, with other cooperative vehicles to form a platoon of standard vehicles. The example instructions also cause the vehicle to coordinate with the other cooperative vehicles to move the formed platoon through the traffic cataract at a constant speed.
For a better understanding of the invention, reference may be made to embodiments shown in the following drawings. The components in the drawings are not necessarily to scale and related elements may be omitted, or in some instances proportions may have been exaggerated, so as to emphasize and clearly illustrate the novel features described herein. In addition, system components can be variously arranged, as known in the art. Further, in the drawings, like reference numerals designate corresponding parts throughout the several views.
While the invention may be embodied in various forms, there are shown in the drawings, and will hereinafter be described, some exemplary and non-limiting embodiments, with the understanding that the present disclosure is to be considered an exemplification of the invention and is not intended to limit the invention to the specific embodiments illustrated.
Human drivers normally prefer to maximize individual travel time. However, when a traffic cataract is encountered, to benefit all the drivers on the road, priority switches from individual travel time preferences to group flow rate though the traffic cataract. As used herein, a traffic cataract refers to a section of a multilane road on which one or more lanes are blocked to cause at least one lane to merge into another lane. For example, interstate highway may have four lanes traveling in a northbound direction with two of the lands block causing the two blocked lanes to merge into the two non-blocked lanes. As another example, a four lane interstate may normally have a flow rate of 24,000 cars per hour and the traffic cataract may cause a portion of the interstate of have an ideal flow rate of 12,000 cars per hour. However, in such an example, the flow rate through the traffic cataract is reduced because of lack of coordinate on the drivers. A better group flow rate depends on moving vehicles through the traffic cataract with a coordinated headway and speed consistent with safe driving.
Human drivers tend to accelerate too fast and too late when the following distance increases and stop too fast and too late when the following distance decreases. This sets up density waves that travel upstream and prevent traffic from reaching a maximum flow rate. Before the traffic cataract, the vehicles move slowly because vehicles in closed lanes are merging into the remaining open lanes. Synchronous flow dominates in this region where vehicles are merging into the free lanes from the blocked lanes. As used herein, synchronous flow refers to (a) a continuous traffic flow with no significant stoppage and (b) synchronization of vehicle speeds across different lanes on a multilane road. As vehicles from closed lanes merge into the stream of open lanes, queued vehicles in the open lanes are pushed back. Synchronous flow may transition into a traffic jam when the density of traffic increases and the speed of the traffic flow decreases. For example, for a few miles before the traffic cataract, the traffic may transition from free flow to synchronous flow. In such an example, right before the traffic cataract, the traffic may transition from synchronous flow to a traffic jam.
Increasingly, vehicles that are equipped with vehicle-to-vehicle (V2V) communication modules that can cooperate when in transit. These vehicles include a cooperative adaptive cruise control (CACC) that coordinates, for example, acceleration and deceleration to, when in groups, efficiently use road space, prevent accidents, and warn each other about road hazards. As used herein, vehicles with CACC are referred to as “cooperative vehicles.” Additionally, as used herein, vehicle without CACC are referred to as “standard vehicles.” As disclosed below, the cooperative vehicles coordinate their movement to marshal cooperative vehicles and standard vehicles though the traffic cataracts. The cooperative vehicles marshal in situations where the cooperative vehicles are a relatively small percentage (e.g., greater or equal to three percent) of the vehicles round the traffic cataract.
The cooperative vehicles detect that a traffic cataract is ahead on the roadway. To detect the traffic cataracts, the cooperative (i) detects traffic transitioning into synchronous flow, (ii) receives a message from a cooperative vehicle that has passed through the traffic cataract, and/or (iii) receive a notification from a navigation system. When the cooperative vehicles pass through traffic cataract, they broadcast a message that includes the location of the traffic cataract and the direction of travel. To move through the traffic cataract, the cooperative vehicles form the standard vehicles into platoons. To form the platoons, the cooperative vehicles (i) coordinate to position themselves across all the lanes of traffic and (ii) travel at a constant speed. This forces the standard vehicles between the rows of cooperative vehicles into synchronized flow so they can't change lanes. One or more of the cooperative vehicles leads a platoon of the standard vehicles through the open lanes of the traffic cataract. The cooperative vehicles adjust the speed of the vehicles such that when the platoon reaches the traffic cataract, it travels with a speed consistent with safe driving while maintaining traffic flow. In such a manner, while individual vehicles wait to travel through the traffic cataract, the average wait for the vehicles on a whole is reduced.
Additionally, in some examples, cooperative vehicles coordinate to facilitate a Cooperatively Managed Merge and Pass (CMMP) system. The CMMP system facilitates particular drivers accessing less congested lanes. Drivers with cooperative vehicles may choose to participate in the system in which driving behavior is monitored, recorded, and evaluated in a collective manner by themselves and other participating vehicles. This system would temporarily allow for particular cooperative vehicles (sometimes referred to as “consumer vehicles”) to drive at higher speeds in less-occupied lanes of traffic and also to merge and pass freely when needed. Other participating cooperative vehicles (sometimes referred to as “merchant vehicles”) voluntarily occupy slower lanes of traffic to facilitated the consumer vehicle to merge into their lanes and pass as needed. The CMMP system operates with individual token-based transactions, where the merchant vehicles and the consumers' vehicles agree to trade units of cryptocurrency (sometimes referred to as “CMMP tokens”). The CMMP tokens are used to validate and authorize a transaction in which, at consumer vehicle request, the merchant vehicles either occupy slower lanes of traffic themselves, or allow the consumer vehicle to merge into their own lane and pass as necessary. The participating merchant vehicles gain CMMP tokens from the consumer vehicle. In some examples, the time allotted to the request of the consumer vehicle is based on the number of CMMP tokens chosen by the consumer vehicle to be spent at that particular time. For example, a driver of a consumer vehicle which is running late for an appointment may request to pass any participating merchant vehicles for a duration of 10 minutes on a particular road or highway for 60 CMMP tokens, at a rate of 10 seconds preferential access per token.
The range detection sensors 104 detect ranges and speeds of vehicles 100 and 102 around the cooperative vehicle 100. The example range detection sensors 104 may include one or more cameras, ultra-sonic sensors, sonar, LiDAR, RADAR, an optical sensor, or infrared devices. The range detection sensors 104 can be arranged in and around the cooperative vehicle 100 in a suitable fashion. The range detection sensors 104 can all be the same or different. For example, the cooperative vehicle 100 may include many range detection sensors 104 (e.g., the cameras, RADAR, ultrasonic, infrared, etc.) or only a single range detection sensor 104 (e.g., LiDAR, etc.).
The example DSRC module 106 include antenna(s), radio(s) and software to broadcast messages and to establish connections between the cooperative vehicles 100, infrastructure-based modules (not shown), and mobile device-based modules (not shown). The DSRC module 106 includes a global positioning system (GPS) receiver and a inertial navigation system (INS) to share the location of the cooperative vehicle 100 and to synchronize the DSRC modules 106 of the different cooperative vehicles 100. More information on the DSRC network and how the network may communicate with vehicle hardware and software is available in the U.S. Department of Transportation's Core June 2011 System Requirements Specification (SyRS) report (available at http://www its.dot.gov/meetings/pdf/CoreSystem_SE_SyRS_RevA %20(2011-06-13).pdf), which is hereby incorporated by reference in its entirety along with all of the documents referenced on pages 11 to 14 of the SyRS report. DSRC systems may be installed on vehicles and along roadsides on infrastructure. DSRC systems incorporating infrastructure information is known as a “roadside” system. DSRC may be combined with other technologies, such as Global Position System (GPS), Visual Light Communications (VLC), Cellular Communications, and short range radar, facilitating the vehicles communicating their position, speed, heading, relative position to other objects and to exchange information with other vehicles or external computer systems. DSRC systems can be integrated with other systems such as mobile phones.
DSRC is an implementation of a vehicle-to-vehicle (V2V) or a car-to-car (C2C) protocol. Any other suitable implementation of V2V/C2C may also be used. Currently, the DSRC network is identified under the DSRC abbreviation or name. However, other names are sometimes used, usually related to a Connected Vehicle program or the like. Most of these systems are either pure DSRC or a variation of the IEEE 802.11 wireless standard. However, besides the pure DSRC system it is also meant to cover dedicated wireless communication systems between cars, which are integrated with GPS and are based on an IEEE 802.11 protocol for wireless local area networks (such as, 802.11p, etc.).
The CACC module 108 facilitates coordination, via the DSRC module 106, with other cooperative vehicles 100. As disclosed in
In the illustrated example of
In the illustrated example of
In the illustrated example of
In a second region 404 of the graph 400, the vehicles 100 and 102 are transitioning to synchronous flow from free flow. The synchronous flow is characterized by a continuous traffic flow with no significant stoppage and synchronization of vehicle speeds across different lanes on a multilane road. In the second region, the headway distance is reduced and the vehicles 100 and 102 begin to synchronize their speeds. When the cooperative vehicle 100 is in the second region 404, the CACC module 108 determines that the traffic cataract 200 is ahead of the cooperative vehicle 100.
In a third region 406 of the graph 400, the vehicles 100 and 102 are in synchronous flow. The vehicles 100 and 102 may abruptly transition from free flow to synchronous flow. When the cooperative vehicle 100 is in the third region 406, the CACC module 108 determines that the traffic cataract 200 is ahead of the cooperative vehicle 100.
In a fourth region 408 of the graph, the vehicles 100 and 102 are jammed. Being jammed is characterized by intermittent movement (e.g., moving short distances with frequent stops). When the cooperative vehicle 100 is in the third region 406, the CACC module 108 determines that the traffic cataract 200 is likely imminent. In a fifth region 410 of the graph 400, the vehicles 100 and 102 are stopped.
The CACC module 108 includes a processor or controller 608 and memory 610. The processor or controller 608 may be any suitable processing device or set of processing devices such as, but not limited to: a microprocessor, a microcontroller-based platform, a suitable integrated circuit, one or more field programmable gate arrays (FPGAs), and/or one or more application-specific integrated circuits (ASICs). The memory 610 may be volatile memory (e.g., RAM, which can include non-volatile RAM, magnetic RAM, ferroelectric RAM, and any other suitable forms); non-volatile memory (e.g., disk memory, FLASH memory, EPROMs, EEPROMs, memristor-based non-volatile solid-state memory, etc.), unalterable memory (e.g., EPROMs), read-only memory, and/or high-capacity storage devices (e.g., hard drives, solid state drives, etc). In some examples, the memory 610 includes multiple kinds of memory, particularly volatile memory and non-volatile memory.
The memory 610 is computer readable media on which one or more sets of instructions, such as the software for operating the methods of the present disclosure can be embedded. The instructions may embody one or more of the methods or logic as described herein. In a particular embodiment, the instructions may reside completely, or at least partially, within any one or more of the memory 610, the computer readable medium, and/or within the processor 608 during execution of the instructions.
The terms “non-transitory computer-readable medium” and “computer-readable medium” should be understood to include a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The terms “non-transitory computer-readable medium” and “computer-readable medium” also include any tangible medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a system to perform any one or more of the methods or operations disclosed herein. As used herein, the term “computer readable medium” is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals.
The sensors 602 may be arranged in and around the cooperative vehicle 100 in any suitable fashion. The sensors 602 may be mounted to measure properties around the exterior of the cooperative vehicle 100. Additionally, some sensors 602 may be mounted inside the cabin of the cooperative vehicle 100 or in the body of the cooperative vehicle 100 (such as, the engine compartment, the wheel wells, etc.) to measure properties in the interior of the cooperative vehicle 100. For example, such sensors 602 may include accelerometers, odometers, tachometers, pitch and yaw sensors, microphones, tire pressure sensors, and biometric sensors, etc. In the illustrated example, the sensors 602 include the range detection sensors 104. The sensors 602 may also include, for example, cameras and/or speed sensors (e.g., wheel speed sensors, drive shaft sensors, etc.).
The ECUs 604 monitor and control the subsystems of the cooperative vehicle 100. The ECUs 604 communicate and exchange information via a vehicle data bus (e.g., the vehicle data bus 606). Additionally, the ECUs 604 may communicate properties (such as, status of the ECU 604, sensor readings, control state, error and diagnostic codes, etc.) to and/or receive requests from other ECUs 604. Some cooperative vehicle 100 may have seventy or more ECUs 604 located in various locations around the cooperative vehicle 100 communicatively coupled by the vehicle data bus 606. The ECUs 604 are discrete sets of electronics that include their own circuit(s) (such as integrated circuits, microprocessors, memory, storage, etc.) and firmware, sensors, actuators, and/or mounting hardware. In the illustrated example, the ECUs 604 include parts that facilitate the CACC module 108 controlling the motive functions of the cooperative vehicle 100, such as a brake control unit, a throttle control unit, a transmission control unit, and a steering control unit.
The vehicle data bus 606 communicatively couples the DSRC module 106, the CACC module 108, sensors 602, and the ECUs 604. In some examples, the vehicle data bus 606 includes one or more data buses. The vehicle data bus 606 may be implemented in accordance with a controller area network (CAN) bus protocol as defined by International Standards Organization (ISO) 11898-1, a Media Oriented Systems Transport (MOST) bus protocol, a CAN flexible data (CAN-FD) bus protocol (ISO 11898-7) and/a K-line bus protocol (ISO 9141 and ISO 14230-1), and/or an Ethernet™ bus protocol IEEE 802.3 (2002 onwards), etc.
At block 814, the first cooperative vehicle 100a adjusts (e.g., increases or decreases) its acceleration to arrive at the specified target position for the first cooperative vehicle 100a at the specific time interval. At block 816, the second cooperative vehicle 100b adjusts (e.g., increases or decreases) its acceleration to arrive at the specified target position for the second cooperative vehicle 100b at the specific time interval. At block 818, the third cooperative vehicle 100c adjusts (e.g., increases or decreases) its acceleration to arrive at the specified target position for the third cooperative vehicle 100c at the specific time interval. At block 820, the fourth cooperative vehicle 100d adjusts (e.g., increases or decreases) its acceleration to arrive at the specified target position for the fourth cooperative vehicle 100d at a specific time interval. At blocks 822, 824, 826, and 828, the cooperative vehicles 100a-100d wait until the other cooperative vehicles 100a-100d are at their respective target position.
At block 906, the CACC modules 108 coordinate to allow the platoon(s) 204 selected at block 904 to advance through the traffic cataract 200, led by corresponding one(s) of the participating cooperative vehicles 100. The lead participating cooperative vehicle(s) 100 adjust the speed of the platoon(s) 204 so that the platoon(s) 204 traverse the traffic cataract 200 at a constant speed. At block 908, the CACC modules 108 coordinate to allow the platoon(s) 204 that are behind the platoon(s) 204 moving at block 906 to move to fill the lane vacated by the moving platoon(s) 204. The lead participating cooperative vehicle(s) 100 adjust the speed of the platoon(s) 204 so that the platoon(s) 204 move into the vacated portion of the lane(s) without standard vehicles 102 from other platoons 204 able to switch to the vacated claims. At block 910, the CACC modules 108 wait until the platoon(s) 204 moving through the traffic cataract 200 and the platoon(s) 204 moving into the vacated lane are in position to facilitate more platoon(s) 204 traversing the traffic cataract 200. The method then returns to block 902.
The flowcharts of
In this application, the use of the disjunctive is intended to include the conjunctive. The use of definite or indefinite articles is not intended to indicate cardinality. In particular, a reference to “the” object or “a” and “an” object is intended to denote also one of a possible plurality of such objects. Further, the conjunction “or” may be used to convey features that are simultaneously present instead of mutually exclusive alternatives. In other words, the conjunction “or” should be understood to include “and/or”. The terms “includes,” “including,” and “include” are inclusive and have the same scope as “comprises,” “comprising,” and “comprise” respectively.
The above-described embodiments, and particularly any “preferred” embodiments, are possible examples of implementations and merely set forth for a clear understanding of the principles of the invention. Many variations and modifications may be made to the above-described embodiment(s) without substantially departing from the spirit and principles of the techniques described herein. All modifications are intended to be included herein within the scope of this disclosure and protected by the following claims.
Number | Name | Date | Kind |
---|---|---|---|
7969324 | Chevion et al. | Jun 2011 | B2 |
8179281 | Strauss | May 2012 | B2 |
8352112 | Mudalige | Jan 2013 | B2 |
8924240 | Depura | Dec 2014 | B2 |
9147353 | Slusar | Sep 2015 | B1 |
9355423 | Slusar | May 2016 | B1 |
9390451 | Slusar | Jul 2016 | B1 |
9443358 | Breed | Sep 2016 | B2 |
9623876 | Slusar | Apr 2017 | B1 |
20090271084 | Taguchi | Oct 2009 | A1 |
20100256836 | Mudalige | Oct 2010 | A1 |
20120004835 | Sato | Jan 2012 | A1 |
20120123660 | Kagawa et al. | May 2012 | A1 |
20120166059 | Aso | Jun 2012 | A1 |
20130116909 | Shida | May 2013 | A1 |
20140195093 | Litkouhi et al. | Jul 2014 | A1 |
20160054736 | Kolhouse | Feb 2016 | A1 |
20170011633 | Boegel | Jan 2017 | A1 |
Entry |
---|
Self-Configuring TDMA Protocols for Enhancing Vehicle Safety With DSRC Based Vehicle-to-Vehicle Communications; Fan Yu; Subir Biswas; IEEE Journal on Selected Areas in Communications; Year: 2007, vol. 25, Issue: 8; pp. 1526-1537, DOI: 10.1109/JSAC.2007.071004. |
DGPS-Based Vehicle-to-Vehicle Cooperative Collision Warning: Engineering Feasibility Viewpoints; Han-Shue Tan; Jihua Huang IEEE Transactions on Intelligent Transportation Systems; Year: 2006, vol. 7, Issue: 4; pp. 415-428, DOI: 10.1109/TITS.2006.883938. |
Analysis of intelligent transport system with optical vehicle-to-vehicle communication; Nikhil Sharma; Vibhor Saini; 2015 International Conference on Soft Computing Techniques and Implementations (ICSCTI); Year: 2015; pp. 155-158, DOI: 10.1109/ICSCTI.2015.7489585. |
A Road Alert Information Sharing System with Multiple Vehicles Using Vehicle-to-Vehicle Communication Considering Various Communication Network Environment; Kenta Ito; Go Hirakawa; Yoshikazu Arai; Yoshitaka Shibata; 2015 18th International Conference on Network-Based Information Systems; Year: 2015; pp. 365-370, DOI: 10.1109/NBiS.2015.56. |
Cyber Physical Systems—Oriented Design of Cooperative Control for Vehicle Platooning; Alexandru Tiganasu et al.; 2017 21st International Conference on Control Systems and Computer Science (CSCS); Year: 2017; pp. 465-470. |
Analysis of ITS-G5A V2X communications performance in autonomous cooperative driving experiments; Ignacio Parra et al., 2017 IEEE Intelligent Vehicles Symposium (IV); Year: 2017; pp. 1899-1903. |
A Survey on Platoon-Based Vehicular Cyber-Physical Systems; Dongyao Jia et al.; IEEE Communications Surveys & Tutorials; Year: 2016, vol. 18, Issue: 1; pp. 263-284. |
Core System Requirements Specification (SyRS), www.its.dot.gov/index.htm Revision A—Jun. 13, 2011 (pp. 1-131). |