Intelligent Traffic Intersection Management Using Motion Planning for Autonomous Vehicles
Viktor Tuul and John Dahlberg
Abstract—With the increasing advances in the field of au- tonomous vehicles it is alluring to ask if a possible vehicular paradigm shift is in the near future. Maximizing road capacity with Intelligent Traffic Intersections that communicate with autonomous vehicles could become a reality, where the need for traffic lights and stop signs is excluded. In this paper, an Autonomous Intersection Management system is introduced that utilizes trajectory-based prioritization and motion planning tech- niques to manage traffic in an orthogonal single lane four-way intersection. The developed system reduces the need for vehicles to slow down or even stop before intersections, contrariwise, it lets all vehicles enter the intersection at the highest allowed speed.
The proposed solution is shown to increase the capacity of in- tersections compared with contemporary intersections managed with traffic lights.
I. INTRODUCTION
ROAD based traffic is increasing all around the globe, especially in densely populated urban areas [1]. The resulting congestion, especially at traffic intersections, implies increased fuel consumption, pollution and in addition wasted time [2]. The advances made in research and development within the fields of autonomous vehicles and communication technology will in a near future enable a great deal of possibilities within transportation systems, including traffic management [3].
When introducing the concept of Autonomous Intersection Management, improvement of efficiency in traffic manage- ment, compared with contemporary methods, by using con- trol of autonomous vehicles has been shown be possible by Dresner and Stone [4]. The Autonomous Intersection Man- ager (AIM) approach may in theory also be used with non- autonomous vehicles [5][6] which implies that eliminating traffic lights is not necessarily limited to self-driving cars.
However, this work examine how communication and control theory can be utilized for exclusively smart autonomous vehi- cles in traffic intersections in order to optimize road capacity and minimize congestion.
First, the vehicle- and intersection models are presented in Section II. Then in Section III the Autonomous Intersection Manager and its interactions with autonomous vehicles are introduced. In Section IV a developed control algorithm is proposed that utilizes motion planning techniques which are used to direct three critical tasks; how the AIM 1) takes the possible trajectories into consideration, 2) determines the individual vehicle prioritization, and 3) calculates the optimal speed request for each individual vehicle in order to ensure highest allowed speed when entering the intersection. Section VII presents the results from simulations performed in our
developed simulation environment programmed in C#, both with our developed control algorithm applied and also with traffic lights. Additionally, comparisons regarding the vehic- ular throughput for both systems are presented. The results are then discussed in Section VIII, and the conclusions are presented in Section IX.
II. MODELS
This section covers the vehicle- and intersection models that are used throughout this paper. In Section II-A the geometric and abstract models of the intersection are introduced, and also how trajectory distances inside the intersection depends on vehicle priority. In Section II-B the vehicle model is presented, where the dynamics and variables of the vehicles that are implemented in the intersection model are covered.
A. Intersection Model
Each vehicles predetermined parameter of trajectory T ri
describing boundary positions, i.e. start and target, is defined by the syntaxes
<trajectory>::=<start><target>
<start>::=<N>|<E>|<S>|<W>
<target>::=<N>|<E>|<S>|<W>,
provided thatstart6=targetand where<N>,<E>,<S>and
<W>are the positions north, east, south and west relative origin in a, to the intersection, locally defined coordinate system. The possible trajectories are defined in Figure 1.
Fig. 1: Visual representation of the intersection trajectories.
The intersection model intends one lane for each incoming direction with lane width L. Some of the trajectories have a risk of collision with other trajectories. The trajectory relations are presented in an adjacency matrix in Table I which is an abstraction of the geometric representation of the intersection model in Figure 1. The purpose of the abstract model is to allow the AIM to handle trajectory-based prioritizations regarding vehicles, and to include them in the motion planning algorithm presented in Section IV.
TABLE I: A matrix that explicitly presents the trajectory con- flict relations where 1 represents a conflict while 0 indicates no conflict between respective trajectory.
NW NS NE EN EW ES SE SN SW WS WE WN
NW 1 1 1 0 1 0 0 0 1 0 0 0
NS 1 1 1 0 1 1 0 0 1 1 1 1
NE 1 1 1 0 1 1 1 1 1 0 1 1
EN 0 0 0 1 1 1 0 1 0 0 0 1
EW 1 1 1 1 1 1 0 1 1 0 0 1
ES 0 1 1 1 1 1 0 1 1 1 1 1
SE 0 0 1 0 0 0 1 1 1 0 1 0
SN 0 0 1 1 1 1 1 1 1 0 1 1
SW 1 1 1 0 1 1 1 1 1 0 1 1
WS 0 1 0 0 0 1 0 0 0 1 1 1
WE 0 1 1 0 0 1 1 1 1 1 1 1
WN 0 1 1 1 1 1 0 1 1 1 1 1
The key purpose of the matrix is to identify which of the trajectories that have collision risk (the ones) and which ones that does not (the zeros).
A vehicle Vi with the trajectory T rithat has a collision risk with vehicle Vj with trajectory T rj has a specified distance dT rT rj
i indicating how far the vehicle Vi can travel inside the intersection to a hypothetical point of collision with Vjoccurs.
Table II presents the traversing distance dT rT ri
j, given that vehicle Vj, with corresponding trajectory on the left hand side, is the prioritized vehicle, i.e. the particular vehicle is expected to arrive to the hypothetical point of collision before Vi. The distances are thus either the quarter circle arc lengths inside the intersection or the distance straight through the intersection, where L is the lane width, which are geometrically identified in Figure 2. The figure additionally shows possible positions for points of collision risks.
Given that vehicle Vj is the prioritized vehicle, the depri- oritized vehicle Vi must give way for Vj. This implies that the distance dT rT rj
i in the intersection for vehicle Vi is given by the values in Table III. The most trivial case is when the traversing distance dT rT ri
j does not depend on which vehicle that has priority. Figure 3 shows a case for two vehicles in conflict with the trajectories W N and SN , which implies the traversing distances dSNW N and dW NSN . According to Table II and Table III the traversing distances for the individual vehicles mostly are the same regardless of priority, which is also illustrated in Figure 3, i.e. the distances do not change.
TABLE II: A matrix that shows the traversing distance inside the intersection for a prioritized vehicle with the trajectory on the left hand side until a hypothetical collision occurs with a deprioritized vehicle.
dT rT ri
j NW NS NE EN EW ES SE SN SW WS WE WN
NW 0 0 0 0 πL
4 0 0 0 πL
4 0 0 0
NS 0 0 0 0 L 0 0 0 0 0 0 0
NE 0 0 0 0 0 3πL
8 3πL
4 3πL
4 3πL
4 0 3πL 8
3πL 8
EN 0 0 0 0 0 0 0 πL
4 0 0 0 πL
4
EW 2L 2L 2L 0 0 0 0 0 L 0 0 0
ES 0 π3L
8 3πL
8 0 0 0 0 0 π3L
8 3πL
4 3πL
4 3πL
4
SE 0 0 πL
4 0 0 0 0 0 0 0 πL
4 0
SN 0 0 0 2L 2L 2L 0 0 0 0 0 πL
4
SW 3πL
4 3πL
4 3πL
4 0 3πL 8
3πL
8 0 0 0 0 0 3πL
8
WS 0 πL
4 0 0 0 πL
4 0 0 0 0 0 0
WE 0 0 πL
4 0 0 0 2L 2L 2L 0 0 0
WN 0 0 3πL
8 3πL
4 3πL
4 3πL
4 0 3πL 8
3πL
8 0 0 0
TABLE III: A matrix that shows the traversing distance inside the intersection for a deprioritized vehicle with the trajectory on the left hand side until a hypothetical collision occurs with a prioritized vehicle. The bold zeros empathizes the numerical differences from Table II.
dT rT ri
j NW NS NE EN EW ES SE SN SW WS WE WN
NW 0 0 0 0 πL
4 0 0 0 πL
4 0 0 0
NS 0 0 0 0 L 0 0 0 0 0 0 0
NE 0 0 0 0 0 3πL
8 3πL
4 3πL
4 0 0 3πL
8 3πL
8
EN 0 0 0 0 0 0 0 πL
4 0 0 0 πL
4
EW 2L 2L 2L 0 0 0 0 0 L 0 0 0
ES 0 3πL
8 3πL
8 0 0 0 0 0 π3L
8 3πL
4 3πL
4 0
SE 0 0 πL
4 0 0 0 0 0 0 0 πL
4 0
SN 0 0 0 2L 2L 2L 0 0 0 0 0 πL
4
SW 3πL
4 3πL
4 0 0 3πL
8 3πL
8 0 0 0 0 0 3πL
8
WS 0 πL
4 0 0 0 πL
4 0 0 0 0 0 0
WE 0 0 πL
4 0 0 0 2L 2L 2L 0 0 0
WN 0 0 3πL
8 3πL
4 3πL
4 0 0 3πL
8 3πL
8 0 0 0
However, when comparing Table II and Table III, dT rT rij and dT rT rj
i differ for two trajectory combinations, i.e. the crossing trajectories N E/SW and ES/W N . Figure 4 shows how the crossing traversing distances dW NES and dESW N are dependent on which vehicle that has priority. In case a) the prioritized vehicle Vj have the trajectory W N (bolded). This particular vehicle must cover its full trajectory length before the deprior- itized vehicle Vi with trajectory ES can enter the intersection in order to avoid collision. This implies that dESW N > dW NES as
specified in Table II and Table III. However as in case b), if the prioritized vehicle Vj has the trajectory ES (bolded), then vehicle Vi with the trajectory W N must give way before it can enter the intersection, i.e. dW NES > dESW N.
Fig. 2: An illustration of possible points of collision risks for all trajectories.
Fig. 3: An illustration that shows an example for two trajec- tories in conflict where the traversing distances do not depend on which vehicle that has priority, i.e. WN in case a) and SN in case b).
Fig. 4: An illustration that shows an example for two trajecto- ries in conflict where the traversing distances depend on which vehicle that has priority, i.e. WN in case a) and ES in case b).
B. Vehicle Model
The vehicle characteristics that are taken into account are defined and described by the variables listed in Table IV, where the index k refers to the variables for any arbitrary vehicle Vk.
TABLE IV: Vehicle variables.
Notation Description Definition Unit
Xk= xk
yk
!
x- and y coordinates [m]
vk= vx,k
vy,k
!
x- and y velocity compo- nents
∂Xk
∂t [m/s]
Fk Force output [N]
Fkmax Force output limit [N]
ak Absolute acceleration Fk
mk
[m/s2] T rk Trajectory <start><target>
mk Mass [kg]
lk Length [m]
Akk Projected front area [m2]
The x- and y positions are defined to be relative the origin, the center of the intersection, see Figure 1.
Each vehicle’s throttle- and break dynamics are modeled with an individual PID-controller which emulates the use of cruise control [7]. The force output Fk of the vehicle depends on the current vehicle speed |vk| and a given speed request, vk,req, and also the upper force output limit Fkmax. The error in speed,
e = vk,req − |vk|
is fed into the PID-controller which returns a force output Fk
that depends on three parts, one that is proportional to the error (P), one that is proportional to the integral of the error (I) and finally one that is proportional to the derivative of the error (D). The output is given by the sum of the three, that is,
Fk= Kpe(t) + KI Z t
0
e(τ )dτ + Kd∂e(t)
∂t
for |Fk| ≤ Fkmax, and where Kp, KD and KI are weights that distributes the influence of the proportional, derivative and accumulated error to the force output.
The drag force is modeled with Fd,k= 1
2ρ|vk|2CDAk,
where ρ is the air density, CD is the drag coefficient, Ak is the projected vehicle front area and |vk| is the absolute speed.
The rolling friction force is modeled with Fw,k= Ckmkg,
where Ck is the coefficient of rolling resistance, mk is the mass of the vehicle and g is the gravitational constant. This results in the net force
Fnet,k = Fk− Fd,k− Fw,k
and resulting acceleration
ak =Fk− Fd,k− Fw,k
mk
.
The integral of the vehicle acceleration gives the speed of the vehicle,
vk= vk0+ Z t
0
akdt
where vk0is the speed of the vehicle entering the system, that is, when |Xk| = Dc, which is the communication boundary between the vehicle and intersection manager, and t is the elapsed time in the system.
III. AUTONOMOUSINTERSECTIONMANAGER
The AIM has a set of predefined parameters that describe the geometry of the system, e.g. the lane width and distance boundary for the communication range. Additionally, the AIM has dynamic parameters that describe distance- and speed margins for the vehicles, as well as the delay for the AIM.
Table V presents the set of parameters.
TABLE V: Geometry and margin variables.
Notation Description Unit
L Lane width [m]
Dc Communication boundary [m]
dMi,j Vehicle- to vehicle distance margin [m]
DM Minimum front-to-back distance between two ve- hicles
[m]
vmax Speed limit [m/s]
Td System delay [s]
A. Data exchange
The exchange of data between the vehicles and the AIM is comprehensively shown in the flowchart in Figure 5.
Fig. 5: Vehicle and AIM communication.
The vehicle-to-AIM data flow consists of the parameters presented in Table VI.
TABLE VI: Vehicle-to-AIM transmitted state variables
Notation Description Unit
ID Unique vehicle ID
Fmax,k Force output limit [N]
dk Absolute distance to the intersection [m]
|vk| Absolute velocity [m/s]
T rk Trajectory
lk Vehicle length [m]
B. Computation of state variables
Based on the speed |vk| of each vehicle Vk and its distance to the intersection, the estimated time to arrival is
Tk= dk
|vk| (1)
where dk is the vehicle’s distance to the intersection edge. If two vehicles Vi, Vj will arrive approximately at the same time to the intersection, then the time for vehicle Vi from entering the intersection to reaching the point hypothetical point of collision is
TT rT rj
i = dT rT rj
i
|vi| (2)
where dT rT rj
i is the traversing distance inside the intersection before a hypothetical collision with another vehicle. This implies that TT rT rj
i depends on the intersection size and the trajectories of both vehicles in question, see Table II and Table III in Section II-A. Lets also denote
dtoti,j ≡ di+ dT rT rj
i (3)
to compactly express the total distance for a vehicle i to a hypothetical point of collision with another vehicle. Note that dT rT rj
i and dtoti,j only makes sense if there is a risk of collision between vehicles i and j.
By taking into account the individual vehicle-to-intersection distance diand the vehicle-to-vehicle distance for two vehicles in conflict,
∆ij = q
(xi− xj)2+ (yi− yj)2 (4) and the vehicle’s trajectory distances inside the intersection before a hypothetical collision, the AIM calculates and sends a speed request vreqto the not prioritized vehicle. This is done in order for the vehicles to fulfill the distance margin criterion,
dMij = DM +1
2(li+ lj) +
where the vehicles trajectories cross, that is, the vehicle-to- vehicle distance ∆ij converges to dMij at that given point in time. The vehicles lengths liand ljare taken into consideration as safety-margins, and the parameter is supposed to be covering common expected error sources, such as the GPS signal error, GPS receiver quality and environmental signal blockage between the vehicles and the AIM. The frequency of which the speed requests are sent to the vehicles inside the communication boundary is 1/Td where Td is the system delay that considers the data rate and quality in the software and hardware of the AIM.
The algorithm is explained in depth in following section.
IV. CONTROLALGORITHM
In this section the control algorithm is presented that takes three critical concepts into account; 1) trajectory conflicts 2) vehicle distance prioritization and 3) motion planning based on speed requests.
One significant reason to enter an intersection at the highest allowed and possible speed is to maximize the vehicle flow by preventing vehicles from unnecessarily slowing down, or even completely stopping, before entering the intersection [3]. The core of the algorithm is to identify trajectory conflicts between all of the vehicles in the system and specify the priority for each vehicle.
A. Priority
When defining the priority of respective vehicle within the communication zone, shown in Figure 6, an appropriate parameter of priority is needed. In this case the vehicles follow the First Come, First Served (or FCFS) principle. For that reason, this algorithm is determined to operate based on the momentary distance to the intersection edge for each vehicle Vk, that is, dk(t). For a set
Vc=Vc1, Vc2, . . . , Vcn
where each trajectory of the vehicles is at least at one point coinciding with each other according to Figure 1 and Table I in Section II-A, for instance vehicles arriving from a mutual start position, it must hold that if
dc1(t0) < dc2(t0) < . . . < dcn(t0) at some arbitrary time t = t0, then also
dc1(t) < dc2(t) < . . . < dcn(t), ∀t
while each vehicle Vkremains within the communication zone.
On the contrary, for a set
Vnc=Vnc1, Vnc2, . . . , Vncn
only including vehicles with non-coinciding trajectories are not restricted by this, i.e. if at a certain time
ds(t0) < dt(t0),
where s, t are index of two vehicles Vs, Vt∈ Vnc, then ds(t0+ ∆t) > dt(t0+ ∆t)
at some later time t = t0+∆t is a possible outcome. Handling either of these two sets is a straight forward process; assuming a system only with vehicles belonging to the first set Vc, then each vehicle Vk is allowed to enter the intersection one by one while prioritizing the ones with the shortest distances dk(t) according to a simple queue. In a system only with vehicles in the latter set Vnc on the other hand, all of the vehicles are approved to enter the intersection simultaneously with maximum allowed speed vmax. However, for a hybrid set
Vh⊆Vc∪ Vnc
Vh6= Vc and Vh6= Vnc , some of the vehicles are in risk of collision whereas others are not, which implies a more complex process of prioritization and a systematic solution is needed.
Fig. 6: Illustration of the communication boundary zone from the simulation environment.
B. Linear Projection
When a conflict for two individual vehicles is detected, that is, their trajectories are at some point coinciding, the AIM calculates and sends speed requests to each of them which is based on their distances and estimated times for reaching the hypothetical point of collision defined in Section III-B.
This is done according to a concept which is to be denoted by Linear Projection and is illustrated in Figure 7. It is used to derive the expression for the speed request intended for a vehicle Vi. The concept Linear Projection is a projection of the states of the vehicle Vi and another arbitrary vehicle Vj
(observe that dj < di!) evaluated at some point of time after the momentary time t = t0 when the first vehicle Vj arrives to the hypothetical point of collision, that is, at
t = t0+ Tj+ TT rT ri
j ≡ Ttoti,j.
The estimation is a linearization of the total distances to the hypothetical point of collision according to equation (3), i.e.
dtoti,j(t) ≈ dtoti,j(t0) − |vi,j(t0)|(t − t0).
This approximation is updated each iteration and therefore converges to the actual distances. The estimated distance between the vehicle in question and another arbitrary vehicle Vj at any point in time is given by equation (4).
In order for the vehicles to have a predetermined distance margin DM when vehicle Vj arrives at the hypothetical collision position, ∆ij must converge to and reach dMij at that given instance. This is achieved by sending a speed request to vehicle Vi, which is expected to arrive after vehicle Vj. First, the estimated time at t = t0 until intersection arrival for vehicle Vj, i.e. Tj defined in equation (1), is calculated.
By taking the traversing time TT rT ri
j of vehicle Vj defined in equation (2) into consideration, the speed request
vi,req= dtoti,j− DM
Ttoti,j (5)
is calculated for vehicle Vi, see Figure 7. This assures that when vehicle Vj arrives at the position of hypothetical
collision, the distance ∆ij between the two vehicles indeed is approximately dMij.
Fig. 7: Linear Projection. State variables when vehicle Vj
arrives to the intersection are estimated by linearization to calculate required speed to avoid collision.
C. The algorithm
Since the FCFS principle is followed in events of limited space, each of the m vehicles V1, V2, . . . , Vm that are rel- evant, i.e. vehicles within the communication zone so that dk ≤ Dc− L, are sorted as representing objects in an abstract data queue with respect to their distance to the origin, implying that d1< d2< . . . < dm. This queue and the following steps are illustrated in Figure 8.
Now, the first step is sending a speed request with the maximum allowed speed to the first vehicle V1 represented in the queue, i.e. v1,req= vmax. The second object in the queue is then denoted as i so that i = 2 and is to be compared with the object j = i − 1 = 1 ahead (Step 2.1, 2.2 in Figure 8).
In a general case, i representing vehicle Vk is to be iteratively compared with all of the objects j ∈i − 1, i − 2, . . . , 2, 1 (Step k.2, k.3, . . . , k.k) ahead with shorter distances. This is performed upwards in the queue by decreasing index j so that j = j − 1 after every iteration. Each comparison is to detect whether there is a risk of collision between the two vehicles Vi and Vjaccording to the adjacency matrix in Figure I. If no risk of collision is detected after iterating until the final index j = 1, then the speed limit vmax is sent as speed request vreq to Vi. However, if a risk of collision is detected with some object j, the estimated trajectories of the two vehicles Vi and Vj are to be investigated with Linear Projection. This is repeated for the objects j until a hypothetical collision is confirmed with vehicle Vq1. For each comparison confirming a hypothetical collision, a proposed restricting speed request vqk,req, ∀k = 1, 2, . . . according to equation (5) is calculated and appended to a list vres = vq1,req, vq2,req, . . . . If any of the restricting speed requests are less than the maximum allowed speed, then the least value is sent as a speed request to Vi, i.e. vi,req = min
∀k vqk,req, vmax , as it has to slow down sufficient to bypass collision with each of the vehicles in conflict that are to arrive before. When the speed request is
sent to Vi, it means that the current j-loop is terminated and object i is to be shifted to the next object i + 1 behind (Step 2.1). Again as in the previous process it is to be compared with objects ahead starting with the new object j = i − 1.
This new j-loop is again iterating until the index j = 1, i.e.
it has reached the first object, while simultaneously saving restricting speed requests before sending one. This double i, j- loop is carried on until object i = m which is the last object and therefore all vehicles have been compared in the particular instance. The next step at this state is to check whether a new relevant object is detected and in that case add it to the queue. Also, current objects in the queue that have left the intersection are not relevant anymore and are to be removed.
Note that a new local index is again introduced, so that the relevant vehicle objects are denoted by 1, 2, . . . m where m as before is the latest added object. The control algorithm is also described with a flowchart in Figure 9. The process of the control algorithm is repeated resulting in conservation of the traffic flow while ensuring that the vehicles are keeping distance margins to prevent collisions.
Fig. 8: Priority queue of the control algorithm.
V. SYSTEMROBUSTNESS
Little’s law [8], which is a result of importance in queuing theory, explains that the average number of objects in a system N is equal to the average arrival rate λ times the average time W an object is spends in the system, i.e.
N = λW.
Little’s law shows that the largest flow of vehicles an inter- section and included roads can manage is equal to the upper limit of N divided by the lower limit of W,
λmax= Nmax
Wmin
Therefore there are two ways to raise the maximum flow of vehicles; either by increasing the average number of of vehicles in the system, or by decreasing the average time a vehicle is present in the system. This implies that a vehicle should maintain a high speed in the system. However, as already stated, the number of vehicles in the system can not be arbitrarily large as there is a limit for how many vehicles the roads can fit.
Initialize empty queue.
Input: If new relevant object ≡ m
detected: append to queue. Remove irrelevant objects.
Sort the m objects in queue by shortest
distance so that d1 < d2 < . . . < dm.
Send v1,req = vmax
to V1. Denote second object
by i, i.e. i = 2.
Initialize empty list vres. Denote other
object by j, so that j = i − 1.
Is object j = 1, i.e. first?
Is object i = m, i.e. last?
Shift object i to next
behind:
i = i + 1.
Compare object i with object j.
Risk of collision for
Vi, Vj
according to adjacency
matrix?
Shift object j to next ahead:
j = j − 1.
Perform Linear Projection.
Append calculated vreq to vres. Send vi,req =
min
∀k vres,k, vmax to Vi.
Yes No
No
No
Yes Yes
Fig. 9: Flowchart of the control algorithm.
The theoretical upper limit for the number of vehicles in the system, bounded by the communication boundary Dc, is given by
Nmax= 4Dc
n Pn
i=1(li+ DM) (6) where 4Dc is the total road length of the four lanes, li is each vehicles length, DM is the distance margin between each vehicle and n is the momentary number of vehicles in the system at an arbitrary point in time. This implies that equation (6) calculates the total road distance divided by the average vehicle length of the vehicles in the system in addition to the distance margin. This holds assuming that the lanes are fully saturated, that is, all vehicles are uniformly distributed across all four lanes with the distance margin DM to each other. The implication of this is that if N > Nmax congestion is built up. Since the length of the vehicles in practice is not constant, Nmax is dynamic. The implication of this is that Nmax is the maximum number of vehicles the system can hold with the assumption that the length distribution for all vehicles is according to the actual vehicles present in the system, for every point in time.
In order for this requirement to be fulfilled, the average throughput, β, must converge to the average rate of incoming vehicles, λ, as
τ →∞lim Z t0+τ
t0
(λ − β)dt = 0 (7)
where t0is a starting point in time and τ is a time of measure.
This implies that the upper limit of the average throughput that can be achieved, βmax, must be greater or equal to the average incoming vehicle rate λ, that is,
λ ≤ βmax.
There are therefore two requirements to be fulfilled to maintain an unsaturated system without congestion over a long period of time;
(N ≤ Nmax
β → λ ≤ βmax
where β is the actual average throughput, which must converge to λ according to equation (7).
VI. TRAFFICLIGHTS
In this section a model for traffic lights is introduced to represent traditional traffic management. The purpose is to generate data that the developed AIM can be compared with.
It is assumed that all geometrical assumptions are identical defined as previous i.e. one lane etc.
To begin with, one cycle length C is the period of time for all signal indicators to serve all four lanes once, that is,
C = 4(G + Y ),
where G is the time for green indicator and Y for the yellow indicator. The traffic light simulation can be in two possible
states; either one of the four signals of the lanes is green while the others are red implying only vehicles in that lane are allowed to pass, or the other state where the two signals that are about to shift from red to green or vice versa are yellow while the others are red, meaning no vehicle is allowed to pass at all. Figure 10 shows the principle of a traffic light test performed in our developed simulation environment, where only one lane at the time has free way.
Fig. 10: Image of a saturated test with traffic lights from the developed simulation environment.
VII. EXPERIMENTALRESULTS
In this section experimental results from simulations are presented in order to evaluate the efficiency, robustness and liability of the system. The tests are performed in our devel- oped simulation environment programmed in C# which allow for real time visual monitoring of the vehicles and the access of dynamic vehicle parameters and statistical data.
Three tests are performed, two with the developed system and one test that considers traffic lights. The first test is stable and is covered in Section VII-A. Then in Section VII-B the second test is performed with full vehicular saturation and reveals the limitations of the proposed system. Finally in Section VII-C a saturated simulation with traffic lights is presented to allow comparisons, which are covered in Section VII-D.
For each simulation, vehicles are spawned from a random position, <N>, <E>, <S> or <W>, in intervals of the period Tspawn and with an incoming speed of venter. Additionally, the intersection speed limit vmax, the distance margin DM and the maximum force output Fmaxfor each vehicle are predeter- mined and taken into consideration. With the assumption that all vehicles have the mass m = 2000kg and an acceleration and retardation limit of amax = 3m/s2, consequently the maximum force output Fmax= mamax= 6000N . The PID- controller parameters are empirically selected to Kp = 500, KI = 1 and Kd= 10, i.e. are specified in a way such that the dynamics of the vehicles correspond to reasonable limitations for vehicles today. The purpose of the settings mentioned is thus also to enable the behavior of the simulated vehicles to coincide with human way of driving. The parameters that are considered in all simulations are shown in Table VII.
TABLE VII: Predetermined simulation parameters for all considered tests.
Notation Description Value Unit
Simulation time 360 [s]
Dc Communication boundary 350 [m]
venter Incoming vehicle speed 20 [m/s]
vmax Intersection speed limit 20 [m/s]
DM Distance margin 5 [m]
Fmax Force output limit 6000 [N]
m Vehicle mass 2000 [kg]
l Vehicle length 5 [m]
Distance margin of common ex- pected errors
0 [m]
Td System delay 0.5 [s]
Kp Proportional constant 500
KI Integral constant 1
Kd Derivative constant 10
A. Simulation 1: Stable
The first simulation shows a results from a stable test, where the system does not get saturated. The incoming vehicle time interval Tspawn and corresponding rate λ = 1/Tspawn are shown in Table VIII.
TABLE VIII: Vehicle inflow rate for Simulation 1: Stable.
Notation Description Value Unit
Tspawn Incoming interval 1 [s]
λ Incoming rate 1 [1/s]
Figure 11 shows that the average rate of incoming vehicles and the average rate of passing vehicles are converging, which is in alignment with equation (7), that implies that the system will not get over saturated.
Fig. 11: Vehicle inflow and outflow, Simulation 1: Stable. The outflow converges to the inflow.
As shown in Figure 12 below, the number of incoming vehicles in the system N has a upper limit of 18, which is less than the saturated limit Nmax= 140 for l = 5.
Table IX shows the calculated robustness parameters along with the statistical data from the simulation.
Fig. 12: Vehicles in the system, Simulation 1: Stable.
TABLE IX: Results for Simulation 1: Stable.
Parameter Value Comment
Nmax 140 For l = 5
N 18 N < Nmax, not saturated
λ 1
β [0, 0.95] for t ∈ [0, 360]s β converges to λ
B. Simulation 2: Saturated
The second simulation shows an over saturated scenario, where the number of incoming vehicles in the system exceeds the limit Nmax, due to the lowered interval of incoming vehicles Tspawn, i.e. increased λ, see table X.
TABLE X: Vehicle inflow rate for Simulation 2: Saturated.
Notation Description Value Unit
Tspawn Spawn interval 0.5 [s]
λ Incoming rate 2 [1/s]
Figure 13 shows that the rate of incoming vehicles and passing vehicles do not converge as λ = 2 and β converges to approximately 1.5, which is not in alignment with the robustness criteria, see equation (7), as β < λ.
Fig. 13: Vehicle inflow and outflow, Simulation 2: Saturated.
The fact that the throughput β does not converge to the inflow λ implies that the number of vehicles in the system will increase with time without any upper limit. Figure 14 shows how the number of incoming vehicles in the system accumulates with time.
Fig. 14: Vehicles in the system, Simulation 2: Saturated.
Congestion is accumulated as the number of vehicles in the system increases beyond the maximum upper limit Nmax.
The lowered interval of incoming vehicles Tspawnincreases the inflow λ to an extent which the throughput β can not reach which is shown in Table XI. The over saturation of vehicles implies that the throughput β does converge to the maximum throughput βmax, see Figure 13 and Table XI. However, as already presented, since λ > β = βmax the robustness criterion in equation (7) is not fulfilled, and congestion is therefore accumulated.
TABLE XI: Results for Simulation 2: Saturated.
Parameter Value Comment
Nmax 140 For l = 5
N 181 N > Nmax, over saturated
λ 2
βmax ≈ 1.5
β ≈ 1.5 β = βmax< λ
C. Simulation 3: Traffic lights
In order to compare the performance of the developed system, with intersection management based on traffic lights, a traffic light test in our developed simulation environment is also performed. The simulation proposes a maximum capacity test filling all four lanes with vehicles, with each vehicle having a front-to-end distance DM = 5m, to correspond to a realistic scenario with fully saturated roads. For this test the signal time parameters G = 25s and Y = 5s are used which gives a cycle length of C = 120s which is typical for intersections with high approach speeds [9]. Table XII present the test parameters, which is in alignment with the saturated test in Section VII-B.
TABLE XII: Parameters, Simulation 3: Traffic lights.
Notation Description Value Unit
Simulation time 360 [s]
G Period of green signal 25 [s]
Y Period of yellow signal 5 [s]
C Period of complete cycle 120 [s]
Fig. 15: Vehicle outflow, Simulation 3: Traffic lights.
Fig. 16: Passed vehicles, Simulation 3: Traffic lights.
The simulation shows that the rate of passing vehicles converges to approximately 0.68 vehicles per second according to Figure 15. The total amount of passed vehicles over time is shown in Figure 16, where the five second yellow light delay with a 25 second interval is spotted by observing the postpone in passed vehicles. The statistical data for the simulation, that is, the number of passed vehicles and the average throughput β are presented in Table XIII.
TABLE XIII: Results, Simulation 3: Traffic lights.
Parameter Value Comment
P 245 Passed vehicles
β ≈ 0.68 Average throughput
D. Comparison
The following comparisons that considers the performance of intersections managed by 1) our developed AIM, and 2) traffic lights, intends saturated flow, that is, the particular simulations done in Section VII-B and Section VII-C. The simulations are, as already presented, performed with equiva- lent conditions, i.e. the basis of the vehicles are the same in order to represent as equal tests as possible.
Plotting the average throughput over time shows that the rate of passing vehicles for the autonomous intersection is greater than for the regular traffic light case, see Figure 17.
Figure 18 presents the number of passed vehicles with respect to time for both cases, comparing the two shows that
Fig. 17: Comparison of the vehicle outflow.
Fig. 18: Comparison of the numbers of passed vehicles.
the capacity is higher for the intersection managed with the AIM.
The results show that the AIM can perform better compared the scenario of simulating traffic lights, in the sense of vehicle throughput. Table XIV presents the number of passed vehicles PAIM, PT Land the average outflows βAIM, βT Lfor respective simulation.
In these particular tests where the used environmental and vehicular parameters are according to Table VII and Table XII, the relative quotient of the outflow for the two tests is
βAIM− βT L
βT L
≈ 1.2
This implies that the AIM is approximately 120% more effi- cient than the use of traffic lights considering the throughput for the specific setting.
TABLE XIV: Results regarding the throughputs and passed vehicles, comparison between Simulation 2: Saturated and Simulation 3: Traffic lights.
System Parameter Value Comment
AIM PAIM 539 Passed vehicles
AIM βAIM ≈ 1.5 Average throughput
Traffic lights PT L 245 Passed vehicles Traffic lights βT L ≈ 0.68 Average throughput
