Adaptive Traffic Signals with Computer Vision

Watch a traffic policeman work a busy junction and you'll see something no fixed-timer signal can do: he looks at the road, sees which direction is drowning in vehicles, and gives it more time. My M.Tech project, Online Smart Traffic Management, set out to give a traffic light those same eyes and that same judgement — using CCTV footage, the YOLOv3 object detector, and an adaptive signal switching algorithm. This post is the overview; the vehicle detection model, the switching algorithm, and the Pygame simulation each get their own deep-dive.

The problem: fixed timers don't know the road is empty

Traffic congestion doesn't just waste time — it burns fuel and pumps out pollution while drivers idle at a red light protecting an empty road. When I looked at how junctions are actually controlled, there were three standard approaches, each with a real flaw:

1. Manual control — traffic police with whistles and sign lights. It works precisely because a human adapts, but there will never be enough officers to staff every junction of a city.
2. Static timers — the same phase sequence, the same durations, repeated forever. Rush hour and 3 a.m. get identical green times.
3. Electronic sensors — inductive loops and proximity sensors buried in the road. They adapt, but accuracy and coverage fight each other: good sensors are expensive, their range is short, and covering a network of junctions needs a lot of them — plus they get destroyed by the very traffic they measure.

The insight that shaped the project: the cameras are already there. Busy intersections in most cities already run CCTV for surveillance. If software can turn that existing video into a vehicle count, the deployment cost of an adaptive signal system drops to almost nothing — no digging up roads, no new hardware beyond maybe re-aiming a camera.

The system: eyes, brain, and a hand on the switch

The design splits into three modules in a clean pipeline:

CCTV frame ──▶ Vehicle Detection (YOLOv3) ──▶ counts per class
                                                    │
Pygame simulation ◀── Signal Switching Algorithm ◀──┘
 (evaluation)          sets green time per lane

• Vehicle Detection. A custom-trained YOLOv3 model takes a snapshot from the camera facing the direction that's about to turn green, and returns the number of vehicles in each class — car, bike, bus/truck, and rickshaw. Classifying matters: a bus takes far longer to clear an intersection than a motorcycle, so a raw count would mislead the timer.
• Signal Switching. The counts feed a formula that computes the green signal time that direction actually needs, clamped between a minimum and maximum so no lane is starved. Signals still rotate in the familiar cyclic order — red → green → yellow → red — because drivers should never have to guess which light comes next.
• Simulation. A 4-way intersection built from scratch in Pygame, with vehicles spawning at controllable rates per direction, lets the adaptive system run head-to-head against a fixed-timer system under identical traffic.

What the numbers said

Across simulation runs with varying traffic distributions — five minutes per distribution, over an hour of total simulated traffic — the adaptive system moved roughly 23% more vehicles through the intersection than the static-timer baseline. The pattern behind the average is the interesting part:

• With traffic spread evenly across all four directions, the adaptive system wins only slightly — a fixed timer is nearly optimal when every lane genuinely needs equal time.
• With skewed traffic — one busy road crossing a quiet one, which is what real cities mostly look like — the gains get large. In the most extreme test, where nearly all vehicles came from one direction, the adaptive system spent its green time where the queue actually was instead of ceremonially serving empty lanes.

That's the whole thesis in one sentence: fixed timers waste green time in exact proportion to how unbalanced the traffic is, and real traffic is always unbalanced.

Why this stack, honestly

YOLOv3 wasn't the only candidate — the report's background study covers Faster R-CNN (accurate, but its region-proposal pipeline is slower per frame) and SSD (fast, single-shot like YOLO). YOLOv3 hit the sweet spot: real-time detection speed on modest hardware, multi-scale predictions that catch both a bus filling the frame and a distant motorcycle, and a mature open-source ecosystem for custom training. For a system that gets a five-second window to analyse an image and set a timer — more on that in part three — inference speed was non-negotiable.

Common pitfalls

1. Counting vehicles without classifying them. Ten bikes and ten buses are not the same queue. Per-class counts with per-class crossing times are what make the computed green time meaningful.
2. Letting the busiest lane jump the queue. Switching to "densest direction first" sounds clever and confuses every driver at the junction. Keep the cyclic order; adapt the durations.
3. Forgetting minimum and maximum green times. Without bounds, a quiet lane can starve forever behind a busy one. The clamp is a fairness guarantee, not a detail.
4. Assuming lab accuracy in the field. Detection trained on clean daytime images degrades at night and in rain — the model is the ceiling on the whole system, which is why part two is mostly about data.
5. Skipping the simulation. You cannot A/B test a real intersection safely. A faithful simulation is the only honest way to measure improvement before touching real signals.

FAQ

Interested in computer vision, IoT, or a full-stack build in Dubai, UAE? Get in touch.