PM & Engineer
Navigation without sight is a design problem. I designed a wearable tool that combined obstacle detection & route guidance through audio.
My role
PM & Engineer
Timeline
Rutgers University · Jan – May 2019
Platform
Wearable hardware + software
Results
The problem
Navigation without sight is a design problem
Visually impaired people navigate the world with a combination of memory, muscle memory, and whatever technology they can afford: canes, guide dogs, and a handful of smart devices that each solve part of the problem but none of it completely.
Existing solutions like SUNU (a sonar wristband) or Google Lookout didn't exist back in 2019. No single system combined real-time object proximity, directional awareness, and turn-by-turn navigation in one wearable, accessible package.
We wanted to build that. A system that could tell you: where you're going, what's in your way, and which direction you're facing, all through your ears, hands-free.
At 21 I scoped this as a hardware gap: what the sensors could detect. What I'd frame now is the user's gap: blind travelers navigate the familiar fluently; it's the unfamiliar that breaks down.
The approach
One system, two layers
VISN was a hardware-software system designed to work as one. The hardware lived on the body; the software ran on the user's phone; they communicated over Bluetooth in near real-time.
Hardware. An Arduino Nano, four Maxbotix ultrasonic sensors, a magnetometer (compass), and an HC-06 Bluetooth module, all wired into a breadboard circuit and enclosed in a fanny pack worn on the chest. The sensors measured the distance and angle to objects in the user's path. The compass tracked the direction they were facing. All of it streamed to the app.
Software. An Android app built in Android Studio. It pulled Google Maps data for turn-by-turn directions and layered in the live hardware stream, so as the user walked, they heard both their route and real-time obstacle alerts: "Object 3 feet ahead. Please move."
The design
The decision that mattered the most
We tried a harness first. It held the hardware well: good sensor angles, stable on the body. But it was heavy, conspicuous, and made people feel more disabled, not less. That wasn't acceptable.
The fanny pack was the answer. Worn on the chest, it gave the sensors the right field of view without restricting movement. It was familiar, lightweight, and, critically, something a person might choose to wear anyway. It didn't announce that you needed help.
That decision shaped how I think about assistive technology. The best tools disappear into the life of the person using them. Dignity is a design requirement.
Outcome
We won our capstone.
We shipped a working end-to-end system: real route guidance from the app, live obstacle detection from the wearable, and a reliable Bluetooth link between the two. In outdoor tests, the experience held together in real walking conditions.
We were also explicit about what was incomplete. Directional left/right guidance from the magnetometer was not production-ready by demo day, indoor positioning remained unreliable, and moving-obstacle handling was out of scope for the capstone timeline.
The outcome was clear: the project direction worked. For four people in four months, it was proof that the core system was valuable, feasible, and worth taking further.
Reflection
If I built VISN today
Here's what I didn't know at the time: product design existed as a discipline. I was the project manager and the engineer on this team, and I thought that was the whole job. The fanny pack call, the audio-first interface, the decision to build around dignity, those came from instinct, not training.
I still think those instincts were right. But I can see now how much further we could have taken them with the tools I've learned since. Seven years later, some of what I'd change is technical: the hardware is smaller, the sensors are better, indoor positioning actually works. But most of what I'd change is about the experience itself, starting with the work it takes to earn it: I'd shadow how blind travelers already move through a route they know by heart, then design only for the gap between that and an unfamiliar one, instead of scoping for “navigation” in the abstract and letting the hardware decide what the product was.
That early hardware work taught me to design through uncertainty. The next chapter moved into enterprise systems, where trust had to scale.