DRIVER ASSISTANCE FOR ENHANCED ROAD SAFETY AND TRAFFIC MANAGEMENT

Transcription

1 DRIVER ASSISTANCE FOR ENHANCED ROAD SAFETY AND TRAFFIC MANAGEMENT by NITIN REDDY Submitted in partial fulfillment of the requirements For the degree Master of Science Thesis Advisor: Dr. Christos Papachristou Department of Electrical Engineering and Computer Science CASE WESTERN RESERVE UNIVERSITY May 2009

2 CASE WESTERN RESERVE UNIVERSITY SCHOOL OF GRADUATE STUDIES We hereby approve the thesis/dissertation of Nitin Reddy candidate for the Master of Science degree *. (signed) Christos Papachristou (chair of the committee) Francis "Frank" Merat Swarup Bhunia (date) March 19, 2009 *We also certify that written approval has been obtained for any proprietary material contained therein.

3 Table of Contents List of Tables... vi List of Figures... v CHAPTER 1 - Introduction Hypothetical working scenarios for car safety Hypothetical working scenario for traffic management Hardware Implications... 8 CHAPTER 2 - Simulation Approach Situations for a single lane Situations for multiple lanes Sample driver profile data CHAPTER 3 - Safety and Accuracy Autonomous vehicles Sensors Accuracy CHAPTER 4 - Algorithms and Software Design Sockets and communication Collision detection algorithms Road Hazard Detection Graphical Interface for Analysis iii

4 CHAPTER 5 - Traffic Management Simulation and Average Speed graphs CHAPTER 6 - Results Practical applications CHAPTER 7 - Conclusion and Future Work References Appendix A - Code for Socket Communication Appendix B - Class definition for a car Appendix C - Software for Graphical Analysis Appendix D - Results for a set of driver profiles iv

5 List of Tables Table 1 Expected output in a single lane configuration Table 2 Expected output in a multi lane configuration Table 3 Observed output for a multiple lane configuration v

6 List of Figures Figure 1-1 Flowchart to show the process of collision avoidance between two cars Figure 2-1 Single lane Figure 2-2 Multiple lanes Figure 2-3 Sample input profile for a driver Figure 2-4 Sample broadcasted data Figure 2-5 Byte layout of the data packet Figure 4-1 Socket connection algorithm Figure 4-2 Decision process for each Vehicle Figure 4-3 Screenshot from the graphical interface Figure 5-1 Traffic simulation Figure 5-2 Average speed variation with no traffic management Figure 5-3 Average speed variation with a corrective traffic management scheme Figure 5-4 Average speed variation with a preventive traffic management scheme Figure 6-1 Sample output for Car B Figure 6-2 Time variation of the Average Safety Distance in a 3 car scenario Figure 6-3 Plot of difference between Requested speed and Suggested speed for each collision 60 Figure 6-4 Road Hazard Detection vi

7 Driver Assistance for Enhanced Road Safety and Traffic Management Abstract by Nitin Reddy This study explores the use of inter vehicle communication to enhance road safety and traffic management. A vehicle s engine control unit (ECU) manages and controls various sensor signals, inputs and determines the output in terms of torque, fuel quantity and actuator positions. The data available in the ECU is however restricted only to that particular vehicle where it was generated. This work presents a scenario where critical data from each vehicle is broadcasted and a dynamic ad-hoc network of vehicles is formed. The algorithms in the ECU then detect possible collisions, decides which vehicle should take action and alerts the driver with the most optimum resolution. The analysis presented here is based on simulation data. Traffic management is achieved with modules placed along the road, which collect the broadcasted data. Modules, after analyzing traffic density and average speeds, interact with neighboring modules. This traffic information is broadcasted to all vehicles in close proximity to the traffic modules. The vehicle uses this information along with details from the navigation system to reroute the automobile to avoid high traffic areas. vii

8 CHAPTER 1 - Introduction Modern day automobiles consist of over 80 processors dealing with a plethora of information. Of these, the most important is the engine control unit (ECU), which deals with engine management, fuel management, dashboard information management, communication control and many other tasks. There is a lot of information present in the ECU especially in terms of vehicle speed, stability, acceleration, steering angle, brake position, average speed, trip meter etc. However on road, the information present in one car is restricted only to that car and is not available for other users of the road. In our system, we hope that all cars are equipped with wireless cards so that there is possibility of interaction of one car with the outside world. This system would be more feasible with the hardware once the drive by wire control systems are put into more widespread (rather than Control Area Network) use; as they, already have wireless communication capabilities. In this system, all cars on the road will exchange information with each other. This will enable each car to detect collisions and alert the driver thereby enhancing the safety and comfort of driving. The exchange would happen without the knowledge of driver and the driver would be prompted only when action is required. Currently existing systems use sensors to measure the proximity of the other vehicle for assisting the drivers. The main disadvantage of such an arrangement is that the sensors have a limited resolution. Also their accuracy reduces in case of low lighting or temperature conditions. For current cars, the benefit of this system would be limited to driver notification through dashboard warning lights and indicators of safety situations. The dashboard would alert the user of the imminent danger and can provide suitable solutions to avoid the same. 1

9 A study of rear end and chain accidents [1] showed that 28% of accidents in US were caused by short car following distance. This number was close to half (13%) in Europe and was 33% in Australia. For preventing these rear end collisions, an increased safety distance is the most appropriate solution. This can be easily achieved be providing feedback to the drivers in case a car in front or the one behind breaches this safety distance. Under special circumstances, for instance, if a vehicle has occupants including children or if there is some problem with the vehicle s functionality (software or hardware), the safety distance can be increased by the driver. The safety distance is a parameter included in the data packet, which is broadcasted, thereby enabling all nearby cars to know each other s safety distance aiding in the algorithms for collision avoidance. Currently autonomous vehicles aren t available for consumers, but considering this system is implemented in newer cars, with actuators to modify car variables such as steering wheel position, braking and speed, these safety algorithms would provide a better driver assistance and additional safety. A driver assistance system like the one mentioned above would bring us a step closer to completely autonomous vehicles. 2

10 For present day vehicles however, total control of the vehicle is always in the hands of the driver and the algorithms would convey the warnings and resolutions via displays mounted on the dashboards. A research conducted on human machine interactions for driver assistance [2] shows various ways in which a warning sign can be displayed to the driver. Few techniques involving audible alerts could be used such as you are driving too close to the car in front, reduce speed by 6 miles per hour. The authors also explored the benefits of haptic techniques such as force feedback on the accelerator pedal. Exploring such haptic techniques for this system, we can enable lane change warnings with vibrations on the steering wheel and speed reduction warnings with force feedback on the accelerator pedals. Systems like the one proposed will provided driver assistance and improve overall road safety and would be a vital part of any intelligent transportation system. 3

11 1.1 Hypothetical working scenarios for car safety Normal Driving: Consider two cars (Car A and Car B) travelling in the same lane in close proximity with each other. The software in these cars will exchange vital information about these cars, including speed and acceleration. The algorithms will now detect if a collision might occur based on the distance between the cars, the safety distance and the rate at which the distance between them is decreasing. If a collision occurrence is detected, the software then decides which car should take action. This is done primarily taking into account the speed of each car, the speed limit of the road and each individual car s interaction with other cars on the road. That is, say Car B is travelling at a speed much higher than the speed limit and a collision with Car A is detected. The software in each of the cars will then determine the most logical operation, which in this case is for Car B to reduce speed. This operation is confirmed by Car B, taking into account other cars on the road. If say for instance, another car (Car C) is also behind Car B and slowing down is not a feasible possibility or might cause a collision, then Car A is sent a signal to accelerate. These decisions are based on multiple factors as well such as number of lanes available and the traffic in the other lanes. After an operation is confirmed by the two cars in question, the driver is notified by a prompt with the most appropriate action. 4

12 Figure 1-1 Flowchart to show the process of collision avoidance between two cars. Lane Change: A car travelling in a lane (say X) wishes to change lane to lane Y. This is detected by either the steering wheel angle and/or an indicator switch by the driver. Based on this input from the user to change lanes the software would detect based on its position, speed, acceleration and lane data and data from other vehicles if any of the neighboring cars would be a 5

13 hazard for the particular lane change. If the algorithm detects a possible collision or an unsafe operation due to the lane changes, it would prompt the user advising against the lane change. This system would be particularly beneficial because of blind-spots (wherein a car s rear view mirror fails to show a 90 field of view), which cause a large percentage of highway related accidents. This system would also make roads safer especially during nights and times of bad weather. Overtaking: Another enhancement to this system is for detecting unsafe conditions while passing other vehicles in roads with no separators between the two ways of traffic flow. This system can prove beneficial especially when a driver is driving behind a larger vehicle thereby reducing their field of vision. 6

14 1.2 Hypothetical working scenario for traffic management We assume that the roads are divided into zones each with their unique id. For this system to work, each zone has traffic modules. These modules have receptors and transmitters in them, which collect information from the cars travelling in that zone and broadcast traffic data. Each car in that zone transmits its information packet that includes current speed, acceleration and average speed over the past few miles. Based on the information from all the cars in that zone, the module then calculates a mean and ignores the information from cars whose percentage variance is very high from the mean. A new mean is calculated based on the new set of data and is compared to the speed limit of that zone. Based on this, the traffic modules then calculate if the particular zone has high traffic (indicative by low average speeds), no traffic (normal averages speeds) or medium traffic. This information is relayed to the neighboring zones, which broadcast this information. A vehicle approaching this zone can then decide, taking the route and destination information from the vehicles navigational system, whether to avoid the zone where higher traffic was detected. The various techniques used for traffic management is explored further in Chapter 5. 7

15 1.3 Hardware Implications Over the years, we have had different modes of communication between on-road vehicles and traffic monitoring system. These have grown from simple hazard flashlights to optical or acoustic signals (vehicle horns) that indicate direction. However, these technologies remain to be limited in their use. Not only do these lack precision but also are often cost ineffective that limit their use in many situations. Cellular networks for instance GSM or radio based information are examples of the system in their inability to provide efficient transmission of data between multiple users. Further, they are also not the best choice to transmit individual data. Wireless LAN technology based Ad-hoc communication systems are unique possible upcoming systems that would have a clear advantage over the current known systems. They have the potential to provide a single user precise and accurate information when available, but it is also readily updated at the exact time and spaced so that an appropriate and best decision is possible. This adhoc network works as a complete system by controlling traffic decisions based on the information that is cogently gathered by receiving signals from surrounding traffic and processing it with its own router, based on its own machine, technical and on road limitations. The data is continuously obtained and processed accurately in real-time. For wireless connectivity there are a lot of possibilities. A lot of work has been done in Dedicated Short Range Communications (DSRC). They operate on a 5.9 GHz frequency system and have been tested for infrastructure to vehicle and vehicle to vehicle environments. High data speeds (factor of 10's of Mbps) can be achieved. Many companies have experimented with DSRC technologies for high speed vehicle communications with satisfying results. These tests were performed primarily for vehicle to stationary object especially for 8

16 systems like automatic toll collection. This DSRC communication architecture can be adapted and implemented for such an inter vehicle communication scheme. There are other technologies that can facilitate such a dynamic network and wireless communication between vehicles. Cars equipped with Wi-Fi with a peer to peer connection capability can easily connect to cars on the road that are within range. When provided with a central gateway, they can upload car and traffic statistics to a traffic module or a central server. Though extra hardware is required for transmitting packets of vehicle information to other vehicles, interfacing these with current cars will be relatively easy. As all modern cars communicate between the processors in the car via a control area network (CAN) bus. Tapping the bus and installing this new card would make existing cars enabled with this feature. For newer cars, this can come preinstalled installed. For traffic information, existing telephone/ electricity poles could be used with additional hardware or traffic light poles could come embedded with these traffic modules. Safety being the most important factor, there needs to be failsafe methods of detecting and analyzing incorrect data, avoiding deadlocks (example: Car A requests Car B to slow down and Car B requests Car A to accelerate) and clearing deadlocks. 9

17 Network communication issues would exist and algorithms need to be designed to ensure that dropped connections, missing packets and delayed packets are handled appropriately. Also the algorithms should ensure that the data received is correct and reasonable. There need to additional checks to validate the presence of cars as per the data required as IP address spoofing could lead to very unsafe conditions. These network issues and the design to overcome them is discussed in further chapters. Another concern is that many manufactures use varying sensors and actuators. The algorithms designed consider this and provide a plug and play features for any sensors as long as it can be supported with compatible drivers. Additionally, for this system to be implemented, all vehicle manufactures will have to adhere to guidelines for information being broadcasted. All the above problems are addressed in Chapter 3 and Chapter 4. 10

18 CHAPTER 2 - Simulation Approach For testing the communication and safety algorithms a simulation test bench was created. A three-car configuration was decided as by using three cars all road occurrences can be effectively duplicated. The cases were defined for a single lane and a multiple lane road. The direction and destination of all the cars is assumed to be same. Three computers represented three vehicles. To effectively test the algorithms accuracy, the three computers were needed to simulate driver behavior. This was done using the driver models. A driver model is a file containing input information on how a driver would drive the car. The following is a sample of data present in the driver model file. Vehicle identification number, speed, steering wheel angle, braking indicator, acceleration, cruise control status, cruise control speed, turn signal indicator and lane information. Each computer is fed with a file containing a large sequence of this data set and which in turn models the behavior of the car. For effective testing, a driver on road is divided into three main profiles. - Normal driver: Drivers close to the speed limit and is not aggressive in acceleration or deceleration. - Cautious driver: Drives much lower than the speed limit than required. - Rash driver: Drives at high speeds and is aggressive in speed and/or lane changes. To ensure that the simulation is as close to the real driving scenario, the normal driver profile was taken from actual freeway test runs. The speed was noted at a fixed sampling rate and turn signal indicators and lane changes information was stored. Braking was recorded and cruise control was turned on when possible. The actual data was then formed as a model for the normal driver. 11

19 Based on the speed limit of the road, the cautious driver and rash driver profiles were generated using pseudo random generated output along with alternate sets of normal driver model data. Based on research ( [3], [4]) done to examine driver reaction to common on road occurrences, such as weather, pedestrians, motor vehicles among others, driver modeling data was added with the findings of this research so as to simulate the behavior and decision making of a real person as close as possible such that the input to the algorithms will be fairly similar to that of an actual driver. Large data sets from the three driver profiles were randomly broken into smaller segments and three vehicle input profiles were generated. Each of these were fed into the three computers as driver inputs. The procedure was duplicated for single and multiple lanes. To effectively test boundary conditions, a vehicle simulator was designed. This simulator gives a user to model conditions that happen very rarely on roads or those that might have been missing from the modeled sets. This simulator takes input from the user via the keyboard and generates the file to be used as the driver model. 12

20 2.1 Situations for a single lane The three cars start with positions as shown in the figure below. Movement of these cars is governed by the input models for each car, the speed limit is known and kept constant for each run. Deliberate accident figures are added to the profiles. The algorithms are tested for the output and this is then compared with the expected output from the tables below. The expected out tables are based primarily on two parameters, the speeds of the cars and the speed limit of the section. Cars can either have a low speed, normal speed or high speed. Low speed is when the car is travelling at a speed much below the speed limit. Normal speed is when the car is travelling at a speed close to the speed limit. High speed is when the car is travelling at a speed much higher than the speed limit. Figure 2-1 Single lane All cases mentioned below assume to give an output as a driver prompt. The algorithms are designed to ensure that failsafe methods exist so as to prevent accidents due to drivers who do not adhere to the suggested solutions as provided by the algorithms. This is explored more in Chapter 4, which deals with software implementation. Scenario 1. Car A is travelling at normal speed, Car B is travelling at normal speed; Car C is travelling at high speed. The distance between Car B and Car C is reducing rapidly and has become less than the minimum safety distance. 13

21 Expected Actions The software in each car will detect collision and since Car C it s travelling faster than the current speed limit, the tentative decision is for it to slow down. This tentative decision is then checked to see if it could pose any immediate danger to a car behind it. Since in this scenario there is no car behind Car C, the algorithms output would be to slow Car C to an appropriate speed to maintain a safe distance. In case the user overrides the request and does not slow down, the following will happen. Car B will check if it can accelerate safely without any problem with Car A. If it is safe to increase speed it prompts the user to momentarily increase it to avoid immediate crash. If the software detects it is not safe to accelerate, Car B will request car A to accelerate and will in turn accelerate to increase the distance. At all stages, Car B sends a request command to Car C to slow down and all the affected drivers are notified of this deadlock issue (if Car A cannot accelerate). Scenario 2. Car A is travelling at normal speed, Car B is travelling at low speeds and Car C is travelling at normal speed (or high speed) Expected Actions If the distance between Car B and Car C is lesser than the defined safety distance, Car B is expected to accelerate to avoid collision. If Car B reaches normal speed and the situation still persists, action will be taken as per case 1. If the driver in Car B fails to accelerate, Car C would then slow down. 14

22 Scenario 3. Car A is travelling at normal speed, car B is travelling at high speeds, car C is travelling at normal speed (or high speed) Expected Actions If the distance between Car A and Car B becomes lesser than the defined safety distance, Car B will prompt its driver to slow down to avoid collision. If driver overrides this by not slowing down, then Car A will signal its driver to accelerate to avoid collision. It is to be noted that Car A will accelerate provided there are no cars in front of it. In all such potential deadlock situations, the driver is alerted of the conditions prevailing then. Scenario 4. Car A is travelling at low speed, car B is travelling at normal speed, car C is travelling at normal speed (or high speed) Expected Actions Expected result is for Car A to accelerate to normal speed. If user at A overrides this, then Car B would be expected to slow down and in turn forcing Car C to slow down. Scenario 5. Car A is going at low speed, Car B is going at low speed, Car C is going at normal speed. Expected Actions 15

23 Cars B will prompt the user to accelerate, this will then lead to a situation as defined in Case 4 and all three will move on normal speed. If either of the users at Car A and Car B does not accelerate, then Car C will slow down to match the pace of Car B. Scenario 6. Car A is going at low speed, Car B is going at low speed, Car C is going at high speed. Expected Actions Car C is expected to slow down to normal speed, and then the scenario is same as that of case 5. The above-mentioned cases can be summarized as shown in the table below: Car A Speed Car B Speed Car C Speed Primary action to be taken Case 1 Normal Normal High Car C to slows down Case 2 Normal Low Normal Car B to accelerate Case 3 Normal High Normal Car B to slow down Case 4 Low Normal Normal/High Car A to accelerate Case 5 Low Low Normal Car B and in turn Car A accelerate Case 6 Low Low High Car C slows down Table 1 Expected output in a single lane configuration 16

24 2.2 Situations for multiple lanes The cases for multiple lanes are similar to those of single lanes. The only two major differences is that lane changing is a valid result of the computation and additional checks in the other lanes need to be considered for lane changes. Considering the layout as shown in the figure following is a list of cases the algorithm will be tested for. Scenario 1. Figure 2-2 Multiple lanes Car A is travelling at normal speed, Car B is travelling at normal speed; Car C is travelling at high speed. The distance between Car B and Car C is reducing rapidly and has become less than the minimum safety distance. Expected Actions Car C software will detect collision and the tentative decision is to change lane. This tentative decision is then checked to see if it could pose any immediate danger to a car in the other lane. In case the driver overrides the request and does not change lanes, the driver will be prompted to slow down. If the driver still ignores this then Car B will check if it can change lane safely without issues. If it cannot, the car then checks if it can accelerate without any possible collisions with Car A. If all conditions lead to a deadlock a deadlock avoidance scheme is implemented. 17

25 Scenario 2. Car A is travelling at normal speed, Car B is travelling at low speeds and Car C is travelling at normal speed (or high speed) Expected Actions If the distance between Car B and Car C is lesser than the defined safety distance, Car B is expected to accelerate to avoid collision. If Car B reaches normal speed and the situation still persists, action will be taken as per case 1. If the driver in Car B fails to accelerate, Car C would then prompt the driver to either slow down or change lane. Scenario 3. Car A is travelling at normal speed, car B is travelling at high speeds, car C is travelling at normal speed (or high speed) Expected Actions If the distance between Car A and Car B becomes lesser than the defined safety distance, Car B will prompt its driver to change lanes to avoid collision. If driver overrides this by not changing lanes or if it is not safe to do so because of cars in the other lane, then Car B will signal its driver to slow down to avoid collision. For a situation that Car B neither changes lane nor reduces speed, Car A driver is notified to change lanes or accelerate based on the situation if the distance becomes lesser than critical distance. 18

26 Scenario 4. Car A is travelling at low speed, car B is travelling at normal speed, car C is travelling at normal speed (or high speed) Expected Actions Expected result is for Car A to accelerate to normal speed. If driver in Car A overrides this, then Car B would be expected to change lanes. Scenario 5. Car A is going at low speed, Car B is going at low speed, Car C is going at normal speed. Expected Actions Cars B will prompt the user to accelerate; this will then lead to a situation as defined in Case 4 and all three will move on normal speed. If either of the users at Car A and Car B do not accelerate, then Car C will prompt its driver to change lanes to avoid collision with Car B. If changing lanes is not feasible or if the driver ignores this alert, Car C will then advise the driver to slow down. Scenario 6. Car A is going at low speed, Car B is going at low speed, Car C is going at high speed. Expected Actions Car C is expected to slow down to normal speed, and then the scenario is same as that of case 5. If the driver does not slow down, then the software will prompt the driver to change lanes. 19

27 The above-mentioned cases can be summarized as shown in the table below: Car A Speed Car B Speed Car C Speed Primary action to be taken Case 1 Normal Normal High Car C to change lane Case 2 Normal Low Normal Car B to accelerate Case 3 Normal High Normal Car B to change lane Case 4 Low Normal Normal/High Car A to accelerate Case 5 Low Low Normal Car B and in turn Car A accelerate Case 6 Low Low High Car C slows down Table 2 Expected output in a multi lane configuration Boundary conditions Apart from the above-mentioned conditions, boundary conditions have been incorporated to test the accuracy of the software for rare circumstances. Instances such as stationary cars (Speed and acceleration zero) and vehicles in reverse and moving backwards (negative speed) have been taken into consideration and the cases for both single and multiple lanes have been added to test for these boundary conditions. 20

28 2.3 Sample driver profile data As described earlier, the method used to generate custom test inputs and simulate boundary conditions was to use computer key press information as vehicle sensor information. Each key was assigned to a specific sensor and when that particular speed was pressed the software considered that as the input for the particular vehicle function. Inputs for speed, brake, cruise control switches (on, off, suspend and resume), steering wheel angle, clutch, gear and lane indicator were defined. The following lines of code directly give the entered key s ASCII value to the program tcgetattr(stdin_fileno, &oldkey); newkey = oldkey; newkey.c_lflag &= ~(ICANON ECHO); tcsetattr(stdin_fileno, TCSANOW, &newkey); thekey = getchar(); tcsetattr(stdin_fileno, TCSANOW, &oldkey); The tcsetattr() function sets the parameters associated with the terminal referred to by the open file descriptor, in this case STDIN_FILENO the standard input. The previous attributes of the system were saved and the flags were reset. The new attributes were set and a key press was read and then the old attributes restored. This allows us to use the keyboard as an external sensor for simulating various activities. 21

29 The speed variation for a sample driver profile is as shown below: Figure 2-3 Sample input profile for a driver. Fig 2-4 is a driver profile with a mixed behavior, all cautious, rash and normal driving behavior is created in time dependant sections. Cruise control was activated for minute segments as evident from the plot. A sample information broadcasted to all cars in the network is as shown below. Figure 2-4 Sample broadcasted data 22

30 The information is broken down as shown in the figure below Figure 2-5 Byte layout of the data packet The cruise control status and the cruise control speed information are used in cases where a collision is detected between two vehicles but they are both driving below the speed limits. The information is also used by the algorithm to calculate the projected distances more accurately. User defined distance is the minimum safety distance the driver would like to keep from vehicles. This information is used to alert the driver in case this distance has been breached. Clutch status indicates if the clutch is pressed and in case of automatic transmission, this is set as a default. Emergency information segment consist of road hazard indicators and other vehicle emergencies if applicable. Road hazard detection and indicators is explored more in Chapter 3. 23

31 CHAPTER 3 - Safety and Accuracy All current driver assistance programs available in the market are based on sensor data. The sensors placed on the body of the car detect any vehicle in the front or at the back and advice the driver accordingly. These systems have limited flexibility as they rely completely on the sensors input for their computations. These sensors have low operating ranges and their performance varies with various factors like environmental factors (like lighting and weather). The biggest drawback of such sensors is the requirement on line of sight for effective detection, since on road occurrences, such as lane changes, overtaking, intersections, curved roads etc prevent these sensors from effectively calculating the distances and possible collisions of the vehicles. Using sensor data only as an added verification, the vehicle communication model designed overcomes these problems of using traditional sensors. Safety of all drivers on the road being of the utmost importance, there are many safety features built into the algorithms. These safety features include comparing the input data with those obtained from a sensor to ensure the data is correct. If sensor data is not available the algorithms check the data for inconsistencies. Chapter 3.3 explores the various checks done to ensure proper accuracy of the data. The most common unsafe conditions occur when there is limited or no communications between two vehicles. 24

32 3.1 Autonomous vehicles Current automobile regulations state that the driver has to be in total control of the car at all points. In recent years however, there have been many safety critical applications that do not leave the driver in total control. A common example of this is the Antilock Breaking Systems (ABS). With an ABS system, when the driver applies the brake, depending on the traction of the vehicle the system prevents the driver applied force from being applied to the braking system. Instead it applies the force in pulses. This it does so as to keep the wheel from getting locked and thereby maintaining steering control for the driver. If the entire force as required by the driver is applied to the brakes then under many conditions traction is lost and the vehicle might skid. Systems such as ABS prevent a driver requested action from causing an unsafe situation. Currently complete autonomous cars are not available for consumers; however there are advanced driving assistance systems which aid the driver in various forms. The system and algorithms developed here is an example of an advanced driving assistance system. These systems can be adapted to semi autonomous systems by connecting actuators to help the software control parts of the vehicle. A simple example would be; in case the algorithms detect that a front collision is detected for the current speed. The system would then limit the total fuel burned so as to induce deceleration and thereby avoiding the unsafe situation. The same can be expanded to all possible unsafe operations including lane changes and sudden deceleration. Another form of driver assistance would be in the form of haptic feedbacks such as vibrations on the steering wheel and force feedback on the accelerator pedals. Such systems remove the complications of an autonomous system but still maintaining an optimum level of safety. 25

33 3.2 Sensors Sensors play a vital role in enhancing the safety of such a driver assistance system. Though the algorithms do not currently use sensor data directly, they use the sensor data as an additional confirmation for the validity of the received data. Sensor data can also be used to provide assistance from objects not having this wireless data transmission feature. For various tasks like collision detection, lane change assistance, overtaking assistance etc. lane information and position information is critical. Position or the location information is obtained form a global navigation satellite system (GNSS) such as the global positioning system (GPS). The location information obtained from the GPS should be with no amount or only a little positioning error. A standard GPS unit might have a positioning error that varies from 5-25 meters; urban settings can further increase the error due to absence of line of sight to the satellites. This error or the lack of a signal occurs due to high rise buildings, signal to noise ratio and other factors. Due to these reasons the algorithms in the GPS are coupled with speed and direction information. The positional error can be improved by adopting techniques like belief theory [5], fuzzy logic [6] or Kalman filter [7]. Few of these techniques or suitable alternatives are already implemented in commercial GPS units. Using real time map matching techniques [8] these errors in positioning can be reduced even further. A lot of research has been done to match the location of a vehicle accurately on a map, these exact location details are important for such a scheme to improve road safety. White et al. [9] have discussed few algorithms for map-matching for personal navigation devices. Since we consider a relatively higher value as the safety distance, which is much above the maximum positional errors in the GPS, the safety consideration due to distance between the cars is acceptable. 26

34 Due to the positional errors in GPS for exact position of the car the GPS input cannot be directly used for lane detection and safety concerns for lane changes. For achieving safety for lane movements, current GPS technology is not sufficient and hence sensors are required in all the cars. There are various techniques to detect lanes, all these techniques detect the lane markings on the road which are either painted or are reflectors. Certain techniques consider edges in grayscale images a feature for lane markings [10] while other might use steerable filters [11]. Recent advancements in image processing have led to various techniques utilizing color images to detect various lane features and to provide lane information [12]. Sensors used to measure speed of a vehicle in front or at the back do so by measuring the separation distance and constantly calculating the rate of change of this distance. Though these sensors provide fairly accurate results under optimum conditions, they have many drawbacks and are used only as a verification method in this system. Since the software is implemented for a Linux kernel, this enables a plug and play feature for a variety of sensors. In Linux all devices are treated as files, any input or output to the devices are basically read or writes to the corresponding files. The software developed for simulation and the algorithms for safety take sensor inputs as a read from the file. This will enable a standard safety device which can be easily incorporated in vehicles for all manufactures. 27

35 3.3 Accuracy Though the data received from a car is always the most current and correct data for that car, safety features need to be implemented in cases where a car transmit wrong data. Since in any network spoofing can be achieved, there needs to be additional checks to ensure the vehicle data is correct and received from the correct party. In the current algorithms the following communication safety features have been implemented. These features improve the accuracy of received data and thus the overall safety of the car. Auto connection: Whenever there is a drop in connection, the cars should attempt to reconnect with each other as fast as possible and resume transmission of data. The software was designed to achieve this; whenever a sudden lack of data is observed, the client part of the connection module continues sending the request for connection and the server part polls all incoming requests and reestablishes the connection. This automatic connection happens with all cars currently in the network. Sensor backup: To validate the data received; the vehicle also compares the received data with its sensor data. Sensor data is used primarily in case of dropped connections and for times when a connection is being established. Though the sensor data might not be sufficient for checking for all safety cases, it is useful in certain scenarios. This sensor data is also advantageous to detect car distances when a car does not have the wireless data transmitting facility. Using sensors protection and driver alerts can be made possible for cars that are not running as well as other objects such as cyclists, pedestrians. 28

36 Spoofing: To prevent a node in the network which spoofs another car and sends erroneous data, each packet of data consists of a unique identifier. The software then checks for this identifier and processes data appropriately. In case it detects two cars sending the same identifier, it ignores the data and uses backup data from the sensors. If data is not available in the sensors then it uses the estimated checks to resolve this issue. To increase security SSL protocol can be used over the sockets. These would increase the connectivity times due to the initial handshake of security certificates but would provide security and data integrity for all communications thereafter. Other forms of spoofing in which the data received from a car which actually does not exist can be detected and corrected using the data from sensors and/or from other cars in the network. Estimated checks: Since the algorithms have data on the previous cycle of all cars, it can calculate a range of values for critical data such as speed. It does this by taking mechanical and physical limitations. For instance, if Car B is travelling at 25mph. Car A receives this data on a continued basis. Taking the speed of transmission and receiving that a data is received every 500ms. In a certain cycle, if Car A receives Car B speed as 45 mph. then Car A will flag this data as incorrect as a 20mph change in speed in 500ms is not within the range of estimated values. These ranges of variation of speed values are currently hardcoded in the algorithms developed, however for a practical scenario these ranges and the maximum variation limits for each car can be sent by the car during the initial communication setup. This would enable cars with different performance levels to set their own estimated levels and share the data with the remaining cars in the network so as to operate at the same level of data consistency. 29

37 Delayed information: Since the vehicles are transmitting data at a fast rate, there is a high possibility of data packets being delayed or the cars not being synchronous in their decisions. An example of this is say Car B is in lane 2, and it changes the lane (say to lane 1). In case Car A is still receiving and processing delayed information from when Car B was in lane 2, this could lead to wrong calculations and unsafe situations. To avoid this problem, each vehicle exchanges timestamp information when they connect. They then include this in each data packet they send. When a vehicle receives a data packet, it then compares the timestamp to its current timestamp, if the received time stamp is lower than its own timestamp, then it flags the data as incorrect. 30

38 CHAPTER 4 - Algorithms and Software Design The software is written in C++ for a Linux platform. The software uses standard C++ libraries and was tested for Linux kernel version Since there is no centralized server to facilitate exchange of information the cars form an Ad-hoc network among themselves. To facilitate this each car behaves as both a server and a client. The server takes in requests from other clients(cars), these requests are data packets consisting of the vehicle data sent from the cars. The client makes such requests to all the cars in the vicinity. More details about the ad-hoc network are available in the next section. The software is written considering only three cars but can be easily adapted for more. Currently the software supports single and multiple lanes. The driver display or notification is achieved via terminal displays. There are three main components in the software. They are communication, collision detection and safety algorithms and deadlock avoidance and critical action. Each will be explored more in the coming sections. To visually observe the movement of cars and for better analysis, a graphical display was created. This was done primarily to see and ensure that the output of the algorithms was correct, no collisions were occurring and the minimum safety distance was maintained. 31

39 4.1 Sockets and communication Since we are dealing with critical information, delivery is of critical importance. Transmission Control Protocol (TCP) was chosen because of the reliability on transferring a packet of data between two sources. TCP controls the message rates and hence makes the vehicles (being simulated on different computers) independent of their scheduling rates. The following flow chart shows how the series of events that take place to transmit and receive data from other cars. Figure 4-1 Socket connection algorithm 32

40 For any socket connection, we need to know the IP address and ports of the two computers. For a dynamic network such as the ad-hoc network for cars, static IP method is not feasible. Also in the absence of a centralized server Dynamic Host Configuration Protocol(DHCP) protocols for configuration is not possible as there is no fixed infrastructure the computers can connect to acquire IP addresses. There are various strategies to assign IP addresses to spontaneously created networks such as the network of cars formed here. One technique uses variable length addressing and assigns varied length address to all network nodes [13]. Another technique [9] for assigning IP address in a network deals with the networks selecting a leader and the leader then assigning the IP address to the remaining network members There are other techniques where addresses are randomly assigned and checked for duplications. All these techniques offer good network joining, merging and partitioning capabilities. There are strategies for dynamic destination sequenced distance vector routing [15]. Advantages of vehicles forming and configuring the network automatically allow the network to be present in the absence of fixed infrastructure. Also, with such dynamic networks joining and splitting/leaving a network will be easier and this is important, as it would be a very common occurrence with vehicle networks. For testing the algorithms for collision safety, we assume the computers to have a static IP and pre-program each computer with the static IP and ports of the others. Though for on road behavior, the IP addresses would be made available using any of the Ad Hoc network formation and maintenance techniques mentioned earlier. Appendix A lists all the class member functions used for network communication and their definitions. 33

41 The software process and the code are explained in the following section: First a server socket is created. CAR_A_SERVER_PORT and CAR_A_SERVER_IP are the ports and ip address for Car A. As mentioned earlier, these are pre defined for each car. servsock = new csocket(car_a_server_port, CAR_A_SERVER_IP); A thread is created that will wait for TCP connections from the clients (other cars). This is required in order to avoid the deadlock where each process waits for connections from others with accept() being a blocking call. pthread_create(&threadid, NULL, accept_connections, pservsock Now the process acts like a client and connects to the other servers that are available. Taking the two cars as B,C the process in A will connect as follows. ogconn1 = new csocket((char *)CAR _B_SERVER_IP, CAR _B_SERVER_PORT); ogconn2 = new csocket((char *)CAR _C_SERVER_IP, CAR _C_SERVER_PORT); Then the process waits for the connections to be set up. This process should connect to two other servers and must accept connections from two others. Preparing FD_SET for listening FD_ZERO(&rfds); maxsock = 0; FD_SET(ogconn1->getsockethandle(), &rfds); FD_SET(icconn1->getsockethandle(), &rfds); if (ogconn1->getsockethandle() > maxsock) maxsock = ogconn1->getsockethandle(); if (icconn1->getsockethandle() > maxsock) maxsock = icconn1->getsockethandle(); 34

42 Each car then calls a separate method to package the data. Once the data has been packaged into the pointer writedata, we send the data to other cars. if (ogconn1->getsockethandle()) bytes = ogconn1->write((void *)writedata, (unsigned int) writedatalen); cperrno = errno; if (bytes == 0) // remote peer socket shutdown gracefully //Write failed for socket! Remote process down! ogconn1->reset(); else if (bytes == -1) // error check errno // Write failed for socket check errno if ((cperrno == ECONNRESET) (cperrno == EPIPE)) ogconn1->reset(); If the function to write the data fails, the software will reset the connection and attempt to resend data on the next process run. For this particular time stamp the car which does not receive data will use either sensor data or the projected data. 35

43 The following code fragment shows the process in which the information sent from other cars is received. At the end of this code segment the pointer readdata points to the data received. if (!icconn1->getsockethandle()) getsensorata(readdata); else if (FD_ISSET(icconn1->getsockethandle(), &rfds)) bytes = icconn1->read(&readdata, MAX_LINE_LEN_LOCALDATA); cperrno = errno; if (bytes == 0) //Write failed!, Remote process down FD_CLR(icconn1->getsockethandle(), &rfds); icconn1->reset(); else if (bytes == -1) //Read failed, check errno if ((cperrno == ECONNRESET) (cperrno == EPIPE)) FD_CLR(icconn1->getsockethandle(), &rfds); icconn1->reset(); In case a read fails, then a car needs to get the details for the other car(s) by other techniques, these include reading sensor data or by distance projection based on the previously received values. Since these exchanges occur at a very fast rate, the projection data is fairly accurate and is a good substitute in case of a temporary data receiving failure. 36

44 The main concern with any synchronized networks is the delay in transmission, since we are considering wireless transmission the software should account for delayed transmission. To overcome delayed transmission when the dynamic network is formed all cars synchronize their time stamps and all data is sent with the latest time stamp. The receiving computer then compares this time stamp with its time stamp and determines if the data received is current. If the received data is old, it has two options, it can either read sensor data or it can request for updated information (by continuously reading the buffer for new received data packets). Since the later can lead to deadlocks (if all cars detect old data and start waiting for current data) this method of obtaining the current data is accompanied by deadlock prevention schemes. The current implementation does cyclic updates on the old data. This scheme does have the drawback of increased processing time to obtain data. But since there would be few cars (factor of 10 s) on the road forming a network and the scheduling time being 10ms a maximum delay would be 100ms(taking 10 cars in the current network). This 100ms delay is assuming all 10 cars simultaneously detect old data. The probability of this occurring is very low and it decreases when more cars are added. If we consider a network, which elects its leader, we can then have the leader issue the latest updated data to all cars that have detected an old data. [14] The data is analyzed to check the validity of the data through vehicle id checks (and via local sensor reading comparison). As discussed in Chapter 3, these checks ensure that the data received is from the correct vehicle itself and that the data is correct. When a remote process is down, due to a drop in connection, or the data is delayed the alternative to cyclic updates is to read local sensor data. The data local sensors provide is limited and are used for only basic computations and driver alerts and do not provide enhanced driver protection as compared to that achieved with wireless transmissions. 37

45 4.2 Collision detection algorithms There are many algorithms for collision detection, and a lot of research has been done to detect collisions in real time between moving objects and static objects and between two moving objects. A published report [16] compares several collision detection algorithms and presents a new real time collision detection of vehicles driving in the virtual environment. All collision detection algorithms are based on the interactions between two polyhedrons. In this simulation the position data of each object is sent by the object itself, so the need for high accuracy in sensing the objects in relaxed. The three collision classifications that are being analyzed by the algorithms are front impact collisions, rear impact collisions and side impact collisions. For any collision detection, the current and future position should be known. The current position is sent via the data packet and hence this information is known. To compute the future distance of the cars, the algorithm uses the speed and acceleration data. The time the process uses to compute the distance is the sum of the times the process takes to send data, receive data, run safety algorithms and any wait times (for sensor inputs). This ensures that the decision taken for the current cycle is the best positions for the cars after the time has elapsed. Since these transfers take place at approximately ms the calculated positions for the vehicles is always optimum. This distance projection is based on the premise that preventing an unsafe condition is far better than correcting an unsafe condition once the unsafe event has already occurred. Once the vehicle projected distance is known the difference between the two would give the distance between the two cars after the said time period. If this distance is less than the defined safety distance, then either of the cars has to make a preventive decision. These decisions might be to accelerate, decelerate or to change lanes. 38

46 The following shows a decision process made by Car B for detecting and resolving a collision with Car C with Car C being in front. Algorithm: 1. Calculate projected distance of each car: BProjDst and CProjDst 2. If projected distances of either car makes them within the safety distance then continue else exit 3. If the vehicles are in the same lane then continue else exit 4. If car C is in front of car B then continue else exit 5. Run collision avoidance for C in front of B routine. Code: if ( ( (CProjDst - BProjDst)<= SAFETYDISTANCE ) && ( CarBLane == CarCLane) && ((CProjDst - BProjDst)>=0) ) //The routine for collision avoidance for Car C in front of Car B Here if the difference between the calculated projected distance is less than the safety distance, cars are in the same lane and car C is in front of B. Then an unsafe condition is detected. Algorithm for Car B: 1. Compare speed of Car B with the speed limit, if higher then continue else exit 2. Compare speed of Car B with the speed of Car C, if equal or higher then continue else exit 3. If Car B has no driver override active or alternate collisions detected then continue else exit 4. Indicate the potential unsafe condition to the driver calculating the action is required. Code: if ( (CarBSpd > SPEEDLIMIT) && (CarBSpd>=CarCSpd)&&(RequestFlag==0)) //driver prompt for the appropriate message with the action required. 39

47 If B s speed is greater than the speed limit and the speed of car C. Then Car B must take a preventive action. This is done provided no other car has requested Car B to take alternate action and there is no user override from previous cycles. This is indicated in the RequestFlag. If the appropriate decision is for a lane change, then the lane of Car B is changed to the next lane. This lane could be to the left or the right. Algorithm: 1. Since an action was required, speed was higher than the other car, so check if the left lane is available. If yes then set the appropriate lane flags and exit. else continue 2. Check if a lane is available to right, if yes then set the appropriate lane flags and exit else continue 3. No lane change is possible, hence set speed change required flag and exit Code: if (CarBLane < NOOFLANES ) CarBLane++; //indicating a move to the left lane LaneFlag = 1; else if ( (CarBLane-1) >0 ) CarBLane--; // indicating a move to the right lane LaneFlag = 1; else // code for alternative action 40

48 Once this tentative action to change lanes has been decided from the software, it is then compared to check if this lane change could pose a hazard to other cars in the new lane. Since we are dealing with three cars, this leaves only car A to be checked. However on road the following code will be run for all the remaining cars in the network in that lane. Algorithm: 1. Calculate projected distance of each car: AProjDst and BProjDst 2. If Car A is in front of Car B then continue else Car B is in front of Car A if a the safety distance between the cars is less than the minimum safety distance then remove the lane change flags and compute alternative action and exit else, lane change is possible- alert the driver and exit 3. Car A is in front of Car B if a the safety distance between the cars is less than the minimum safety distance then remove the lane change flags and compute alternative action and exit else, lane change is possible- alert the driver and exit Code: if( (( ( (AProjDst - BProjDst)<= SAFETYDISTANCE )&& ((AProjDst - BProjDst)>= 0 ) ) ( ((BProjDst - AProjDst)<=SAFETYDISTANCE)&&((BProjDst - AProjDst)>= 0) ) ) && ( CarBLane == CarALane) && (LaneFlag==1) ) //Lane change not possible. Alternative action required else //lane change required and it is possible, alert the driver. The above lines of code check if the decision taken by B to change lanes is safe and no interference with Car A is detected. If there is any interference with Car A with either the resulting position of Car B in front of Car A, or with Car A in front of Car B. the decision made to change lanes is reversed and modifications are done to vary the speed of the car to ensure that the safety distance requirements are met. 41

49 The flow chart below illustrates the inspections done for each cycle of operation Figure 4-2 Decision process for each Vehicle 42

50 In some cases due to low speed of the car in front, compared to the higher speeds of the car behind the calculated safety distance between them for the time period will be very low. To maintain the given safety distance the speeds would have to be lowered by a considerable amount. To prevent this large deceleration/acceleration, the algorithm tries to increase the safety distance safely over time. This it does by making the speeds of the car as close to the other car as possible. For instance, if the car in front is travelling at 45 mph and the car behind at 50mph the distance calculated between the cars is 25 meters. Then to maintain the 50-meter safety distance limit, the car in the back might have to reduce its speed 40. A decrease in speed from 50 to 40 mph will definitely cause a large drop in torque and will be uncomfortable to the driver to perform this deceleration. To overcome this, the speed is reduced in steps. This information of reduced speed is displayed to the driver to take the appropriate action. In the example mentioned above, the software at Car B detected the collision and alerted the driver to either change lane or to reduce the speed. Car A software also detects the collision based on the same principles but displays the fact that action is required by Car B to the driver. The process has to adapt itself and modify the decision in case it detects that other car s driver has not made the required corrections. This it does by checking the next data packet to see if corrections were applied, if not, the process calculates an appropriate action and alerts its driver. These alternative calculations are also done when a critical distance is breached. This is to ensure that in case of very fast travelling cars, the time taken for the driver of the faster car to take action is not wasted and in turn both drivers take action to improve the safety situation. 43

51 Many decisions lead to a deadlock situation. A simple example would be as following: The vehicles are in position as per figure 2-2. Car A, Car B and Car C are travelling at normal speed and Speed of A < Speed of B < Speed of C. Based on the algorithm Car A should accelerate to match the speed of B. Car B should accelerate to match the speed of Car C. Suppose Car A cannot accelerate and Car C cannot decelerate due to their conditions with other cars in front or behind. In the case where there is no additional lane and if the distances between Car A-Car B and Car B-Car C are below the safety distance then a deadlock has occurred. These type of deadlocks cannot be prevented and have to be addressed. In case a deadlock such as the one above is detected and an impact has been detected, the cars will then run the deadlock clearing algorithm. This algorithm advises the all the drivers in the current network and the lane where the deadlock was detected to drive at a speed slightly below the speed of the car in front of them. The most optimum speed to drive at is also displayed such that the deadlock is cleared. This ensures that a collision does not occur and also ensures that the distances between the cars are increased gradually. This check is done every time the process is scheduled hence the software automatically gives a better solution if the deadlock has cleared. 44

52 4.3 Road Hazard Detection To improve safety under unknown road conditions, each vehicle based on the speed variation determines if a sudden drop or a sudden increase in speed is due to a road condition. These hazards might be potholes, objects on the road, slippery bridges and other unsafe road conditions. Potholes or objects on the road can be determined by a sharp decrease in speed in the absence of other vehicles in front. Ice on the road can be determined by activation of ABS systems at lower speeds. Sharp turning roads can be determined by a steady change in steering wheel angle and no changes in lane. Knowledge of the above mentioned conditions prior to them occurring on the road can lead to better driver preparedness and hence better safety. For simulation purposes, we consider road hazards to decrease the speed sharply. In case the speed of a car follows such a steep decline, it alerts all cars in the network by sending the information in the data packet as part of the emergency information segment. Currently the information sent is the hazard status, location of the hazard, lowest car speed during the hazard detection process. The hazard status indicates a predefined type of hazard, whereas the lowest speed during detection gives an indication to other cars as to which speed is most optimum to navigate through the particular hazard with minimum driver discomfort. Cars approaching this hazard will, on receiving the unsafe road condition alert, determine the most optimum time and location to take appropriate action. Since here we consider only hazards that decrease speed, the appropriate action for each car is to reduce speed at an optimum distance away and indicate this to the driver mentioning the hazard type and the reduced speed required. 45

53 4.4 Graphical Interface for Analysis Since the cars exchange information at a rate, which is a fraction of second, manually observing and verifying the algorithms correctness is a very tedious process. In less than a minute there could be over hundred computations and corresponding flags displayed. A graphical interface was hence developed to analyze the various car behaviors visually. The programs were written in OpenGL using GLUT. GLUT is an OpenGL utility toolkit that provides a portable API thus enabling usage over various operating system platforms. A window is created and the screen is split into three road segments. The movement and positions of the vehicles is defined by the events captured from the algorithm outputs and this is reflected by graphics on the roads. Small rectangles were representative of the cars and were color coded for ease in viewing. The software was designed to execute within 20ms because if the rate exceeds 20ms a viewer could observe flickering of the screen (Because the refresh rate of the monitor is close to 50Hz). The process to simulate the movement of the cars as per the safety algorithms output is described below: Appendix C contains the software for this visual demonstration. The software process is explained below: 46

54 First the roads were drawn and three rectangles of varying color were defined. Algorithm: 1. Initialization 2. Select the display mode 3. Define a window of required size and position. 4. Create the window 5. Display the roads and the cars 6. Read car position data and reposition the cars 7. Read any keyboard inputs for exit notification 8. Repeat steps 6 and 7. Code: glutinit (&argc, argv); glutinitdisplaymode (GLUT_SINGLE); glutinitwindowsize (1200, 500); glutinitwindowposition (10, 5); glutcreatewindow ("Visual Demo of Car Interaction"); glutdisplayfunc (display); glutidlefunc (display); //change any idle values accordingly glutreshapefunc (reshape); glutkeyboardfunc (keyboard); glutmainloop (); Based on the information about car position and lane, the movement of the three rectangles was updated by the glutidlefunc (display) and glutreshapefunc (reshape) function calls. The positions of the rectangles were updated as and when new position data was available. The glutkeyboardfunc (keyboard) function takes input from the user to stop the simulation. If the travelled distance exceeded the maximum resolution of each zone, the rectangles were drawn on the next zone. The resolution and length of the roads can easily be modified to facilitate a zoom function. 47

55 A Screenshot from the graphical interface showing the cars in the first zone is shown below. Figure 4-3 Screenshot from the graphical interface Once the car reaches the end of the first zone, they appear from the starting position of zone 2 and similarly at the end of zone 2, they appear at the start of zone 3. The lenght of each zone is close to 1 mile and depends on the resolution defined. The graphical interface was split this way to ensure that exact positions of each car with respect to the other can be easily observed even when one car has crossed one particular zone while the others are still in it. The graphical interface was critical in examining the input profiles and the algorithms output. It enabled us to create input profiles for various accident scenarios and verify if the algorithms detected and resolved the collisions. Two windows running simultaneously, one of the input profile and other of the algorithms output clearly shows all the collisions being avoided and also the decision taken can be noticed. 48

56 CHAPTER 5 - Traffic Management Traffic management is required for various purposes. Effective traffic management can lower journey times by a large factor. They also have direct correlation with the number of accidents that occur and also with fuel consumption. Traffic management is achieved by monitoring the current traffic condition of the road and taking action when an abnormal traffic is detected. The action could be to lower the traffic density and thereby improving the speeds of the cars. This is achieved by either to lower the speed limit of the vehicles entering the section with high traffic or signaling them to take alternative routes. An experiment for active traffic management was conducted by The highway Agency for reducing congestion in motorways in Britain [17]. The results of the experiment over the course of 6 months clearly show the reduction of journey times by a factor of 25%. It also indicates that traffic management lowers accidents and also assists in reducing pollution by reducing the fuel consumption quantities. Currently, road traffic is regulated and controlled by a set of complex road parameters. These are usually obtained using different methods such as magnetic inductive loops, radar, infrared, microwave, ultrasonic and video cameras etc. Most of these techniques however are not perfect, presenting with issues in different conditions varying from lighting to unfavorable weather. Few of the methods listed above also fail to accurately detect very slow or immobile vehicles. Researchers are constantly coming up with possible alternatives [18] to overcome these concerns. Such techniques do provide solutions to some of the problems in obtaining road parameters but they are not sufficient and complete by themselves to constantly obtain and analyze traffic information in real time. Algorithms exist [19], [20] to use video processing 49

57 techniques for efficient traffic analysis but the expensive equipment and video processors make it difficult for a widespread use. Products available in the market for traffic management and traffic flow details suffer from the drawback of not being fully automated. Traffic information providers often use aggregated information from various sources and can result in accidents, roadblocks, construction and similar issues. One important drawback of these systems is also their requirement of user intervention at various stages to obtain accurate statistics, to flag appropriate conditions, and to detect accidents and stopped vehicles. Current implementation of active traffic management by the highway agency in Britain [17] uses inductive loop sensors designed to set electronic message signs and advisory speed limits. These sensors are located at every 100 meters on the road to observe the flow of traffic. A central station then takes all the inputs provided and calculates the best speed limits. The biggest drawback of this system apart from the cost is the need for human intervention especially to detect accidents and stalled cars through the CCTV cameras. In our technique, we use traffic modules on the road to capture the broadcasted information from the vehicles. Since this packet of information directly gives the vehicle speed, distance and acceleration amongst other parameters, overhead processing costs due to vehicle detection are reduced and traffic analysis becomes fairly straightforward. Also the added benefit of this system over other techniques for traffic monitoring is that with this system we can directly get the traffic information for each lane. This enables the software to manage the traffic in an enhanced fashion. The traffic information thus obtained can be stored and analyzed over a period 50

58 of time to observe traffic and lane usage patterns. This data could improve traffic forecasts and predictions. In addition, it would enable urban planners to make better decisions on road infrastructure. Chapter 6 highlights few of the practical applications of using this system apart from traffic analysis and management. Considering the entire road to be divided into various zones, traffic management in each zone is achieved with one or more traffic modules placed in the zone. A traffic module consists of a receiver and a transmitter, a receiver captures the broadcasted information whereas the latter can transmit data to and from other vehicles. Each traffic module is connected to traffic modules in its neighboring zones. These modules capture the broadcasted data packet from the vehicles and then use this data from various vehicles passing through the zone to calculate the traffic density and average speed of vehicles. Based on predefined time slots, current traffic is analyzed by comparing average speed in that time slot with the speed limit of the particular zone. The value of average speed is improved by ignoring the speed values of cars that differ with a large variance from the calculated mean. Based on the variation from the speed limit, each zone can be flagged as No traffic, Moderate traffic and High Traffic. Each traffic module then relays this information to its neighboring zone s traffic modules. For better coverage and management of traffic, this information can be relayed to other zones in its vicinity as well. 51

59 The traffic module then sends a data packet to each car from which the broadcasted information was gathered. This packet includes all the information about its neighboring zones. A navigational unit in the vehicle can then use this information along with the route profile to decide if re-routing is necessary and advantageous to improve the time of arrival. The system voids the need for human intervention as these traffic modules directly get the speed and emergency data of the cars. In case of accidents or a stalled car, these modules can immediately close certain lanes by using variable message sign (VMS) and by broadcasting this information to other traffic modules and thus the cars in the neighboring zones. There are two main strategies for traffic management, corrective and preventive. A corrective traffic management scheme continuously checks for the current traffic conditions, and decides if there is high traffic, and then moves to resolve the high traffic condition by rerouting cars or other methods. Whereas, a preventive scheme continuously checks for the traffic levels by checking the density and average speeds and projects based on current conditions if a high traffic zone might occur. If yes, it then tries to prevent the occurrence of the high traffic zone by either re-routing vehicles or by controlling the speeds on vehicles entering the zone (by changing the speed limits actively). 52

60 5.1 Simulation and Average Speed graphs For analysis of this traffic management scheme, we have considered a 3-mile segment. This was divided into 3 zones of 1 mile each. We assume that Zone 2 has a bypass section and traffic headed for zone 2 can take the alternate route. The scheme is as shown in the figure below. Here we also assume that each of the zones have the traffic modules and can communicate with each other. Figure 5-1 Traffic simulation We then take create various input profiles and schedule different cars in the three segments. For this simulation, 25 cars were created and randomly distributed on the road. The initial speed was assigned as a function of the driving profile, as cautious, normal or rash. The speed of each car then varies a function of traffic density. At first the cars are run normally without any traffic management. A corrective traffic management technique is then used. That is, when the average speeds become lower than a set percentage of the speed limit, the zone is flagged as high traffic and cars approaching that zone receive the information about high traffic and can take the alternative route to avoid delays (for simulation purposes it is assumed that all cars will take the alternative route if advised to do so by the corresponding flags). On the other hand, a preventive technique analyzes the changes in average speeds at any given time interval and reroutes traffic to prevent the occurrence of a high traffic zone. 53