Using Intelligent Traffic Lights to reduce vehicle emissions Adriana Szekeres Department of Computer Science University Politehnica of Bucharest Scientific coordinators: Prof. Valentin Cristea, University ”Politehnica” of Bucharest Ing. Ciprian Dobre, University ”Politehnica” of Bucharest July 2009
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Using Intelligent Traffic Lights to
reduce vehicle emissions
Adriana Szekeres
Department of Computer Science
University Politehnica of Bucharest
Scientific coordinators:
Prof. Valentin Cristea, University ”Politehnica” of Bucharest
Ing. Ciprian Dobre, University ”Politehnica” of Bucharest
Continuous research in ITS is being conducted. The World Congress and
Exhibition on Intelligent Transport Systems and Services, takes place in Stock-
holm in September 2009. The 16th annual event, which rotates between Europe,
the Americas and the Asia-Pacific region, comes to Sweden for the first time
and takes place at Stockholm International Fairs (Stockholmsmssan), from 21st
- 25th September 2009. The theme of this prestigious event is ITS in Daily Life,
exploring how ITS can improve everyday mobility.
2.4 Vehicular Ad-hoc NETworks
Vehicular Ad Hoc Networks (VANETs) are a special kind of networks that form
between cars that are able to communicate with other cars (vehicle-to-vehicle
communication) or with other roadside base stations (vehicle-to-infrastructure
communication). To be able to communicate with eachother or with the in-
frastructure, the cars are equiped with short-distance communication devices. A
major advantage of VANETs is that they don’t need an infrastructure and do not
use a central administration so that the nodes can communicate with each other.
However, VANETs are not without problems. Due to the great mobility of the
nodes, VANETs can suffer rapid changes in the topology, frequent node discon-
nections, as well as information waste. A serious issue with VANETs is also the
security. The security of such networks is addressed in Raya & Hubaux (2007).
The authors present some possible threats and the corresponding solutions.
18
2.5 Travolution
2.5 Travolution
After two years of research Audi has developed a traffic management system,
Travolution, who aims at reducing car emissions. Travolution is based on vehicle-
to-semaphore communication. The semaphore will inform the car about the time
until a color phase changes.
The 1.2 milion ¤project has already been tested. In Ingolstadt, the home of
Audi, 46 ”intelligent” semaphores have been synchronized to minimize stopped
time and pollution. Three of them have been equiped with Travolution system
to be able to communicate with also specially equipped Audi A5 and A6 Avants.
The testing will continue and more Travolution systems will be deployed.
19
Simulation Environment
Testing a VANET application is a very expensive process when using real cars,
real equipment and real roads. Real testing should be done only as a final stage
of the project. Instead, a VANET simulator can be used. To test my application
I have decided to use VNSim, described in Gorgorin et al. (2006). Developed
at University ”Politehnica” of Bucharest, VNSim is a microscopic simulator1
that implements the components nedeed for any VANET application: wireless
communication module, mobility module, map simulator module, etc.
3.1 VNSim System Architecture
VNSim is an event-based traffic simulator which works on discrete time incre-
ments. This means that, at each time increment, all the current events2 are
pulled from the queue of events and handled randomly. After executing all han-
dling code, the simulation time progresses to the next time increment.
Three types of events have been considered: send, receive and GPS (see Figure
3.1 for the complete architecture of VNSim - the picture was taken from Gorgorin
et al. (2006)). When a send event is pulled from the queue of events, the execution
of a handler function is triggered. This function prepares the message to be sent
and then it schedules the corresponding receive events for all those nodes the
simulator decides to deliver this message to (for example, in case of a broadcast
message, all the nodes situated in the communication range of the sender will
receive this message). The GPS event is rescheduled periodically for each node.
1a simulator that takes into account the actions of each individual vehicle2events that have been scheduled to take place at the current simulation time
20
3.2 Mobility module
Figure 3.1: VNSim architecture
3.2 Mobility module
The mobility module is responsible with moving the car to its next position during
a time increment, according to a mobility model. The mobility model takes into
account the personality of the drivers, the interactions with other cars, traffic
rules, etc.
3.2.1 Maps
All traffic simulators should have a digital map on which to position the cars. In
VNSim, TIGER maps are used (see Bureau (2008)). These digital maps are avail-
able for free and consist of two types of files: Record Type 1 (RT1) and Record
Type 2 (RT2). RT1 files contain information about all the road segments of the
points of the road segments for representing the curves. The points are given in
terms of geographical coordinates (latitude and longitude). Interpolation is used
21
3.2 Mobility module
to compute more intermediate points. This will increase the accuracy of the map.
To compute the distance between two points on the map, VNSim uses conversion
tables from degrees to meters depending on the latitude and longitude.
Unfortunately, TIGER files lack some useful traffic-specific information, such
as the number of lanes on the roads, the slope of the roads and the positions of
traffic control systems (traffic lights, traffic signs, etc.). Knowing the slope of the
roads would have been vey useful for my application, beacause it influences the
forces that act on the car.
To integrate my application into VNSim I had to override a small part of the
mobility module. In the next section I will explain the implementation of this
complex module.
3.2.2 Implementation details
Using Java as the programming language, the implementation is based on the
object-oriented paradigm.
To be able to position the cars on roads, this module uses a representation of
the digital map, implemented as the Map class. This class contains an array of
objects of type Road and each road contains an array of objects of type CarIn-
stance. Class CarInstance models the vehicle’s behavior; imagine it as being the
driver. The most important method this class implements is the move() method.
This is where all the decisions about the next position of the car are made. To
predict the next position of the car1 three factors are taken into account: traffic
control systems, the position of adjacent vehicles, and the drivers personality.
Whenever the method move() is called, the driver starts analysing the traffic
conditions, to decide the wanted speed. At first, the traffic control system at the
next intersection is checked (for instance, if the next intersection is controlled
by a traffic light and the color is red, the driver should decelerate, assuming
that the distance between the car and the traffic light is sufficiently small). The
next intersection this car is going to pass through is represented by an object of
1assuming that the car has a predefined route; for example, the simulator knows when acar is turning left
22
3.3 Traffic data dissemination
type Intersection, stored in class CarInstance. The next intersection is computed
whenever the car changes the road segment. After checking the conditions at
the intersection, the adjacent vehicles are taken into account to make the final
decision. If the final decision implies a greater speed than the current one, the
driver accelerates with a predefined acceleration, according to his/her personality.
3.3 Traffic data dissemination
Traffic data dissemination basically refers to how data can be transfered between
cars forming a VANET. Two main mechanisms of traffic data dissemination are
explained in Nadeem et al. (2004): flooding and diffusion. In the flooding mecha-
nism, each node periodically broadcasts information about itself. On receiving a
broadcasted message, the node stores it in its database and immediately forwards
the message to any node within its range, by rebroadcasting it. In the diffusion
mechanism, each node broadcast information about itself and about the other
nodes from its database. In 3.2 the diffusion mechanism is illustrated. Assuming
that vehicles 2 and 3 are in the transmission range of vehicle 1 and vehicles 3 and
4 are in the transmission range of vehicles 2 and 3, respectively, and will stay this
way during two broadcast intervals. The final state of each vehicle’s database,
after the two broadcast periods, is illustrated in the third picture of 3.2.
I did’t explicitly use diffusion in my application, as the only information beeing
broadcasted and rebroadcasted is the information about the traffic light. How-
ever, I will test my application using fixed traffic ligths1 as well as adaptive traffic
lights2, described in Gradinescu (2006). In case of adaptive traffic lights, cars use
the diffusion mechanism to send information about themselves.
1traffic ligths that have a fixed, predefined phase length2traffc lights that can change their phase lenghts between cycles, e.g. they could extend the
green phase in case of a lengthy car queue
23
3.4 Fuel Consumption and Pollutant Emissions Estimation
Figure 3.2: Diffusion mechanism
3.4 Fuel Consumption and Pollutant Emissions
Estimation
VNSim can be used to estimate fuel consumption and pollutant emissions. This
is very useful for testing my application. This section describes the method used
to compute fuel consumption and emissions.
Estimating fuel consumption and pollutant emissions is a necessity when eval-
uating traffic management applications. To model fuel consumption and emis-
sions (CO2, CO, HC, NOx), the authors of VNSim used the work of Akcelik and
Besley, from Akcelik & Besley (2003). Akcelik and Besley describe the method to
estimate emissions and fuel consumption used in aaSIDRA1 and aaMOTION2.
The method presented in their paper has been simplified to take into account
only light vehicles.
The formula used to estimate the value of fuel consumed (mL) or emissions
produced (g), in a time interval (∆t), is:
1an intersection analysis package, developed by Akcelik and Associates 20022a single-vehicle microscopic simulation package that uses a time-step simulation model
24
3.4 Fuel Consumption and Pollutant Emissions Estimation
∆F = (fi + β1RTv + [β2Mva
2v
1000]a>0)∆t , RT > 0 (3.1)
∆F = fi∆t , RT ≤ 0 (3.2)
where:
• ∆ F [mL or g] - the quantity consumed or gas emitted (HC, CO, NOx)
during a time interval;
• v[m/s] - vehicle instantaneous velocity;
• a[m/s2] - acceleration;
• Mv[kg] - vehicle mass (1400 kg on average for light vehicles in a city envi-
ronment);
• RT [kN] - total force acting on a car, including air drag and rolling resistance;
RT = Mva+ Frr + Fad (3.3)
• Frr - rolling resistance force;
Frr = CrrMvg (3.4)
• Crr - rolling resistance coefficient, 0.15 on average for each tire (depends on
road surface)
• Fad - air drag force
Fad =1
2ρv2ACD (3.5)
– ρ - air density (1.29 kg/m3);
– A - frontal car area;
– CD - drag coefficient;
25
3.4 Fuel Consumption and Pollutant Emissions Estimation
• fi[mL/s or g/s] idle fuel consumption rate or gas emissions rate;
• β1[mL or g per kJ] fuel consumed or gas emitted per engine energy unit;
• β2[mL or g per (kJm/s2)] coefficient for fuel consumption or gas emissions
per unit of energy-acceleration, reflects the function behavior on positive
acceleration.
The values for fi, β1 and β2 are presented in Figure 3.3 and have been taken
from Akcelik & Besley (2003).
Figure 3.3: The values of the coefficients used in Equation 3.1
Carbon dioxide (CO2) is calculated based on the fuel consumed, with the
following formula:
∆F (CO2) = ∆F (fuel)fCO2 (3.6)
• fCO2 - the CO2 emission rate given per quantity of fuel [g/mL] (it is equal
to 2.5[g/mL] for light vehicles).
In Figure 3.4 there are three graphics showing fuel consumtion related to speed
and acceleration for vehicles passing through an intersection. (The picture was
taken from Gradinescu (2006))
26
3.4 Fuel Consumption and Pollutant Emissions Estimation
Figure 3.4: Fuel consumption for vechicles passing through an intersection
27
Design and Implementation
With the number of cars expected to double in the next 20 years, more efficient
traffic managemnt will be needed. Intelligent traffic lights systems and VANETs
have been given a lot of attention in the last years. The evolution of traffic lights
is very impressive considering that the simplest traffic lights operate on timers,
with predetermined periods of red, yellow and green. Today, complex traffic lights
systems can be deployed to help improve traffic conditions.
Intelligent traffic lights are traffic lights that are able to send useful informa-
tion to the approaching vehicles, to servers, to other traffic lights, etc. or that
are aware of the approaching vehicles and use this information to make decisions
that can smooth traffic flow.
4.1 System design
The intelligent traffic system we have developed is mostly based on traffic light-
to-vehicle and vehicle-to-vehicle communication (see Figure 4.1). We assume that
the traffic lights and the vehicles are equiped with short range communication
devices and computing power. The traffic lights are used to periodically broadcast
information about the current color of the lights and the time until it changes,
for each segment of road it controlls. The cars use the information received from
traffic lights to adjust their speed according to an algorithm that aims at reducing
the quantity of emissions. Also, because of the short communication range of the
traffic lights, the cars rebroadcast the message received from the traffic light.
28
4.1 System design
Figure 4.1: Intersection with intelligent traffic light
29
4.2 Implementation details
4.2 Implementation details
To be able to implement an application that predicts as accurate as possible the
movement of a car on a given distance, or in a given amount of time, I needed
a different mobility model than the one implemented in VNSim. All the previ-
ous applications/protocols tested with VNSim (see Gradinescu (2006), Gorgorin
(2006) and Ichimescu (2008)) didn’t need a very accurate mobility module, as
they were not focused on the movement of the car. My application is focused
more on the algorithms being run on the vehicles. These alghorithms need to
know with high precisions the future speed and position of the car. The inte-
gration with VNSim is important because it will enable testing the application
using complete scenarios (the maps simulator and the communication module
already implemented in VNSim will be of great use). In this section I will start
by describing the implementation of the application I have developed and then
I will continue with a description of how my application can be integrated into
VNSim.
4.2.1 The standalone application
By the standalone application I refer to the part of the application which has
not been integrated in VNSim and can be tested separately. The only thing that
I used from VNSim for this part of the project was the Estimating Emissions
module, which is described in the previous chapter (see Section 3.4).
The application has been written in Java. For a clear view of the entire
structure, the UML diagram is illustrated in Figure 4.2. In the next paragraphs
I will explain each of the implemented classes:
• DESolver - This class implements the Runge-Kutta 4 method to solve
ordinary differential equations.
• DifferentialEquation - This class represents an ordinary differential equa-
tion. Field s represents the independent variable (in our case it represents
time) and field q represents the array of dependent variables (in our case
these will be speed and distance). Field nrEq represents the number of
30
4.2 Implementation details
equations to be solved simultaneously. The most important method of this
class is getRightTerm. This abstract method, that must be implemented by
all the classes that extend this class, represents the value of the right-hand
expresion of the differential equation. For example, in Equation 2.25, the
function getRightTerm will return the value of v, evaluated at the current
values of zn and tn.
• Car - This class extends DifferentialEquation class and implements the
getRightTerm method using Equation 2.20. It also contains all the nec-
essary fields for implementing the equations discussed in the State of the
Art chapter, section Mechanical Physics. For example, field muR is the
rolling friction coefficient, field omegaE represents the engine revolutions
per minute, etc. This class can be extended by various classes to represend
different models of cars.
• OrdinaryLightCar - This class extends Car class to initialize the fields
for an ordinary light car. For example, the area field will be initialized with
2.1 m, the wheelRadius field will be initialized at 0.3186 m, etc.
• SimulatorEvaluation - This class implements the two algorithms applied
in case of green and red traffic lights (these simple algorithms are described
further in this section) and it is also used for testing.
4.2.1.1 The algorithm applied in case of green lights
This algorithm is applied when a car, approaching an intersection with traffic
light, is informed that the current traffic light color is green. The algorithm must
decide if the driver can catch the green light emitting a smaller quantity of gases
than stopping at the red light. The steps of the algorithm are:
• predict the movement of the car, assuming the driver tries to catch the
green light (he/she accelerates until the needed speed) and estimate the
emissions. The pseudocode for this part of the algorithm is:
31
4.2 Implementation details
Figure 4.2: UML class diagram for the standalone application
32
4.2 Implementation details
1 car .distance = 0 // the total distance traveled by the car2 car .time = 0 // the total time the car traveled3 timeIncrement = 0.06 // the time increment to apply runge-kutta4 car .setMode(”accelerate”)5 while car .distance < distanceToTrafficLight6 neededSpeed = (distanceToTrafficLight − car .distance)÷
(greenTime − car .time)7 if neededSpeed > MAXSPEEDALLOWED8 return // the driver cannot catch the green light9 if neededSpeed <= car .speed
10 car .setMode(”cruise”)11 car .updateSpeedAndLocation(timeIncrement) // this updates
car.time, car.speed and car.distance12 car .estimateEmissions()
• predict the movement of the car, assuming the driver maintains constant
speed, stops at the red color, then accelerates to the speed he had before
stopping and estimate the emissions. The pseudocode for this part of the
algrithm is:
1 car .distance = 0 // the total distance traveled by the car2 car .time = 0 // the total time the car traveled3 timeIncrement = 0.06 // the time increment to apply runge-kutta4 car .setMode(”cruise”) // the driver keeps a constant speed5 while car .distance < distanceToTrafficLight − 100
// assume the driver starts to break100m before the intersection
6 car .updateSpeedAndLocation(timeIncrement)7 car .estimateEmissions()8 car .setMode(”break”) // the driver breaks to stop to the red light9 while car .distance < distanceToTrafficLight
10 car .updateSpeedAndLocation(timeIncrement)11 car .estimateEmissions()12 car .setMode(”accelerate”)
// the driver accelerates to the speed he had before stopping13 while car .speed < WANTEDSPEED14 car .updateSpeedAndLocation(timeIncrement)15 car .estimateEmissions()
33
4.2 Implementation details
• compare the results obtained in the two situations and recommend the
optimal speed to the driver
4.2.1.2 The algorithm applied in case of red lights
This algorithm is applied when a car, approaching an intersection with traffic
light, is informed that the current traffic light color is red. The algorithm must
decide if, upon reducing the speed in order to enter the intersection when the
light color is turning green, the quantity of emissions is smaller. The steps of the
algorithm are:
• predict the movement of the car, assuming the driver reduces the speed in an
attempt to avoid the red light and estimate the emissions. The pseudocode
for this part of the algorithm is:
1 car .distance = 0 // the total distance traveled by the car2 car .time = 0 // the total time the car traveled3 timeIncrement = 0.06 // the time increment to apply runge-kutta4 car .setMode(”break”)5 while car .distance < distanceToTrafficLight6 neededSpeed = (distanceToTrafficLight − car .distance)÷
(greenTime − car .time)7 if neededSpeed < MINSPEEDALLOWED8 return // the driver cannot avoid the red light9 if neededSpeed >= car .speed
10 car .setMode(”cruise”)11 car .updateSpeedAndLocation(timeIncrement) // this updates
car.time, car.speed and car.distance12 car .estimateEmissions()
• predict the movement of the car, assuming the driver maintains constant
speed, stops at the red color, then accelerates to the speed he would have
needed to avoid the red light, if that would have been possible. The pseu-
docode for this part of the algrithm is:
34
4.2 Implementation details
1 car .distance = 0 // the total distance traveled by the car2 car .time = 0 // the total time the car traveled3 timeIncrement = 0.06 // the time increment to apply runge-kutta4 car .setMode(”cruise”) // the driver keeps a constant speed5 while car .distance < distanceToTrafficLight − 100
// assume the driver starts to break100m before the intersection
6 car .updateSpeedAndLocation(timeIncrement)7 car .estimateEmissions()8 car .setMode(”break”) // the driver breaks to stop to the red light9 while car .distance < distanceToTrafficLight
10 car .updateSpeedAndLocation(timeIncrement)11 car .estimateEmissions()12 car .setMode(”accelerate”)
// the driver accelerates to the speed he had before stopping13 while car .speed < NEEDEDSPEED14 car .updateSpeedAndLocation(timeIncrement)15 car .estimateEmissions()
• compare the results obtained in the two situations and recommend the
optimal speed to the driver
4.2.2 Integration with VNSim
To integrate the application with VNSim, some classes of the vehicular simulator
must be extended, in order to override some important methods. For a clear view
of the integration module, see Figure 4.3. In the next paragraphs I will explain
all the classes from the integration module:
• EmissionsCar - This class extends the SimulatedCarInfo class. The Sim-
ulatedCarInfo class represents the car node in the vehicular simulator. The
car is equiped with a radio device, simulated by class Radio, in order to
transmit/receive messages. The important method this class implements
and which I have overriden, is onReceive. This method is called whenever
this car receives a packet. If the packet contains a message from the traffic
light, one of the two algorithms presented in the previous section, will be
applied.
35
4.2 Implementation details
• EmissionsTrafficLight - This class extends the WirelessTrafficLight class
and overrides the method prepareMessage to permit the traffic light to
broadcast periodical messages about the current state of the traffic lights
colors and durations.
• EmissionsDriver - This class simulates the car driver. It extends the
CarInstance class and overrides the method move. This method is respon-
sible with finding the next position and speed of the car.
• SegmentLightsInfo - This class is used for creating the message sent by
the traffic light. It contains information about the current color and its
duration for a specific road segment, controlled by the traffic light.
• TLMessage - This class simulates a message sent from the traffic light.
For each segment of road controlled by the traffic light, an object of type
SegmentLightsInfo is created. This class contains the timestamp1, the cycle
length and an array of SegmentLightsInfo.
1the time when this message was created
36
4.2 Implementation details
Figure 4.3: UML class diagram for integration in VNSim
37
Experimental Results and
Analysis
This chapter presents all the experimental results obtained for the standalone
application (see Design and Implementation, 4.2.1). The integration with VNSim
has not been finished so this section will not contain complete scenarios; it will
contain scenarios that involve only one car.
5.1 Preliminary experiments
This section illustrates how acceleration influences the emissions rate. The fol-
lowing graphics show the results of two different scenarios for typical driver be-
haviours 1. In the first scenario, the driver keeps accelerating until the car reaches
30 m/s. Figure 5.1 illustrates how speed and acceleration change in time. In the
second scenario, the driver accelerates until the car reaches 15.22 m/s and then
he/she maintains a constant speed (see Figure 5.3).
Looking at the acceleration curve in Figures 5.1 and 5.3, two observations can
be made: 1) the very steep slopes (three in Figure 5.1 and two in 5.3) are due to
gear shifting and 2) acceleration is decreasing in time, due to the gear ratio (see
Mechanical Physics section, 8) and the increasing drag force. The quantity (in
grams) of emitted CO2 and CO in the first scenario, is shown in Figure 5.2 and
the results of the second scenario can be visualized in Figures 5.4 (in which the
car traveled for the same amount of time as the one in the first scenario) and 5.5
(in which the car traveled the same distance as the one in the first scenario).
1assuming that the same car is used
38
5.1 Preliminary experiments
Figure 5.1: A car that accelerates from 0 km/h to 108 km/h
Figure 5.2: The emissions of a car that accelerated from 0 km/h to 108 km/h
39
5.1 Preliminary experiments
Figure 5.3: A car that accelerates from 0 km/h to 54.8 km/h and then maintains
a constant speed
Figure 5.4: The emissions of a car that accelerated from 0 km/h to 54.8 km/h
and than maintained a constant speed - the car traveled a given amount of time
40
5.1 Preliminary experiments
Figure 5.5: The emissions of a car that accelerated from 0 km/h to 54.8 km/h
and that maintained a constant speed - the car traveled a given distance
Comparing the results of the two scenarios, it can be noticed that the quantity
of gases emitted by the car in the second scenario (≈ 129g of CO2), is smaller
that the one obtained in the first scenario (≈ 360g of CO2). (Noticing the slope
of the emissions curve in Figure 5.5 we can compute the total distance the car
can travel until its emissions reach the ones in Figure 5.2 - TODO).
41
5.2 Experimental results of the decision algorithm - green traffic lights
5.2 Experimental results of the decision algo-
rithm - green traffic lights
This section presents the experimental results obtained with the use of the al-
gorithm applied in case of green traffic light, described in the previous chapter
(see Design and Implementation, 4.2.1.1). The algorithm has been used in two
scenarios.
In the first scenario, a car traveling at 40 km/h ( ≈ 11 m/s) has 15 seconds to
catch the green light. The distance between the traffic light and the car is 200 m.
The algorithm predicts the speed and acceleration of the car until it passes the
intersection and estimates the quantity of emissions in two possible situations: 1)
the driver tries to catch the green light and accelerates until the needed speed is
reached (see Figure 5.8) and 2) the driver maintains a constant speed, stops and
waits at the red light and then accelerates until the previous speed is obtained
(see Figure 5.6). The estimated quantity of emissions is illustrated in Figures 5.9
- for the first situation (≈ 54 grams of CO2) and 5.7 - for the second situation
(≈ 96 grams of CO2). Based on these results, the system advises the driver to
accelerate (until ≈ 62 km/h (≈ 17.2 m/s) is reached) in order to catch the green
light. By doing this, the driver could reduce the quantity of CO2 by 42 grams.
In the second scenario, the same car, now traveling at 22km/h (≈ 6 m/s), has
to catch the green light, given the same conditions as in the previous scenario. As
before, the algorithm predicts the speed and acceleration of the car until it passes
the intersection and estimates the quantity of emissions in the two situations
described earlier: 1) illustrated in Figure 5.12 and 2) shown in Figure 5.10. The
estimated quantities of emissions for the two situations are shown in Figure 5.13
(≈ 110 grams of CO2) and Figure 5.11 (≈ 58 grams of CO2), respectively. Based
on these results the system advises the driver not to accelerate, in the attempt to
catch the green light. If the driver complies with this suggestion, he/she would
reduce the quantity of CO2 by 52 grams.
42
5.2 Experimental results of the decision algorithm - green traffic lights
Figure 5.6: A car traveling at a constant speed of ≈ 11 m/s, stops at the red
traffic light and then accelerates until it reaches the same speed again
Figure 5.7: The gases emitted by the car described in Figure 5.6
43
5.2 Experimental results of the decision algorithm - green traffic lights
Figure 5.8: A car traveling at ≈ 11 m/s accelerates in order to catch the green
light
Figure 5.9: The gases emitted by the car described in Figure 5.8
44
5.2 Experimental results of the decision algorithm - green traffic lights
Figure 5.10: A car traveling at a constant speed of ≈ 6 m/s, stops at the red
traffic light and then accelerates until it reaches the same speed again
Figure 5.11: The gases emitted by the car described in Figure 5.10
45
5.2 Experimental results of the decision algorithm - green traffic lights
Figure 5.12: A car traveling at ≈ 6 m/s accelerates in order to catch the green
light
Figure 5.13: The gases emitted by the car described in Figure 5.12
46
5.3 Experimental results of the decision algorithm - red traffic lights
5.3 Experimental results of the decision algo-
rithm - red traffic lights
This section presents the experimental results obtained with the use of the algo-
rithm applied in case of red traffic light, described in the previous chapter (see
Design and Implementation, 4.2.1.2). The algorithm has also been used in two
scenarios.
In the first scenario, a car traveling at 60 km/h ( ≈ 16.6 m/s) approaches a red
traffic light color which will last for the next 20 seconds. The distance between
the traffic light and the car is 200 m. The algorithm predicts the speed and
acceleration of the car until it passes the intersection and estimates the quantity
of emissions in two possible situations: 1) the driver tries to reduce speed in
order to avoid the red color (see Figure 5.14) and 2) the driver maintains a
constant speed, stops and waits at the red light and then accelerates until the
speed needed to avoid the red color (in the first situation) is obtained (see Figure
5.16). The estimated quantity of emissions is illustrated in Figures 5.15 - for the
first situation (≈ 28 grams of CO2) and 5.17 - for the second situation (≈ 75
grams of CO2). Based on these results, the system advises the driver to reduce
the speed (until ≈ 34 km/h (≈ 9.47 m/s) is reached) in order to avoid the red
light color. By doing this, the driver could reduce the quantity of CO2 by 47
grams.
In the second scenario, the same car, now traveling at the same speed (60km/h),
approaches a red traffic light color which, this time, will last for the next 40 sec-
onds. As before, the algorithm predicts the speed and acceleration of the car until
it passes the intersection and estimates the quantity of emissions in the two situ-
ations described earlier: 1) illustrated in Figure 5.14 and 2) shown in Figure 5.16.
The estimated quantities of emissions for the two situations are shown in Figure
5.15 (≈ 46 grams of CO2) and Figure 5.17 (≈ 37 grams of CO2), respectively.
Based on these results the system advises the driver not to reduce the speed, in
the attempt to avoid the red light. If the driver complies with this suggestion,
he/she would reduce the quantity of CO2 by 9 grams.
47
5.3 Experimental results of the decision algorithm - red traffic lights
Figure 5.14: A car traveling at 60 km/h (≈ 16.6 m/s) stops at the red traffic light
and then accelerates until it reaches the speed it would have needed to avoid the
red color (which lasted for 20s), if possible
Figure 5.15: The gases emitted by the car described in Figure 5.14
48
5.3 Experimental results of the decision algorithm - red traffic lights
Figure 5.16: A car traveling at at 60 km/h (≈ 16.6 m/s) reduces speed to 34
km/h (≈ 9.47 m/s) in order to avoid stopping at the red light
Figure 5.17: The gases emitted by the car described in Figure 5.16
49
5.3 Experimental results of the decision algorithm - red traffic lights
Figure 5.18: A car traveling at 60 km/h (≈ 16.6 m/s) stops at the red traffic light
and then accelerates until it reaches the speed it would have needed to avoid the
red color (which lasted for 40s)
Figure 5.19: The gases emitted by the car described in Figure 5.18
50
5.3 Experimental results of the decision algorithm - red traffic lights
Figure 5.20: A car traveling at at 60 km/h (≈ 16.6 m/s) reduces speed to 15.3
km/h (≈ 4.25 m/s) in order to avoid stopping at the red light
Figure 5.21: The gases emitted by the car described in Figure 5.20
51
Conclusions
The purpose of this thesis was to describe a method to reduce car emissions using
an intelligent transportation system. The method described here consists in using
intelligent traffic lights to minimize the number of stop-starts due to the red light
and the vain accelerations to catch the green light (which are very frequent and
are shown to influence the emissions rate).
The intelligent traffic lights were used to periodically broadcast, for each road
segment controlled, the current traffic light color and the time until it will change.
This information is used by the decision algorithm proposed in chapter three,
Design and Implementation. The role of this algorithm is to help the driver to
1) avoid the red traffic light or 2) catch the green traffic light, if this is possible
and also results in reducing the quantity of emitted gases.
To decide if it is less fuel consuming to try to catch green/avoid red, by
accelerating/decelerating in order to reach the needed speed, a method to predict
the car movement was necessary. For this, we developed a simulator that uses
the motion ecuation of a car to predict its speed and position at any time.
The prediction of the movement of the car is the most challenging part of this
project. To be able to simulate a specific driver’s behaviour and know how the car
is going to move in different situations, is a very difficult task, as many parameters
must be taken into account (all the forces that act on the car - we have to know
even the weather conditions, and the human factor - which complicates very much
the algorithm and can ruin the results of the prediction). Although the results
obtained in chapter four, Experimental Results and Analysis, are promising, the
simulator was developed with many simplifications: in determining the motion
equation, just the x-axis was taken into account and the weather was ignored
52
5.3 Experimental results of the decision algorithm - red traffic lights
(this means that the slopes and the curves of the roads were ignored - 3D maps
are needed to obtain complete information about the roads), the human factor
was much simplified (we assumed that, when accelerating, the driver increases
the engine’s rpm by ≈ 150).
In conclusion, much research and work must be done until a very accurate
version of this application can be deployed on cars. When 3D maps appear, the
only major problem that remains to be solved is the human factor. For this, we
propose three solutions that must be reasearched:
• building an application that is capable to learn the behaviour of the driver
using a history of his/her actions in different situations (the behaviour when
approaching a curve, the rate of acceleration when approaching a slope, etc.)
• letting the driver configure the application according to his/her driving style
• letting the application inform the driver not only about the needed speed
but also about how hard to push the throttle pedal by using, for example,
fuzzy logic.
Also, as future work, the integration with VNSim should be finished to enable
testing the application on complete scenarios (the interference with other cars
must be taken into account and VNSim already does that).
53
References
Akcelik, R. & Besley, M. (2003). Operating cost, fuel consumption, and
emission models in aasidra and aamotion. 25th Conference of Australian Insti-
tutes of Transport Research. 24, 26
Bourg, D.M. (2002). Physics for Game Developers . O’Reilley. 3
Bureau, U.C. (2008). Topologically integrated geographic encoding and refer-
encing system. US Census Bureau, http://www.census.gov/geo/www/tiger,
accesed 2009. 21
Gorgorin, C. (2006). Information dissemination in vehicular ad-hoc networks.
University ”Politehnica” of Bucharest, Diploma Thesis. 30
Gorgorin, C., Gradinescu, V., Diaconescu, R., Cristea, V. & Iftode,
L. (2006). An integrated vehicular and network simulator for vehicular ad-hoc
networks. Proceedings of the 20th European Simulation and Modelling Confer-
ence, Toulouse. 20
Gradinescu, V. (2006). Vehicle ad-hoc networks: Adaptive traffic signal con-
trol. University ”Politehnica” of Bucharest, Diploma Thesis. 23, 26, 30
Haworth, N. & Symmons, M. (2001). Driving to reduce fuel consumption and
improve road safety. Proceedings Road Safety Research, Policing and Education
Conference, Melbourne. 14
Ichimescu, A. (2008). Optimizarea traficului in aglomeratii urbane. University