No Pedestrian Left Behind: Adaptive Traffic Signals That Watch and Wait

Paper: 2604.25887 Authors: Anas Gamal Aly, Hala ElAarag Categories: cs.CV, cs.AI, cs.RO, eess.SY

The Gap

Traffic signals have been adaptive for vehicles since the 1980s—loop detectors sense cars and adjust timing. But pedestrian signals remain stuck in the fixed-timer era. Press the button, get your 20 seconds, and the light changes whether you’ve finished crossing or not. This works fine for able-bodied adults walking at 1.2 m/s, but elderly pedestrians average 0.9 m/s, wheelchair users 0.8 m/s, and someone checking their phone might drop to 0.6 m/s. Prior work on pedestrian detection focused on collision avoidance for autonomous vehicles or counting foot traffic for urban planning—not real-time intervention in signal timing.

The gap: no deployed system monitors individual pedestrian progress during crossing and extends the signal when someone is moving too slowly to finish in time.

Problem: Fixed pedestrian timers strand slow walkers
   |
   v
Assumption: Real-time tracking can identify at-risk pedestrians
   |
   v
Method: YOLOv12 detection + ByteTrack + adaptive controller
   |
   v
Evidence: 71.4% reduction in stranding (9.10% -> 2.60%)
   |
   v
Conclusion: Vision-based adaptive signals are feasible and effective

The Increment

One sentence: Before this paper, pedestrian signals were blind timers; after, they can see who’s still in the crosswalk and wait for them.

Core Mechanism

NPLB has three stages running in a pipeline. First, YOLOv12 processes each video frame from a crosswalk camera and outputs bounding boxes around detected pedestrians with confidence scores. Second, ByteTrack takes these detections and maintains persistent IDs for each person across frames, tracking their position over time even through brief occlusions. Third, an adaptive controller monitors the tracked positions: when the pedestrian signal countdown drops below a threshold (say, 5 seconds remaining) and any pedestrian is still more than 2 meters from the curb, it sends an extension command to the traffic signal controller, adding 5-10 seconds to the phase.

The system runs at 30 FPS on edge hardware. YOLOv12 was fine-tuned on the BGVP dataset (a collection of crosswalk videos with annotated pedestrians in various lighting and weather conditions). ByteTrack uses a Kalman filter to predict pedestrian motion between frames and matches detections using IoU (intersection over union) of bounding boxes. The controller uses simple geometric rules: calculate distance from bounding box center to the far curb, estimate time needed at average walking speed, compare to remaining signal time.

Camera Feed (30 FPS)
   |
   v
+------------------+
| YOLOv12 Detector |  <-- Fine-tuned on BGVP dataset
+------------------+
   |
   | Bounding boxes + confidence scores
   v
+------------------+
| ByteTrack        |  <-- Kalman filter + IoU matching
| (Multi-object    |
|  tracking)       |
+------------------+
   |
   | Tracked pedestrian positions + IDs
   v
+---------------------+
| Adaptive Controller |  <-- Distance check + time estimate
+---------------------+
   |
   | Extension signal (if needed)
   v
Traffic Signal Controller

Think of NPLB as a lifeguard watching a swimming pool. The detector (YOLOv12) is the lifeguard’s eyes, scanning the water and spotting each swimmer. The tracker (ByteTrack) is the lifeguard’s memory, keeping tabs on which swimmer is which even when they dip underwater briefly. The controller is the lifeguard’s judgment: if someone is still in the deep end when the pool is about to close, blow the whistle and keep the pool open a bit longer. The lifeguard doesn’t need to know why someone is swimming slowly—maybe they’re tired, maybe they’re helping a child—just that they need more time. Similarly, NPLB doesn’t classify pedestrians as “elderly” or “disabled”; it just measures: are you still in the crosswalk when time is running out?

Key Concepts

• Multi-object tracking (MOT): Imagine watching a crowded dance floor from above. You can see people moving, but if you blink, can you tell which person is which when you open your eyes? MOT solves this by giving each person a persistent ID. ByteTrack does this by predicting where each person will be in the next frame (using their velocity from previous frames) and matching new detections to predictions. If a detection is close to a prediction, it’s probably the same person. If someone is briefly hidden behind another person (occlusion), ByteTrack keeps their ID alive for a few frames, waiting for them to reappear. This matters for NPLB because you need to know if the person near the curb now is the same person who was in the middle of the crosswalk 3 seconds ago—otherwise you might extend the signal for someone who already finished crossing.

• [email protected] (mean Average Precision at 50% IoU): This is how we measure detector quality. IoU (intersection over union) compares a predicted bounding box to the ground truth: if they overlap by 50% or more, it counts as a correct detection. Precision is: of all the boxes you drew, how many were correct? Average Precision summarizes precision across different confidence thresholds. mAP averages this across all object classes. YOLOv12’s 0.756 [email protected] means that 75.6% of its high-confidence pedestrian boxes overlap ground truth by at least half—good enough for tracking, though it will miss some people and occasionally hallucinate a pedestrian where there’s a trash can.

• Adaptive signal control: Traditional traffic signals run on fixed cycles: 60 seconds green for cars, 20 seconds for pedestrians, repeat. Adaptive control breaks the cycle when needed. Vehicle-adaptive signals (common since the 1990s) use loop detectors in the pavement to sense waiting cars and adjust green time. NPLB does the same for pedestrians but uses vision instead of loops. The key constraint: you can’t extend the pedestrian phase indefinitely or cross-traffic backs up. NPLB’s controller only extends when (1) someone is still crossing AND (2) time is almost up, limiting extensions to 12.1% of cycles in their simulations.

Framework Shift

Before (fixed timers):              After (NPLB):

Press button                        Press button
    |                                   |
    v                                   v
+--------+                          +--------+
| Timer  |                          | Timer  |
| starts |                          | starts |
+--------+                          +--------+
    |                                   |
    | 20 seconds                        | 20 seconds
    v                                   v
Light changes                       Camera watching
(regardless of                          |
 pedestrian                             | Still crossing?
 position)                              v
                                    +---------+
                                    | Extend? |
                                    +---------+
                                       / \
                                  Yes /   \ No
                                     /     \
                                    v       v
                              +5-10 sec   Light changes

From blind countdown to vision-guided patience, the core shift is treating pedestrian crossing time as a variable to optimize, not a constant to enforce.

Expert Assessment

Problem choice: Real gap. The elderly and disabled advocacy groups have complained about this for decades. The problem is well-documented (MUTCD guidelines acknowledge it but offer no solution beyond “make the timer longer,” which delays traffic for everyone). This paper attacks a genuine safety issue that existing adaptive signal research ignored because it focused on vehicle throughput.

Method maturity: Straightforward engineering, not a research breakthrough. YOLOv12 is off-the-shelf, ByteTrack is standard MOT, and the controller is a few if-statements. The contribution is integration and deployment thinking, not algorithmic novelty. That’s fine—sometimes the gap is “no one built the obvious thing.” But the paper oversells the detector comparison (5 models tested, YOLOv12 wins) as if this were a core contribution when it’s really just due diligence.

Experimental integrity: The Monte Carlo simulations are the weak link. They assume pedestrian speeds drawn from distributions (elderly: 0.9 m/s ± 0.2, etc.) but don’t model pedestrian behavior realistically. Real people speed up when they see the countdown, or freeze in the middle if they think they won’t make it. The 71.4% improvement is probably real but the exact number is suspect. The paper also doesn’t test on real intersections—just simulations fed with BGVP video. Where’s the pilot deployment? The baselines are fair (fixed timer vs. NPLB) but limited (no comparison to simpler heuristics like “extend if any motion detected in crosswalk”).

Writing quality: The related work section is a laundry list of pedestrian detection papers with no critical synthesis. The method section is clear but repetitive (the controller logic is explained three times in slightly different words). The results section front-loads the good news (71.4% reduction!) and buries the failure modes (what happens in heavy rain? at night?). Rewriting the evaluation section to lead with limitations and then show how the system performs despite them would make this more credible.

Verdict: Weak accept — solid engineering work addressing a real problem, but the evaluation needs real-world validation before this is deployment-ready.

Takeaways

Steal the two-threshold trick: NPLB uses separate thresholds for detection confidence (0.5) and tracking persistence (keep ID alive for 30 frames even if confidence drops). This is a general pattern for any vision system that needs to be conservative about false positives but robust to brief occlusions. In your own work, tune detection and tracking thresholds independently.

The “time-to-safety” metric: Instead of classifying people (elderly? disabled?), NPLB just measures: will you reach safety in time? This reframes the problem from demographic prediction (hard, privacy-invasive) to geometric prediction (easy, privacy-preserving). Applicable anywhere you’re tempted to classify users when you really just need to predict an outcome.

Edge deployment constraints shape algorithm choice: The paper chose YOLOv12 over Faster R-CNN not because it’s more accurate (it’s not, by much) but because it runs at 30 FPS on a Jetson Xavier. This is the right way to pick models for real-time systems—latency and throughput matter more than the last 2% of mAP. If you’re building something that needs to react in real-time, benchmark on target hardware first, then optimize accuracy within your latency budget.