vyzrhalo

I wanted thin, wireless glasses with video, a HUD, and computer vision. Naturally, I also started looking into building the display hardware. Optics, controllers, batteries, heat—every answer seemed to come with another thing to figure out.

We went with XREAL 1S glasses. I still wanted to build my own, but I wanted us to have a demo first. That became vyzrhalo, a motorcycle perception prototype my teammates and I built at my first in-person hackathon.

We’d experienced loss and seen people get hurt without access to the safety features we wanted to build. This felt personal. I wanted to explore whether we could help a rider notice danger early enough to react.

We planned blind-spot and rear-approach alerts using left, right, and rear cameras. Eventually, turn signals and CAN telemetry would add context. A car on the left matters more when you’re about to turn left. The HUD would show a warning or a temporary camera view, then get out of the way. The rider already had a road to watch.

At first, I wanted the Pi to handle everything. Capture, inference, streaming, and rendering quickly added up. We split the work: the MacBook handled vision and the HUD, while the Pi kept the camera and glasses connections.

That meant video travelling both ways over Wi-Fi. Sending it raw would use too much bandwidth, so we compressed the camera stream with H.264 and the returning HUD with HEVC/H.265. VideoToolbox encoding on the Mac and hardware decoding on the Pi kept that work off the CPU.

For the camera stream, RTP/UDP avoided waiting for transport-level retransmissions, with packet loss as the tradeoff. We cared about getting current information to the rider. GStreamer connected capture, encoding, transport, and playback, giving us a pipeline we could configure without writing every stage ourselves.

OpenCV and YOLOX handled detections. The native HUD used C++20, Metal, and CoreText. Python/FastAPI services, ElevenLabs, and LLM adapters supported the backend and voice work.

Our 30,000 mAh power bank sounded reassuring. Then I had to work through what it was powering. We needed the right voltage and enough available current, including the cameras and display adapter. Cable limits and shared outputs mattered too.

I couldn’t assume every disconnect was a code problem just because code was what I was comfortable changing. We started with one camera and one stable stream, then added more. That gave us a way to narrow down power, driver, and bandwidth issues.

The glasses connected to the Pi’s micro-HDMI output through an active HDMI-to-USB-C adapter. Its green LED could stay on while we had no picture. We checked HDMI on another display, Linux connector detection, and the glasses on a known-good source. We worked through display modes, cables, power, and throttling a piece at a time.

The school network had a captive portal and forced 2.4 GHz. We spent time investigating our setup before realizing the restriction came from the network.

We created a hotspot, connected everything, and… still 2.4 GHz. I thought we’d at least earned a different problem.

This time, Apple’s Maximize Compatibility setting was responsible. Turning it off fixed the band issue. We finally had control over the connection we were trying to debug.

Lowering the display brightness made the background look truly transparent. Except now the text was slightly blurry. Our readability work focused on sparse, bright text and icons over black. White text, amber warnings, and cyan navigation gave each element a clear purpose.

Warnings also flickered, and feeds disappeared. We separated live video from slower inference, limited the queues, and checked freshness so old frames wouldn’t keep piling up. Warning text could stay briefly to remain readable. Detection boxes had to match their frame. Knowing where a vehicle used to be wouldn’t help much.

When the HUD stopped, we needed to know where it had failed. We added persistent launchers, independent Pi services, readiness checks, and recovery controls. Checking “Mac rendering” separately from “Pi receiving” let us recover one part without restarting the whole setup.

During the hackathon, we also connected a Three.js simulation to the HUD. It supplied camera views, movement, braking, vehicles, and pedestrians. That let us repeat scenarios without waiting for motorcycle hardware or physical GPS and IMU modules.

Browser maps and SQLite reports let us explore shared hazards with scripted riders. We could merge duplicate reports, track confidence, expire old information, and display heatmaps. We also explored Solana as a way to share reports.

The custom ribbon cable connected to the glasses overheated and came off. We nearly had to present the whole thing on the MacBook’s screen.

We took the setup apart and secured the connection on the spot. The glasses were still connected to the Pi, and they worked again. Now we just needed them to hold together for the demo.

They did. We walked away with first place in our track and a second award. My first in-person hackathon, and we’d won twice. After everything it took to get there, sharing that moment with my teammates meant a lot.

There’s more I want to do: CAN integration, shared hazard warnings, and an event recorder that keeps 20–30 seconds of footage before an incident, with synchronized telemetry and a save button. Eventually, those reports could help inform a civic dashboard.

I still want to revisit the custom glasses too. I have a much better idea of what I’d be signing up for now.

Thank you to Hidar, Salah, and Yusha for building this with me and working through the parts that refused to cooperate. I’m proud of what we made together. I’m glad this was my first in-person hackathon.