PRE2016 1 Groep2

Updating the Current Intersection System to be Compatible with Autonomous Vehicles.

---

Group members

• Lisanne van Wincoop (0849855)
• Jeroen van Dongen (0889788)
• Sjoerd Westendorp (0864518)
• Rodger van der Heijden (0851985)
• Johan Hendriks (0824890)

Introduction

On day 1 our idea for a project was to build a small robot that could teach itself to walk by using self learning AI. This idea was quickly abandoned when it was brought to our attention that these already exist. We were also unable to combine lots of USE aspects with the idea.

The next idea was investigate algorithms of intersections with only autonomous vehicles and to build a simulation of it. We could compare different algorithms and decide in which was best in certain situations. The problem was that it didn't contribute to real world scenarios because lots of algorithms used unrealistic assumptions, including: all traffic must be autonomous and there is no packet-loss in communication between car and intersection,

After receiving feedback on our second idea, we had a long discussion with Mr. Borghuis. To address all the points in the criticism received: unrealistic assumptions, no contribution, little USE, why 100% autonomous cars. We came up with an idea to update current intersection systems to encorporate autonomous vehicles. The project idea allows a realistic intermediate solution in the process only allowing autonomous cars in traffic.

Focus

Our main focus area concerns: Automated traffic regulation (ATR).

Narrow that down is our specific focus: Updating the Current Intersection System to be Compatible with Autonomous Vehicles (Vehicle Intersection Control).

Restrictions on the focus area:

• Crossing has 4 directions.
• Traffic is randomly generated, the ratio between autonomous and normal cars will be changeable.

A multitude of traffic accidents happen at intersections^{citation needed}. These are also the bottlenecks in terms of efficiency since human drivers have varying reaction times. Drivers can also get stressed behind the wheel and lose valuable time while commuting. Contemporary intersection could make traffic more efficient by utilizing data from sensors of autonomous cars and controlling autonomous cars passing the intersection. By making the intersections smarter, user comfort can be greatly increased. Also society will benefit from more efficient driving past intersections, since emissions can be greatly reduced, which benefits the environment. Enterprises will also be positively influenced, since people will be able to get to work quicker instead of being stuck at an intersection.

Objectives

Main objective:

• Optimizing traffic flow at intersections by making them compatible with autonomous vehicles.

Objectives:

• Using sensor data from autonomous cars to make traffic light algorithms more aware of current traffic
• Choose a suitable communication protocol between autonomous cars and the intersection.
• Find existing efficient algorithms for autonomous cars at intersection in a literary review.
• Combine said algorithm with current traffic light algorithms to optimize traffic flow of both normal and autonomous cars.
• Make sure the traffic flow is optimal, which results in less waiting time and less emission.
• Create a transition solution that can combine the use of autonomous cars with human drivers by using the current intersection system.
• Keep in mind the perception of safety and the actual safety of passengers inside the autonomous cars.
• Decrease the number of traffic accidents involving cars on crossings.

Approach

The approach that is chosen is research and simulation oriented. Most information on existing solutions must come from literature and ongoing research. By identifying the state of the art, we will try to combine traffic light algorithms with algorithms that only work with 100% autonomous cars at the intersection. When such combination has been made, a simulation will be created and tested, after which an evaluation will follow.

Literature review

Intersection algorithms now

Alles 100% normaal verkeer Kruispunten nu

Sensor and communicationsystems of autonomous cars

Sensoren en communicatiemogelijkheden van autonome auto's van nu

Existing communication systems in traffic

Communcatie systemen (bussen/ambulances) nu met kruispunten

USE Aspects

Initially, some choices have to be made regarding the consideration of the USE-aspects in order to start designing the algorithm and communication protocol. Here, the aspects regarding the initial choices will be discussed.

Keeping in mind the initial estimated market share of autonomous cars

This is a USE-aspect from a society point of view. The crossing that is to be design should be compatible with the transition period after the introduction of autonomous cars on the market. In the beginning, the market-share of the autonomous cars will be relatively low compared to cars with human drivers. However, when the autonomous vehicles have been on the market for some time, the expectation is that the market-share will increase as society becomes more used to the presence of autonomous cars on the road. This means that the intersection should be usable for a minority as well as a majority of autonomous cars. [1]

In the design and the simulation the influence of this USE-aspect will be shown by a graph of the throughput of the crossing versus the percentage of autonomous cars on the crossing. The throughput is measured by the mean time that the cars spend on the crossing.'

As the percentage of autonomous cars on the crossing increase, this will impact the traffic situation. Human drivers might become a minority if the launch of autonomous cars is a success. This gives way for more advanced behavior from the autonomous vehicles. An example of this could be that when there are multiple autonomous cars subsequently nearing the crossing, they could use platooning to cross the intersection more efficiently. However, this is a hypothetical theory about the efficiency of autonomous cars that might be outside the scope of this research.

Viewing autonomous cars as lounge cars that adjust driving behavior to perfect timing and comfort

In the future, a plan for the autonomous cars is that they function as lounge cars for people to order to come and pick them up with the assignment to take them to the right destination at a certain arrival time. This image is envisioned by for example the CEO of Tesla, Elon Musk and the CEO of the taxi service Uber Travis Kalanick. [2]

However, it might be a more distant future image than is aimed for with this research. As previously mentioned, the full potential of this service might be reachable when the market-share of autonomous vehicles is increasing. Realizing a perfect solution for this aspect of autonomous driving when utilizing existing technology might therefore be outside the scope of this research.

Safety systems in communication between autonomous cars and the intersection

One of the keys to the customer acceptance of autonomous vehicles is decreasing the risk of hacking. Without means to stop this, customer acceptance will never be optimal. [2] However, the way to stop this lies in complicated software which would be a project alone to construct. It is possible however, to keep in mind the possibility of communication failure between the car and the crossing.

The risk of hacking however, is present in many modern technological applications. Personal computers are very sensitive to hacking and yet the majority of society has accepted the risk. A more recent example is the introduction of drones that are used in the airforce or modern surveillance technology. Although these technologies lead to many controversial debates, there is a large number of people who endorse the use of these systems.

In [3] it is argued that modern society itself is a “risk culture”. Society is constantly searching for new energy sources and technological advancement that can drive the earth forward. People are getting used to putting their trust in new systems since new technologies are increasingly being introduced into their lives. Risk nowadays also varies between social groups and cultures. This indicates that some groups will be more risk-taking than others and also that autonomous vehicles have a good chance of being accepted by the group that is most risk-taking and then gradually accepted by other cultures that are more apprehensive, despite the fact that the technology carries with it the risk of hacking. [3] This paints a more nuanced picture of the implementation of new technology into society, which many business and market studies do not consider.

Maximising the throughput while keeping in mind the safety of the users

When human drivers are passing the intersection, it will not feel safe to them if autonomous cars start planning ideal trajectories around them and overtake them on the right side of the road or cross right in front of their bumper because the autonomous car calculated that this would be possible. This is very risky since human drivers are easily scared and can react unpredictably and cause unavoidable collisions. When this occurs, another problem arises: how to collide as ethically correct as possible… Even if it might not be as efficient, autonomous cars will need to keep a certain distance to human drivers in mind.

However, one of the main advantages of autonomous driving is the predicted increased efficiency as well as safety. This indicates that a tradeoff has to be made between the efficiency of the autonomous cars and the safety and the perceived safety of the human drivers, in other words an optimization problem.

In the case of the perceived safety of human drivers, this is influenced by the way in which the autonomous cars plan their trajectory. If they plan their trajectories more aggressively (for example overtaking on the right), this will increase the discomfort of the human drivers. This aggression can be simulated by increasing or decreasing the constraints bound to the freedom of trajectory planning for the autonomous cars. What is less obvious is how to measure the level of discomfort of the human drivers, without the pitfall of resorting to simplified if-then reactions.

Efficiency or throughput however, is more easy to measure. For this, the mean time cars spend on a normal, autonomous car free crossing can be used. If after implementation of the new crossing this mean time decreases, the efficiency has increased.

The environmental factor

Society is involved in heavy environmental debate in which traffic plays an important role. The implementation of autonomous cars and taxi services, should decrease the CO2 -emission by their increased traffic efficiency. This means that if the throughput of the intersections is increased, society will benefit in environmental terms.

By using the mean carbon footprint of cars, the emission on the crossing can be measured. This will be an additional result to the optimization problem introduced above.

Conclusion

The market-share of autonomous cars will change rapidly in the transition period, which is the setting of this research. Therefore, it is important to consider the influence of this change when designing the intersection.

Focus is kept on the begin phase of the introduction of autonomous cars, which means that considering fully operational autonomous taxi services is outside the scope of this research.

The implementation of safety systems is an important factor in the introduction of autonomous vehicles. Even though the design of such software is subject matter for future work, in this design problem communication failure and the consequences of this can be considered.

An optimization problem is introduced when considering the (perceived) safety of human drivers and the efficiency of the intersection. The latter can be measured and identified, while the human factor of perceived safety leads to reactions that are more complicated to consider, without resorting to unrealistic simplifications.

Sources --> Weet niet goed hoe ik moet refereren in wiki dus heb ze even hier neergezet [1] Unknown. (2015, 08 18). Forecasts. Retrieved from Driverless-future: http://www.driverless-future.com/?page_id=384

[2] Intelligence, M. (2016). Autonomous/Driverless Cars – Market Potential Estimation and Possible Competitive Landscape – Forecasts, Trends and Analysis (2016 - 2021). Retrieved from Mordorintelligence: http://www.mordorintelligence.com/industry-reports/autonomous-driverless-cars-market-potential-estimation?gclid=CJmT0Me6oM8CFYu6GwodhhABbw [3] Flynn R., Bellaby P. (2007). Risk and the Public Acceptance of New Technologies. New York: Pelgrave Macmillan.

Future

-->

Simulation

Here details and progress of the simulation will be kept up-to-date.

Junction Explanation

A common four way intersection with 2 turn lanes at each side, one for going right, one for going left and straight. Originally the intersection had no turn lanes, but this form of intersection is too uncommon to be representative of the general case. Besides this, an intersection with no turn lanes on any side could very easily be improved by allowing right turn on red for autonomous cars in some cases, but this is a trivial improvement to a simple scenario.

The intersection represents a common traffic light crossing between two one-lane roads. Besides this there is also a simulation of pedestrians, however there is no simulation of cyclists. No simulation of cyclist is needed as, from the intersection point of view, they do not behave differently enough from pedestrians to make a difference for our algorithm, as the roads can just have cycling lanes instead of sidewalks.

Code Explanation

The simulation is created in Java using NetBeans IDE.

Renderer To display things on the screen Java's Swing. This is a relatively simple graphics library, however it has many limitations. One such limitation is its timer function, which had a hard time to trigger 60 times per second even at low computational loads. As such the generic Java Utility class Timer was used to reach the targeted 60 FPS. In reality since the timer uses a target 16 ms delay between frames, the real amount of a frames is slightly higher than that.

The Renderer class is used to obscure the inner workings of the graphical part from the algorithm. The advantage here is that the functioning of the algorithm is independent to the functioning of the graphical code. This means that changes to the graphical section will not change the behaviour of the algorithm and vice versa.

The Renderer class contains a JFrame, which is the window displayed on screen, and the JPanel. This JPanel is actually the RenderWorld class, which extends the JPanel with the features needed for this simulation, like the sliders. The RenderWorld class also implements key and mouse listeners, allowing for user input.

The Main class

From Main.java, other source files will be uploaded later.

Current frontend view

package use_trafficintersection.algorithm;
import java.awt.Color;
import use_trafficintersection.*;

/*
From here the algorithm and the Renderer interface
The renderer controls the program and calls three functions of Main
- The constructor, allowing the algorithm the setitself up.
- Loop, where the algorithm does its job.
- Draw, where the renderer gets told where the cars are and what else to draw.

BTW: The renderer loves uneven numbers. 
Almost everything gets displayed better if their size is uneven.
*/

public class Main {
    // Renderer
    public static Renderer renderer;
    
    // Debug value that get displayed by the renderer
    public int debugInt = Renderer.DEBUG_INT_NOSHOW;
    public String debug = "";
    
    // ------------------------------------
    
    public Main(Renderer r){
	// Place a reference to renderer into main class.
	// We are going to need this to draw things on screen.
	renderer = r;
	/*
	    Setup algorithm function
	    Do not use renderer or anything graphical inside this function
	*/
	
	debug = "WORLD AND CAR RENDERING TEST";
	debugInt = 0;
    }
    
    public void loop(){
	/*
	    Have the algorithm calculate and simulate the next step
	*/
	debugInt++;
	if(debugInt > Renderer.WORLD_SIZE/2 + 50)
	    debugInt = - Renderer.WORLD_SIZE/2 - 50;
    }
    
    public void draw(){
	/*
	    Draw the vehicles
	    - Drawing the world already has been done
	    - Drawing the top bar will be done after this
	*/
	
	renderer.drawCar(-Renderer.LANE_OFFSET,0+debugInt,Renderer.CAR_MAX_WIDTH,30,Color.RED,0);
	renderer.drawCar(Renderer.LANE_OFFSET,0+debugInt,Renderer.CAR_MAX_WIDTH,30,Color.BLUE,0);
	
	renderer.drawCar(5*Renderer.LANE_OFFSET,0,Renderer.CAR_MAX_WIDTH,30,Color.GREEN,debugInt/27.0f);
	renderer.drawCar(10*Renderer.LANE_OFFSET,0,Renderer.CAR_MAX_WIDTH,30,Color.WHITE,debugInt/9.0f);
    }
}

Sources and References

Sources

• A Multiagent Approach to Autonomous Intersection Management.
• Decoupled Cooperative Trajectory Optimization for Connected Highly Automated Vehicles at Urban Intersections.
• A review on agent-based technology for traffic and transportation.
• Microsimulation analysis of automated vehicles on multiple merge junction highways
• A Review of the Applications of Agent Technology in Traffic and Transportation Systems

Collaboration

Milestones

• Literature review
  • Current intersection systems;
  • Sensor and communication abilities of current autonomous vehicles;
  • Communication systems that are already present in current intersections (busses and ambulances have the ability to control the traffic lights to a limited extent)

• Coupling between intersection and the autonomous car

• Simulation
  • Algorithm (backend)
  • Visualisation (frontend)
  • Test

• USE aspects (to be considered with every decision that will be made). The considerations of the USE will be discussed throughout the report and delivered in an evaluation chapter at the end of the report.

• Evaluation of Simulation
  • Wiki
  • Presentation
  • Final simulation

Planning

The planning has been divided in three phases that categorize the main elements of the project. During the startup phase, the goal is to create a good basis for the project by doing a literature review and make a (global) plan that can be a guideline for finalizing the project.

In the chart, the specific activities that belong to each phase have been listed. The green cells indicate when these activities will take place.

The USE aspects have not been mentioned specifically, since this is an integral element of the research and will have to be considered and reviewed every step of the way.

Task division

The tasks divided per week are an indication of the work that needs to be done by all the group members. The reserved hours for each task are mentioned in the schedule below.

Sjoerd

• Week 2:
  • Brainstorming on subject an milestones. (5 hours)
  • Work on simulation (8 hours)
  • Researching: sensors and communicationsystems of autonomous cars. (7 hours).
• Week 3:
  • Brainstorming on subject an milestones. (5 hours)
  • Continue startup work on the simulation. (6 hours)
  • Start on algorithm (the whole group is involved in this weeks decisions on the algorithm). (10 hours)
• Week 4:
  • Finalize frontend of simulation. (6 hours)
  • Start working on backend of simulation. (6 hours)
  • Finalize report on sensors and communication systems. (4 hours)
• Week 5:
  • Work on backend of simulation (15 hours)
• Week 6:
  • Finalize backend of simulation (15 hours)
  • Visualize results of simulation. (3 hours)
• Week 7:
  • Tweaking and evaluation backend algorithm. (10 hours)

Johan

• Week 2:
  • Brainstorming on subject an milestones. (7 hours)
  • Researching: Existing communication systems in traffic.(9 hours)
• Week 3:
  • Final literature review (if still necessary after the work in week 2). (5 hours)
  • Start on algorithm (the whole group is involved in this weeks decisions on the algorithm). (7 hours)
  • Reporting on Existing communication systems in trafic. (6 hours)
• Week 4:
  • Finalize frontend of simulation (12 hours)
• Week 5:
  • Work on backend of simulation (15 hours)
• Week 6:
  • Use literary review to adjust backend if neccesary. (10 hours)
• Week 7:
  • Tweaking and evaluation backend algorithm. (10 hours)

Jeroen

• Week 2:
  • Brainstorming on subject an milestones. (5 hours)
  • Managing wiki. (2 hours)
  • Work on planning. (4 hours)
  • Evaluation of Simulation. (9 hours)
• Week 3:
  • Finalize literature review (if still necessary after the work in week 2). (6 hours)
  • Start on algorithm (the whole group is involved in this weeks decisions on the algorithm). (4 hours)
  • Keep Wiki page updated. (4 hours)
• Week 4:
  • Keep Wiki page updated. (4 hours)
  • Combine all the literary review results in a comprehending summary. (12 hours)
• Week 5:
  • Keep Wiki page updated. (4 hours)
  • Help tweaking simulation. (8 hours)
• Week 6:
  • Keep Wiki page updated. (4 hours)
  • Evaluate USE aspects of the algorithm and simulation. (4 hours)
• Week 7:
  • Final editing on Wiki page. (15 hours)
  • Evaluate results simulation (3 hours)

Rodger

• Week 2:
  • Brainstorming on subject an milestones. (5 hours)
  • Researching: Intersection algorithms now. (10 hours)
• Week 3:
  • Final literature review (if still necessary after the work in week 2) (4 hours)
  • Start on algorithm (the whole group is involved in this weeks decisions on the algorithm). (4 hours)
  • Evaluate USE aspects of the algorithm. (4 hours)
• Week 4:
  • Report on Intersection algorithms now. (8 hours)
• Week 5:
  • Evaluate frontend of simulation, adjust GUI. (8 hours)
• Week 6:
  • Evaluate USE aspects of the algorithm and simulation. (4 hours)
• Week 7:
  • Review the results of simulation and write report on it. (10 hours)

Lisanne

• Week 2:
  • Brainstorming on subject an milestones. (5 hours)
  • Work on presentation and planning. (8 hours)
• Week 3:
  • Giving presentation. (1 hour)
  • Final literature review (if still necessary after the work in week 2) (4 hours)
  • Start on algorithm (the whole group is involved in this weeks decisions on the algorithm). (4 hours)
  • Evaluate USE aspects of the algorithm. (4 hours)
• Week 4:
  • Combine all the literary review results in a comprehending summary. (12 hours)
• Week 5:
  • Evaluate frontend of simulation, adjust GUI. (8 hours)
  • Help with managing wiki. (3 hours)
• Week 6:
  • Preview the results of simulation and write report on it. (10 hours)
  • Help with managing wiki. (3 hours)
• Week 7:
  • Evaluate USE aspects of the algorithm and simulation. (4 hours)
  • Help with final editing of Wiki page. (8 hours)

Meetings and weekly planning

A record of all held meetings can be found here.