FPGA Traffic Light Controller

Project Report

Laney Williams
EENG 4990 - Project VIII

Spring 2009
Table of Contents

Abstract....................................................................................................................................3

Problem Analysis.....................................................................................................................3

Controller Design.....................................................................................................................6

Concept and Specifications..........................................................................................7

Implementation..........................................................................................................11
Testing........................................................................................................................16

Sensor Design........................................................................................................................19

Concept and Specifications........................................................................................19

Implementation..........................................................................................................20
Testing........................................................................................................................20

System Integration.................................................................................................................21

Environmental and Safety Considerations.............................................................................23

Conclusion.............................................................................................................................23

References..............................................................................................................................23

1
2
Abstract

Traffic lights are meant to ease congestion, but in some situations they can be more of a
hindrance than a help. The situation I am considering is “road and highway”: a seldom-used
country road intersects a sometimes busy highway. In a normal sensor-actuated system, the
highway light is usually green, and the road light is usually red. The highway light would turn
red when a car approaches the intersection from the road and trips that sensor. However, this
logic does not take into consideration approaching cars on the highway, which must make a
quick stop from high speeds. I hope to solve this problem by creating a traffic light controller
with sensors on the highway also integrated into the logic. This will move traffic light control
towards look-ahead traffic-actuated control. The logic will be implemented in VHDL on an
FPGA, with sensor circuits as input.

Problem Analysis

A country road intersects a sometimes busy highway between two cities. This road configuration
can be represented in the following figure.

Cars on country road travel at lower speeds of about 30 MPH. Cars on highway travel at higher
speeds about 60 MPH. Cars on road must cross highway safely.

3
The road and highway intersection is represented in the following figure:

The yellow boxes are the positions of the traffic lights; the blue diamonds are the positions of the
sensors. This is a normal sensor-actuated traffic light design. In "The Design Methods
Comparison Project,” Bahill, et al. (1) proposed the following an algorithm for this traffic light:
• Normally, the highway light shall be green and the road light shall be red.
• When a sensor signals that a tractor is on the road, the highway light shall change to
yellow.
• After a short-time interval (STI, nominally 10 seconds) the highway light shall change to
red and the road light shall change to green.
• The road light shall stay green until the tractor clears the sensor or after a long-time
interval (LTI, nominally 50 seconds), whichever comes first.
• Then the road light shall become yellow.
• After a short time interval the road light shall become red and the highway light shall
become green.
• The system shall stay in that state for a least a long time interval.
• After a long time interval the highway light shall be switched when the sensor detects a
tractor.

4
Their state diagram for this algorithm follows:

The above design could be improved. This logic does not take into consideration approaching
cars on the highway, which must make a quick stop from high speeds. General traffic rules
specify that cars on the road would yield to the highway, because the cars on the road at low
speeds can stop more easily. However, this is not the case with this design. For instance, one car
on the road, that has already stopped, could make several cars on the highway stop. This is
illustrated in the following figure.

This is inefficient and less safe. I hope to solve this problem by creating a traffic light controller
with sensors on the highway also integrated into the logic.

5
There are three new features which I have put in my design: look-ahead sensors (2, 3), green-
light extension (2, 3), and an all-red-light phase (2). The sensors on the highway shall be a
certain distance from the intersection (more on this in the next section). In this way the highway
sensors are “look-ahead” sensors. I have added an optional green-light time extension, so cars
on highway can pass before the car on the road, having the car on the road yield to the cars on
the highway. I also hope to make the traffic light control safer by adding an all-red-light phase,
to protect other drivers from those who try to “beat the yellow light,” but don’t quite make it.
This will move traffic light control towards a safer look-ahead traffic-actuated control.

6
Controller Design

Concept and Specifications

The road and highway intersection can be represented with this drawing (The yellow boxes are
the positions of the traffic lights; the blue diamonds are the positions of the sensors.):

My algorithm for the controller is as follows:

• Normally, the highway light shall be green and the road light shall be red.
• When the road sensor signals that a tractor is on the road the lights shall remain
unchanged for at least a long time-interval (LTI, 10 seconds).
• After a LTI, the highway green light shall be extended for the time the highway sensor is
active plus a short-time interval (STI, 3 seconds), or for a very-long-time interval (VLTI, 30
seconds) has passed, whichever comes first. Then the highway light shall change to yellow.
• After a STI, the highway light shall change to red.
• After a STI, the road shall become green.
• The road light shall stay green for the time the road sensor is active plus a STI or for a
LTI, whichever comes first.
• Then the road light shall become yellow.
• After a STI the road light shall become red.
• After a STI the highway shall become green.
• The system shall stay in that state for a least a LTI.

7
I drew a state diagram to represent my control algorithm in a way that can be easily synthesized
in digital logic. My state diagram for this algorithm follows:

This is a Moore state machine. The outputs are a function of the present state only and will
continue until the machine switches to another state. I have given each state a name (in bold
type on top of each state bubble) and the outputs are the traffic lights activated (on bottom of
each bubble). The logic follows the arrow to the next state when the Boolean algebra expression
next to that arrow is logic ‘TRUE’ or ‘1’.

8
A block diagram for the state machine and its accompanying timers is shown in the following
diagram.

The timers deserve special attention, as they are internal signals. Internal timers have their own
logic. Timers are started with individual internal ‘start signal.’ Timers continue to count clock
pulses as long as the ‘start signal’ is ‘1.’ When timer has reached its maximum count it outputs a
pulse (STI, LTI, and VLTI). In addition, sometimes the some timers can be interrupted. The
“Transition,” “AllRed,” and “Normal” states use uninterrupted timers. The “Extend” and
“Crossover” states can interrupt and reset the STI timer. If a car triggers the sensor, it starts the
STI timer. If another car triggers the sensor, the STI timer resets and starts again when that pulse
ends. This state only ends if STI and sensor signal are ‘0’, or if a maximum time is reached.
This is illustrated in the next two charts. The first chart shows the timing with no interrupting
signals, and the second chart shows the timing with interrupting signals.

9
These time intervals are chosen very specifically to conform to traffic theory concerning the
“look-ahead” sensors on the highway. For sensor placement and traffic timing, one must
consider the “dilemma zone” (3). In this zone, drivers have differing desire or ability to stop
after seeing a yellow light. This zone is determined by probability of drivers stopping.
Zimmerman and Bonneson (3), have determined that at 5 sec before intersection about 90% of
drivers stop (a probable stop), and at 2 sec before intersection about 10% of drivers stop (a
probable go). The “delimma zone” is about 3 seconds, which is why I chose this time for the
STI. The dilemma zone is illustrated in the following figure.

The rules for sensor placement are as follows:

• Road sensors shall be placed immediately before the stop-line.
• Highway sensors shall be placed immediately before the dilemma zone. [Distance from
stop-line (ft) = 5 (s) × Speed (ft/s)]

1
These rules are illustrated in the following figure.

Implementation

The state diagram can be easily converted into digital logic equations and into VHDL code by
using enumerated types, a synchronous process, and a combinatorial process (4). In VHDL, you
can create a special “state type”, and make all your state variables, that is, the names of the
states, of that type.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity trafficlight is
Port ( sensorR : in STD_LOGIC;
sensorH : in STD_LOGIC;
Reset : in STD_LOGIC;
Clock : in STD_LOGIC;
HwayGreen : out STD_LOGIC;
HwayYellow : out STD_LOGIC;
HwayRed : out STD_LOGIC;
RoadGreen : out STD_LOGIC;
RoadYellow : out STD_LOGIC;
RoadRed : out STD_LOGIC);
end trafficlight;

architecture Behavioral of trafficlight is

11
--enumerated state type
type traffic_type is ( Normal, Extend, Transition1, AllRed1, Crossover,
Transition2, AllRed2 );
--define state variables
signal current_state, next_state: traffic_type;
--timer signals and constants
signal STI, LTI, VLTI, start_STI, start_LTI, start_VLTI, restart_STI:
STD_LOGIC:= '0';
constant clk_freq: integer:= 50000000; -- clock frequency (50MHz clock)
constant Max_STI: integer:= 3*clk_freq; -- = # cycles in 3 s
constant Max_LTI: integer:= 10*clk_freq; -- = # cycles in 10 s
constant Max_VLTI: integer:= 30*clk_freq; -- = # cycles in 30 s
signal count_STI: integer range 0 to Max_STI:= 0;
signal count_LTI: integer range 0 to Max_LTI:= 0;

begin
...

In the synchronous process (which I called traffic_next_state), the current state changes to
the next state at the next clock pulse, or resets to the normal state. The combinatorial process
(which I called traffic_current_state) uses a case statement for each state, dictating the
outputs and logic for state change. The combinatorial process is based on the current state, and
dictates the next state.

...
traffic_next_state: process (clock, reset)
begin
if (clock'event and clock = '1') then
if (Reset='1') then
current_state <= Normal;
else
Current_State <= Next_State;
end if;
end if;
end process;

traffic_current_state: PROCESS (sensorR, sensorH, Reset, current_state, STI,

LTI, VLTI)
begin
case current_state is
when Normal =>
----0utputs
HwayGreen <= '1';
HwayYellow <= '0';
HwayRed <= '0';
RoadGreen <= '0';
RoadYellow <= '0';
RoadRed <= '1';
----Internal LTI timer logic
start_STI<='0';
start_VLTI<='0';
if (sensorR='1') then
start_LTI <= '1'; --start LTI timer only when sensorR is ON
else
start_LTI <= '0';

1
 end if;
-----Next-state logic
if (LTI='1' AND sensorR='1') then
next_state <= Extend;
else
next_state <= Normal;
end if;
when Extend =>
----Outputs
HwayGreen <= '1';
HwayYellow <= '0';
HwayRed <= '0';
RoadGreen <= '0';
RoadYellow <= '0';
RoadRed <= '1';
----Internal VLTI timer logic
start_STI <= '1'; --start STI timer
start_LTI<='0';
start_VLTI <= '1'; --start VLTI timer
if (sensorH='1') then
restart_STI <='1'; --restart STI timer
else
restart_STI <='0';
end if;
-----Next-state logic
if (((not sensorH)='1' and STI='1')OR VLTI='1') then
next_state <= Transition1;
elsif ((not sensorR)='1') then
next_state <= Normal;
else
next_state <= Extend;
end if;
when Transition1 =>
----Outputs
HwayGreen <= '0';
HwayYellow <= '1';
HwayRed <= '0';
RoadGreen <= '0';
RoadYellow <= '0';
RoadRed <= '1';
----Internal timer logic
start_LTI<='0';
start_VLTI<='0';
start_STI <= '1'; -- always start STI timer in this state
----Next-state logic
if (STI = '1') then
next_state <= AllRed1;
else
next_state <= Transition1;
end if;
when AllRed1 =>
----Outputs
HwayGreen <= '0';
HwayYellow <= '1';
HwayRed <= '0';
RoadGreen <= '0';
RoadYellow <= '0';

1
 RoadRed <= '1';
----Internal timer logic
start_LTI<='0';
start_VLTI<='0';
start_STI <= '1'; -- always start STI timer in this state
----Next-state logic
if (STI = '1') then
next_state <= Crossover;
else
next_state <= AllRed1;
end if;
when Crossover =>
----Outputs
HwayGreen <= '0';
HwayYellow <= '0';
HwayRed <= '1';
RoadGreen <= '1';
RoadYellow <= '0';
RoadRed <= '0';
----Internal timer logic
start_STI<='1'; --start STI timer
start_VLTI<='0';
start_LTI <= '1'; --start LTI timer
if (sensorR='1') then
restart_STI <='1'; --restart STI timer
else
restart_STI <='0';
end if;
----Next-state logic
if (LTI='1' OR ((not sensorR)='1' and STI='1')) then
next_state <= Transition2;
else
next_state <= Crossover;
end if;
when Transition2 =>
----Outputs
HwayGreen <= '0';
HwayYellow <= '0';
HwayRed <= '1';
RoadGreen <= '0';
RoadYellow <= '1';
RoadRed <= '0';
----Internal timer logic
start_LTI<='0';
start_VLTI<='0';
start_STI <= '1'; --always start STI timer in this state
----Next-state logic
if (STI = '1') then
next_state <= AllRed2;
else
next_state <= Transition2;
end if;
when AllRed2 =>
----Outputs
HwayGreen <= '0';
HwayYellow <= '0';
HwayRed <= '1';

1
 RoadGreen <= '0';
RoadYellow <= '1';
RoadRed <= '0';
----Internal timer logic
start_LTI<='0';
start_VLTI<='0';
start_STI <= '1'; --always start STI timer in this state
----Next-state logic
if (STI = '1') then
next_state <= Normal;
else
next_state <= AllRed2;
end if;
end case;
end PROCESS;
...

In the combinatorial process (traffic_current_state above) each state chooses when to start
one of three separate, internal timers. These internal timers required a separate process (which I
called traffic_timer). This process simply counts clock pulses (5) when the timer’s ‘start
signal’ is HIGH and ‘restart signal’ is LOW until the proper time is reached and it sends out a
pulse.
...
traffic_timer: PROCESS (clock, start_STI, start_LTI, start_VLTI, restart_STI,
count_STI, count_LTI, count_VLTI)
begin
if (Clock'event and Clock = '1') then
if (start_STI = '1') then
if (restart_STI = '1') then
count_STI <= 0;
STI <= '0';
else
if (count_STI = Max_STI) then ----counts to 3 s
count_STI <= 0;
STI <= '1';
else
count_STI <= count_STI + 1;
STI <= '0';
end if;
end if;
elsif (start_STI = '0') then
count_STI <= 0;
STI <= '0';
end if;
if (start_LTI = '1') then
if (count_LTI = Max_LTI) then --counts to 10 s
count_LTI <= 0;
LTI <= '1';
else
count_LTI <= count_LTI + 1;
LTI <= '0';
end if;
elsif (start_LTI = '0') then
count_LTI <= 0;

1
 LTI <= '0';
end if;
if (start_VLTI = '1') then
if (count_VLTI = Max_VLTI) then ----counts to 30 s
count_VLTI <= 0;
VLTI <= '1';
else
count_VLTI <= count_VLTI + 1;
VLTI <= '0';
end if;
elsif (start_VLTI = '0') then
count_VLTI <= 0;
VLTI <= '0';
end if;
end if;
end process;

end Behavioral;

Testing

The code is difficult to test due to the long timers (in terms of number of clock pulses). I was
going to test first in ModelSim simulation software. However, ModelSim only allows for testing
time of up to 1000 ns. To test the code in theory, I changed the clock pulse to 1 GHz and the
STI, LTI, and VLTI timers to 30 ns, 100 ns, and 300 ns, respectively.

The first case I tested was that there is only a car on the road which does not move before a LTI,
or there could be many cars on the road spaced less than or equal to a STI apart all of which do
not make the crossover before a LTI.

wait for 50 ns;

in_sensorR<='1', '0' after 350 ns;
wait;

1
The second case I tested was that there is only a car on the road which moves before a LTI, or
there could be many cars on the road spaced less than or equal to a STI apart all of which make
the crossover before a LTI.

wait for 50 ns;

in_sensorR<='1', '0' after 250 ns;
wait;

The third test is that there is a car on road, and three cars approaching on the on highway spaced
a STI or less apart, and the car on the road makes the crossover before a LTI. To illustrate this I
have used three pulses to represent to cars hitting the sensor.

wait for 50 ns;

in_sensorR<='1', '0' after 450 ns;
in_sensorH<='1' after 120 ns, '0' after 125 ns, '1' after 140 ns,
'0' after 145 ns, '1' after 160 ns, '0' after 165 ns;
wait;

1
The fourth and final test is that there is a car on road, and many cars approaching on the
highway. To illustrate this, I have kept the highway value at ‘1’ instead of using pulses.

wait for 50 ns;

in_sensorR<='1';
in_sensorH<='1';
wait;

In testing, I observed a delay of at most 4 clock pulses. This is expected in Moore state
machines. In the real system, with 3, 10, and 30 second timers and a 50MHz clock this is only a
80 ns delay. This should not be noticeable.

1
Sensor Design

Concept and Specifications

The sensor for the traffic light will have to sense both high-speed cars on the highway and
stationary cars on the road. This is why I have chosen pressure sensors. A piezoelectric traffic
sensor, such as the RoadTrax BL sensor from Measurement Specialties Inc., is embedded in the
road and output a positive voltage when a vehicle drives over. The output voltage for a car is
approximately 500 mV. The output can be upwards of 5 V for a large fully-loaded truck. The
plot for the output voltages is shown in the following two graphs (the output for a car is on the
left, the output for a fully-loaded brick truck is on the right). (6)

The output of this sensor should be amplified and fed into a comparator against a reference or
threshold voltage.

It is not feasible for me to test a sensor RoadTrax BL sensor because of size and cost restrictions.
However, I can test a similar small-scale device, the FlexiForce A201 piezoresistive force sensor.
The A201 varies its resistance in an inversely proportional relationship to applied force (7).
When negative voltage is applied to the sensor in a negative feedback configuration, the output is
analogous to a piezoelectric sensor. This configuration is shown in the following figure (7).

As with the RoadTrax BL sensor, the A201’s output should be amplified and fed into a
comparator against a reference or threshold voltage.

1
Implementation

I will be implementing the sensor design with the FlexiForce A201, as a small-scale model. The
A201 datasheet has a suggested amplifier circuit (8). I changed the amplifier to a uA741 and
added a voltage comparator. The output of the amplifier is given by: Vo = Vcc- * Rf/Rs. With
Rf = 15k, when sensor is pressed the amplifier’s output voltage is between 1 V and 4 V.
Therefore, I configured the comparator so that if the amplifier’s output is greater than 1 V, the
output of the comparator goes logic high or Vcc, otherwise the output is logic low. The sensor
circuit is shown in the following figure.

Testing

To test the small-scale sensor circuit, I pressed the force sensor, as Vout was attached to an
oscilloscope. When the sensor does not experience any force the output voltage is about 80 mV.
When the sensor is pressed the voltage makes a clean jump up to (then down from) 5 V. The
output is a digital signal with 80 mV (LOW) and 5 V (HIGH).

2
System Integration

In a real-life traffic light situation the system components would be organized as in the following
diagram.

The placement of components would be laid out as in the following diagram.

2
However for testing purposes, the layout will be different. The VHDL code will be synthesized
on the Spartan-3 XC3S200 FPGA. The sensor will be synthesized from its discrete components
on a breadboard. I should be able to interface the sensors with the FPGA through the expansion
connector pins.

Environmental and Safety Considerations

I have integrated both environmental and safety considerations into my design, in accordance
with IEEE ethics: “making decisions consistent with the safety, health and welfare of the public.”

2
In order to minimize energy consumption, the system will use LED’s instead of regular
incandescent bulbs. LED’s use 4 to 18 watts compared to 150 to 69 watt incandescent bulbs (9),
increasing efficiency. LED’s also last 10 times longer than incandescent bulbs (9), decreasing
replacement waste. The design is also safer than the old semi-traffic-actuated design. The
green-light-extension phase with "look-ahead" sensors is safer. A study (10) shows a 35%
reduction in crash rate for intersections with approach speeds of 55 mph over unmodified
intersections. Additionally, the all-red-light phase is safer. A study (10) shows a 30% average
reduction in all traffic accidents over unmodified intersections. However, there are still dangers
which I must state, in accordance with IEEE ethics: “disclose promptly factors that might
endanger the public or the environment.” There are two worst-case scenarios: a glitch causes all-
green lights, and a power outage causes no lights. A possible solution to both scenarios is to
install separate circuitry, on a generator, to monitor for these conditions and over-ride with
blinking-lights.

Conclusion

In conclusion, my design effectively improves upon the basic sensor-actuated design for this type
of intersection. My design has sensor input for high-speed cars on the highway, using “look-
ahead” sensors. This design allows cars on the road to yield to the cars on the highway, by
adding a green-light extension. Rapidly approaching cars on the highway will not have to stop
for one car on the road that has just pulled up to the traffic light. My design also adds an all-red-
light phase to protect drivers against red-light runners. A piezoresistive sensor can be used as a
piezoelectric sensor, if negative voltage is applied to the sensor in a negative feedback
configuration. The output voltage of the piezoelectric or piezoresistive force sensors can be
easily converted to digital by a comparator for input into the controller. The controller and
sensors could easily be implemented in a real-life intersection.

References

(1) Bahill, A. Terry, and Mack Alford, K. Bharathan, John Clymer, Douglas L. Dean, Jeremy
Duke, Greg Hill, Ed LaBudde, Eric Taipale, and A. Wayne Wymore. "The Design Methods
Comparison Project." IEEE Transactions on Systems, Man, and Cybernetics, Part C:
Applications and Reviews, Vol. 28, No. 1, pp. 80-103. February 1998.

(2) Van Katwijk, Ronald. “Multi-Agent Look-Ahead Traffic-Adaptive Control.” TRAIL Thesis
Series, The Netherlands TRAIL Research School, January 2008.

(3) Zimmerman, K., and J. Bonneson. “Detection-Control System for Rural Signalized
Intersections.” Texas Transportation Institute, Texas A&M University. 1 December 2000.

(4) Traylor, Roger L. “State Machines in VHDL.”

http://web.engr.oregonstate.edu/~traylor/ece474/new_vhdl_pdfs/state_machines_in_vhdl.pdf

2
July 2004.

(5) Free Information Society. “25.175MHz to 1Hz Clock Divider in VHDL.”

http://www.freeinfosociety.com/site.php?postnum=521

(6) Measurement Specialties Inc. http://www.meas-spec.com/downloads/RoadTrax_BL.pdf

(7) Tekscan Inc., FlexiForce Force Sensors. http://www.tekscan.com/flexiforce/flexiforce.html

(8) Tekscan Inc., FlexiForce A201 Datasheet. http://www.tekscan.com/pdfs/DatasheetA201.pdf

(9) U.S. Environmental Protection Agency. “Energy Efficiency Sector: Led Traffic Signals.”
http://epa.gov/climatechange/wycd/downloads/CO_LED.pdf January 2000.

(10) Agent, Kenith, and Nikiforos Stamatiadis, Samantha Jones. “Development of Accident
Reduction Factors.” Kentucky Transportation Center, College of Engineering, University of
Kentucky. June 1996.