Daniel Melnikov · Smarter Traffic Signals

The 30-second version

I started with a simple local question: if far more cars travel through an intersection in one direction, why should both directions get equal green time? So I stopped guessing. I went to a real Evanston intersection, counted traffic for an hour, and let the data decide.

From there I derived the best fixed timing with calculus, built a simulation where queues carry over from minute to minute, and designed a camera system that could feed a smarter controller. I also say plainly where the model falls short, because a result is only useful if you know its limits.

Field data
Hand-counted arrivals, queues, and discharge, minute by minute.

Calculus & modeling
Optimization of a delay function; persistent-queue simulation.

Computer-vision design
Camera geometry and measurements specified (proposed, not yet built).

Research writing
A full paper with appendix, assumptions, and limitations.

The problem

A signal has a limited amount of green to hand out. A 60/60 split is simple, but if one road carries almost three times the traffic of the other, drivers on the busy road pay for it. Even a well-tuned fixed plan can't see a backed-up line forming right now.

The key result of Phase I is clean: under the model, green time should be split in direct proportion to demand. With R as the North–South red time and L = 120 s:

R* = L · λ_EW / (λ_NS + λ_EW) ⇒ G*_NS = 120 × 0.7165 ≈ 85.98 s

Try the model

Drag the sliders. Delay uses my Phase I formula on the real one-hour volume (3,122 vehicles). Find the minimum yourself, then see if it matches the math.

North–South share of traffic North–South green time (of 120 s)

Modeled delay for your split

Best possible split for this traffic

Your split vs. 60/60

Phase II: a signal that can see

Averages hide the moments that hurt most: a surge, a slow-clearing queue. In Phase II the controller updates every minute, carries queues forward in time, and weighs three things:

1 · Arrivals
Vehicles crossing a virtual line about 400 ft upstream.

2 · Queue
Vehicles waiting near the stop line, which persist into later minutes.

3 · Discharge
How quickly vehicles actually clear on green. Two slow periods showed up in my data.

Queue_d(t+1) = max(0, Queue_d(t) + Arrivals_d(t) − Served_d(t))

The arrival-only controller reacts to the newest counts. The camera-aware controller also sees inherited backlog and clearing speed, so a direction can earn extra green even when its latest arrivals are smaller.

The 400-ft zone is a design assumption, not an engineering standard. The field data were counted directly; the camera pipeline is the proposed way to automate it.

Results

Four strategies, same minute-by-minute arrivals and discharge conditions. Cumulative queue delay over the hour, lower is better.

Equal 60/601,052,910

Optimized fixed199,626

Arrival-only adaptive139,057

Camera queue-aware115,736

Vehicle-seconds. Average per vehicle: 337.3 s → 63.9 s → 44.5 s → 37.1 s.

The comparison that matters most is between the two adaptive controllers: same one-minute updates, same 25–95 s green limits, and the only difference is queue and discharge information. That is worth 16.77% less delay.

Phase I and Phase II measure different things (expected red delay vs. persistent queue delay), so their numbers shouldn't be compared directly.

Beyond one intersection: nine hypothetical road types

An appendix tests the same idea on nine synthetic intersections, from wide–wide to narrow–narrow. These are scenarios, not field measurements.

Configuration	Fixed (s/veh)	Queue-aware (s/veh)	Change
Wide–wide (4/4)	14.3	4.8	+66.7%
Large–large (3/3)	26.0	8.8	+66.3%
Large–medium (3/2)	95.4	32.6	+65.8%
Large–small (3/1)	239.7	74.2	+69.0%
Medium–medium (2/2)	44.2	18.9	+57.1%
Medium–small (2/1)	212.8	97.3	+54.3%
Small–small (1/1)	72.1	44.4	+38.5%
Wide–narrow (4/1)	215.1	32.7	+84.8%
Narrow–narrow (1/1)	50.7	26.0	+48.7%

Here "Change" is the percent of modeled delay removed. These use illustrative capacity (0.45 veh/s per lane) and deterministic demand waves, so treat them as demonstrations, not forecasts.

How I did the work

Observe. One hour at Lincoln Street and Green Bay Road, starting around 8:00 AM, recording each vehicle by direction plus minute-level queue and discharge conditions.
Model. Derived the fixed split that minimizes expected red-signal delay, then compared it with a 60/60 baseline.
Simulate. Ran four strategies on identical minute-by-minute data so the comparison was fair, with controllers only allowed to use past information.
Stress-test. Tried nine synthetic road layouts, clearly labeled as hypothetical, and reported both relative and absolute effects.
Check myself. Listed the limitations and laid out a plan to compare against real timing plans in shadow mode, without touching the live signal.

Biggest lesson: a headline percentage can mislead. The queue trajectories, the assumptions behind them, and the absolute numbers matter just as much.

Why Evanston

Lincoln Street and Green Bay Road isn't a made-up intersection. The City's Green Bay Road Corridor Improvements Project includes traffic-signal improvements at Lincoln Street, part of a larger effort to improve safety for pedestrians, vehicles, buses, and trucks. This project is a transparent, student-scale model of that real local problem, not a replacement for the City's engineering.

What this does and doesn't show

One morning, one hour, one intersection. Repeating across days, seasons, and weather is the first next step.
Two-phase model: no turn phases, pedestrians, buses, or coordination with neighboring signals.
Discharge capacity is a simplified assumption, not lane-by-lane calibration.
The camera system isn't built or tested yet. Occlusion, night, weather, and detection error are open questions.

Next: replicate the counts, build the video pipeline and compare it to hand counts, then run the model in shadow mode against real timing plans.