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

article needs more references

There are multiple technologies possible for detecting cars; lasers, rubber hoses filled with air, but most commonly inductive loops. These loops work by detecting a change of inductance; the metal body of a waiting car changes the inductance. Around the world different algorithms are used in traffic light timings.

Fixed time control

The most basic model. There are 3 groups of traffic; three different modes, being:

1. The main road
2. The road that crosses it
3. Pedestrians

Without checking anything, the lights just cycle through these possibilities. There aren’t any sensors required, only the actuators. It is possible to allocate different time periods to the three cycles, for instance keeping the light on a busy source road green for a longer period of time. Usually the intervals are about 30 seconds, but this depends on the region.

By making use of the sensors in pedestrian traffic lights, a small optimization can be used.

if (pedestrian_button == pushed) {
	cycle through three modes }
else {
	cycle through mode #1 and #2 }

These methods can be of use in populated areas, where there (most likely) are cars waiting anyway to detection does not offer any benefit. Not using sensors for the cars makes these intersections cheaper and more fault-proof.

Vehicle Actuation

Only useful when one road has way more traffic than the road crossing it. Basically it’s green for the main road, until a car is detected on the side road.

while (!car detected from side road) {
	green light on main road }
else {
	green light on side road }

Urban Traffic Control

A quite sophisticated system that is centrally controlled. The intervals can be altered in real-time. This is useful if there happens to be for example a concert ending, causing a sudden influx of traffic from one way. Or, during peak hours, increase the time intervals of all directions, to reduce the lost time during transitions. Additionally it is possible to create a “groene golf” by linking sites together. This system is used in, among others, London, New York (7660 intersections out of 12460) and 83% of Toronto intersections (15% using SCOOT).

Split Cycle Offset Optimisation Technique

This technique uses detectors away from the intersection, say 50 to 200 meter, which makes it possible to know what traffic is approaching the intersection before it is actually waiting. Apparently the alterations to the UTC are rather small timewise, but efficiency-wise they can make a big difference.

Interesting find: Ingolstadt, German city (audi) which uses intelligent traffic light system. Via special equipment the vehicles communicate with the traffic lights. These lights send, for instance, the time until the next color change, allowing the vehicle to adjust their speed, even automatically when adaptive cruise control is present. Or, when already waiting for a red light, the traffic light can communicate the waiting time. As far as I can tell, it does not affect the time intervals on the traffic lights themselves.

Sensor and communicationsystems of autonomous cars

article needs more text and communications part

Following is a list of sensors and their properties, advantages and disadvantages.

Sensors

Sensor goals:

1. Know where you are going
2. See where you are going
3. Get where you are going

Lidar: (Tesla does not have it, only uses camera/radar/sonar)

• Cannot detect lanes
• Cannot detect Traffic signs/lights
• Can detect humans
• Very high cost
• Lots of data
• Easier for algorithms to manipulate data
• 360 view

Radar:

• Cannot detect lanes
• Good at detecting motion
• Cannot detect traffic signs/lights
• Poor detection of pedestrians
• Cheap
• Even less data than camera
• Cannot detect standing objects
• Long range: Long range radar is a 20 degree arc out to 174m (~570 ft) updated every 50ms and handling object speeds from -100 m/s to +25 m/s (~220mph closure to ~55 mph separation,) medium range is a 90 degree arc out to 60m (~200ft) updated every 50 ms and handling object speeds from -100 m/s to +25 m/s.

Camera:

• Cheapest
• Lots of data, albeit less than lidar
• Can detect lanes
• Can detect traffic signs/lights
• Can detect humans
• Needs advanced algorithms (deep learning) to correctly understand images
• Needs more cameras to get 360 view

GPS:

• Only send information about location
• Cheap
• Needs a clear view of the sky

Ultrasonic/sonar:

• Sensitive to smoke and dirt
• Very short range (max 5m)
• Very wide range
• Small devices
• Needs more devices for 360 view (12 sensors in Tesla)

Odometer:

• Velocity from shaft encoders/gps
• Steering angle from wheels angle sensors

Questions regarding the project

A few important questions arise that are in need of answering for the project.

1. Different cars will have different sensors, how will it be made compatible?
2. Which sensordata is important for the intersection to acquire?
3. Where will the interpretation of data be done? (Lidar is a lot of data!)
4. The communication-module needs to compatible between the autonomous cars, how will be dealt with different updates and versions?
5. How will packetloss be processed in the simulation and how can a protocol be made to minimize its effect.

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.

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.

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. 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 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. 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.

Algorithm

RPC's

Requirements

The design has to satisfy any requirement you formulate. This means that a requirement needs to be specific/measurable!

• The algorithm concerns a common four-way intersection with two turn lanes; one for going right, the other one for going left/straight.

Preferences

These are likes and want-to-haves. Measurability is less important.

• The algorithm is able to know when packet loss occurs, and is able to deal with such situations. (Amount of % packetloss can be adjusted)
• The algorithm makes sure autonomous cars that are grouped together will move like a platoon. However, if there is an significant amount of normal cars, the algorithm will decrease the number of cars in the platoon.

Constraints

Necessary conditions, design choices are fixed from the start.

• Pedestrians are simulated but no cyclists. (They do not behave significantly different than pedestrians, as the roads can have cycling lanes instead of sidewalks.)
• Pedestrians have a maximal allowed waiting time.

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

Current frontend view

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: Normally in java one would not define a main class, but in order to allowing for the separation of graphics and algorithm two classes are needed, one for the graphical side (Renderer) and one for the algorithm (Main).

The main class has three important functions: The constructor, this is where the simulation must be setup. The draw function, where the simulation tells the graphical section what has to be displayed. And the loop function, where all cars and pedestrians take one step and the algorithm does its calculations.

Draw and loop are explicitly separate. Although for most draws there is also one loop. Loops can be skipped if the simulation is paused, and draws can be skipped if the frame rate is too high for Swing to handle.

Note that a draw and loop counter exists. The loop counter is used as a in simulation time unit. This means that the vehicles in the simulation will report their time spent in the intersection in terms of computation steps rather than seconds. The latter method would make the results of the simulation frame rate dependent. With the former method the simulation can be done at any speed.

Pedestrians: The pedestrian simulation relies on different walking speed and drawing offset to make the crowds look like crowds. The difference in walking speed disperses the crowds once the traffic lights go on green. The drawing offset makes it so if multiple pedestrians are on one spot, they instead are drawn as a bunch of circles close together.

In the pedestrian simulation each pedestrian is a finite state machine: They have a state to walk towards the intersection, one to wait at the light, and one to walk away once the light is green. Since each pedestrians only want to go one of the four cardinal directions, each pedestrians need to cross at most one road. The effect pf pedestrians crossing multiple parts of the intersection is the same as simply increasing the number of pedestrians.

Cars: Although the fundamentals are ready, for a large part these are not implemented yet. However, the following is already set: A percentage of cars spawned is autonomous. Since autonomous cars is rather lengthy, it is shortened to “auto” in the code while normal cars are called “car”. An auto is just an different kind of car, where the difference is defined by a Boolean (true or false value).

Code

Code from Main.java; Main Java code, other source files will be uploaded later.

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
• Tesla specifications and sensors

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.