clearly not accessible(problem we are fixing)
dark mode
light mode
live navigation
directions report
robot's eyes
interacting with folks
suggesting a better route
admin controls

UnMapped

Inspiration

All of us were new to the JHU campus, and Google Maps was the first thing to fail us — it sent our friend Mark, who has a broken leg, straight toward a staircase even after he explicitly selected a no-stairs route. Around the same time, we noticed JHU's own campus map was outdated, with accessibility annotations that didn't match reality. We even found an "accessible route" sign standing right next to a staircase. Apple Maps wasn't much better: it routed us in a wide circle around a lawn we could have walked straight across, adding unnecessary distance for no real reason. On top of that, Baltimore's streets are often narrow and uneven, which can be genuinely difficult to navigate in a wheelchair, and more than once Apple Maps sent us down dark, empty streets at night just because they were technically shorter. Each of these was really the same problem in disguise: existing maps assume one route fits everyone, when in reality the "best" path depends entirely on who's walking it.

What it does

UnMapped generates route suggestions tailored to what each user actually needs — whether that's a student rushing to class who wants the fastest path, or a wheelchair user who needs to avoid stairs and steep slopes entirely. Unlike Google or Apple Maps, which build their maps top-down from LiDAR-equipped cars, we let users submit and label their own routes with accessibility features and safety notes along the way. A robot then physically walks those user-proposed routes to independently verify whether they're actually accessible and safe for scooters, wheelchairs, and pedestrians. That verified data is what lets users confidently choose the route that actually fits their situation, instead of hoping a generic algorithm got it right.

How we built it

App stack

Frontend: We started with wireframes, moved to low-fidelity sketches, and then used React to bring the design to life, hosting the final app on Vercel with a custom CSS and React-based UI.

Integration: We used Mapbox for our base maps and built a custom Dijkstra-based routing algorithm weighted by real observations collected from the robot, supplemented with JHU's existing (if outdated) accessibility data as a starting layer.

Robot stack

We used a Unitree Go2 robot dog to physically walk user-specified routes, recording LiDAR and camera data throughout via ROS2. That raw data is then processed in two ways: a vision-language model (VLM) extracts semantic accessibility information — signs, construction sites, parked cars — while custom Python scripts analyze the LiDAR and IMU data to flag sections that are too narrow or too steep.

Routes can be proposed by a human user, or generated automatically by the VLM given just a source and destination. In the app, users select the accessibility conditions that matter to them, and we surface the route — along with everything they need to know about it, from accessibility to lighting and general safety — that best fits their requirements.

Challenges we ran into

Deployment issues ate up more time than expected — invalid admin sessions, 502s, and 405 errors kept popping up.
Managing our time and expectations across 36 hours, without overcommitting or sacrificing sleep entirely.
Balancing the drive to build something genuinely impressive against our own mental and physical health.
Trying to do too many things in parallel instead of sequencing our work.
Finding a cozy place to actually sleep during the hackathon.

Accomplishments that we're proud of

Everything we built — the team, the idea, the hack, and the demo — but also the experience of engaging directly with the JHU community, Baltimore locals, and industry mentors along the way, and the feedback that gave us to shape the product.
Shipping a project we genuinely believe can benefit both the JHU and greater Baltimore community, not just serve as a hackathon demo.

What we learned

Smarter ways to work within VLM API limits — like looping through available models to find ones that haven't hit rate limits yet, and packing as many tokens as possible into a single call.
Building a full-stack product that doesn't just work, but includes features people genuinely want, is hard — even with agentic AI accelerating parts of the process.
Open communication is the foundation of good teamwork, especially under hackathon time pressure.

What's next for UnMapped

We want to expand UnMapped beyond Johns Hopkins into more communities across Baltimore, scaling both our user base and our robot deployment. We plan to do this through open-source collaboration with community leaders and charities who can connect us with disabled users who need this most, as well as with influencers who can help spread the word and grow our impact.