RowdyAccess

Accessible walking directions for UTSA's two campuses: community-mapped ramps and barriers, AI photo detection, and step-free voice navigation.

Comment

Inspiration

Most campus maps assume everyone can take any path. For a wheelchair user, a single missing curb ramp or a short flight of steps can turn a five-minute walk into a detour, or a dead end. People with low vision face their own obstacles: unmarked crossings, clutter, and unclear routes. We wanted a map that treats accessibility as the main feature, not an afterthought, and we built it for the UTSA community, where the Main Campus and the Downtown Campus each have their own quirks.

What it does

RowdyAccess provides accessible walking directions at both UTSA campuses.

  • Accessibility map: Every sign on the map is a piece of accessibility data: curb ramps, crosswalks, pedestrian signals, steps, obstacles, and missing ramps. Green means passable, orange means not. Filled signs with a blue tick are verified; outlined ones are not yet checked. Each sign shows its source (OpenStreetMap, our AI models, or a person) and a photo or Street View when available.
  • Community reporting: With "Add map info," anyone can upload a photo or drop a pin to report a barrier or a ramp. Our models analyze uploaded photos and suggest what they contain.
  • Admin dashboard: Admins review, verify, edit, or delete any point so the data stays trustworthy.
  • Routing and navigation: Users choose Walk, Wheelchair, or Low vision mode. Passable routes appear in blue, and impassable sections appear in red, with a step-free alternative offered. Users can also speak a trip ("From the library to the student union, in a wheelchair"). Live navigation includes a moving arrow, spoken turn-by-turn directions, and automatic rerouting.
  • Extras: UTSA parking lots, VIA Link stops, mobile support, and dark and high-contrast themes.

How we built it

  • Backend: FastAPI with SQLite for storage.
  • Frontend: React, with Google Maps or OpenStreetMap as the map layer.
  • Routing: The OpenStreetMap walking network with our own accessibility rules layered on top. Each mode (Walk, Wheelchair, Low vision) changes which edges are allowed or penalized, so a step can be a minor cost for one mode and a hard block for another.
  • AI detection: Two models running on our GPU. YOLO11 finds obstacles and signals in photos, and RampNet finds curb ramps in street-level imagery.
  • Voice search: Google Gemini interprets spoken trip requests, with our own rule-based parser as a fallback so voice still works if the model fails.

Challenges we ran into

  • Incomplete data: OpenStreetMap often lacks curb ramp and step information, so a route can look fine on paper and still be blocked in reality. That is why we combine OSM, AI detections, and human reports, and why we track the source and verification status of every point.
  • Trusting AI output: Detection models make mistakes, and a false "ramp" could send someone down an impassable path. We made AI detections visibly distinct (unverified until a person confirms them) and built the admin review flow around that.
  • Mode-specific routing: Deciding what counts as "blocked" differs by user, and rerouting around a blocked section without making the trip absurdly long took careful tuning.
  • Reliable voice input: Natural speech is messy, so we added the rule-based backup parser to handle cases where the language model misinterprets a request or is unavailable.
  • Live navigation: Keeping the arrow, spoken directions, and rerouting smooth on a phone, with noisy location data, took many iterations.

Accomplishments that we're proud of

  • A working end-to-end system across two campuses, from photo upload to AI detection to verified map data to routed navigation.
  • A trust model that shows where each piece of information came from and whether a person has verified it.
  • Voice-driven trip planning that works even when the primary language model does not.
  • Accessibility built into the interface itself, with high-contrast and dark themes, spoken guidance, and mobile support.

What we learned

  • Accessibility data is only as good as its coverage and freshness, so community input and verification matter as much as the algorithms.
  • AI is best used to suggest and speed up human review, not to replace it, especially when mistakes affect someone's safety.
  • Routing for accessibility is a different problem from shortest-path routing: the "best" route depends on who is traveling.
  • Fallbacks are essential. Designing a rule-based backup made the whole system more dependable.

What's next for RowdyAccess

  • Expand beyond UTSA to other campuses and cities.
  • Improve the models with more labeled campus imagery, including the confirmed reports from users.
  • Add indoor routing, including elevators, accessible entrances, and building interiors.
  • Include real-time hazards such as construction, broken elevators, and temporary closures.
  • Partner with UTSA accessibility services and student groups to keep the map verified and growing.

Built With

Share this project:

Updates

Submission history