Connected Vehicles in Urban Traffic: a Case Study

A Thesis Entitled

Potential Impacts of Connected Vehicles in Urban Traffic: a Case Study

by Tariq Rahim Rahimi

Submitted as partial fulfilment of the requirements for The Master of Science Degree in Civil Engineering

______

Dr. Eddie Y. Chou, Committee Chair

______

Dr. Liangbo Hu, Committee Member

______

Dr. Yanqing Xu, Committee Member

______

Dr. Amanda Bryant-Friedrich, Dean

College of Graduate Studies

The University of Toledo

May 2018

This document is copyrighted material. Under copyright law, no parts of this document may be reproduced without the expressed permission of the author.

An Abstract of Potential Impacts of Connected Vehicles in Urban Traffic: a Case Study by

Tariq Rahim Rahimi

Submitted as partial fulfilment of the requirements for The Master of Science in Civil Engineering

The University of Toledo

May 2018

This research is an introduction to the topic of simulating vehicles capable of being connected with the infrastructure. The connectivity helps vehicles make better decisions and improves the general traffic flow. It is built around SUMO, an open source traffic simulation software developed by German Aerospace Center (DLR) of traffic studies.

Three different scenarios of an urban intersection are simulated. First, an isolated intersection with current traditional traffic is simulated. Then, a camera connected with traffic light is simulated as a form of infrastructure to vehicle connectivity. The camera detects the vehicles in a specific distance from the stop line and adapts the traffic lights in order for the vehicles to pass the intersection safely. Third scenario is where vehicles are given some characteristics of autonomous and connected vehicles sporting less gap between each other, near perfect driving, and faster perception-reaction time.

The main goal of our work is to be able to simulate how vehicles with some sort of connectivity impact traffic flow. We used the output from the fixed scenario as our base and compared the numbers we got from the second and third scenarios. We found out that

iii the second scenario yields a better traffic flow with lesser delay and queue length.

Moreover, the third scenario had cut more than half of the delay and queue length.

In this study, we took an urban intersection and used it as an isolated one. We think if three parameters can have this much effect on traffic flow, having a fully connected and autonomous vehicle will have a larger effect on reducing collisions and congestions. My professor, colleagues and I are planning to do further studies of different intersections and roadways and evaluate its applicability.

Acknowledgements

This thesis would not have been possible without the love, support, and encouragement from my parents, brothers and only one sister. I would like to thank Dr.

Liangbo Hu and Dr. Yanqing Xu on agreeing to serve as committee members. I would like to thank Tei Zheng for helping me out with C++ codes and working on a front-end with me for the SUMO simulation software.

I wholeheartedly thank my advisor, Dr. Eddie Y. Chou who never doubted in my ability of being successful in working on a topic I chose. Words cannot justly express the depth of my gratitude for having a wonderful and supporting supervisor as Dr. Chou.

Contents

Abstract iii

Acknowledgements v

Contents vi

List of Tables vii

List of Figures ix

List of Abbreviations xi

List of Terms xii

Preface xiii

1 Background 1 1.1 Problem Statement 1 1.2 Background 3 1.2.1 Automation Levels 4 1.2.2 What is a traffic simulation software? 8 1.3 Objective 9 2 Literature Review 11 2.1 General Background 11 2.2 Public Acceptance 13 2.3 Current State of AVs as of Early 2018 14 2.3.1 Technologies in the market 16 2.3.2 Some history of Automation Technology 20 2.4 CV 21 2.5 Simulation 23 2.5.1 Existing simulation software 24

2.6 SUMO 30 3 Methodology 32 3.1 Data: 32 3.1.1 The Westgate intersection 34 3.2 Car following model 35 3.2.1 Speed 36 3.2.2 Acceleration and deceleration 37 3.2.3 Gap between vehicles 38 3.3 Simulation Scenarios 38 3.3.1 Fixed scenario: Preset/Pre-timed signals 39 3.3.2 Adaptive scenario: Using a camera connected to traffic lights 42 3.3.3 Connected scenario: Using some characteristics of AVs/CVs 44 4 Results 48 4.1 Fixed Time Scenario 48 4.2 Adaptive Scenario 51 4.3 Connected Scenario 53 5 Discussion 56 5.1 Limitations 56 5.1.1 Simulation graphics: 56 5.1.2 User interface 58 5.2 A GUI Front End 58 5.3 Recommendations 61 References 62

A Detailed AV History 65

B Basics of performing a traffic simulation in SUMO 74

C Files used in Thesis 89

vii

List of Tables

Table 2.1. Some history of Automation Technology...... 20 Table 3.1. Traffic signal phases obtained from the field around 5 pm ...... 33 Table 3.2. Max and min green timings for actuated 122s cycle ...... 43 Table A.1. Vehicle Automation Timeline (Chronological)……………………………...65

viii

List of Figures

Figure 1-1. Level zero or no automation (left) and level one automation ...... 5 Figure 1-2. Level two automation details (left) and level three automation ...... 6 Figure 1-3. Level four automation details (left) and Level five automation ...... 7 Figure 1-4. Five levels of automation explained in terms of what is controlled by a Human driver and what systems are automated...... 8 Figure 2-1. Types and details of how an AV works in three steps. Source: clemson.edu 12 Figure 2-2. GM’s expected driverless car without steering and pedals. GM.com...... 15 Figure 2-3. Decelerating when gas pedal is not pressed (left). When closer, it will raise the gas pedal to discourage the driver from accelerating (right). Source: Nissan.com ...... 17 Figure 2-4: A snapshot from a simulation in progress in SUMO...... 24 Figure 2-5: A snapshot of Autodesk InfraWorks while simulating the Westgate intersection...... 25 Figure 2-6: A simulation of multimodal traffic in Vissim. Image: PTVgroup.com ...... 26 Figure 2-7: Showing real-time queue outputs in InfraWorks...... 29 Figure 2-8: Showing real-time output of vehicle waiting time in terms of colors. Dark blue is less or no waiting and Yellow is representing more waiting time...... 29 Figure 3-1: Vehicle counts calculated and used for simulation ...... 33 Figure 3-2: Westgate intersection and its surrounding area...... 34 Figure 3-3: Speed distribution of our simulation ...... 37 Figure 3-4: Simulation running in SUMO ...... 40 Figure 3-5: Average Time Loss in all approaches for various detector lengths...... 43 Figure 3-6: minimum gap values effect on Time Loss ...... 45 Figure 3-7: Effects of various driver imperfection values on Time Loss ...... 45 Figure 3-8: Time Loss vs. reaction time ...... 46 Figure 4-1: Time Loss and Waiting Time averages for different cycle length ...... 49

Figure 4-2: Average Time Loss/Delay in all approaches for different cycle lengths ...... 50 Figure 4-3: Queue lengths and Time Loss trends observed for different cycle lengths ... 51 Figure 4-4: Time Loss for different fixed and adaptive (up to 150%) cycle lengths ...... 52 Figure 4-5: Queue Lengths for different cycle lengths in Fixed and Adaptive Scenarios 52 Figure 4-6: Adaptive and connected scenarios time loss for various signal times ...... 53 Figure 4-7: Queue Lengths for Adaptive and Connected scenarios ...... 54 Figure 4-8: Time Loss for all three scenarios ...... 55 Figure 5-1: Simulation showing vehicles went over each other and reported it as crash. Geometry deficiency in SUMO ...... 57 Figure 5-2: A GUI Front-end created for users to be able to simulate faster...... 59

List of Abbreviations

ACC Adaptive Cruise Control AV Autonomous Vehicle AI Artificial Intelligence API Application Program Interface

BMV; DMV Bureau of Motor Vehicle; Department of Motor Vehicle

CV Connected Vehicle CAV Connected and Autonomous Vehicle CC Cruise Control

DARPA Defense Advanced Research Projects Agency DLR German Aerospace Center (Translated from German) DOT Department of Transportation

LIDAR Light Detection And Ranging (remote sensing)

MaaS Mobility as a Service MoD Mobility on Demand

NHTSA National Highway Traffic Safety Administration

O/D or OD Origin/Destination

PROMETHEUS Program for European Traffic with Highest Efficiency and

Unprecedented Safety

SAE Society of Automotive Engineers SUMO Simulation of Urban Mobility; and open-source traffic Simulation software

VMT Vehicle Miles Travelled

List of Terms

Automate: to apply automation to; to convert to largely automatic operation. According to Oxford English Dictionary (OED).

Automation: automatic control of the manufacture of a product through a number of successive stages; the application of automatic control; the use of electronic or mechanical devices to replace human labor. On the other hand, the OED includes the following definitions for autonomy and autonomous:

Autonomy: the right of self-government, of making its own laws and administering its own affairs; the condition of being controlled only by its own laws and not subject to any higher one; a self-governing community.

Autonomous: of or pertaining to an autonomy; possessed of autonomy, self-governing, independent.

Driverless: a vehicle without having a driver, maybe Level four or five.

Vehicles: Cars; used interchangeably

Edge: an approach or a part of road, such as West Bound is an edge comprised of many lanes.

TraCI: Traffic Control Interface, is a library used to connect sumo with python.

Depart: Entering the simulation

Arrive: Finishing the designated trip

xii

Preface

Autonomous Vehicles (AVs) are referred to cars or robots that steer the vehicle on their own or controlled remotely. Here, we mostly focus on having vehicles with some characteristics of Connected and Autonomous Vehicles (CAVs). We believe that the

Automation technology is useful if they work in a safe connected environment where various modes of transportation can talk to each other and offer beneficial information.

In this paper, we demonstrate the effects of a few characteristics of a Connected and

Autonomous Vehicles. Although this is just one case and we shouldn’t generalize it, we think it has the potential to relieve the congestion and reduce the queue lengths in our roads.

xiii

1 Background

1.1 Problem Statement

Some of the most common problems pointed out in many traffic engineering studies are congestion, safety, and/or collisions. Experience has shown that there will always be some sort of congestion whether we add extra lanes to an existing infrastructure or build new roadways. Additionally, road safety includes many factors, human driver error being the biggest one. Human beings have many variables to count but age, vision, and mental state are the most important ones when one gets behind the steering. Different age groups drive differently, vision can go bad over time. Drivers’ capabilities change with changes in the mental or psychological state. Some drivers get distracted easily which can cause congestion and safety problems and may even get into an accident.

According to literatures in the second chapter, Connected and Autonomous Vehicles promise a better traffic flow while using the existing infrastructure. It is also possible to use some RSUs (Road-Side Units) and OBUs (On-Board Units) to increase the traffic network safety and flow of information between vehicles and infrastructure.

As we don’t have access to CAVs as of now, we can simulate some of their characteristics and measure how those will affect the current flow. In order to do that, first we will study the existing fixed time traffic and measure factors like the average delay for each vehicle

1 and total queue length. Then, we will use different scenarios of vehicle and infrastructure connectivity. One such approach is to use a camera (lane are detectors in simulation) to detect vehicles in a specific distance from the respected stop line on all sides of the intersection. The detector will then change the traffic light to green, if it is red and will prolong the green if it is already green, for the vehicles to pass on a first come first serve basis.

Another approach is to let the vehicles and traffic lights connect to each other and have less gap and a change in acceleration and deceleration in order to not wait a lot behind the stop line. The idea here is that vehicles will be able to propagate their information to the traffic light and be able to access the remaining traffic light green time (or the current phase) to adjust their speed and to be able to cross the intersection safely without any delay.

The benefits of CVs/AVs have been extensively investigated through various case studies and traffic simulations. We used an open-source traffic simulation to measure the effects of connectivity. After getting data from both traditional vehicles and modified situations, we will compare the cases and conclude the paper with our findings.

In Chapter 2, the existing research about AVs, CVs, and traffic simulation software are discussed in detail. Chapter 3 gives a general overview of traffic simulation. Chapter 4 explains the procedure for simulating the intersection of our choice. Chapter 5 explains how we got the outputs and what do they mean. Chapter 6 concludes by reviewing and summarizing the outputs and talks about what should be done in the future to simulate AVs more precisely.

1.2 Background

So far, the intersection controls that were commonly used have been the traffic signals, stop signs, roundabouts, and often a police officer. All of the intersection controls other than the traffic signals allowed the traffic to flow on a first come first serve basis.

Yield-sign and stop-sign controlled intersections are referred to as Un-signalized intersection. Yield signs are used in entrances to one or more approaches. They are mostly used to control minor roads, ramp intersections, and/or Y-intersections. Roundabouts are considered the only different geometric designed version where yield signs are used on all approaches. The case is different with a stop sign. It can be used in many scenarios such as minor road only control, two-way stop, three-way stop, and multi-way or all way stop.

Traffic lights are believed to be made to give each direction a fixed time and not have a lot of congestion. It is believed that the traffic light controlled intersection has been a cheaper option than a roundabout and works well for a huge amount of traffic in at-grade intersections. Although the technology has allowed us to have various preset times in different times of a day or night.

Many intersections including signalized intersections offer left and right turns. If they sported a dedicated turn-lane, the straight through vehicles might not suffer a lot of delay.

As it is well-known among traffic engineers that some delay is caused by the left-turn.

Drivers are advised to have a specific headway or gap between their cars and the cars ahead of them. It is recommended to have a gap in case an obstacle comes in front of the driver ahead of you and he decelerates and or acts accordingly, the driver behind will have sufficient time to react to the situation by slowing down or steering away from the current lane, without knowing the reason in time. In case of connected vehicles, the cars will be

3 able to follow each other closely with less gap, which increases the capacity of the lane and more vehicles can be served in the same amount of space, and communicate with the vehicles in surrounding to get an idea of the situation and act accordingly.

AVs are vehicles with a set of computer algorithms controlling the wheels, removing the redundant human being behind the steering, and goes by what it learns. Vehicles that are involved in some sort of communication between them and/or with infrastructure are considered CVs whether they are automated or traditional.

We would like to use the CAV term to Vehicles that are automated and have some form of connectivity with infrastructure and/or other vehicles. The author believes connectivity is the future and as a big percentage of people still don’t want to let go of the steering; we believe traditional and automated vehicles can go along each other well while they are connected.

Researchers would like to use the word Automated rather than Autonomous as

Autonomous would give the idea of fully automated vehicle which is not readily available today. The word automated give a rather good sense of the automation level.

1.2.1 Automation Levels

In 2013, United States Department of Transportation’s NHTSA announced their policy regarding vehicle automation and defined them in 5 automation levels from No automation - Level 0 to Full self-driving automation – Level 4, on their website. These definitions are considered very broad in terms of explaining the differences. Society of

Automotive Engineers came up with a little detailed version of it specifically the Level 3, which they divided into Level 3 and Level 4.

Figure 1-1. Level zero or no automation (left) and level one automation details (right). Adapted from DPCCars.com VW automation video

SAE categorized the levels 0 to 2 as human monitored levels. Level 0 is a vehicle with no driving assistance system. Vehicles that have some sort of driver assistance system is considered level 1. While vehicles having 2 or more Advanced Driver Assistance System

(ADAS) working simultaneously are considered level 2 vehicles. These vehicles might include Adaptive Cruise Control (ACC), Lane Keep Assist (LKA), and automatic emergency braking systems. In these 3 levels, driver must keep control of and use the assistance systems as an additional help and not solely rely on them. Level 2 might use sensors, cameras, radars, and or LIDAR. Most of the modern commercially available vehicles are considered as level 2.

Figure 1-2. Level two automation details (left) and level three automation details (right). Adapted from DPCCars.com VW automation video

Level 3 is where things get interesting. In this level, vehicles can perform specific tasks without driver’s help and when it reaches to a point it can’t assume the responsibility it will advise the driver to take over. Taking the car on-ramp and off-ramp and driving it on a highway probably with adaptive cruise control and lane keep assist together would be considered a level 3. If some capabilities were not programmed in this level, they vehicle will hopefully go to the edge of the road and stop.

Although we can call level 4 as autonomous, there are still some limitations to this level.

The level 3 definition of NHTSA was considered somewhat ambiguous which SAE dissected to level 3 and level 4.

Level 4 is where a vehicle can pretty much drive itself in typical traffic and normal weather conditions in various highways and city road scenarios.

Figure 1-3. Level four automation details (left) and Level five automation details (right). Adapted from DPCCars.com VW automation video

However, they might not be able to drive in thick fog, unpaved or roads without markings and signs. Circumstances that are not defined well or are yet to be addressed by the artificial intelligence and fed to the internal computers.

Navya shuttle buses are on example of level 4, which is used to transport employees of

EDF nuclear power plant to the worksite in Civaux, France.

Finally, Level 5 would mean that there is no need of the redundant passenger to go with you wherever you want to go. It will be unmanned, unrestricted, and will be able to do all the driving without any complications. All levels are visualized together in the following figure which is depicted from SAE and created by Vox.com.

Figure 1-4. Five levels of automation explained in terms of what is controlled by a Human driver and what systems are automated. Image source: Vox adapted from SAE International

1.2.2 What is a traffic simulation software?

When Traffic engineers and planners propose new roadway plans, change the road networks, or even a small thing such as adding a left-lane bay, they need to forecast the effects on traffic flow. Also, when wanting to integrate major public buildings, such as

8 stations, airports, stadiums, or even a giant Retail Company to the current network, their impacts ought to be considered.

In some cases, some new proposals where physical changes to the road are not involved, such as deploying new mobility technology like connected and autonomous vehicles or wanting to know how will changes in traffic light timing and sequencing affect the traffic flow, the need for a traffic simulation software arises. We chose traffic simulation software based on some criteria detailed in the next chapter.

1.3 Objective

We are simulating an isolated intersection for the current traffic and then giving traffic lights and cars some sort of connectivity. We are using different scenarios in order to connect the traffic lights and vehicles on the road. One such example is detecting the vehicles through a camera which is connected to the traffic lights control. Traffic lights will adapt its green state in order to let the vehicles pass the intersection successfully. The other option is, reducing the minimum gaps between the cars and changing the perception- reaction time for the cars. We will then study the outputs and compare impacts of the different scenarios.

As it is widely known that Signal Phasing and Timing (Spat) is often done for the traffic lights to be able to accumulate the stream of traffic properly. As it will be shown in the coming chapters that the new connected technology will help alleviate the congestion and reduce the delay. We are hopeful for connected vehicles, not just autonomous vehicles but connected traditional and autonomous vehicles is our future for a few decades to come.

The second chapter will include literature review on the topics of AV/CV, simulation, and

SUMO. Chapter 3 will have the methodology and Chapter 4 will include the simulation and its results. We will conclude the thesis with Discussion and Conclusion.

2 Literature Review

2.1 General Background

These days, the academic literature on the potential impacts of Connected Vehicles and AVs is an evolving area of study. Connectivity and automation have been the subject of attention and featured in government reports, media articles, research studies, novels and even movies. It is said to be the big disruptive innovation in the decade. Although it is mainly technology driven, it is supposed to have a huge societal impact on the various parts of the lives of people. It is predicted by researchers such as Fagnant & Kockelman [2014] that the Vehicle Miles Traveled (VMT) and vehicle emission will change significantly, as a result of AV deployment. With this research, regional planners may incorporate AV impacts in their air quality estimates, traffic delay projections, travel demand models, and related decision-making processes.

According to various literature, automated and connected vehicles promise the following benefits, which may include but are not limited to:

• Reduced amount of collisions [Eidhall et al. 2007]

• Higher speeds [Franke et al. 1998] because computers will make decisions faster

• Better traffic flow [Fernandes & Nunes 2010] as there will be less congestion due to

less safety gaps and automatic intersection scheduling.

• Increased accessibility [Han et al. 2011] as people with disabilities and physical

limitations such as age, vision or health condition will be able to ride the vehicles as

passengers.

• Higher fuel efficiency [Bullis 2011] as computer will find and take the best route in

various traffic conditions.

• Less space for parking [Horatiu 2010] because cars will be parked closely and more

accurately by computers thus less parking infrastructure will be needed

• No need of a driver because the vehicle will drive itself, in case of full automation.

• Less people needed for the transportation infrastructure such as drivers, traffic police

and toll staff. [Cheng 2013]

Clemson university vehicular electronic laboratory explained how an AV would work. It goes into detail of how a sensor will get the static and moving object information (input) and send it to the electronic control unit (processor) which will digest the information and decide what actuators (output action) should perform which in turn controls the vehicle.

Types and details of each category is explained well in the following chart.

Figure 2-1. Types and details of how an AV works in three steps. Source: clemson.edu

2.2 Public Acceptance

It is anticipated that CV/AVs will reduce congestion, minimize accidents, reduce social exclusion and lower travel time, though some are not yet convinced. While experts seem more confident about the adoption of AV technology, the public are still afraid of letting a robot car drive them. Sun et al. [2017] went over the existing literature and addressed many broad categories including but not limited to AV features and mobility models’ investigation, connectivity to infrastructure, public’s concerns and attitude, and policy implications. It added that Australian government’s 2016 Smart Cities Plan advocated for technology and listed AVs as a transformational technology that will have a broad impact on cities. The paper further argues that there are still more unknowns to the

AV technology from social and technical sides alike. It gives the example of people’s attitude towards a level 4 or 5 autonomy. People’s concerns range from excitement to suspicion [Bazilinsky et al. 2015]. Kyriakidis et al. [2015] conducted a study of 5000 people’s behaviors and concerns in 109 countries and yielded that almost one-third of the people in the survey do not believe AVs will get half of the market share before 2050.

After doing a good amount of literature review, Sun et al. [2017] concluded that although several trials of AVs are conducted all over the globe, there are still a lot of unknowns in terms of how and when it will happen. It adds that in terms of technology, the automation is not a new concept. It has been there in other sectors, such as rail, for decades but unlike these sectors, roads present more challenges particularly with mixed traffic and pedestrians.

It further states that with AVs, liability and insurance will change and Australia doesn’t have a legislative or regulatory framework in place to deal with AV issues. It explains

13 further that AVs will change the way mobility works now and that AVs will be used more efficiently through shared models.

2.3 Current State of AVs as of Early 2018

With the release of model S and X in 2015, Tesla gave people a taste of what the future autonomous vehicles might look like. Many manufacturers such as Volvo,

Mercedes-Benz, Ford, GM, BMW, and Audi have begun testing driverless cars [Eno 2013

& KPMG 2013]. Ford has started AV testing at the University of Michigan’s MCity site, a 32-acre test facility with 16-acres of roads and traffic infrastructure, where simulation of what believed was the industry’s first tests of AVs in wintry conditions [Umich record,

2016].

Waymo, Google’s AV group, built an entire simulated city in California while Uber constructed its miniature city in Pittsburgh to test AI algorithms of their driverless cars

[The Atlantic, Nov 15, 2017]. As of March 2014, Nevada, California, Florida, and

Michigan have passed legislations enabling autonomous vehicle testing on their roads [Eno

2013 & KPMG 2013]. Further, AVs have captured the interest of stakeholders through their potential implications that as of December 28 2017, State of California Department of Motor Vehicles Occupational Licensing Branch has given permits to 49 companies that range from cars to hardware manufacturers and software companies to AI startups to test

AVs on public roads [California DMV].

GM partnered with Cruise Automation and built what they claim to be a safe self-driving electric vehicle from the ground up in Detroit integrating the self-driving system developed by Cruise Automation. The vehicle used for testing is a an all-electric Chevrolet bolt EV, named Cruise AV which will be used as ride-sharing fleet is expected to be launched in

2019 [GM safety report 2018].

Figure 2-2. GM’s expected driverless car without steering and pedals. GM.com

According to Motor Trends website, GM will deploy a CT6 model of the luxurious Cadillac cars in 2018 which is equipped with level three automation as an upgrade to the famous super cruise. They also stated that Audi is working on a 2019 model of their two different cars to be released with a level three technology to the market. While most of the manufacturers want to skip the level three and invest more of their time and resources on releasing a level four vehicle in 2020 and beyond.

More precise throttling and braking could facilitate lower vehicle headways and accommodate closely-spaced vehicle platoons, both of which could significantly increase lane capacity [Smith, 2012]. In addition to congestion reduction, autonomous vehicles will also likely reduce the need for new infrastructure. The literature estimates that vehicle platooning could increase highway lane capacity by up to 500 percent. Moreover, it claims that autonomous vehicles could contribute to a significant redefinition of vehicle ownership and enhance the opportunities for vehicle sharing [KPMG & CAR, 2012].

2.3.1 Technologies in the market

According to Plunkett Research (2012), the number of automobiles is ten-fold of the amount in 1960s. Globally, there are more than one billion vehicles on the roads and increasing.

According to Nissan Corporate (2013), the roads are much safer now with the technologies deployed in Nissan cars. One example of such technologies is the Intelligent Pedal or

Distance Control Assist System (DCAS). Suppose if a car is getting close to the vehicle in front. “If the driver releases the gas pedal, the system automatically applies the brakes smoothly to decelerate the vehicle and help the driver maintain an appropriate following distance. If the driver is pressing the gas pedal, the gas pedal actuator moves the gas pedal upwards to assist the driver to release. The car system applies the brakes when the driver is not pressing the gas pedal”.

Figure 2-3. Decelerating when gas pedal is not pressed (left). When closer, it will raise the gas pedal to discourage the driver from accelerating (right). Source: Nissan.com

It uses radar and cameras to determine the distance. Another example of DCAS is explained in the photo on the right. If the vehicle in the front is slowing down, the driver should decelerate too to avoid any collision. When the system realizes that braking is required, it will sound a buzzer and show an indicator in the meter gauge. Then the system will raise the gas pedal upwards to tell the driver to press the brake pedal in order to slow down.

The Intelligent Car Initiative aims to increase the speed of AVs deployment in Europe so that it helps create more safe and convenient transportation system. Cars having the driver assistance technologies are considered Partial AVs here. New vehicles entering the market are including increasing degrees of automation. Some of the Partial automation technologies listed on the Intelligent Car Initiative website and the adaptive system(s) components that existed or currently exist(s) in the market are as follows:

Adaptive Cruise Control (ACC): this system adapts the standard cruise control to the car in front. If the preceding vehicle slows down it will lower the set speed of the cruise control and vice versa.

Adaptive Headlights: this system moves each headlamp in all four directions in reaction to the angle of steering and speed of the vehicle.

Anti-lock Braking System (ABS): whenever a driver brakes hard, this system will prevent the wheels from locking up through modulating the brake pressure.

Blind Sport Detection System: this system monitors the cars surrounding your vehicle. If they come near you or in your blind spot they will buzz and warn you.

Driver Drowsiness Monitoring: a feature that detects the driver’s facial features, eye closure, head pose and even movements of hands and feet and will alert the driver if distraction or drowsiness is detected.

Electronic Brake Assist System (EBS): Whenever the driver wants to stop the vehicle, this system helps bring the vehicle to a stop as quickly as possible.

Electronic Stability Control (ESC): Whenever a driver deviates from the vehicle’s trajectory or intended direction, this system comes to help. It applies small amounts of brakes on each wheel which can bring the vehicle back to its intended path. The driver doesn’t initiate the system and sometimes won’t even notice that the systems intervened.

Gear Shift Indicator (GSI): Whenever a driver is driving in a gear that consumes more fuel or is driving aggressive, the system gives a visual warning to change the gear to a smoother one and drive economically.

Internet connectivity with LTE: This system helps vehicles to maintain good connectivity with the outer world and be able to update its internal software and use accurate positioning for automation.

Lane Departure Warning System (LDWS): This system is different than LKA. It just warns the driver if the car deviates from the lane.

Lane Keeping Assistance (LKA): This is one of the new systems that is used to keep the vehicle in the lane it is going. It won’t change the lane by itself unless the driver turns the blinker on.

Mayday systems (such as OnStar) with 911 connectivity: This system helps get help when any incident occurs.

Night Vision: This system helps the driver see better in the night time. It usually works for the same range as the beam headlights.

Obstacle and Collision Warning System: This system detects obstacles and other vehicles that the car is approaching. It will give a warning if there is a risk of collision.

Parking Assist and self-park: This system helps drivers with parking properly. If the car approaches an object or a vehicle it gives warning. Self-Parking does a good job in parallel parking.

Pedestrian alert systems: This system detects pedestrian walking into the streets.

Whenever it detects a pedestrian it gives a warning to the driver.

Rear view camera: This system gives an extra eye to the driver to back up and watch the rear end of the vehicle and its trajectory properly.

Tire Pressure Monitoring System (TPMS): This system monitors the air pressure in all four wheels.

Traffic Sign Recognition: This system recognizes the traffic signs through cameras and sensors available. It is one of the most important technologies for this decade.

Vulnerable Road User Protection System: This system helps protect the road users such as pedestrians and cyclists and prevents collision.

2.3.2 Some history of Automation Technology

Most of the efforts were supported by government funds and research programs, including the U.S. DOT’s research program named Automated Highway System (AHS) in

1990s, and Defense Advanced Research Projects Agency (DARPA) which executed many challenges.

Although it is believed that the first attempt towards technology taking the wheel dates to

1500s, Leonardo da Vinci, who was working on a self-propelled cart, the following table demonstrates timely advances towards automation technology.

Table 2.1. Some history of Automation Technology. Adapted from SeminarLinks presentation with small modifications. Years/Decades Automation Technology 1920s Transmitting Antennae 1930s Embedded circuits and radio controllers 1950s Detector circuits Special radio receivers Audible and visual warning devices 1960s Electronically controlled highways Powered and controlled by buried cables Wayside communication relaying computer messages 1980s Laser radar, computer vision and autonomous robot control Off-road map and sensor-based autonomous navigation 1990s Extensive systems engineering work and research Video cameras on board and use of stereoscopic vision algorithms 2000s Real-time control system Cameras, sensors RFID tags GPS 2010s Artificial Intelligence, Neural Networks, Machine Learning LIDAR, 3D mapping, etc.

The evolution of automation technology is described in different ways, such that the period before1950s is considered as the period of magnets and sensors embedded in the roadway.

Then, around 80s with computers becoming powerful, radar and autonomous navigation took charge and drove us to the twenty first century. And finally, with the use of machine learning and AI, modern LIDAR and sensors can even operate without having any visual speed limits and traffic lights and learn and relearn from a lot of information in a very little time.

Anyways, fully AVs will not come to the market at once. Manufacturers will add new features to the vehicles in bits and pieces and mostly go up one level at a time. Additionally, with new advancements, we expect the driverless cars to be on the roads in the next few years.

A more detailed version of the automation history is attached as Appendix A.

2.4 CV

The United States Department of Transportation (USDOT) has recently sponsored several connected vehicle research initiatives and pilot programs across the US to support vehicular technologies for safety, mobility and environment. They state under the topic of connected vehicle “requires a robust, underlying technological platform that can provide consistent, interoperable, and safe operations for all users” [CV Technology ITS-

USDOT]. The transformative capabilities in connected vehicle technologies showed that they can make the surface transportation safer, smarter and greener [CV Deployment ITS-

USDOT]. Technically, connected vehicles communicate with each other through a network of wireless radio signals, devices and the infrastructure. The aim for CV technology

21 research is primarily conducted to provide efficient V2V and V2I connectivity [Chandra

& Camal ICSDEC 2016].

In their paper, Dresner et al. [2008] argues that when vehicles become autonomous, interactions amongst the vehicles will become more probable. Although automated vehicles have been efficient in highways and freeways scenarios, urban traffic scenarios and intersections will be somewhat challenging. They believe current AVs precisions will not be utilized efficiently with current methods in place. They suggest an alternative coordinating mechanism for the movement of AVs through intersections. Intersections will use a reservation-based approach built on communication protocols with multi-agents, namely drivers and AVs. They simulated their mechanism and it outperformed the intersection control technology in place. They used a driving agent and first come first serve policy. Whenever a driver agent approaches the intersection it is given a reservation; the policy will then run an internal simulation of the trajectory and determine which tiles or grids will be occupied by that vehicle and if at any time the vehicle occupies a reservation tile already reserved by another vehicle the request will be rejected. Other than that, the policy will accept the reservation and reserve appropriate tiles for the period they will be occupied by that vehicle.

As the literature suggests, autonomous vehicles will bring a potential shift in the current transportation system. Knowing about the behavior of current drivers we can start developing strategies for integrating autonomous vehicles in a beneficial manner.

2.5 Simulation

Efforts have been made to bring about new efficient Inter-Vehicle Communication

(IVC) protocols for safety applications and on-demand route planning in case of traffic incidents or congestion. Sommer et al. (2011) discusses the need for bi-directionally coupled networks and road traffic simulation for improving IVC protocols. They believe that having a model that represents the situation better will yield meaningful results. They developed a hybrid simulation framework named Veins (Vehicles in Network Simulation) which combines the road traffic simulator software SUMO and a network simulator called

OMNeT++. In order to prove the concept, they evaluate the two incident warning protocols over (Vehicular Ad hoc Network) VANETs and illustrated the benefits of bidirectional coupling.

AVs can help optimize traffic in many new ways. Approximately Orchestrated Routing and Transportation Analyzer (AORTA) is one of the multi-agent open-source microscopic simulators created at the University of Texas, Austin by the authors to optimize the driverless traffic at a city scale. The software creates intelligent behaviors for driver agents and intersection policies to be followed by them which enhances traffic optimization. These control intersection crossing, agents’ inter-communication and routes them safely to their destination. They simulated one hour of traffic with a step duration of 0.1 seconds. While the policies for intersections may vary, the agents spawned and the routes were the same.

They experimented delays at autonomous reservations intersections, stop signs, and traffic signals in Austin and Houston using the heuristics mentioned. It showed that Autonomous reservations outperformed stop signs and traffic signals. The research was funded by

National Science Foundation, ONR, and Federal Highway Administration [Carline et al.

2012].

2.5.1 Existing simulation software

Although there are various traffic simulation software, I will be comparing a few software that I have considered to be on my list.

I went through the following three simulation packages:

1. SUMO – Simulation of Urban Mobility, version 0.23.0

SUMO is an open source, portable, multi-modal, micro- and mesoscopic simulation

software that can handle large road networks.

Figure 2-4: A snapshot from a simulation in progress in SUMO.

2. Autodesk Infra Works 2017

One of the recent software that has made its way to the transportation industry. It

has great 3D graphics but still lacks essential simulation commands. Infra Works is

basically built for all Transportation planning and design works ranging from

drainage to creating roundabouts and bridges and doing some traffic studies.

Figure 2-5: A snapshot of Autodesk InfraWorks while simulating the Westgate intersection. 3. PTV Vissim V9.0

One of the leading and costly traffic simulation software in the industry.

Figure 2-6: A simulation of multimodal traffic in Vissim. Image: PTVgroup.com The following criteria are used for comparing the above software. I adopted some of the criteria of selecting the simulation software from Kotushevski [2010]:

a. Open source and free use

b. Portability

c. Wiki Documentation and User interface

d. Creating traffic and vehicle patterns

e. GUI and simulation graphics

f. Ability to simulate large traffic networks

g. Simulation output

I will try to explain as much detailed as I can and know.

A. Open source and free use

Of the three packages, SUMO was open-source and free to use while PTV Vissim had

feature restrictions for academics and students or 30 day trial. The plus point for the

open-source is that their source codes are accessible and can be further modified by

other programmers. Infra Works was free to use through registering as a student and

for academic purposes.

B. Portability

Almost all commercial engineering software are made for windows PC. SUMO, an

open-source software has the ability to run in windows and unix/linux based operating

systems as executable/installable and portable as well. InfraWorks is mostly cloud

based which means if you needed to run a simulation, you need to have internet access

and cloud credits, which Autodesk provides you with some.

C. Documentation

Although PTV Vissim and Infraworks have video tutorials and paid trainings, SUMO

has online wiki and documentation available to everyone with basic examples. There

is a mailing list that one can subscribe, to get the latest updates on what developers

and other users are working on.

D. Traffic and vehicle patterns

As of the time of the writing, all three software can create traffic simulation and

vehicle OD trips but each one has their specific limitations. As of now, InfraWorks

doesn’t have an active traffic light system. Also, it only supports an O/D matrix.

Vissim and SUMO have a lot of potential in generating various types of trips whether

static, dynamic, or random.

E. Graphics and GUI

Compared to the other two, InfraWorks uses a great amount of graphics in vehicle

shapes and infrastructure. It sports a 3D view of the buildings and surroundings.

InfraWorks and Vissim offer a nice interface and are easy to work with. Even though

SUMO and Vissim are more two dimensional, producing a SUMO simulation requires

some knowledge of coding and command prompt (shell/terminal).

F. Simulation ability

All three software have the ability to simulate microscopic circumstances. Although,

InfraWorks is created for a more broad planning and works more as a Mesoscopic and

Macroscopic program. Vissim and SUMO can be used to simulate AVs/CAVs while

InfraWorks is not very big on simulation.

G. Simulation output

InfraWorks and SUMO have settings to show the queue length and average delay in

real-time. SUMO and Vissim can give you an output in various formats such as

comma-separated worksheet “.csv” and text “.txt” files. I couldn’t get around

Infraworks a lot and I believe the real-time 3D visualization is the output.

Figure 2-7: Showing real-time queue outputs in InfraWorks. SUMO color changing real-time output.

Figure 2-8: Showing real-time output of vehicle waiting time in terms of colors. Dark blue is less or no waiting and Yellow is representing more waiting time.

2.6 SUMO

Behrisch et al. [2011], the first paper by German DLR officials which introduces

SUMO as an open source traffic simulation software capable of creating networks from scratch and importing networks from open street map, shapefiles, Vissim, MATsim and other commercial software. It also includes many internal packages for creating networks and demand modeling components. The suite is considered a multimodal microscopic traffic simulator in which each vehicle is given an identifier (name), departure time, and route through the network. Users can add more details to each individual vehicle if wanted.

Properties such as velocity, lane to use, and the position can be specified.

Behrisch et al [2011] added details about the vehicle types and physical properties that can be assigned to the vehicles. Afterwards, they introduced the packages that come inside the suite which is summarized as follows:

Programs for creating SUMO format networks:

Netgenerate: abstract networks can be generated by this application.

Netconvert: networks, maps, and shapefiles from other software can be converted to a

SUMO readable map using netconvert command through command prompt.

Netedit: a graphical network editor and creator

Polyconvert: it imports polygons and points of interests specified in a different format and converts them into shapes that can be visualized by SUMO-GUI

Programs for Traffic Demands:

Od2trips: is used to convert O/D matrices to single vehicle trips and assign a road edge for departure/arrival positions.

Jtrrouter: it uses the turn percentages at intersections throughout the network to compute efficient routes for each individual vehicle. It can be used for small networks.

Dfrrouter: is the extended version of jtrrouter, it computes the routes from induction loop measurements.

Activitygen: it generates a demand based on a population’s mobility patterns.

There are many other tools not included as internal programs. Most of these tools include

Python scripts, Java programs, Shell scripts, and Java libraries. These useful tools are available in the installation folder under sumo/tools directory. You can learn more about the tools from SUMO wiki.

http://sumo.dlr.de/wiki/Tools/Main

The suite can be used to generate outputs for its simulations. They can range from single vehicle position and speed at each given time step up to complex information about trips, delays, and queue lengths along specific lanes or streets. They later added noise and pollutant emissions to be outputted as well.

For more detailed information on creating a simulation using SUMO, see Appendix B.

3 Methodology

Measuring effects of connected vehicles on the standard traffic has been studied for a few years now. I would like to take that concept and use it in one of the busiest intersections of the city of Toledo in the state of Ohio. In order to be able to measure the effectiveness of connected vehicles, we first simulate the current state of traditional traffic and measure the outputs then we will simulate different scenarios of connectivity and obtain the results. We will start this chapter by talking about the data we needed to collect.

3.1 Data:

We collected the traffic counts from the city of Toledo and ODOT’s TCDS or

Transportation Data Management System. The counts are listed in the table, we went on and calculated the amount of right turns, left turns, and straight through vehicles. The following values were used in all three different scenarios of the simulation with little modification.

In order to get the traffic lights phases and timings, we went to the field and observed the intersection in late afternoon which is considered the busiest time, and recorded the green, yellow, and red values for several phases.

Figure 3-1: Vehicle counts calculated and used for simulation

We used the values with a small modification in the order of phases which are as follows;

Table 3.1. Traffic signal phases obtained from the field around 5 pm

Phases Green Amber

Straight through NS 38 5

Left turns 14 4

Straight through EW 38 5

Left turns 14 4

We used the tables as inputs for the simulation of standard traffic i.e., traditional traffic.

3.1.1 The Westgate intersection

The intersection we are simulating is called Westgate Intersection in the Westgate village. Secor road and Central Avenue are intersecting here. Secor Road goes north-south and is connected with I-475, just a few hundred feet from the intersection, through off- ramps and on-ramps and from the length of 2.5 miles I-475 plays the role of a collector for the I-75 interstate highway. While Central Avenue is laid out east-west and is a part of US-

120 and if you go more west, it becomes a part of US-20 and US-120 at the same time. The intersection is a little over 3.5 miles from the US-20, US-120, and I-475 grade-separated intersection. US-20 and I-475 then connect I-75 in a junction in Perrysburg, a suburb of

Toledo. Additionally, there are some big retail stores and some famous fast food restaurants which make this particular intersection one of the busiest intersections of the city.

Figure 3-2: Westgate intersection and its surrounding area.

In this chapter, we will discuss the basics of traffic movement. Topics of traffic movement range from simple concepts like speed and acceleration to complex details of car-following models used in the study.

3.2 Car following model

We used the car-following model described by Stefan Krauss in his thesis which is the current default car-following model in SUMO with little modification and named

SUMOKrauss. I will describe some of the characteristics we adapted that has obvious effects on simulation.

The Krauss car-following model used in SUMO is based on the same idea of Stefan

Krauss’s model which is: “Let vehicles drive as fast as possible while maintaining perfect safety (always being able to avoid a collision if the leader starts braking within leader and follower maximum acceleration bounds).”

The two big differences between the Krauss original car-following model and the

SUMOKrauss modified version as described in the SUMO documentation are as follows; one of them is the deceleration parameter which is changed in order to handle the vehicles without violating any safety rules. The other one is that the formula for safe velocity was adapted using Euler position update rule which will maintain safety instead of Ballistic position updated rule.

Some of the default vehicle characteristics and values used in the SUMOKrauss car following model are as follows:

Acceleration = 2.6 m/s2 (8.5 ft/s2) max acceleration ability

Deceleration = 4.5 m/s2 (14.76 ft/s2) max deceleration ability

Sigma = 0.5 ranges from 0 to 1

Tau = 1.0 second reaction time (min time headway)

Note that the values used for acceleration and deceleration describes the ability of the vehicle type, it doesn’t necessarily mean it will use these max values. In normal circumstances, we tend to use half perfect drivers which are not very aggressive or very slow. The distance used for reaction is defined as the minimum time headway plus the min gap.

3.2.1 Speed

The speed tables on Central Ave and Secor Road were 40 mph which we input as

18 m/s which is equal to 40.26 mph, a little over 40. There are different ways of assigning the speed limit. Once can specify speed limits for each lane or road, it can also be specified for each vehicle type. We specified it for each road separately, in case the user wants to put different values for each road.

Speed distribution is essential to achieve realistic car-following behavior. If all of the vehicles had the same speed, they will not be able to catch up with each other and result in large headways. Fortunately, SUMO has two good commands for keeping a good balance of the speed distribution. A good distribution can be obtained using speed factor and speed deviation.

Figure 3-3: Speed distribution of our simulation

As it can be seen from the frequency distribution above, vehicle speeds are pretty much spread. Speed factor and speed deviation will result in a distribution where 95% of the vehicles drive between the limits specified by these commands. speedFactor=normc(20,0.1,0.75,1.25) (mean, dev, min, max) speedFactor=norm(20, 0.1) (mean,dev)

Speedfactor = 0.9 any value

SpeedDev = 0.1 (-+10 %)

3.2.2 Acceleration and deceleration

Some researchers tweak acceleration and deceleration criteria of vehicles as a characteristic of AV. We are not much interested in these but we are rather intrigued by the reaction time, driver imperfection, and minimum gap criteria.

37 actionStepLength is one of the interesting commands in SUMO, which in par has direct connection with action and reaction taken by the vehicle/driver either to accelerate/decelerate or change lane. This value is processed to the closest positive multiple of the simulation step length.

3.2.3 Gap between vehicles

Keeping a gap of the length of a vehicle is encouraged by the state of Ohio Board of Motor Vehicles in urban roads. It advises drivers to add an extra vehicle’s length distance for each 10 mph speed increment. We are using a minimum gap of 2m (6.56 ft.) for passenger vehicles and 3m (9.84 ft.) for larger vehicles.

3.3 Simulation Scenarios

We simulated three different scenarios. The fixed time scenario of the intersection having preset signal times and cycle lengths. The second scenario has a camera installed and connected to the traffic lights so that it can detect vehicles in a specific distance and extends the green (adapt the traffic lights) to the vehicles. Finally, the third scenario is what we call the connected scenario. In this scenario, we change some parameters of the vehicles such as, reducing or eliminating the driver imperfection, reducing the min gap, time headway and reaction time. They are used along with the adaptive signal configuration used in the second scenario. Adaptive traffic lights in both second and third scenarios work on first come first serve basis.

For beginners, small handout has been prepared on how to perform a successful microscopic traffic simulation in SUMO. The document is attached as Appendix B. We

38 have also created a user friendly front-end for people who don’t want to get into writing codes.

3.3.1 Fixed scenario: Preset/Pre-timed signals

The general scenario is explained here which applies to all three unless stated otherwise.

In order to simulate the Westgate intersection, we created our four-leg intersection

(network of roads) with lengths of 250 m (820 ft.) each way. Although SUMO is currently configured to align the medians not the centerlines of roads as a whole, we tried to have it look as realistic as possible. When we created two outbound lanes, the cars were getting into collisions. In order to have the collision problem solved, we decided to have four lanes in both the inbound and outbound and block two lanes.

Figure 3-4: Simulation running in SUMO

We adopted the signal timings we recorded from the field and have allowed right on red as it is in the intersection. Four phases have been chosen for the traffic lights. You can enter the amount of time you want to allocate for green/yellow/red states. First phase will control the straight through and right turns from Secor road. Second state will have the left turns from North and South Secor road to Central Ave. Third phase controls the straight through and right turn traffic flows from Central Avenue. And lastly, the fourth phase controls left turns from Central Avenue to Secor road. Phase definitions along with green/yellow/red states will be written in an additional file which will be loaded to modify the definitions automatically generated by the program.

As you might see in the Appendix B, one way to generate the vehicles is by creating a flow file and giving it vehicle amount through four different commands. vehsPerHour, Period,

Number, and probability are the commands used for generating vehicle flows in a specific time and number. The first three commands produce vehicles with a constant spacing and inserts it to the simulation while probability is somewhat considered dynamic and it has randomness to it.

We generated the OD trips or route file through a python code as we wanted it to enter the simulation more randomly and have the cars choose their approaches more randomly. We entered one hour vehicle counts for each possible approach (RT, LT, TH, 3 approaches per leg, 12 approaches in total) and used a peak hour factor (PHF) of 0.95 for each 15 minute interval. Then calculated its probability by dividing the counts per approach by the total counts and used the probability through “if” conditions in a while loop to generate the vehicles randomly.

We used two vehicle types, namely truck trailer and passenger cars having the following characteristics of the default SUMOKrauss car-following model and made a few changes.

Vehicle characteristics and/or driver behaviors used throughout the simulation are as follows unless otherwise stated:

Passenger Vehicle:

Acceleration: 3 m/s2 (9.84 ft/s2) Deceleration: 4.5 m/s2 (14.7 ft/s2)

Length: 5m (16 ft.) Driver imperfection: 0.5, default minGap: 2 m (6.56 ft.), default Reaction time (tau): 1 sec, default

Speed deviation: 0.1 (10%)

Trucks:

Acceleration: 1 m/s2 (3.28 ft/s2) Deceleration: 4 m/s2 (13.12 ft/s2)

Length: 8m (26.25 ft) Driver imperfection: 0.5, default minGap: 3 m (9.84 ft.), default Reaction time (tau): 1 sec, default

Speed deviation: 0.1 (10%)

The random trips generated through the python code is then written to a route definition file (.rou.xml) which is used along with the network file created in previous steps (.net.xml) to run a simulation. These two files along with any other additional files such as traffic light definitions and output file names should be put in a SUMO configuration file

(.sumocfg) and when launched with sumo-gui, it will visualize the simulation in a GUI.

3.3.2 Adaptive scenario: Using a camera connected to traffic lights

In this scenario, a vehicle detector is used alongside the traffic lights. Of the different varieties we chose the lane area detector, known as E2 in SUMO, which is detecting vehicles in a specific distance from the stop line.

We evaluated the average Time Loss and Queue Lengths in various lengths of 25m (82 ft.),

50m (164 ft.), 75m (246 ft), and 100m (328 ft.) and the results yielded 50m as a good option to use.

Average Time Loss for various detector lengths in an adaptive scenario 90 80 70 60 50 40 30

Time Time Loss (s) 20 10 0 25 50 75 100 Detector Lengths (m)

Figure 3-5: Average Time Loss in all approaches for various detector lengths.

All adaptive and connected scenarios are based on 50m detector length. Whenever a vehicle is detected in this range in any of the four directions and 16 lanes, the detector will send the information to the signal control in order to give green for the respective phase, if the current state was red, otherwise it will prolong the green time to a maximum value defined for that particular phase.

We kept the cycle lengths and set a minimum and maximum duration for the green timings to be adjusted for vehicles in the detector range.

Table 3.2. Max and min green timings for actuated 122s cycle

Phases Min Green Normal Max Green

Straight through NS 5 38 57

Left turns 5 14 21

Straight through EW 5 38 57

Left turns 5 14 21

Any vehicle with a min Time Loss of 1 second will be detected and outputted to the csv file. As a general value, 150% of the current green time was chosen for the max green and

5 seconds is a good minimum value to allow at least 2 vehicles to pass.

3.3.3 Connected scenario: Using some characteristics of AVs/CVs

In this scenario, we used the adaptive signals used in the second scenario and went on to change the vehicle and driver characteristics. In order to understand each behavior/characteristic’s effect on the Time Loss and Queue length, we used different variations of each behavior.

As cars become more intelligent, they will be able to communicate with each other and use the time and space efficiently. One such thing is reducing the gap between vehicles and increasing the road capacity. Different minimum gap values are evaluated and the results are shown. The default values of 2.5m (8.2 feet) is used for a passenger vehicle and 4m

(13.12 feet) for a truck. We reduced the gaps to 0.5m (1.6 feet) for passenger car and 1m

(3.28 feet) for larger vehicles. As the results show, reducing the gap will reduce the delay by about an average of 3.5 seconds per vehicle although it is not a big chunk of the total delay (time loss).

Time Loss (s) based on different Gap values 42.5 42 41.5 41 40.5 40

Time Time Loss (s) 39.5 39 38.5 38 0.5 2.5 minimum Gap (m)

Figure 3-6: minimum gap values effect on Time Loss

The second factor examined is called driver imperfection which is denoted by the name of sigma in SUMO. It is suggested to use a value of 0.5 for a normal driver that might make mistakes. Three different values are tested in order to observe the effects.

Time Loss (s) based on various driver imperfection values 60

Time Time Loss (s) 40

30 0.1 0.5 1 Driver imperfection (sigma)

Figure 3-7: Effects of various driver imperfection values on Time Loss

The sigma value of 0.1 which is used for a somewhat perfect driver yielded more reduction in time loss is the one we will use for our connected scenario. Sigma value of 0.5 which is the default for a human driver and the value of 1.0 which is a number used for an imperfect driver have higher time losses. The sigma graph indicates a near perfect driver such as a computer will reduce the delay by 10 seconds which accounts for around 25% reduction from the normal version.

The third characteristic studied is called tau which is the reaction time and is also described as the minimum headway time plus the minimum gap. Four different tau values are evaluated. The reaction value of 0.1 second is the one we think a computer might get when improved. One second is the default value used by the simulation engine.

Time Loss (s) based on various Reaction Time (tau) values 65 60 55 50 45 40

Time Time Loss (s) 35 30 25 0.1 0.5 1 1.5 Reaction Time, Tau (s)

Figure 3-8: Time Loss vs. reaction time

The reaction time graph indicates a reduction of more than 30 seconds from the 1.5 second scenario to 0.1 seconds. It cuts the loss time more than 55%. The difference in time loss

46 between 1.0 second (SUMO’s default) and 0.1 second is around 15 seconds which can be translated as about 1/3rd reduction.

At the end, we used the smallest values of gaps, sigma, and tau with lower values of time loss to create our connected scenario and evaluate it in different cycle lengths. The simulation results for all the cases will be discussed in Chapter 4 in detail while Chapter 5 will contain the conclusion we drew and state the limitations of the program. It will also entail the front-end we created for people who don’t want to get into coding.

4 Results

We were able to get different outputs from the simulation and try to translate it in a way that would make sense. It is important to state that we haven’t taken any other factor such as pedestrians into account.

In order to get a proper resemblance of the simulation to the real-world situation and have a somewhat meaningful result we simulated around at least 10 hours for all cycle lengths in all three scenarios. Due to not having enough vehicles around intersection in the first three minutes of simulation, we deleted the beginning and the same for the end of simulation as cars will be less and finishing. To be exact, we deleted the first 200 seconds.

The three important factors that are measured and analyzed here are; Wait Time (at an intersection), Congestion (Queue Length), and Delay (Time Loss which includes the Wait

Time in the intersection). These are given in the outputs generated in two different files, namely “Queue Output” and “Tripinfo”. Tripinfo file contains Time Loss and Waiting

Time at an intersection while queue output file contains the queuing time and length. We organized the data in excel spreadsheets and most of the time used their medians and sometimes averages in our results.

4.1 Fixed Time Scenario

Time is one of the most important factors in traffic studies. Time lost or delay due to congestion is a constant challenge for traffic users and engineers. Time Loss was observed

48 for various cycle lengths for the amount of traffic present in the intersection. Although three different factors were recorded and evaluated, queue lengths and Time Loss had more meaningful visualizations. Technically, Time Loss is the total of waiting time and other slow-downs occurring on the road.

Time Loss vs. Waiting Time for Fixed Time Signals 105 100 95 90 85 80 Time Time (s) 75 70 65 60 80 100 120 140 160 Cycle Length (s)

Time Loss Waiting Time

Figure 4-1: Time Loss and Waiting Time averages for different cycle length

As it can be seen in the graph, the Time Loss other than the wait time in intersection averages to about 20 seconds and have the same trend. We will drop the wait time factor after this.

Time Loss for various cycle lengths in a Fixed Time Scenario

100

90 Time Time Loss (s) 85

80 80 100 120 140 160 Cycle Length (s)

Figure 4-2: Average Time Loss/Delay in all approaches for different cycle lengths

Although SUMO is not a signal optimizer program, the Time Loss and Fixed Time Signals chart shows that with a 100s cycle length the traffic will suffer less Time Loss in their journey. We didn’t include results from 60s and 40s cycle lengths as there were some vehicles performing emergency brakes and were decelerating while reaching the traffic light. We couldn’t get information from the city about the current situation of signals and when was it optimized.

Queue lengths were observed for all the cycle lengths and it suggests the same trend as the

Time Loss and waiting time. Queue length will be plotted for the adaptive and connected scenarios of 122 seconds cycle only as it doesn’t add extra information. The queue lengths also show that 100s cycle length is the optimal case.

Time Loss and Queue Lengths for Fixed Time Signals 105 215 210 100 205

95 200 195

Time Time (s) 90 190

185 QueueLength (ft) 85 180 80 175 80 100 120 140 160 Cycle Length (s)

Time Loss Queue Length

Figure 4-3: Queue lengths and Time Loss trends observed for different cycle lengths

4.2 Adaptive Scenario

Different versions of adaptive scenarios are used throughout the US for different purposes. We didn’t use the semi-actuated traffic lights as they are used in a scenario typical of country roads intersecting with a highway or situations where the main street has a big volume of traffic and side road has a very small flow. In this case, the main street will always have green unless a vehicle is detected on the side streets.

In our case, we used the cycle lengths of fixed signals and increased the maximum green values up to 150%. As it can be seen in the graph, adaptive signals reduce the Time Loss by more than 55% for an intersection like this.

Average Time Loss for various cycle lengths Fixed vs. Adaptive Scenario 110 100 90 80 70

60 Time Time Loss (s) 50 40 30 80 100 120 140 160 Cycle Length (s)

Fixed Adaptive

Figure 4-4: Time Loss for different fixed and adaptive (up to 150%) cycle lengths

If we look at the queue lengths of both Fixed and Adaptive scenarios, the latter shows an average decrease of more than 65% of the queue length of the former.

Queue Lengths for Fixed and Adaptive Scenarios 250

200

150

100

50 QueueLength (feet)

0 80 100 120 140 160 Cycle Length (s)

Fixed Adaptive

Figure 4-5: Queue Lengths for different cycle lengths in Fixed and Adaptive Scenarios

As the volume of traffic grows and there is a constant traffic flow on all approaches of an intersection, the gap in adapted and fixed scenarios converge. Thus, some large cities will choose preset/pre-timed signals over the adaptive case. In case of large pedestrian volumes, some cities might consider fixed time signals over actuated in favor of safety rather than efficiency.

4.3 Connected Scenario

Effects of adding characteristics of Connected and Autonomous Vehicles were discussed one by one at the end of Chapter 3. Here, all three behaviors are added together namely reducing driver error (imperfection), minimum gap, and having a faster reaction time are the ones studied under the connected case. As these characteristics are added on top of the adaptive scenario, it is expected to yield better results.

Time Loss for various cycle lengths Adaptive vs. Connected 45

Time Time Loss (s) 25

15 80 100 120 140 160 Cycle Length (s)

Adaptive Connected

Figure 4-6: Adaptive and connected scenarios time loss for various signal times

As expected, connected scenario reduces the time loss by more than an average of 50% of the adaptive case. Although minimum gap has lowered the time loss, the biggest factors in this scenario are the reduction in the reaction time and driver imperfection.

Queue Lengths for various cycle lengths Adaptive vs. Connected 80

40 QueueLength (feet) 30 80 100 120 140 160

Cycle Length (s)

Adaptive Connected

Figure 4-7: Queue Lengths for Adaptive and Connected scenarios

Queue lengths are significantly reduced compared to Time Loss. The graph shows an average reduction of 55% in queue lengths for connected scenario compared to its adaptive counterpart.

Time Loss for various cycle lengths Fixed vs. Adaptive vs. Connected 105 95 85 75 65 55

Time Time Loss (s) 45 35 25 15 80 100 120 140 160 Cycle Length (s)

Fixed Adaptive Connected

Figure 4-8: Time Loss for all three scenarios

If we plot all three cases in one single graph and compare the connected scenario to the fixed scenario, there is a huge fall of time loss and in case of a traffic study a huge win for the users and operators.

To sum up, according to our study, connected scenario is expected to cut the congestion by almost 4/5th of the fixed case and reduce the queue length by a whopping 83% on average.

5 Discussion

5.1 Limitations

We have undertaken the cases for just one intersection and do not intend to generalize our study and claim it will give the same results in all intersections all over the state of

Ohio or US as a whole. But we do think the connected scenario will result in a better traffic flow and a significant reduction in the queue lengths.

5.1.1 Simulation graphics:

There are a few discrepancies in terms of visualizing a simulation. The first one is the geometry. In our case, if you chose two lanes of inbound for traffic while the outbound is 4 lanes, cars will run into each other and cause a collision. Therefore, vehicle is teleported

(removed) from the simulation. As indicated by the authors, SUMO tends to align the medians of both inbound and outbound roads which causes the problem. They have put the geometry problem into their schedule of to be fixed issues.

In case we want to create an intersection manually, we can align the edges to each other properly in the netedit package available inside SUMO installation folder. We didn’t go through that part as it is time consuming. This problem persists only while creating the

56 intersection out of scratch, it is resolved in maps imported from OpenStreetMap and other programs.

Figure 5-1: Simulation showing vehicles went over each other and reported it as crash. Geometry deficiency in SUMO

In the current scenario, the left-turn vehicles in the farthest lanes are coming into contact with each other which is not a pleasing action for the eyes of the viewer. It is not considered a collision in theory, it is a left turn for the simulation and the paths don’t cross in practice as well. For this thesis, we created four inbound and outbound lanes in all directions and then blocked out two inbound lanes to eliminate the possibilities of collisions.

5.1.2 User interface

Normally, you need to have some coding knowledge to work with SUMO. The good thing is, it supports all major and famous languages such as xml, python, c++, Java. There are some GUIs created in Java and C++ to interact with SUMO simulation engine. There are other software such as NS2, OMNet++ which tracks the devices used in the vehicles.

We worked on a GUI for SUMO so that people with little to no knowledge of coding would be able to simulate some scenarios.

5.2 A GUI Front End

The front end has a picture of an intersection drawn which asks for all the necessary data needed to give to the back-end in order to create the required files for a successful simulation. Currently, we have just created it for one intersection but we will expand it for bigger and various scenarios. Users are able to define the different approaches of traffic flow. They can choose if they want the right-most lane to just have a straight through or a straight with a right turn. Also, they can simply switch off a route they don’t want to use, such as turning off the left turn.

Specifying a length for the roadway is optional. Users can specify the length of the road if they want to, in case nothing is inputted, it will take it as 250m (820 ft.) by default.

Additionally, users need to input the number of vehicles (counts) they want to simulate for all directions in the text boxes provided for the right-turns, straight through, and left-turns.

Figure 5-2: A GUI Front-end created for users to be able to simulate faster.

There is no limitation in terms of the counts, you can just simulate 5 minutes, one hour, or days if you want to. You can choose the type of intersection control from the drop-down box located under the right side of the layout. Currently, the front-end supports signalized intersections and we will add the yield-controlled and stop-controlled variables to it.

The user needs to put the traffic light phases. The program currently supports four phases, so the one should input the time periods for green and amber lights of each phase. You can also choose to make the traffic light actuated. If you choose actuate traffic light from the drop-down box, you will be asked to specify the minimum and maximum durations of green state. It will prolong the green state for vehicles that are detected by the camera so

59 they could be able to cross the intersection safely without any delay. Additionally, you need to enter the radius (distance) you want the camera to detect vehicles on all four directions and all lanes. The distance is computed from the stop line before the intersection.

When all this information is entered, the user needs to click Create Network button so that the program creates the road network. Then the user needs to choose the vehicle types and characteristics such as acceleration, deceleration, length, speed deviation, reaction time and other parameters. When the data is entered the user needs to click on the “create vehicles” button which will create the route file with vehicle definitions and right and left turns or straight through approaches.

Finally, the run simulation button is clicked to see the simulation in a GUI mode.

Back-end operations:

Let’s begin with our Cartesian coordinates. We have chosen the middle of the intersection to be our beginning point i.e., (0.0). There are three important points that goes into the node file. Mainly, node id, coordinates, and traffic control.

The connection file is created from RT, LT, TH signs. The incoming and outgoing lanes and roads are recorded here. Also, the edge file is also written based on this information.

Then, all these three files are put as inputs into the network configuration file to create a network file. Whenever the “Create Network” button is pressed, these three files along with the network configuration file will be created and ran which will output the network file.

After the vehicle information is added and “Create Vehicle Trips” button is clicked, it will generate the route file containing id, type and time of vehicle departures and their chosen routes.

The signal phase timing will be added to an additional traffic light file and will be loaded alongside route and network files when the “Run Simulation” button is pressed. You can choose if you want output csv files for the queue lengths and waiting time and time loss data.

It will give you an information dialog box if any important or needed information is missing. If not, it will go through and create the necessary xml files for nodes, edges, connections, and the network which will be used for simulation.

5.3 Recommendations

Although we will be working on a highway and ramp scenario as well, we just have a few suggestions:

1. It would be a good idea if it is done in Vissim and other similar software simultaneously and the results are compared side by side.

2. It would be better to simulate two or three intersections and then a larger area such as a suburb so that the results can be expandable.

3. One might think of using GLOSA (Green Light Optimizing Signal Advisory) as a fourth case and conclude their results. It means there will be a two-way communication between vehicles and traffic signals. Both extending the green time by the traffic light and reducing its speed when green time reaches its maximum and is going to turn red by the vehicle.

References

Bazilinskyy, P, Kyryakidis, M. & de Winter, J 2015, ‘An international crowdsourcing study into people’s statements on fully automated driving’, Procedia Manufacturing, 3, pp. 2534–2542.

Behrisch M., Bieker L., Erdmann J., and Krajzewicz D. (2011). Institute of Transportation Systems, German Aerospace Center DLR, ‘SUMO – Simulation of Urban MObility: an overview’.

Bullis K. (2011). “How Vehicle Automation Will Cut Fuel Consumption.” MIT Technology Review.

Carlino D., Depinet M., Khandelwal P., and Stone P., (2012). “Approximately Orchestrated Routing and Transportation Analyzer: Large-scale Traffic Simulation for Autonomous Vehicles”

Casley S. V., Jardim A. S., Quartulli A. M. (2013). “A study of Public Acceptance of Autonomous Cars.” Worcester Polytechnic Institute

Cheng P, 2013 Master’s Project Paper: Autonomous Navigation and Collision Avoidance Robot

Clemson University Vehicular Electronics Laboratory. Accessed Mar 2018. https://cecas.clemson.edu/cvel/auto/AuE835_Projects_2011/Vallabhaneni_project.h tml

Connected Vehicle Technology, ITS, USDOT https://www.its.dot.gov/

Connected Vehicle Pilot Deployment Program, ITS USDOT https://www.its.dot.gov/factsheets/pdf/JPO_CVPilot.pdf

Chandra & Camal ICSDEC 2016: A simulation-based evaluation of connected vehicle technology for emissions and fuel consumption. Shailesh Chandra and Francisco Camal. Dept of Civil Engineering and Construction Management, California State University, Long Beach, USA.

Dresner K, Stone P. (2008). “A multi-agent approach to Autonomous Intersection Management.”

Eidehall A., Pohl J., Gustafsson F., and Ekmark J. (2007). “Toward autonomous collision avoidance by steering. Intelligent Transportation Systems”.

Fernandes P. and Nunes U. (2010). “Platooning of autonomous vehicles with intervehicle commu-nications in SUMO traffic simulator. Intelligent Transportation Systems.”

Franke U., Gavrila D., Gorzig S., Lindner F., Puetzold F., and Wohler C. (1998). “Autonomous driving goes downtown. Intelligent Systems and Their Applications.”

GM self-driving safety report. 2018. Accessed Mar 2018. http://www.gm.com/content/dam/gm/en_us/english/selfdriving/gmsafetyreport.pdf

Han L., Do Q., Guo C., and Mita S. (2011). “Optimal motion generation for autonomous vehicle in maze-like environment. Intelligent Transportation Systems.”

Horatiu H. (2010). BMW Remote Controlled Parking. BMW Blog.

Intelligent Car Initiative. Accessed December 2017. https://www.lu.lv/materiali/biblioteka/es/pilnieteksti/transports/i2010.%20Intelligen t%20car.pdf

Kotushevski G, 2010. Thesis titled “Intelligent driver agent model for autonomous navigation in a computer simulated vehicular traffic network.”

Kyriakidis, M, Happee, R & de Winter, JCF 2015, ‘Public opinion on automated driving: Results of an international questionnaire among 5000 respondents’, Transportation Research F, 32, pp.127–140.

MotorTrend. Accessed March 2018. http://www.motortrend.com/news/gm-super-cruise- 2018-cadillac-ct6-with-auto-pilot/

NHTSA Automation Levels https://www.transportation.gov/briefing-room/us- department-transportation-releases-policy-automated-vehicle-development

Nissan Corporate. 2013. Nissan Technology. Accessed Mar 2018 https://www.nissan-global.com/EN/TECHNOLOGY/

Nissan Corporate. Intelligent Pedal. Accessed Mar 2018 https://www.nissan-global.com/EN/TECHNOLOGY/OVERVIEW/dcas.html

Plunkett Research. 2012. Automobiles and Truck Trends. http://www.plunkettresearch.com/trends-analysis/automobiles-hybrid-electric- business-market/

SeminarLink Autonomous Car presentation. Accessed Mar 2018. https://www.slideshare.net/asertseminar/autonomous-car-32512833, www.seminarlinks.blogspot.com

Sommer C, German R, and Dressler F, 2011 Bidirectionally Coupled Network and Road Traffic Simulation for Improved IVC Analysis.

State of California DMV, accessed on Jan 5, 2018. https://www.dmv.ca.gov/portal/dmv/?1dmy&urile=wcm:path:/dmv_content_en/dm v/vehindustry/ol/auton_veh_tester

Sun Y., Olaru D., Smith B., Greaves S., and Collins A. (2017). Road to autonomous vehicles in Australia: an exploratory literature review. theAtlantic, accessed Nov 15,2017: https://www.theatlantic.com/technology/archive/2017/11/life-in-a-driverless- city/545822/

Umich Record, 2016: https://record.umich.edu/articles/ford-u-m-testing-autonomous- cars-snow-mcity

WonderHowTo https://driverless.wonderhowto.com/news/definitive-guide-levels- automation-for-driverless-cars-0176009/. Accessed Mar 2018

Appendix A

Vehicle Automation History

Table A.1: Vehicle Automation Timeline (Chronological)

Photo Technology/Characteristic Manufacturers Radio technology controlled 1925/1926 Houdina by a second car following Radio Control, close behind American Wonder, New York

Image: Jalopnik/wikimedia Depicted radio controlled 1939 Bel Geddes, electric cars that were moving General Motors via electromagnetic fields created by circuits embedded in the road.

Image: Wikipedia

Photo Technology/Characteristic Manufacturers GM showcased a series of 1950-60s General experimental cars having Motors Firebirds electronic guiding system. Firebird II had receivers for detector circuits embedded in roadways Image: gmheritagecenter Experimental detector circuits 1957 RCA Labs, were buried in the roadway Nebraska sent signals to guide the car and determine its presence and velocity.

Image: technicacuriosa.com First car to have cruise 1958 Chrysler control and speeding warning Imperial

Image: imperialclub.com Image: Les Earnest is considered the 1961 Stanford Cart stanford.edu world’s first truly self-driving on the moon wheeled vehicle. Not for passenger use

Photo Technology/Characteristic Manufacturers Followed a track of white 1977 Tsukuba striped lines on the road up to Mechanical 30 km/h. Some call it the first Engineering Lab, true AV for processing Japan power.

Image: computerhistory.org VaMoRs 5-ton van having 1986-1987 two cameras was tested at Universitat der speeds up to 100 km/h. Bundeswehr, PROMETHIUS projects Daimler-Benz a part featured Adaptive Cruise of PROMETHIUS Control technology

Image: media.daimler.com VITA II (Mercedes 500SEL) 1994 VITA II demonstrated with automated PROMETHIUS driving on public roads of project, Europe Paris. Tech: Distronic plus and automatic pre-safe brake

Image: media.daimler.com The vehicle (Mercedes 1995 VaMP 500SEL) drove (almost) PROMETHIUS completely autonomously up project, Europe to speeds of 108 mph and around 100 miles from Munich, Germany to Copenhagen, Denmark Image: web2carz.com

Photo Technology/Characteristic Manufacturers 1990 Pontiac Trans Sport 1995 NavLab 5 used Neural Networks to Carnegie Mellon steer the vehicle from University Pittsburgh to Los Angeles Roboticists with 98.2% autonomy.

Image: wired.com Drones equipped with radars 1995 General and thermal imaging cameras Atomics MQ-1 were used autonomously for Predator 14 hours at a time.

Image: Wired.com ARGO system followed 1996 ARGO, based painted lane markings using on the experiences of vision system, with an PROMETHIUS, average speed of 90 km/h for Project, Uni of 2000 km in June 1998 Parma, Italy

Image: argo.ce.unipr.it Cars, buses and snowplows; 1997 PATH, U of included platooning and Cali-Berkeley forward and reverse course Automated Highway runs; used magnets in System (AHS) Demo roadway with GM and USDOT Image: path.berkley.edu Carnegie Mellon University 2004 DARPA Grand

Red Team "Sandstorm" 7.32 Challenge – Mojave

miles Desert region,

California Image: CMU website

Photo Technology/Characteristic Manufacturers Stanford Racing "Stanley" 2005 DARPA Grand 150 miles in 6 hours 54 Challenge – Mojave minutes Desert region, California

Image: Stanford website Carnegie Mellon University 2007 DARPA Urban Tartan Racing "Boss" 60 Challenge – miles urban, 4 hours 10 Victorville, minutes California

Image: CMU website Delivered pizza across the 2008 Levandowski's San Francisco- Oakland Bay Pribot Bridge, California (Harris 2014)

Image: Google.com Traffic assistance system 2008 GM Opel capable of driving itself on Vectra highway.

Image: GM website Google self-driving car team 2009 Google Prius assembled; LIDAR system as basis for data acquisition - California

Image: Google.com 121-mile hill climb, 156 2010 Audi Pikes turns, 27 minutes Peak, Colorado

Image: Audi website

Photo Technology/Characteristic Manufacturers 50 miles of automated driving 2011 AutoNOMOS on urban public streets in Labs Berlin Drive Berlin, Germany

Image: Google.com 300,000 miles testing on 2012 Google Lexus public roads in California 450h

Image: Google.com Rural-urban demo in real, 2013 Vislab complex traffic, relies on BRAiVE, Uni of

vision system Parma, Italy Image: U of Parma website 60-mile rural-urban 2013 Daimler Bertha demo, vision based from - Benz Road Trip, Mannheim to Pforzheim Germany

Image: Daimler.com Tested truck platooning 2013 Scania (semiautomated) Transport between Sodertalje and Laboratory, Sweden Helsingborg, Sweden

Image: Scania website Electric, low speed vehicle 2014 Induct Navya (12 mph), commercially available

Image: Navya website

Photo Technology/Characteristic Manufacturers Mastering city street driving, 2014 Google Self 700,000 miles, interactions Driving car with cyclists, signals, and construction zones and Neigborhood Electric Vehicle prototype Image: Google.com First licensed automated 2014 Freightliner commercial truck to drive on Inspiration Truck, a U.S. public highway Daimler, Nevada

Image: Daimler website Peloton is developing a 2014 Peloton Truck cloud-based truck operations Platooning by Denso center and participating in and Intel Capital and field trials. other investors

Image: Google.com 100 increasingly automated 2014-2017 Volvo vehicles, toward zero deaths "Drive Me," (2020) Gothenberg, Sweden

Image: Volvo website Freeway driving, onramp 2015 Tesla to off-ramp, vision for 2023 "Autopilot"

Image: Tesla.com Testing automated car 2015 Acura RLX features on roads of the Concord Naval Weapons Station in East Bay area.

Photo Technology/Characteristic Manufacturers Image: Acura website Delphi drove an Audi from 2015 Delphi cross San Francisco to New York, country trip, Audi crossing 15 states and 3,400 miles with 99% autonomy.

Image: Audi Delphi website Uber opens a fake city in 2015 Uber Advanced Pittsburgh for research and Technologies Center development in mapping, vehicle safety and automation technology.

Image: Uber website Cruise AV is a Chevy bolt 2018-2019 GM EV built from ground up partnered with integrating self-driving Cruise Automation software developed by Cruise Automation. Image: GM.com Concept vehicle 2020-2025 Nissan Autonomous Drive Concept vehicle 2025 Mercedes-Benz Future Truck

https://www.wired.com/brandlab/2016/03/a-brief-history-of-autonomous-vehicle- technology/ https://360.here.com/the-timeline-of-automation http://www.computerhistory.org/atchm/where-to-a-history-of-autonomous-vehicles/ http://media.daimler.com/marsMediaSite/en/instance/ko/The-PROMETHEUS-project- launched-in-1986-Pioneering-autonomous-driving.xhtml?oid=13744534

72 https://www.web2carz.com/autos/car-tech/6396/the-vamors-was-the-worlds-first-real- deal-autonomous-car http://www.gm.com/mol/selfdriving.html

Appendix B

Guide on how create a traffic simulation in SUMO

By no means will this document replace the SUMO documentation. This is just a very basic step by step process for the very beginners. Please consult online SUMO wiki/documentation for more.

Some common knowledge about SUMO:

There is a command line version of sumo and a Graphical User Interface version of it is also available which is referred here as sumo-gui. Sumo works in MKS system by default.

Therefore, lengths will be in meters (m), and speed in meters per second (m/s). Hereafter, simulation will refer to traffic simulation.

Terminology

SUMO Command prompt version of SUMO.

Netconvert A package inside sumo used to create road networks readable by

sumo

Polyconvert A package inside sumo used to create polygon objects readable by

sumo

Sumo-gui A graphical user interface version of sumo, used for visualization

OD Trips Trips with an origin and one or many destinations (route)

randomTrips.py A python script used to generate random OD trips

Links for the software:

http://sumo.dlr.de/ executable (installable) and source code (portable) files are

available

SUMO:

 Microscopic simulation - vehicles, pedestrians and public transport are modeled

explicitly

 Online interaction – control the simulation with TraCI (Traffic Control Interface)

 Simulation of multimodal traffic, e.g., vehicles, public transport and pedestrians

 Time schedules of traffic lights can be imported or generated automatically by SUMO

 No artificial limitations in network size and number of simulated vehicles

 Supported import formats: OpenStreetMap, VISUM, VISSIM, NavTeq

 SUMO is implemented in C++ and uses only portable libraries (Python used for

manipulation)

Main SUMO Files:

Node files (.nod.xml) Edge files (.edg.xml)

Edge Type files (.typ.xml) Network configuration file (.netc.cfg)

Network files (.net.xml) route files (.rou.xml)

SUMO configuration files (.sumo.cfg); This file is used for running the simulation

There are different ways to create a simulation:

The basic principle for all the methods is:

Create a road network, a vehicle route files, and then use them for simulation.

Configuration files are used to create desired outputs from the given inputs.

Ways of creating a fully functional simulation:

There are usually two ways of creating a simulation. One way is to use a ready-made

map from OpenStreetMap project or import a map from another simulation software. The

other way is to create everything from scratch. Here, we will explain how to create

simulations with both approaches.

Using a map (OpenStreetMap)

I. In this approach, we first zoom in to the extents of our study area in the OpenStreetMap.org

and export it to an osm file such as, map.osm. We then create a road network file from this

map file using a SUMO internal package “Netconvert” as in the following code written in

the command prompt. Here, we named the output network file as “map.net.xml”.

Netconvert --osm-files map.osm -o map.net.xml

II. [optional] If we want to have some geographical elements such as, buildings, rivers, and

other polygons in the map. The “Polyconvert” add-in will extract the polygons from the

OSM map file and create an output of polygons which we name as “map.poly.xml”. The

polygons are created according to the various styles and shapes designated in the

typemap.xml file. The typemap file contents are put at the end of the document.

Polyconvert --net-file map.net.xml --osm-files map.osm --type-file typemap.xml -o

map.poly.xml

III. To create OD trips and specify the number of cars or let the simulation engine generate

random number of cars and trips we use the randomTrips python script. The python script

is located at the SUMO installation folder. To do that, we will use the road network that

was created in the step one as the infrastructure for creating the many OD trips and routes

for vehicles to flow on. If we want to specify the number of vehicles that will go around

random trips in the network, we need to write it in the “-e NoOfVehs -l”. Here, we are

naming the output route file as “map.rou.xml”.

python "C:\Program Files (x86)\DLR\Sumo\tools\randomTrips.py" -n map.net.xml

-r map.rou.xml -e 1000 –l

IV. Finally, we will use the network file from step I and the route file from step III and any

additional files like the polygon as inputs in the SUMO configuration file and visualize the

simulation using the SUMO-GUI version. The contents of the sumo configuration file is

scribed at the end of the document.

Sumo-gui -c new.sumo.cfg

Creating a simulation from scratch

A. Creating everything from a scratch; Manual writing (or using MOVE.jar)

In this approach, we need to create the nodes and junctions, edges (road strips), connections

(which road strip connects with which one), traffic flow (going from east to west, west to

east, north to south, and vice versa), and turns (right or left turn from one road strip to

77 another). After creating these files, we will generate road network and route files from them to run the simulation.

We can create these files using the MOVE java file which has a ready-made format or create the files on our own in a text editor. To proceed with this way, we need to sketch the intersection/s on a paper and name the corners (nodes) and specify their locations in X-Y coordinate system. We will start creating our files from here. Let’s suppose we want to create the network in sketched in the Image below. Here, we have chosen node zero as the origin for the cartesian.

First, the node file (nod.xml). Each node has it has four main characteristics namely node id, horizontal and vertical location, and whether it has a traffic light or not. The following code is written for the nodes to be created.

Then, we create the edges from nodes. Edge file has the following properties:

Edge name (id), where does the edge start from, where the edge ends (to), number of lanes, and default speed in m/s. A sample of the file is shown below.

Next, we create the network file from the node and edge files we created in the first and second step and name the output network file as new.net.xml. This process can be done in a single line of code in command prompt and a configuration file (netc.cfg), as the following, can be used too.

Netconvert -c new.netc.cfg

The network file generated will have information about all the edges, traffic light logic

(phases and duration), junction properties, and edge connections i.e., which edge/lane is connected to which edge/lane. A few sample lines of the network file are shown here:

After that, we create the traffic flow file. The main characteristics of flow are flow id, which edge it starts from, to which edge it goes, when does it start (milliseconds), at what time this flow ends (milliseconds), and how many vehicles flow in this specific route. The sample is shown below.

Then, we create the turn file which will have the information of how much traffic will turn from which edge to what edge and from what time till when.

Next, we generate the route file. Route file is the output of network, flow, and turn files together. We can get the output through creating a configuration file (rouc.cfg) like the following and running simple command line code on it.

Jtrrouter -c new.rouc.cfg

A sample of the output route file is shown below:

The last configuration file named sumo configuration file is then used to generate a visual simulation form the network and route files. It looks like the following:

Here, you can add a few lines of code to get the outputs such as queue-output The simulation starts with the following command.

Sumo-gui -c new.sumo.cfg

Creating a network file and route file for an intersection

Here, we will sketch a single intersection with 2-lanes. In this method, we would like to control as many parameters as we can. We will have control over the total number of cars present in the network, number of vehicles making a right turn, specify the number of vehicles making a left turn, and the number of vehicles going straight through in all bounds.

As we start everything from scratch, we will write the node file first. A sample is shown below.

Then, we need to specify the edges and lanes. As we want to specify how many vehicles should go straight or make turns, we need to tell the software the origin and the destination.

Therefore, we name the roads a little bit different. Each road strip will be divided into inbound and outbound and will have an “i” or “o” with them. The sample below shows that clearly.

After that, as an additional file, we can use the road type file. As you see in the edge file, there is a type characteristic, these are explained by the type file. A sample is shown below.

Next, we write a connection file. Connection file is used to specify which lane of which edge connects to which lane and edge. It, sort of, determines the turns and throughs. The sample is as follows.

Now, we take these four files as an input for creating our network file. We can do it through a configuration file and a simple line of code in command prompt. It is the same file as we used in the previous method. The sample is shown below.

netconvert -c cross.netccfg

The network file is created which includes the same properties of edges, types, junctions, traffic lights, and connections that were created as an output in the previous method.

The difference between the previous method and this method is that we want to control the simulation and movement of the vehicles. Therefore, we use a custom-made python script in which we specify all the characteristics we want to have in the route file so that the traffic moves according to our will. The code is shown in parts below.

In this first snapshot, the packages and libraries needed for python to work with sumo are imported.

In this part, we define the generate_routefile function which will include almost everything after this. The green text is the comments we put near each line of code. The pLL route designation refers to the probability of the cars whose initial direction is left (coming from east) and go left (west). The pLU would mean that the vehicle direction is left (coming from east) and will go up (north).

In this portion of the code, it creates a route file and writes four vehicle types into it. We have specified four types of vehicles with different acceleration, deceleration, length, minimum gap, maximum speed, and graphical shapes.

In addition, we name the routes in our own words. In this cross section, 1 is the designation used for the left leg of the intersection (west), 2 is the right leg (east), 3 is the downward leg (south), and 4 is the upper leg (north). To explain one of the routes, East-West, the code

“2i 1o” means that vehicles come from the East Bound (right leg) and goes to the West

(left leg). Here, i refers to input and o refers to output, or incoming and outgoing.

In this part, we want to use the last vehicle to generate different random vehicle types which gets its value randomly from the loop in the range of N. Additionally, vehicle number will give each vehicle/vehicle type a continuous or ordinal number. Furthermore, a random number is generated between zero and one and is compared with the probability of each route, defined above, and a vehicle type is generated. We write the same code for all the routes.

This part of the code is run at the command prompt and will give us the output, not an essential part of the file. It shows the real percentage of the vehicles for each route.

This print line is the last line of the generate_routefile function. The last if function will run the generate_routefile function and generate the route file. To run the python script, we write the following code in the command prompt.

python routes_Gen.py

The route file will look like this.

The final step for running the simulation is using the sumo configuration file. The same procedure as explained in the method explained before.

sumo-gui -c cross.sumo.cfg

The simulation will look like the following:

Thank you,

Tariq Rahim

Appendix C

Files used in this thesis

Node file (.nod.xml)

Connection file (.con.xml)

Edge file (.edg.xml)

Network Configuration file (.netccfg)

Python file for trip (route) generation (.py) import os, sys, socket, time, struct import optparse import subprocess import random if "SUMO_HOME" in os.environ: sys.path.append(os.path.join(os.environ["SUMO_HOME"], "tools")) sys.path.append(os.path.join(os.path.dirname(sys.argv[0]), "..", "tools")) import traci PORT = 8813 def generate_routefile(): random.seed(100) # make tests reproducible # vehCounts per hour from each direction # route naming is From To such as EW would mean coming from East and going West PHF = 0.95 cEW = 5830.0 / PHF cEN = 2750.0 / PHF cES = 2920.0 / PHF cWE = 5320.0 / PHF cWN = 4510.0 / PHF

cWS = 2370.0 / PHF cNS = 5320.0 / PHF cNW = 2170.0 / PHF cNE = 3110.0 / PHF cSN = 6130.0 / PHF cSW = 2840.0 / PHF cSE = 1430.0 / PHF TotalCounts = cEW+cEN+cES+cWE+cWN+cWS+cNS+cNW+cNE+cSN+cSW+cSE # demand of a single vehicle per second from different directions # These percent probabilities are calculated as follows: # pEW = cEW / Total counts pEW = cEW / TotalCounts # 0.175675676 pEN = cEN / TotalCounts # 0.056306306 pES = cES / TotalCounts # 0.027027027 pWE = cWE / TotalCounts # 0.18018018 pWN = cWN / TotalCounts # 0.045045045 pWS = cWS / TotalCounts # 0.04954955 pNS = cNS / TotalCounts # 0.157657658 pNW = cNW / TotalCounts # 0.058558559 pNE = cNE / TotalCounts # 0.022522523 pSN = cSN / TotalCounts # 0.155405405 pSW = cSW / TotalCounts # 0.027027027 pSE = cSE / TotalCounts # 0.045045045

# Truck Percentages for each direction pTEW = 0.015 pTEN = 0.015 pTES = 0.015

pTWE = 0.015 pTWN = 0.015 pTWS = 0.015 pTNS = 0.015 pTNW = 0.015 pTNE = 0.015 pTSN = 0.015 pTSW = 0.015 pTSE = 0.015

vehCounts = [cEW, cEN, cES, cWE, cWN, cWS, cNS, cNW, cNE, cSN, cSW, cSE] routeNames = ["EW", "EN", "ES", "WE", "WN", "WS", "NS", "NW", "NE", "SN", "SW", "SE"] probabilities = [pEW, pEN, pES, pWE, pWN, pWS, pNS, pNW, pNE, pSN, pSW, pSE] TruckProbabilities = [pTEW, pTEN, pTES, pTWE, pTWN, pTWS, pTNS, pTNW, pTNE, pTSN, pTSW, pTSE]

with open("practice10.rou.xml", "w") as routes: print >> routes, """

""" lastVeh = 0 vehNr = 0 i=0 j=0 deptime=0

while (i < TotalCounts): timestep = 36000/TotalCounts deptime = deptime + timestep approach = random.uniform(0,1) VehType = random.uniform(0,1) if approach < pEW: if VehType < pTEW: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime)

vehNr += 1 if approach < pEW+pEN and approach>pEW: if VehType < pTEN: print >> routes, ' ' % (vehNr, deptime) vehNr += 1

else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 if approach < pEW+pEN+pES and approach>pEW+pEN: if VehType < pTES: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 if approach < pEW+pEN+pES+pWE and approach>pEW+pEN+pES: if VehType < pTWE: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1

if approach < pEW+pEN+pES+pWE+pWN and approach>pEW+pEN+pES+pWE: if VehType < pTWN: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 if approach < pEW+pEN+pES+pWE+pWN+pWS and approach>pEW+pEN+pES+pWE+pWN: if VehType < pTWS: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 if approach < pEW+pEN+pES+pWE+pWN+pWS+pNS and approach>pEW+pEN+pES+pWE+pWN+pWS: if VehType < pTNS: print >> routes, ' ' % (vehNr, deptime) vehNr += 1

else: print >> routes, ' ' % (vehNr, deptime)

vehNr += 1 if approach < pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW and approach>pEW+pEN+pES+pWE+pWN+pWS+pNS: if VehType < pTNW: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 if approach < pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW+pNE and approach>pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW: if VehType < pTNE: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 if approach < pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW+pNE+pSN and approach>pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW+pNE: if VehType < pTSN: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else:

print >> routes, ' ' % (vehNr, deptime) vehNr += 1 if approach < pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW+pNE+pSN+pSW and approach>pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW+pNE+pSN: if VehType < pTSW: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 if approach < pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW+pNE+pSN+pSW+pSE and approach>pEW+pEN+pES+pWE+pWN+pWS+pNS+pNW+pNE+pSN+pSW: if VehType < pTSE: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 else: print >> routes, ' ' % (vehNr, deptime) vehNr += 1 print(i) i=i+1 print ("pEW: %f, pEN: %f, pES: %f, pWE: %f, pWN: %f, pWS: %f, pNS: %f, pNW: %f, pNE: %f, pSN: %f, pSW: %f, pSE: %f")\ %(pEW, pEN, pES, pWE, pWN, pWS, pNS, pNW, pNE, pSN, pSW, pSE)

# (pEW 0.17, pEN 0.066, pES 0.033) print(TotalCounts, cEW, cEN, cES, cWE, cWN, cWS, cNS, cNW, cNE, cSN, cSW, cSE) print (approach, VehType) # 0.618120 print >> routes, "" # this is the main entry point of this script if __name__ == "__main__": generate_routefile()

Route file (.rou.xml), python output

100

SUMO Configuration file (.sumocfg), used for running the simulation and getting an output

101

Traffic Light Logic (Tls.add.xml) additional file

102