StopMate

github link: https://github.com/OlufemiAllyson/StopMate-Accessible-Transit

Inspiration

Knowing when your bus will arrive should not depend on owning a smartphone.

Transit apps are convenient for many riders, but they assume access to a charged phone, mobile data, and an interface someone can comfortably use. That can leave out people with disabilities, people experiencing homelessness, older adults, and riders without reliable access to technology.

Airports and major terminals already provide shared arrival displays and announcements. We asked: What if we brought that experience to everyday bus stops?

StopMate repurposes familiar technology into a small, accessible transit terminal. Our mission is simple: making public transit work for everyone.

What it does

StopMate lets riders request upcoming bus arrivals without using a personal phone. They can:

Say “Hey StopMate.”
Wave a hand in front of the sensor.
Press a physical button.

The device retrieves arrival predictions from Gainesville’s official RTS API and announces supported routes and estimated arrival times. A character display provides text information, while an eight-LED ring uses route colors and positions to represent arrival-time ranges.

These alternatives support different needs. Spoken information can help blind and low-vision riders, while text provides another way to receive information for Deaf and hard-of-hearing riders. Multiple input methods let riders choose how to interact.

Our companion website mirrors the device’s announcements and lets an authorized operator change the selected stop. It includes mobile layouts, high contrast, and screen-reader support. **WCAG 2.1 AA is our accessibility target. We envision installation at major stops, with reachable controls and clear space for wheelchair users.

How we built it

We built the firmware in C++ using Arduino and PlatformIO on an ESP32-WROVER.

An INMP441 microphone captures audio for a custom wake-phrase model trained with Edge Impulse. The quantized model runs directly on the ESP32, so ordinary wake-word recognition does not require streaming microphone audio to a cloud service.

After a request, the ESP32 uses Wi-Fi to retrieve predictions from the RTS API. It then assembles prerecorded speech snippets stored on a microSD card into an announcement containing the route, destination, and arrival time. This lets us reuse audio clips instead of storing a separate recording for every possible announcement.

The hardware combines a Freenove audio amplifier and speaker, an ultrasonic sensor, a physical button, an LCD1602 display, and an RGB LED ring.

We also built an Express-based companion website deployed on Fly.io. In the current prototype, a USB-connected computer bridge forwards device events to the server, allowing the website to display what the device actually announced.

Challenges we ran into

The 3D printing lab at Marston Science Library was closed for the weekend, so we weren't able to print our planned enclosure and had to adapt our hardware housing on the fly.

Running speech recognition alongside networking, audio playback, and sensor handling required careful management of the ESP32’s limited resources.

Wake-word detection was especially challenging. Training examples did not always match audio captured by the real microphone. We added a serial-controlled recording workflow so we could collect samples through the device itself and improve our training data. We also adjusted confidence thresholds to balance missed requests against false activations.

The ultrasonic trigger needed repeated testing. A sensor that reacts too easily can interrupt people nearby, while one that requires too much movement can be frustrating to use. We refined its background-distance handling and trigger conditions through physical testing.

Integrating the peripherals also meant resolving shared-pin constraints, microphone configuration, display behavior, and audio-storage requirements. Finally, we had to keep the website synchronized with the device’s actual response rather than showing an unrelated schedule.

Accomplishments that we're proud of

We built a working prototype that connects a physical interaction to a transit-data request, a spoken response, and a matching web update.

We are particularly proud of running custom wake-phrase inference directly on the ESP32 and providing button and gesture alternatives. Voice recognition is useful, but riders should have other ways to ask.

We also created reusable announcement audio, modular route configuration, remote stop selection, and an enclosure concept that brings the components together.

Most importantly, accessibility shaped the product from the beginning. We considered how riders request information, how they receive it, and whether they need to own another device to access it.

What we learned

Accessibility requires choices. A spoken answer does not meet every rider’s needs, and neither does a screen. Offering different ways to interact can make the same information available to more people.

We also learned that a model’s performance during training does not guarantee the same behavior on physical hardware. Microphone placement, background noise, and real voices make testing essential.

Building the complete system taught us how closely embedded software, machine learning, hardware, and web development depend on one another. A useful experience requires those pieces to work together reliably.

What's next for StopMate

Our next step is testing with disabled riders and local accessibility organizations. Their feedback should guide control placement, tactile identification, display readability, and announcement behavior.

We also plan to:

Improve wake-word recognition using more real microphone recordings and testing in street noise.
Expand supported routes, destinations, and languages.
Print 3D casing.
Replace the prototype’s USB web bridge with a direct device-to-server connection.
Improve how the system distinguishes unavailable predictions from connectivity failures.
Complete an accessibility audit of the website.
Develop and test an outdoor enclosure, power supply, and maintenance plan.

We would seek a transit partner for a small pilot at major stops, measuring whether riders can independently request and understand arrival information.

Our goal is a mini terminal at every stop, making public transit work for everyone.

Built with: ESP32-WROVER, C++, Arduino, PlatformIO, Edge Impulse, INMP441, I²S, microSD, ultrasonic sensing, LCD1602, RGB LEDs, Gainesville RTS API, Node.js, Express, JavaScript, HTML, CSS, Fly.io.