BuzzBike (BB)

Inspiration

Every year in the U.S., more than a thousand cyclists are killed in traffic crashes, NHTSA counted 1,166 in 2023, with roughly 50,000 more injured. The danger that causes a lot of those crashes is the one you can't see: you can watch the road ahead, or you can watch the car coming up behind you, but not both at once. We wanted to give cyclists a sense they don't currently have, a felt awareness of what's approaching from behind, without taking their eyes off the road.

What it does

BuzzBike (BB) is a rear-facing 24 GHz radar unit that mounts behind the rider and tracks what's approaching, then tells the rider which side it's on through buzzers built into the handlebar, left buzzer for a left approach, right buzzer for a right approach, both together for something coming straight up the middle. As a threat closes in, the pattern escalates from a calm "something's there" tone to an urgent rattle. The entire decision, detect, classify, decide, alert, happens on the bike itself in milliseconds, with no phone pairing and no internet connection required.

How we built it

The system is two Seeed XIAO ESP32-C3 boards talking over ESP-NOW.

Radar unit: reads a LD2450 24 GHz radar over UART at 256000 baud, watching for its 30-byte frame (0xAA 0xFF 0x03 0x00 ... 0x55 0xCC) and decoding up to three tracked targets' X/Y position and speed. Each target is run through a corridor filter (ignore anything more than ±2 m to the side) and a range filter (LD2450's ~6 m rated range), then we compute straight-line distance and closing speed for whatever's closest and relevant.

From there, threat level comes from time-to-contact — distance divided by closing speed, rather than distance alone, so a car closing fast triggers ALERT/CRITICAL sooner than a slow-moving one at the same range. Direction (LEFT/CENTER/RIGHT) comes from the lateral offset, but raw radar lateral readings are noisy, so we exponentially smooth them and apply a hysteresis band: easy to enter the center zone, harder to leave it, plus a short frame-hold before a direction switch is accepted at all. That single change cut direction flicker from 24 flips down to 4 in our bench testing.

Every ~100 ms, the radar unit packs threat level, direction, distance, lateral offset, closing speed, and angle into a compact 16-byte struct and broadcasts it over ESP-NOW, no pairing, no router, just a fire-and-forget packet to the handlebar unit.

Handlebar unit: listens for that packet and drives two (optionally three) Grove buzzers with distinct beep patterns per direction, 2 beeps for left, 3 for right, a held tone for center, collapsing into a fast, insistent pattern for CRITICAL. Just as important: it tracks a heartbeat. If no valid packet arrives for a full second, or the radar reports it isn't seeing frames at all, the unit doesn't just go quiet and pretend everything's clear, it flags the link as down, so the rider never mistakes "disconnected" for "all clear." Both units also print live diagnostics over serial (packets/sec, lost packets, RSSI, and a plain-English cause) and expose single-key serial commands so we could tune mirroring, filtering, smoothing, and the center band live on the bench without re-flashing.

Challenges we ran into

Noisy lateral readings caused direction flicker — a target near the LEFT/CENTER boundary would jitter between directions frame to frame. Smoothing plus a hysteresis band with a frame-hold fixed this.
Telling a real threat from a non-threat — a pedestrian standing still, or walking away, shouldn't trigger an alert just because they're close. We filter on closing speed and time-to-contact, not raw distance, so stationary or departing objects stay silent.
Failing safely — a dropped radio link or a radar that stops sending frames is dangerous if it just goes quiet, because the rider can't tell "no threat" from "no data." We built in an explicit heartbeat timeout and failsafe state instead.
Time pressure — we had to cut turn signals and a brake light feature this weekend to get the core detection-and-alert loop solid and demo-ready.

Accomplishments that we're proud of

Getting the full pipeline, radar sensing, on-device threat classification, wireless alert, physical buzzer feedback, working end-to-end with sub-second latency and zero cloud dependency. We're especially proud of the direction-smoothing result (24 → 4 flicker events) and of building a failsafe that fails loud, not silent, which we think matters as much as the detection accuracy itself.

What we learned

Time-to-contact is a much better predictor of urgency than raw distance, it's what let us catch a fast-closing car earlier than a slow one at the same range. We also learned how much real-world sensor noise demands deliberate smoothing and hysteresis; a naive threshold on raw radar output would have made the alerts unusable. And we came away convinced that failure-mode design (what happens when the link drops) deserves as much attention up front as the happy path.

What's next for BuzzBike

This is an experimental prototype, not a certified safety device. The LD2450 radar we used is built for tracking people and tops out around 6 meters, which is why we demo with walkers rather than cars. Next steps: swap in a longer-range automotive-grade radar, move from buzzers to vibration motors in the grips for a more discreet and specific alert, and add back the turn-signal and brake-light features we cut this weekend.