Drift

Inspiration

In the 1920s, people paid for bus rides by giving coins directly to the driver, or by dropping them in the fare collection box. People fumbled for change, people dropped change. A 4 minute process.

In the 2000s, this system evolved to where passengers can tap a card to board. While faster, drivers often kept the front door open to ensure everyone tapped. A 2 minute process.

After today, passengers can simply walk in, with all the doors of the bus open. A less than a minute process!

We all take busses every day. Last year in Metro Vancouver alone people went on around 400 million bus trips. For this many bus trips a year, was there something we could do to streamline each individual experience of riding the bus?

Yes!

What it does

Drift enables enables users to pay for bus rides seamlessly without physical interaction.

When users want to ride a bus, they'll first check the app to find the closest bus routes to their location. Users will also be able to monitor the locations of the busses in real time (just like on Uber).

When users want to ride a bus, simply walk on!

Our app has active trip detection. We know when the user is on the bus, and the app will charge the user accordingly. Hands free. Just walk on, walk off!

How we built it

We built the app frontend with React Native. We have a mobile interface for checking the nearest routes, as well as checking where the nearest busses are on the route map. This comes from TransLink bus location data. We also have mobile interfaces for the trip history and setting up payment methods, done through the Stripe API.

In our backend, we use Node.js, which is deployed on Render. We handle user authentication, payment processing, and storing the trip history in the backend. We used a MongoDB database to store all the information we used, making sure to hash user passwords.

In order to implement active trip detection, we built a custom geolocation matching engine. We compare the users GPS location with the GPS location of the nearest busses. If a user is moving in the same direction and speed as a bus for 30 seconds, we will detect that they are on a bus (no one can run that fast!), and will charge them accordingly.

Our geolocation matching engine makes sure that users are not inaccurately charged - if they are just walking and a bus drives past them, we won't charge the user. Also, the engine detects which bus the user is on. At the UBC bus loop, many busses start close together, so when the bus routes diverge, we will show the correct bus in a user's trip history.

Furthermore, we used simulated data services with Python (FastAPI), deployed on AWS, to test our bus tracking. The simulation uses WebSocket services to simulate the user GPS location for testing and demos, and to simulate TransLink bus data to overcome real-time API rate limits.

Challenges we ran into

React Native Expo version 52 does not support Server-Sent Events (SSE), so to set up our own AWS EC2 instance with a load balancer in order to use secure WebSockets.

Additionally, Expo version 52 doesn't support streaming over HTTP GET requests, which led us to use WebSockets for simulation purposes.

Due to TransLink's rate limits, we couldn't access real-time bus data, so we instead used simulated bus data, which was sourced from TransLink's scraped data from the previous day and streamed via a WebSocket.

Accomplishments that we're proud of

We managed to push through thick and thin past the limitations of the software stack we used. Also, we're super proud that we were able to create our own microservice architecture. Finally, the process of making a full-stack React-Native app from scratch was a first for all of us. We worked with React before, but tackling the transition between React and React-Native was difficult but we managed to work it out in the end!

What we learned

We learned how to solve a real-life problem we had through building. Tackling a problem of this scale is difficult, and we'll hit lots of bumps on the way, but it's doable, and the accomplish we'll feel at the end will be immensely satisfying!

What's next for Drift

We have lots in store for Drift.

We want to implement dynamic fare adjustments - youth and seniors get discounts, and we want our payments to reflect that.

We want to implement trip aggregation, to ensure users are not charged multiple times for transfers within the 90 minute window of a trip's start time.

Finally we want to create a machine learning model to enhance trip detection accuracy.

Thank you for reading our DevPost! We hope you've had as much fun reading this as we've had fun making this! :)