-
-
thumbnail
-
-
-
landing page
-
hardware interaction
-
hardware interaction
Problem
When the power goes out, traffic lights go dark. Humans treat a dark signal as an all-way stop and read the other drivers. Autonomous vehicles have a harder time: during the December 2025 San Francisco blackout, dark signals left AVs stalled at intersections and waiting on remote help. Every one of those stalls means a blocked intersection and a human operator pulled in. AVs need a way to know the signal state when they can't see the light.
Solution
Wayfinder gives the car three layers of defense, checked in this order:
Beacon: A battery-backed beacon at the intersection relays the signal controller's phase. It keeps broadcasting after the grid goes down, so the car understands the state of the outage.
Model: If the beacon is missing or stale, a model infers the light's phase from how the surrounding vehicles are behaving (queued, accelerating, crossing).
All-way stop: If the model isn't confident, the car falls back to a safe all-way stop instead of freezing.
On Open Motion Waymo data, the model is 95% accurate when it commits (at a 0.8 confidence threshold). It only calls "go" on a real red 2.5% of the time.
Implementaion
Data: Waymo Open Motion Dataset (~1.4 TB). We compiled the protos locally and wrote a lightweight TFRecord reader.
Model: We extracted per-lane behavioral features from ~2M rows across 16k scenarios and trained a LightGBM classifier with abstention. The self-driving car's own track and all signal-state data are excluded from the features to prevent label leakage. Lanes are grouped by approach (N/E/S/W), and the car's specific lane is detected so turn lanes don't blur the prediction.
Beacon: An M5Stack/ESP32 running broadcasts an 18-byte packet at 10 Hz, containing the phase, a scenario step, a sequence number, and an HMAC. A Python bleak receiver verifies each packet and pushes it over a WebSocket.
Dashboard: A three.js scene player replays real Waymo scenarios with floating signal heads showing the phase, confidence ring, decision source, and the ground truth next to each prediction.
Spoof Testing
The beacon's HMAC exists to stop a bad actor from broadcasting a fake "green light" and getting a car to proceed through a live intersection. To prove that defense actually holds, we built a spoofing harness rather than just trusting the design on paper.
Setup: two laptops standing in for "attacker" and "intersection." One laptop broadcasts scene/phase packets over the same wireless channel the real M5Stack beacon would use, with the ability to sign packets correctly (legitimate simulated beacon) or send unsigned/incorrectly-signed packets (spoof attempt). The receiver runs two listeners in parallel — one trusting the physical serial connection from the real M5Stack hardware, one listening wirelessly — and tags every accepted packet with its source (m5 vs sim) so a forged packet can never be mistaken for the real beacon downstream.
Result: packets without a valid HMAC signature are rejected outright — no scene change, no dashboard update, just a logged rejection. Only packets signed with the shared secret are accepted and passed through to the decision pipeline. This mirrors the real threat model: physical access to the M5Stack is required to spoof the trusted channel, and anyone attempting to spoof over the wireless channel without the key is cryptographically locked out, not just filtered by convention.
Sources
https://quaternius.itch.io/lowpoly-cars https://sketchfab.com/3d-models/bicycle-low-poly-minimalistic-5c70d53e069a4112a58683ede7bc2be6 https://www.cgtrader.com/3d-models/car/car/low-poly-car-jaguar-i-pace-waymo-driver https://sketchfab.com/3d-models/simple-stylized-stickman-base-3d-model-c54b8d1ae8154980aa440c7de6d6abc7#download
Log in or sign up for Devpost to join the conversation.