DEGREE PROJECT, IN COMPUTER SCIENCE , FIRST LEVEL STOCKHOLM, SWEDEN 2015
A Comparison of a Genetic Algorithm and Simulated Annealing Applied to a Traffic Light Control Problem
A TRAFFIC INTERSECTION OPTIMIZATION PROBLEM
BENJAMIN BURVALL AND JOHANNES OLEGÅRD
A Comparison of a Genetic Algorithm and Simulated Annealing Applied to a Traffic Light Control Problem
A Traffic Intersection Optimization Problem
Burvall, Benjamin Olegård, Johannes
Degree Project in Computer Science, DD143X Supervisor: Herman, Pawel
Examiner: Ekeberg, Örjan
Abstract
This work compares a Genetic Algorithm (GA) and Simulated Annealing (SA) when applied to a variant of the Traffic Light Control Problem (TLCP).
TLCP is about controlling the lights in one or more traffic intersections in order to optimize traffic flow. This is important in order for society to function properly. The idea is that to solve this problem quickly, as would be necessary in a real traffic situation, stochastic search algorithms like SA and GA should be used. GA and SA in particular are chosen because they are often used in previous work.
A 4-way traffic intersection is simulated. GA and SA are used to find a schedule for lighting the traffic lights in such a way that for a given collection of cars, the traffic flow is maximized. The goal is to study how traffic flows in the solutions produced by GA and SA when the problem size increases.
The conclusion of this work is that SA seems to generally finds better solutions than GA in small search spaces and that SA and GA are comparable in larger search spaces.
Sammanfattning
Det här arbetet jämför en Genetisk Algoritm (GA) och Simulated An- nealing (SA) när de appliceras på en variant av Trafikljusstyrningsproblemet (TLCP). TLCP handlar om att styra trafikljus i en eller flera trafikkorsningar för att optimera trafikflödet genom dem. Detta är viktigt för att samhället ska fungera bra. Tanken för att lösa problemet tillräckligt snabbt för att fungera i verklig trafik är att använda sig av stokastiska algoritmer såsom GA och SA. Just GA och SA har valts eftersom de ofta används i liknande arbeten.
En 4-vägs trafikkorsning simuleras. GA och SA används för att hitta ett schema för hur trafikljusen ska styras för att trafikflödet ska optimeras, för en given mängd bilar. Målet är att studera hur trafikflödet för lösningarna producerade av GA och SA skalar när storleken på problemet växer.
Som slutsats konstateras att SA generellt hittar bättre lösningar på kor- tare tid än GA när det gäller mindre lösningar. För större lösningar var GA och SA jämförbara.
Contents
List of Figures iv
1 Introduction 1
1.1 Scheduling . . . 1
1.2 Problem Statement and Scope . . . 3
1.3 Hypothesis . . . 3
1.4 Outline . . . 4
2 Background 5 2.1 Traffic Light Control Problem (TLCP) . . . 5
3 Methods 9 3.1 Optimization Methods . . . 9
3.1.1 Genetic Algorithms (GA) . . . 9
3.1.2 Simulated Annealing (SA) . . . 11
3.1.3 Implementations . . . 12
3.2 Model . . . 13
3.2.1 Data . . . 13
3.2.2 Simulation . . . 16
3.2.3 Evaluation . . . 18
3.3 Running Tests . . . 18
4 Results 20 5 Discussion 24 5.1 The Comparison . . . 24
5.2 Criticism of Simulation . . . 25
5.3 Possible Practical Applications . . . 26
6 Conclusion 27
7 Bibliography 28
List of Figures
2.1 Cycles . . . 6
3.1 Lanes . . . 14
3.2 Example Configuration . . . 14
3.3 All Lights Green With Collision Points . . . 15
3.4 Maximal Configuration . . . 15
4.1 SA average traffic flows . . . 21
4.2 GA average traffic flows . . . 21
4.3 SA average running times . . . 22
4.4 GA average running times . . . 22
4.5 SA and GA traffic flow comparison . . . 23
4.6 SA and GA running time comparison . . . 23
Chapter 1
Introduction
Scheduling, in general, is about allocating the “what, when and where”. For example tasks, times and machines, or people, times and rooms. Often there are many solutions and some solutions are more suitable than others.
Therefore optimizing these problems often require computers.
1.1 Scheduling
This section introduces different scheduling problems and variations of these problems. Some real world applications include:
Meeting scheduling
Business meetings and university courses and exams can be timed to fulfill certain conditions, e.g. minimize collision, distribute workload
& preferences.
Task planning
When 𝑛 tasks need to be performed by 𝑚 workers, scheduling can be used to minimize the total time (or cost), possibly fulfilling certain conditions. For example: tasks have different requirements, workers have different qualifications, workers need vacation, etc.
Traffic routing
Cars and network packets can be timed and routed to minimize conges- tion. Electric circuits can be routed to distribute heat and interference load across a board.
These problems are usually difficult; in fact most variations are NP-hard.
Meaning, that finding an optimal solution deterministically generally takes a long time, even on computers. Compare e.g. traffic routing with the known NP-hard traveling salesman problem (TSP).
CHAPTER 1. INTRODUCTION 1.1. SCHEDULING
It suffices to say, efficient and optimal schedulers are useful for many real world applications.
The problem in focus in this work is a variation of traffic routing called the Traffic Light Control Problem (TLCP). Consider one or more traffic intersec- tions: with traffic lights, times and lanes. By scheduling green and red lights for the lanes in different ways it is possible to optimize the overall traffic flow. Efficient flow of traffic is necessary for society to function properly, e.g.
for business, leisure and in case of emergency.
There are many ways to schedule a functional intersection, e.g. by green- lighting a single lane at a time. That would, however, stall the other lanes, and it is more efficient to greenlight multiple lanes at the same time. Fur- thermore, there are also safety constraints to take into consideration. For example, some lanes should not be greenlit at the same time to prevent col- lisions. In real traffic systems a short optimal schedule is usually chosen ahead of time and is then cycled. [1–3] This way, the schedule can be reused for a long time. However, this is not necessarily efficient, since unoccupied lanes may still be greenlit. Therefore, research has been spent on developing dynamic systems and efficient algorithms that can make decisions in real time (e.g. [1–4]).
In this work a single 4-way intersection is modeled, with each arm con- sisting of two intersection-facing lanes: one lane for left-turning cars and one lane for cars continuing forward or to the right. The exact variation of TLCP in this work, is the problem of finding a schedule of a given size that is optimal for a specific collection of cars about to arrive at the intersection.
The optimality of a schedule is represented by the evaluation value, which is a real number in the range [0, 1] where 1 is optimal. The evaluation is determined by simulating the cars in the intersection with that schedule.
This problem is solved in this work by stochastically trying different schedules in order to find a schedule as optimal as possible within a lim- ited amount of time.
There exists different algorithms for heuristically trying different sched- ules in this way. In this work, two such algorithms are tested: a genetic algorithm (GA) and simulated annealing (SA). The goal of this work is to compare these two algorithms when applied to the above TLCP.
Both algorithms work by starting with some (usually random) schedule and by repeatedly making small stochastic changes to the schedule in order obtain other schedules that are possibly closer to optimal.
GA works specifically by starting with a population of schedules and obtaining another population by combining the schedules in different ways.
CHAPTER 1. INTRODUCTION 1.2. PROBLEM STATEMENT AND SCOPE
SA works by walking from one schedule to the next. A candidate schedule is chosen randomly, but is only accepted as the next schedule if it is better or, by a probability based on the current temperature. The temperature is initially high and decreases as time passes. The idea is that it initially is useful to accept a less optimal schedule in order to try vastly different schedules as not to get stuck in a local optimum, i.e. a schedule that seems like the best possible when only considering its immediate neighborhood of solutions. [7–9]
1.2 Problem Statement and Scope
The goal of this work is to study and compare the two stochastic optimization algorithms GA and SA, when applied to the TLCP. That is:
∙ How does the traffic flow of the solutions, found by the algorithms, scale with the problem size?
The primary motivation for the choice of algorithms is that they are cited in many works regarding optimization, both TLCP and other scheduling problems. [1,4,10,11]
The focus of this work is on optimizing a single 4-way intersection where all input is immediately available. This is not a study of online algorithms, where results can be produced from small pieces of input at a time. In comparison, the algorithm presented in this work will require a larger amount of input to draw any conclusions.
1.3 Hypothesis
GA is expected to converge slowly, but surely. It is hypothesized that GA is not particularly well suited to take advantage of characteristics specific to TLCP.
SA is expected to be fast due to processing one solution at a time, but may for the same reason not find a as high-quality solution overall compared to GA which search in multiple places simultaneously. Though, this depends on how transitions between solutions are defined. Because of this, SA is expected to find better solutions than GA in smaller search spaces when run for the same amount of time.
SA is expected to find a good enough solution fast, but “stagnate” after that. In comparison GA is expected to take longer to find a good enough solution, but should stagnate at a slower rate. GA is expected to find better solutions than SA in larger search spaces when run for the same amount of time.
Therefore it is hypothesized that GA scales better than SA.
CHAPTER 1. INTRODUCTION 1.4. OUTLINE
1.4 Outline
The following chapter, 2 Background, reviews TLCP in previous work.
In chapter 3 Method a model for TLCP and its simulation are presented.
The two algorithms are explained and some implementation details shown.
Following, in chapter 4 Result, diagrams for the performance of the im- plementations are presented. These are then discussed in the final chapters.
Chapter 2
Background
This chapter provides an overview of TLCP and previous works.
2.1 Traffic Light Control Problem (TLCP)
As described in the previous chapter, TLCP is an optimization problem for one or more intersections where the goal is to optimize the overall traffic flow. There exists many variations and models of TLCP, some study a single intersection [2,11] while most study multiple intersections in a network [1,3,4,12].
Real traffic is usually control by using fixed cycles of phases. For example, let an intersection consist of 4 intersection-facing lanes. A simple cycle would be to greenlight a single lane at a time as shown in figure 2.1a. It is also pos- sible to cycle in pairs of lanes, as shown in figure 2.1b. The former cycle has four phases and the latter has two phases. Note that the cycles do not neces- sarily have to greenlight each lane exactly once, e.g. (𝐴𝐵, 𝐶, 𝐴𝐵, 𝐴, 𝐷, 𝐵), where 𝐴, 𝐵, 𝐶, 𝐷 are different lanes is also a possible cycle.
Cycles are usually manually planned ahead of time and then repeated indefinitely by the traffic lights in the intersection, hour by hour, day by day, year by year. Statistics are used to, for some measure, optimally choose a cycle and adjust the duration length for each phase of the cycle [1]. For example, if some lanes are more likely to have a larger amount of cars than the other lanes, they can be given more greentime in the cycle. Since cycles are planned ahead of time, they are not adjusted in real time to the current traffic situation. This has some drawbacks, for example, lanes where there are no cars currently may still be greenlit, possibly for a long duration of time, making cars in other lanes wait unnecessarily.
CHAPTER 2. BACKGROUND 2.1. TRAFFIC LIGHT CONTROL PROBLEM (TLCP)
(a)
(b)
Figure 2.1: (a) and (b) show examples of cycles for a small intersection.
Arrows indicate transitions in time.
Research on TLCP is mainly spent on:
∙ Finding optimal cycles and durations (as mentioned above).
∙ Finding efficient algorithms for making optimal decisions about what traffic lights to light when and for how long.
The former seems less common in recent decades, probably due to fast com- puters making complex real time algorithms for the latter approach more feasible.
CHAPTER 2. BACKGROUND 2.1. TRAFFIC LIGHT CONTROL PROBLEM (TLCP)
Below some papers are listed to give an overview of previous works.
Dunne and Potts (1964) [2] provided a simple algorithm for controlling a single intersection with two crossing lanes where turning is forbidden. The algorithm uses a cycle of two phases (one for each lane) and works by re- peatedly making the decision whether it is time to switch phase or not. The decision is made based on the time since the last phase switch and how many cars are waiting in each lane. The algorithm ensures that phase lengths is not too short or to long based on a minimum and maximum phase lengths.
The algorithm will attempt to switch phase early if the number of cars in the currently greenlit lane becomes 0 or otherwise small compared to the other lane.
Serafini and Ukovich (1989) [3] modeled fixed cycles for a system of more than one intersection. This is done by constructing graphs where nodes are events and edges represent relations and constraints between these events.
An event refers to the event of switching a traffic light from green to red or from red to green. For a given total cycle length, the problem is to find cycles for all intersections that fits the constraints. They formulate the problem as a mixed integer linear programming problem using their model and prove that it is NP-complete. A simple backtracking algorithm to solve to problem is provided.
Jansson (2010) [11] evaluates the use of GA to optimize a more compli- cated intersection in real time on FPGA hardware. The intersection includes car, tram and pedestrian traffic.
Dong, Huang and Liu (2011) [1] propose variations of GA and particle swarm optimization (PSO): Chaos GA, Chaos PSO, SA PSO, Catastrophe PSO. The algorithms are used to find optimal cycles for a simple grid of 3 by 3 intersections.
A. Stevanovic, J. Stevanovic, Kergaye, and Martin (2011) [10] study the use of traffic signal priority. That is, dynamically giving priority to e.g.
buses. This may include e.g. making traffic lights stay green longer if a bus is nearby. The GA-based traffic optimization program VISGAOST to test different traffic signal priority parameterizations and their effect on op- timization results when simulating.
Cui, Shin, Miyazaki and Lee (2013) [4] use machine learning to optimize intersections in real time. They use cellular automata to simulate traffic and bayesian networks to predict probability distributions of congestions.
Particle swarm optimization (an algorithm similar to GA) is then used to find the phases to use next.
CHAPTER 2. BACKGROUND 2.1. TRAFFIC LIGHT CONTROL PROBLEM (TLCP)
Chen, et al. (2013) [13] propose a lane-level dynamic traffic control (LDTC) system. It uses vehicular networks and traffic cameras to collect information about lane position and turning intentions. The goal is to max- imize the intersection throughput and still be fair to other lanes. Meaning, while setting green light for the lanes with highest traffic flow for through- put maximization, it also sets green light for lanes with lower traffic flow for fairness provision.
Chapter 3
Methods
This chapter presents a model of the problem. Details for the algorithms, implementations and measurements are also presented.
3.1 Optimization Methods
This section explains the two algorithms and their implementations.
3.1.1 Genetic Algorithms (GA)
Genetic Algorithms (GA) are a family of stochastic algorithms inspired by evolution and are often used for optimization [5], especially nonlinear. These algorithms come in many variations, but in general operate as shown in algorithm 1 below.
Algorithm 1: Genetic Algorithm P = sample(S);
while max(fitness(p, P) for p in P) < goal do parents = select(P);
offspring = {};
for (a,b) in parents do children = crossover(a,b);
offspring = offspring + children;
end
C = {mutate(c) for c in offspring};
P = merge(C, P);
end
Let the search space 𝑆 be the set of all solutions to the problem instance.
A solution is also called a chromosome [5], and is a bit string of length 𝐿.
The basics of GA is changing, sampling and evaluating these chromosomes to find optimal chromosomes.
CHAPTER 3. METHODS 3.1. OPTIMIZATION METHODS
The algorithm starts by creating a population of chromosomes, usually randomly [5]. From this population pairs are selected [5, 6] and, through a process called crossover [5,6], used to create offspring (more chromosomes).
Each offspring may be then be mutated [5, 6]. Finally the offspring is used to create the next generation [5,6] of chromosomes. This process is repeated until the population is good enough, in some measure.
An evaluation-function, or fitness-function, is used to measures the good- ness of chromosomes. The goal of the algorithm is to find chromosomes that (sufficiently) maximizes the evaluation function [5,6]. The meaning of evalu- ation and fitness vary between works and authors. Sometimes they are used interchangeably, other times evaluation is independent of the current pop- ulation while fitness is dependent on the current population [5]. The latter definition is used in this work.
The rest of the section is dedicated to describing the different parts of GA and their different variations.
Selection [5,6] is the process of sampling pairs randomly from the popu- lation. Chromosomes of higher fitness are more likely to be selected.
The probably most common method of selection is the so called roulette wheel sampling [5,6]. The population is sampled (with replacement) and the probability of a chromosome being chosen is proportional to its fitness. If the evaluation-function is 𝑓, then the fitness of chromosome 𝑥 can be defined as 𝑓(𝑥)/ ˆ𝑓, where ˆ𝑓 is the average evaluation of the population [5]. The sampled population is then sampled again to produce pairs. Other selection methods based on the roulette wheel mainly differ in how the fitness-function is defined.
Another method is rank selection [5, 6], where the chromosomes are ranked (sorted) according to evaluation. Basing the fitness on the rank (instead of directly on the evaluation) can help prevent the algorithm con- verging too early (i.e. getting stuck in local optima) [6].
A third way is tournament selection [5,6]. Iteratively, two chromosomes are selected and the fittest of the two is chosen. The resulting set is sampled to produce pairs.
Crossover [6] is the process of using the selected parent pairs (from the selection) to generate offspring. There are many ways of doing this, e.g.
by splitting the parents in half and combining one half from each parent:
(𝐴1𝐴2, 𝐵1𝐵2) to (𝐴1𝐵2, 𝐵1𝐴2).
Mutation [6] is applied to some randomly chosen offspring. This could e.g. involve flipping a randomly chosen bit in the chromosome. Mutation can be used to create more variation and help explore the search space.
CHAPTER 3. METHODS 3.1. OPTIMIZATION METHODS
Elitism forces part of the population to be reused in the next generation.
This is e.g. to ensure that the chromosome with highest evaluation is not lost. Also, to prevent the population size from growing over generations some less fit chromosomes could be purged in this phase.
3.1.2 Simulated Annealing (SA)
Simulated Annealing (SA) is another stochastic algorithm for performing combinatorial optimization search.
The algorithm is originally based on another algorithm by Metropolis et al. [14] that simulates the behavior of collections of atoms at different temperatures [8].
Algorithm 2: Simulated Annealing 𝑥0 := choice(S);
best = 𝑥0; for 𝑡 in 1..𝑛 do
prev := 𝑥𝑡−1;
𝑦 := choice(N(prev));
if C(𝑦) < C(prev) or rnd() < exp(-(C(𝑦) - C(prev)) / T(𝑡)) then 𝑥𝑡:= 𝑦 ; // new solution is good enough if C(y) < C(best) then
best = 𝑦;
end else
𝑥𝑡:= prev ; // reuse last solution end
end
Let the search space 𝑆 be the set of all solutions to the problem instance.
The algorithm (see algorithm 2 above) starts at time 𝑡 = 0, where an ini- tial solution 𝑥0 is chosen (e.g. randomly) from 𝑆. Each subsequent solutions 𝑥𝑡, 𝑡 > 0, are computed using the previous solution 𝑥𝑡−1.
A candidate solution 𝑦 is chosen randomly from the neighbors of the previous solution (𝑦 ∈ 𝑁(𝑥𝑡−1)). The goodness of a solution is determined by a cost-function 𝐶 (smaller is better). If the cost of the candidate is lower than the cost of the last solution it is immediately used as the next solution.
The candidate may still be used as the next solution with probability [7–9]:
𝑝(𝑦, 𝑡) = exp (︂
−𝐶(𝑦) − 𝐶(𝑥𝑡−1) 𝑇 (𝑡)
)︂
where 𝑇 (𝑡) is the temperature. 𝑇 should be a non-increasing function, i.e.
starts high and cools over time. Note how the probability decreases as 𝑇 decreases. That is, the probability of choosing bad candidates decreases over
CHAPTER 3. METHODS 3.1. OPTIMIZATION METHODS
time. This is the main-idea of simulated annealing: accept some bad so- lutions early in order to explore the solutions space, and get stricter when approaching the final solution. Because of this, SA can avoid getting stuck in local optimum. The probability also depend on the difference in cost – this represents the difference in energy between the two states. A smaller difference in energy increases the probability of the candidate being recon- sidered [7–9].
3.1.3 Implementations GA Implementation
GA was implemented in Java using the JGap library [15]. JGap was chosen due to its ease of use. It defines a chromosome to be a finite sequence of genes. A TLCP configuration is represented by an integer gene bounded to the range [0, 7], i.e. enumerating the 8 maximal configurations. Chro- mosomes are evaluated by the function 𝑓(𝑥) = 1 + 𝐸(𝑥), where 𝐸 is the evaluation function presented in section 3.2.3. The implementations uses JGap’s DefaultConfiguration-class. This includes a selector, a crossover- operator and a mutator.
The crossover-operator is applied first in each iteration. Two chromo- somes are selected at a time. Each chromosome is selected randomly (note:
uniformly) with replacement from the population. The crossover is per- formed by dividing the chromosomes in two at a random point in the range [0, 𝑛), and then swapping the genes at and after that point: (𝐴1𝐴2, 𝐵1𝐵2)to (𝐴1𝐵2, 𝐵1𝐴2). The two new chromosomes are then added to the population.
This crossover-operation is repeated 0.35·population size times (rounded to nearest integer) per population. Each time a new pair is selected.
After the crossover-operator, the mutator is applied. The mutator de- cides for each gene in each chromosome whether a mutation should be applied to that gene. The decision is made randomly, with probability 121 .
A mutation is applied to a gene 𝑔 by adding a random number in the range [−8, 8). If this causes 𝑔 to deviate from the interval [0, 7] it is set to a random number in that interval.
Finally, the selector is applied. The selector retrieves the
𝑏 = 0.90 · population size most fit chromosomes (rounded to nearest integer) from the population. The remaining population size − 𝑏 of the chromosomes are removed and replaced by cloning the most fit individuals (of the kept part) of the population. This is essentially a form of elitism rank selection.
Since the selector is applied last, JGap’s genetic algorithm differs from the one presented in the background section (algorithm 1). Note also how
CHAPTER 3. METHODS 3.2. MODEL
This, however, requires an intermediate population which may be expensive to compute. Since clones are allowed in JGap’s algorithm, the selection may as well be applied after the crossover and mutation.
SA Implementation
SA was implemented in java specifically for this work and did not use any external libraries. It follows the algorithm as described in algorithm 2.
Like the GA implementation, configurations are represented by integers bounded to the range [0, 7]. Initial solutions are generated randomly. The cost function is defined as 𝐶(𝑥) = 1 − 𝐸(𝑥), where 𝐸 is the evaluation function presented in section 3.2.3.
The temperature function is defined as:
𝑇 (𝑡) =
{︃𝑘𝑒−𝜆𝑡 if 𝑡 < 𝑡𝑚𝑎𝑥
0 otherwise
for some constants 𝑘, 𝜆 and 𝑡𝑚𝑎𝑥. (based on the definition used in [16]).
Candidates are generated by randomly selecting integers 𝑖 ∈ [0, 𝑛) and 𝑞 ∈ [1, 7]. The solution is then modified by the rule:
𝑐𝑖 ← rem8(𝑐𝑖+ 𝑞)
where 𝑐𝑖 is the 𝑖:th configuration in the solution sequence, and rem8 is a function returning the remainder for division by 8. To obtain a candidate the above rule is repeated (for different 𝑖 and 𝑞), for a random number of times in the interval [1, 10].
3.2 Model
This section describes a model of the problem.
3.2.1 Data
A single 4-way intersection is modeled. Each arm has 2 intersection-facing lanes: one for left turning cars and one for cars continuing forward either to the right. See figure 3.1. Let a problem instance (or input) consist of an integer 𝑛 and a set 𝑅 of cars, where 𝑛 is the number of discrete time steps to schedule. Each car in 𝑅 is represented by five values: source arm, turning direction, a non-negative distance from the intersection center along that arm, a maximum velocity and a maximum acceleration. Distance 0 indicates a position directly in front of a traffic light and each unit of distance is a car length. How these values are used is further explained in section 3.2.2.
CHAPTER 3. METHODS 3.2. MODEL
Figure 3.1: Turning behaviour based on lanes. Rotate the image to see the corresponding behaviour for the other four arms.
A problem solution (or output) is a mapping from each time step 𝑡, 0 ≤ 𝑡 < 𝑛, to a configuration 𝑐 ∈ 𝐶. Alternatively: a sequence of length 𝑛 consisting of configurations from the set of all configurations 𝐶. A configu- ration decides the color (red or green) of each traffic lights at a given time.
An example configuration is illustrated in figure 3.2: green lights on the east arm right-hand lane and red lights everywhere else. Note, however, that this particular configuration may be inefficient since only one lane is moving. A more efficient configuration might be to also greenlight the west arm right lane.
Figure 3.2: An example configuration. The green and red (also crossed) disks indicate traffic lights. The green arrows indicate the allowed routes as
CHAPTER 3. METHODS 3.2. MODEL
All possible combinations of red and green lights are not necessarily ap- propriate configurations. If, for example, the east arm right lane and the south arm right lane are both green at the same time, cars from these lanes may collide in the northeastern part of the intersection. All possible colli- sions are shown in figure 3.3. As such, by prohibiting specific configurations some hard constraints can be enforced, e.g. prohibit collisions.
Figure 3.3: The crosses illustrates the collision points.
Some configurations, like all lanes greenlit, could also cause the intersec- tion to lock up (cars wait on each other in a cycle). Such configurations can be seen as inefficient and not considering them speeds up the search. It is also possible to simply penalize the choice of configuration when collisions happen. E.g. result in lower fitness in GA.
A reason for allowing all configuration is that this could be well suited for GA. A configuration could be represented by a bit string where bit 𝑖 would correspond to lane 𝑖 (for some enumeration) being greenlit when the bit is set and redlit when the bit is not set.
In this work, the former way of prohibiting some configurations has been chosen due to being more realistic and also simplifying the implementation.
Figure 3.4: Some base maximal configurations. By rotating the images all 8 maximal configurations can be produced.
CHAPTER 3. METHODS 3.2. MODEL
Let a configuration be maximal if no additional red light can be turned into a green light without risking collisions. A subset of all maximal config- uration are shown in figure 3.4. All maximal configurations can be produced by rotation of the images. All 8 maximal configurations are used in the simulation described in the next section. Only enabling the maximal config- urations is thought to be most efficient while also disabling collisions.
3.2.2 Simulation
To evaluate a solution is to simulate the intersection with the sequence of configurations in the solution. The simulation works per algorithm 3 below.
Due to the choice of configurations in the previous section, collisions cannot happen. Therefore, each lane can be simulated independently. Furthermore, the simulation has been simplified such that cars closer to the intersection are moved first. Each car need only consider the position of the preceding car after the preceding car has been moved. This simplification may not be entirely accurate since cars move and accelerate at different speeds which in some cases may slow down traffic slightly.
The configurations in the solution is simulated in turn as time steps.
Each time step consist of 15 ticks, which is the unit of time cars move. The simulation first tries to move as many cars as possible across the intersec- tion. How many cars that get across depend on their: distances from the intersection, velocities, maximum velocities, maximum accelerations, where they will turn, and the time available. The cars may turn at their maximal velocity, which is an unrealistic simplification. Note that the distance across the intersection vary depending on where the cars will turns. Compare e.g.
the relative lengths of the arrows in figure 3.1.
When a car gets across it simply gets deleted and is not considered again.
This is not entirely correct since the cars will limit the available space on the destination lane and prevent more cars from getting across. This was deemed unnecessary and have been simplified, e.g. how long should the destination lane be if it needs to be simulated? The cars that are left are then each moved as far as possible towards (but not across) the intersection. The cars will have to decelerate when approaching the intersection or the car in front.
Amber (or yellow) lights have not been mention so far and are not explicit in the simulation. In the simulation the decision whether a car should cross the intersection or wait at the lights is determined by whether it would make it across in time or not. In a real situation this decision is made by the driver and is generally based on: speed, whether and when the lights turn. The idea in the simulation is that the lights are amberlit in time to signal the next driver that they can not make it across in time. The actual amberlighting is
CHAPTER 3. METHODS 3.2. MODEL
Algorithm 3: Simulation for h in lanes do
C = cars in h ordered by increasing distance;
t = 0;
while t < n do start = t;
while t < n and is_green(t, h) do t = t + 1;
end
green_time = t - start;
while t < n and not is_green(t, h) do t = t + 1;
endred_time = t - start - green_time;
if green_time ̸= 0 then
/* move as many cars as possible across
intersection */
for c in C do
dt = ticks(green_time);
if not can_cross(c, dt) then break ; // not enough time end
delete(c) ; // car finished end
end
/* move cars towards (but not across) intersection */
for c in C do
end_position = 0;
end_velocity = 0;
c2 = car preceding c;
if c2 exists then
end_position = dist(c2);
end_velocity = velocity(c2);
enddt = ticks(green_time + red_ time);
move_toward(end_position, end_velocity, c, dt);
end end end
CHAPTER 3. METHODS 3.3. RUNNING TESTS
Cars move in intervals with constant accelerations following the equa- tions:
𝑎(𝑡) = 𝑐𝑎 𝑣(𝑡) = 𝑐𝑎𝑡 + 𝑐𝑣 𝑝(𝑡) = 𝑐𝑎
2𝑡2+ 𝑐𝑝
based on acceleration (𝑎), velocity (𝑣), position (𝑝) and time (𝑡).
Constants 𝑐𝑎 (acceleration), 𝑐𝑣 (initial velocity) and 𝑐𝑝 (initial position) differ for each interval.
When a car attempts to move from a point 𝑝0(current position) to a point 𝑝1 (e.g. in front of a red light or behind another car), it will first attempt to accelerate to its maximum velocity, then keep that velocity for some distance, and then decelerate. Cars always use their maximum acceleration when accelerating, and the negative maximum acceleration when decelerating. In reality cars would move in smoother motions but this has been simplified.
3.2.3 Evaluation
Let the function 𝐸 : 𝐶𝑛 → R determine the traffic flow of a solution. A larger value is better.
𝐸 is defined as:
𝐸(𝑥) = 1 − time steps until all cars across
𝑛 (3.1)
This will produce a value between 0 and 1. The flow is essentially defined as the percentage of the planned time necessary to get all cars across the intersection. The faster the intersection is emptied, the greater flow.
3.3 Running Tests
To test the algorithms, twelve input files were generated. Each file contains the number 𝑛 of configurations to plan, and a number of cars with different parameters as described in section 3.2.
Each lane was randomly generated in twelve approximately equally sized segments. The input file with number 𝑖 (𝑖 ∈ 1 . . . 12) uses the first 𝑖 segments of each lane. For each file the number of configurations to plan was 𝑛 = 100𝑖 and the number of cars was approximately 500𝑖. The cars are randomly placed in each segment and their number per segment vary slightly.
The algorithms are then run on the files. The idea is to try a few different
CHAPTER 3. METHODS 3.3. RUNNING TESTS
Each time a algorithm is run on a file, the following is recorded: the most optimal traffic flow found, the running time, and the simulation count. The first refers to greatest evaluation value 𝐸(𝑥) found, the second to the actual time in seconds to run the algorithm on the file, and the last to the total number of simulations performed.
The main focus is the most optimal traffic flow found since this is of relevance to the problem statement. For discussion, the running time and number of simulations performed, will also be presented as results.
Note that since traffic flow is a normalized value, the relative differences are studied rather than absolute differences.
Since the algorithms are stochastic, each parameterized run on a file is repeated 50 times. Averages of traffic flow, running time and simulation count are the actual values studied.
Chapter 4
Results
Tests ran on a laptop PC with:
Archlinux, linux 3.17.6-1 AMD E-350 Processor @ 2.4 GHz 2 Cores
RAM 3.5 GB
Tables 4.1 4.2 shows different parameterizations of SA and GA, respec- tively, that have been tried. The id of a parameterization will be used to refer to it.
id 𝑘 𝑡𝑚𝑎𝑥 𝜆 simulation count
SA1 4𝑛2/1000 200000/𝑛 0.01 200000/𝑛
SA2 6000 6000 0.02 2279
SA3 5𝑛 5𝑛 0.01 5𝑛
Table 4.1: SA parameterizations
id population size generation count simulation count
GA1 500 5 4750
GA2 190 15 5020
GA3 20 100 3420
Table 4.2: GA parameterizations
CHAPTER 4. RESULTS
Figures 4.1 and 4.2 shows the average traffic flows 𝐸(𝑥) for SA and GA parameterizations, respectively.
Figure 4.1: The average evaluation values for the different parameterizations of SA.
Figure 4.2: The average evaluation values for the different parameterizations of GA.
CHAPTER 4. RESULTS
Figures 4.3 and 4.4 shows the corresponding average running times.
Figure 4.3: The running times for the different parameterizations of SA.
CHAPTER 4. RESULTS
Figures 4.5 and 4.6 shows a comparison between SA2 and GA3 in traffic flow and running time, respectively. These parameterizations where cho- sen because they were considered to be be best of the ones tried, for each algorithm respectively.
Figure 4.5: The average evaluation values for the considered best parame- terizations for SA and GA.
Figure 4.6: The average running time for the considered best parameteriza- tions for SA and GA.
Chapter 5
Discussion
In this chapter the method and results are discussed and criticized.
It should be noted that the running time taken by the algorithms con- sists mainly of running simulations. Hence, any differences in running time between algorithms and parameterizations are mainly caused by how many simulations are run. This is one of the reason why mainly traffic flow is measured, rather then execution time.
5.1 The Comparison
Figures 4.5 and 4.6 suggest that SA scales better than GA, both in traffic flow and running time, at least for the parameterizations used. GA evaluates more solutions and therefore takes more time. Still GA generally does not find better solutions.
However, the margin between GA and SA seems to get smaller as the file size increases. This is partially because of the way the evaluation function is defined, i.e. variations look smaller due to being normalized. Another reason is likely because the search space increases considerably in size. This means that in general more space has to be searched in order to find good solutions. Since the parameterizations SA2 and GA3 do not change with file size, they do not try more solutions as file size increases although the increase in search space size would require them to do so in order to find good solutions. As such, both should get lower traffic flow as file size in- creases. From experiments SA has been shown to be very sensitive to its parameterization (see e.g. figure 4.1) and because of this it is possible that SA degrades faster than GA when file size increases and therefore decreasing the margin between them. This would suggest SA scales worse than GA, or at least that SA requires finer tuning than GA to scale well.
CHAPTER 5. DISCUSSION 5.2. CRITICISM OF SIMULATION
in shorter time than GA3 on smaller files (see figures 4.5 and 4.6). However, though the margin decreases as file size increases GA does not necessarily seem to be passing SA. Rather, both algorithms seem less likely to find good solutions when file size increases. This may be because neither SA2 or GA3 scales their parameters by file size. This suggest that GA and SA do not get enough iterations to converge. But, if GA were to run for more generations, it would become slower or population size would have to be decreased, which may further impact the result, which would suggest that SA scale better. Figures 4.2 and 4.4, however, suggest that population size can be dramatically decreased in favor of more generations and still find better better solutions. It would seem that GA and SA are comparable on larger search spaces, when considering the parameterizations tried.
For SA2, GA1, GA2 and GA3 the same parameters were used for all file sizes. As mentioned above, all parameterizations of both algorithms seem less likely to find good solutions when file size increases. It may therefore be better to scale the parameters by file size, as in SA1 and SA3.
SA1 tries fewer solutions as file size increases. This makes the running time about the same for all file sizes, as shown in figure 4.3. As is to be expected, this results in lower traffic flow in solutions when file size increases, as shown in figure 4.1. Besides being lower the traffic flow also varies more for SA1, showing SA1 does not getting enough time to properly converge.
SA3 does the opposite, i.e. searches more solutions as file size increases.
Note that that SA2 uses a parameterization corresponding to SA3 running on file 12 (i.e. with 𝑛 = 1200), with a small change to 𝜆. Figure 4.1 shows that SA2 generally find better solutions than SA3 on the first few files, but slightly worse on the last few files. The switch likely occurs on the file where both parameterizations try the same amount of solutions.
Another way of going about the tests could be to optimize the parameters per file, i.e. try many different parameters for the file, and use the best result when comparing. This may, however, be unrealistic if the algorithms were to run in real time on a real problem. The time necessary to find the parameters may not be available in such a situation.
5.2 Criticism of Simulation
As noted in chapter 3, the simulation is not entirely realistic and may there- fore not accurately reflect a real situation. However, it is believed that it could still be used to approximate small intersections, where not enough cars pass to show the inadequacies of the simulation.
As shown, the found traffic flows vary between files. This suggests that traffic is very dynamic and that the simulation portraits this in the search space. Likely the search space vary considerably between files. It can also be argued that it is caused by unknown bugs and instabilities in the simulation.
CHAPTER 5. DISCUSSION 5.3. POSSIBLE PRACTICAL APPLICATIONS
On the subject of evaluation it can be argued that the definition and measurement used for traffic flow is too simplistic. The evaluation function should have been better grounded in theory. Originally multiple measures were considered when the evaluation function was being defined, but due to most of them being too closely related they were dismissed.
Furthermore, all time steps had the same size in ticks. A more realistic intersection should make use of configurations of varied-size time steps. For example, a solution could be redefined as a sequence of configuration-and- size pairs instead of a sequence of only configurations. It should also be noted that the evaluation used was defined in terms of time steps used. By using time steps of varying size and defining evaluation in terms of ticks instead of time steps, a larger variety (and likely more optimal) evaluations could have been produced.
Combined with varying-sized time steps, it should also be considered to allow non-maximal configurations. Non-maximal configurations were origi- nally not used, due to enlarging the search space to no clear benefit. With varied-size time steps, however, it might sometimes be optimal to let lanes gather some amount of cars before greenlighting them. All maximal config- urations greenlight exactly two lanes, meaning that to greenlight some lane another must also be greenlit and this may prevent cars from gathering there.
That is, allowing only maximal configurations could hamper the potential of varied-sized time steps.
5.3 Possible Practical Applications
A possible practical application of the method would be to plan intersections ahead of time in small intervals. If it is possible to accurately predict when cars will arrive at the intersection, it would be possible to plan ahead, e.g.
20 minutes at a time. This is, of course, heavily dependent on the prediction mechanism.
Some previous work (such as [2]) present systems and algorithms that make decisions based on the number of incoming cars, but does not consider the spacing between those cars. With the speed of todays computers it is probably possible to make decisions based on the exact cars that are approach the (spacing, types of cars, etc.), not the just number of cars. This is similar to the approach other precious work (such as [4]).
It should be noted that computations were single-threaded and did not make use of parallelization. In a real situation it may be necessary to do so, to make the solutions fast enough. The algorithms may, however, make use of the parallelization in different ways and one way may be more appropriate.
Chapter 6
Conclusion
It is difficult to draw any hard conclusion without using statistics and the difference is heavily dependent on parameterization and there likely exists better parameterizations for both SA and GA.
We would however like to conclude that: SA generally finds better solu- tions than GA in small search spaces and that SA and GA are comparable on larger search spaces.
Chapter 7
Bibliography
[1] Chaojun Dong, Shiqing Huang, and Xiankun Liu. Comparative study of several intelligent optimization algorithms for traffic control appli- cations. In Electronics, Communications and Control (ICECC), 2011 International Conference on, pages 4219–4223, Sept 2011.
[2] Michael C. Dunne and Renfrey B. Potts. Algorithm for traffic control.
Operations Research, 12(6):870–881, 1964.
[3] Paolo Serafini and Walter Ukovich. A mathematical model for the fixed- time traffic control problem. European Journal of Operational Research, 42(2):152 – 165, 1989.
[4] Cheng-You Cui, Ji-Sun Shin, Michio Miyazaki, and Hee-Hyol Lee. Real- time traffic signal control for optimization of traffic jam probability.
Electronics and Communications in Japan, 96(1):1–13, 2013.
[5] Darrell Whitley. A genetic algorithm tutorial. Statistics and Computing, 4(2):65–85, 1994.
[6] Mitchell Melanie. An introduction to genetic algorithms, volume 3. Cam- bridge, Massachusetts London, England, Fifth printing, 1999.
[7] Dimitris Bertsimas and John Tsitsiklis. Simulated annealing. Statist.
Sci., 8(1):10–15, 02 1993.
[8] S. Kirkpatrick, C. D. Gelatt, and M. P. Vecchi. Optimization by simu- lated annealing. Science, 220(4598):pp. 671–680, 1983.
[9] LPPP Van Ginneken and RHJM Otten. An inner loop criterion for simulated annealing. Physics letters A, 130(8):429–435, 1988.
[10] A. Stevanovic, J. Stevanovic, C. Kergaye, and P. Martin. Traffic con-
CHAPTER 7. BIBLIOGRAPHY
[11] Gustaf Jansson. Traffic control with standard genetic algorithm - a simulated optimization control of a traffic intersection. Thesis work in Intelligent Systems Design, (2010:127), 2010.
[12] Weizhen Gu and Xingde Jia. On a traffic control problem. In Paral- lel Architectures,Algorithms and Networks, 2005. ISPAN 2005. Proceed- ings. 8th International Symposium on, pages 6 pp.–, Dec 2005.
[13] Lien-Wu Chen, Chia-Chen Chang, P. Sharma, Jen-Hsiang Cheng, Chien-Cheng Wu, and Yu-Chee Tseng. A lane-level dynamic traffic control system for driving efficiency optimization based on vehicular networks. In Pervasive Computing and Communications Workshops (PERCOM Workshops), 2013 IEEE International Conference on, pages 297–299, March 2013.
[14] Nicholas Metropolis, Arianna W Rosenbluth, Marshall N Rosenbluth, Augusta H Teller, and Edward Teller. Equation of state calculations by fast computing machines. The journal of chemical physics, 21(6):1087–
1092, 1953.
[15] JGAP Team. Jgap, April 2015. http://jgap.sourceforge.net.
[16] AIMA Team. Aima 3e java, April 2015. https://github.com/
aima-java/aima-java.
