GIF

Inspiration

Running is one of the few sports people can enjoy almost anywhere, often on their own. When work is difficult, I sometimes go for a solo run to clear my head. When I reach a new personal best, it gives me a sense of accomplishment.

One day, I saw a visually impaired runner running with a guide. I began to wonder: Do visually impaired runners ever want to run alone? Do they enjoy running for the same reasons I do?

We spoke with visually impaired runners and learned that running can be a source of mindfulness, a personal routine, and a serious athletic pursuit. But without being able to see the track, they cannot simply head out for a solo run. Even when training with a guide, they may need to match the guide’s pace instead of their own.

Running alone outdoors can be dangerous, so we focused on a more controlled setting: an athletic track. We set out to build a device that could help visually impaired runners stay within a lane and experience the freedom of a solo run.

What It Does

Haptic Lane Guide is a chest-mounted smartphone and a waist-worn vibration belt that provide lane guidance on a running track. The phone camera detects lane lines, while its motion sensors help account for the runner’s movement. The phone then sends directional cues to five vibration motors around the belt over Bluetooth Low Energy (BLE).

The motor locations indicate which way to move, and the vibration pattern communicates how urgently the runner should correct their position. If the system loses track of the lane, both outer motors vibrate as a stop signal. The system is designed to run locally on the phone, without an internet connection or cloud-based AI service.

How We Built It

The phone runs a JavaScript web app using OpenCV.js 4.10. Since we did not have access to a Mac for native iOS development, we hosted the app over HTTPS with GitHub Pages and ran it in the Bluefy browser, which supports Web Bluetooth.

At about 30 frames per second, the app identifies white lane markings against the red track by filtering pixels in HSV color space. It uses the phone’s measured tilt to transform the camera view into a top-down map, then tracks the two lines around the runner’s lane. Once the runner presses “Lock,” the system follows those lines through both straight and curved sections. A Kalman filter uses gyroscope data to smooth out camera motion and predict movement between frames.

The app estimates the runner’s position and heading within the lane, then sends a five-byte motor-intensity array to an Arduino UNO R4 WiFi about 20 times per second. The Arduino controls the five coin vibration motors. If it stops receiving packets for 0.3 seconds, a watchdog shuts off the motors.

Because we could not test on an outdoor track after every change, we also built a record-and-replay evaluation setup. It replayed synchronized video and motion-sensor data through the production code and compared results with human-labeled lane departures. We used it alongside 66 Node unit tests, headless Chrome benchmarks, and arduino-cli to evaluate changes and demonstrate the belt indoors.

Project repository: Haptic Lane Guide on GitHub

Challenges We Ran Into

Our first major challenge was latency. Initially, we sent raw sensor data from the phone to a laptop for processing. At the event, congested Wi-Fi caused delays ranging from 0.5 to 30 seconds. Even a local hotspot added hundreds of milliseconds of delay and had about 20% packet loss. We moved the computer vision and control pipeline onto the phone and connected it directly to the belt over BLE. This brought median camera-to-motor latency down to 46 milliseconds.

Developing for iOS without a Mac brought another issue: Bluefy’s motion-sensor events sometimes froze for one or two seconds. We added stale-timestamp detection and used Kalman-filter predictions until live readings resumed.

A tracker that worked while walking did not work reliably while jogging. Video review showed that the runner’s upper body swayed by about ±8° with each stride, and our system was compensating for that movement twice. After correcting the coordinate calculations and improving line-matching heuristics, lane-line matching during jogging increased from 45% to 90%, and in-lane classification accuracy rose from 83% to 96%.

The belt also gave too many rapid, confusing cues. Early prototypes changed states 68 times per minute, including 43 left-right reversals caused by the runner’s natural body movement. We smoothed position and heading over a window longer than a stride and required a new directional cue to hold for at least 1.5 seconds. That reduced changes to 14 per minute with no left-right reversals, while true departure warnings still triggered within 0 to 0.5 seconds.

We also had to tune the hardware to human perception. Pulses lasting 60 milliseconds were too short for the motors to spin up and feel distinct. Wear-testing showed that 200-millisecond pulses were much clearer, so we redesigned the urgent warning pattern around that duration.

Some ideas did not make the final build. Adaptive white thresholds made lane lines clearer in changing light, but caused the tracker to jump lanes near diagonal start markings. We also tried several gyroscope-based methods to prevent lane jumping, but torso sway made them less reliable for detecting real departures. We documented these results and kept the final geometric thresholds conservative rather than tuning them too closely to our small set of videos.

Accomplishments We’re Proud Of

We built a working prototype in two nights and three days, starting without prebuilt hardware. After learning at a first-time-hacker Q&A that we could not bring hardware, we sourced components locally, worked through wiring problems, and built the vibration belt. We are proud that we turned an idea into a functioning phone-to-belt system during the hackathon.

We are also proud of making the lane tracker work at jogging speeds, where body movement created a much noisier camera view than walking. The prototype can identify the runner’s lane and measure lane deviation while jogging, bringing us closer to helping visually impaired runners complete laps independently on a track.

What We Learned

Technically, we learned that a fast, responsive system often depends more on a well-chosen setting and careful signal processing than on a complex model. Moving computation onto the phone transformed the latency, and measuring real vibration pulses helped us design cues people could actually feel. We also learned to test against recorded data and ground truth before making claims about performance.

As first-time hackers, we learned to turn an early idea into a concrete problem, build a prototype, and respond to unexpected challenges one at a time. We saw that making steady progress often teaches us more than waiting until every part of an idea feels certain.

What’s Next

The current prototype has been tested while an adult runner jogged on a track, but it is still a prototype. Even a track has hazards, and the system needs further testing and refinement before it can support more independent use. Our next step is to improve detection around overlapping markings such as start and finish lines, where the tracker can lose the runner’s lane. We also want to address remaining track hazards and continue evaluating the system with visually impaired runners.