Adaptive traffic signal control with RL and a YOLO vehicle detector

“AI traffic lights” is a common smart-city pitch. The part most versions skip is the one that matters: does it measurably help, and under what conditions does it stop helping?

So the order of work was fixed before any controller existed: build the intersection, measure a fixed-timer baseline, then build each smarter controller and score it on the identical scenario with the identical scoring script.

• Fixed-timer baseline: SUMO’s static program, 42s green and 3s yellow per approach pair.
• Rule-based adaptive controller: reads per-lane halting counts over TraCI every simulation step and extends, cuts or holds the green phase with gap-out logic.
• DQN agent: a Gymnasium environment over the same intersection. State is both queues, current phase, green time elapsed and how long the red side has waited. The action is keep or switch, bounded by the same 10s minimum and 60s maximum green.
• Scoring: every run writes per-vehicle tripinfo XML, and one script turns it into wait time, time loss, max wait and throughput.

Under saturation the adaptive controller still lowered average wait but completed 12.7% fewer trips. Logging every green phase showed why: its short minimum green caused 2.3x more time lost to yellow transitions than the fixed timer.

Phase logging also showed that in the first two scenarios all of the improvement came from one mechanism: ending a green phase once its queue cleared, instead of holding it for 42 seconds. The extend-on-demand logic never fired. The honest claim is about that cutoff, not about extend-on-demand control.

Arrival detection. The controller inferred new arrivals from the net change in queue length. Under real demand, cars arrive and leave on the same step, so the queue stays flat while traffic keeps coming and the controller gapped out too early. I replaced it with vehicle-ID tracking (set difference on lane vehicle IDs). Afterward gap-out fired in 0% of phases at light demand and 97% at heavy demand, as it should.

The RL agent, five times:

v3 fixed a real bug: a switch costs four simulated seconds but returned one reward, so switching looked free to the agent. v4 recovered most of the throughput gap but starved one direction (EW waited 97.7s on average, NS 7.2s). v5 balanced the directions and gave the throughput back. With fixed hand-picked weights, fixing one objective broke another every time.

To replace SUMO’s ground-truth vehicle counts with something a real intersection could have, I fine-tuned YOLOv8n on UA-DETRAC traffic-camera footage: 6,808 training images, single “vehicle” class.

Two data problems came first. The class names in the export were video-clip IDs, not vehicle types, so I verified the boxes were valid and remapped everything to one class. Then a 1-epoch run scored 0.909 mAP50, which was too good. A check showed all 60 video clips were in both train and validation, so near-identical consecutive frames were being graded against each other.

Precision is 0.918 but recall is 0.819: the model misses about 18% of vehicles, so it systematically undercounts. Any controller fed by it would have to correct for that, not treat the counts as exact.

• Feed YOLO’s detected counts into the controllers in place of simulator ground truth. The two halves are not connected yet.
• Replace the hand-weighted scalar reward with a weight sweep or a constrained RL formulation.
• Add turning movements and a second intersection.