Inspiration
Getting from one place to another on campus seems simple until the shortest route includes stairs, a steep slope, or an elevator that is out of service. For wheelchair users, people with temporary injuries, or anyone with limited mobility, a route that looks perfectly valid on a normal navigation app may actually be unusable.
This inspired us to build RouteAble, a campus navigation system that does not simply ask, "What is the fastest route?" Instead, it asks, "What is the best usable route for this person right now?"
What it does
RouteAble recommends routes based on a user's individual mobility requirements.
A user selects:
- their starting location,
- their destination, and
- a mobility profile such as Wheelchair User, Limited Mobility, Avoid Steep Slopes, or Fastest Route.
RouteAble then calculates a suitable route while considering factors such as stairs, slope, travel time, and elevator availability.
The prototype also includes live disruption simulation. If an elevator becomes unavailable, the routing network is updated and RouteAble automatically searches for another accessible route. If there is no safe route available, the user is told rather than being directed along an unusable path.
RouteAble also compares the accessibility-aware recommendation against the ordinary fastest route, making the accessibility trade-off visible to the user.
How we built it
We modelled the campus as a weighted graph.
Campus locations are represented as nodes, while paths between locations are represented as edges. Each edge contains accessibility information including:
- travel time,
- number of stairs,
- slope level,
- elevator dependency, and
- whether the path is indoors.
Different mobility profiles change how these paths are evaluated.
For example, in wheelchair mode, stairs and very steep paths become hard constraints and cannot be selected. For other mobility profiles, difficult paths can instead receive additional cost penalties.
We use NetworkX to calculate the lowest-cost valid path through the graph. When an elevator outage is activated, affected connections are reconsidered and the route is dynamically recalculated.
The web application was built using Python and Streamlit, with Plotly for the interactive route visualisation and pandas for displaying route information.
Challenges we ran into
One of our biggest challenges was deciding how to represent accessibility mathematically. Accessibility is not simply another distance measurement. Some features should make a route less desirable, while others can make a route completely unusable depending on the user.
We addressed this by separating hard constraints from weighted penalties.
Another challenge was handling changing conditions. An accessible route may depend on an elevator, but that route can suddenly become unusable if the elevator goes out of service. We therefore designed the routing graph so that disruption information can change the available routes dynamically.
We also wanted the system to explain its decisions rather than simply displaying a line on a map. This led us to include route metrics, individual segment information, and a comparison against the fastest route.
Accomplishments that we're proud of
We're proud that RouteAble is more than a static accessibility map. The recommendation changes according to both the person using it and the current state of the environment.
Our working prototype can:
- calculate accessibility-aware routes,
- support multiple mobility profiles,
- avoid inaccessible infrastructure,
- react to simulated elevator outages,
- visualise the recommended route,
- explain individual route segments, and
- compare accessible routes against conventional fastest routes.
What we learned
Building RouteAble taught us how graph theory can be applied to a real-world accessibility problem. We also learned how to translate human requirements such as limited mobility into computational constraints and weighted costs.
The project showed us that optimisation is not always about finding the mathematically shortest route. Choosing the right objective and constraints can be just as important as the algorithm itself.
What's next for RouteAble
Our hackathon prototype currently uses simulated campus route and disruption data. The next step would be connecting RouteAble to real campus GIS and facilities information.
Future versions could include:
- real-time elevator and facility status,
- detailed accessibility and gradient data,
- indoor turn-by-turn navigation,
- crowding information,
- lighting and safety preferences,
- community-reported accessibility issues, and
- accessible routing across multiple campuses.
The same concept could eventually extend beyond universities to hospitals, railway stations, airports and other public spaces, helping make navigation more personalised and inclusive.
Log in or sign up for Devpost to join the conversation.