Motivation

School day mornings can be stressful, especially if, like my household, you depend on public transport to get to school. In addition to getting through the morning routine on time, we have to constantly keep an eye on the bus information, to ensure that we have a bus on the way which will get us to school on time.

After a few incidents of missed buses and late marks, I decided to do something to help.

Identifying the pain points

The reliablity of schedules

The planning and preparation involved in our daily commute is not difficult on its own, but public transport does not always run on schedule, and bus schedules are especially susceptible to disruption from a large number of external factors such as weather, traffic, road works and etc.

The 0743 bus is considered “on time” if it arrives any time between 0740 and 0745, and it normally does. This is easy to prepare for and accommodate. Things are much more difficult if the bus is cancelled and doesn’t arrive at all, and if road works are holding up any part of the bus route, the time table is irrelevant.

The only way to manage this is to keep an eye on map apps on the phone, checking every few seconds in case a bus has been cancelled mid-way, or is being held up unexpectedly.

The reliablity of apps

These apps do not provide an easy way to refresh the bus-stop-specific view, so we have to keep switching in and out of the detail view to see changes, and hope we aren’t seeing cached or stale data. We also found that the apps tend to try and simplify the view, which is probably great for the casual user, but not so great when we really need to be able to tell the difference between a scheduled arrival, and a GPS-tracked estimate.

Refreshing an app view shouldn’t be a job

This is a lot of work to do while also ~~shepherding the unwilling kitten~~ gently encouraging the child to get their stuff in order, and gather their things, wear matching socks, of the same colour, and the same length, on different feet, and so on.

Tracking the bus had become its own job, and I decided to see if there was a way to make a thing that could do this for us.

Exploring API options

My first challenge was to find a source for reliable bus service data.

The Citymapper API had been discontinued in 2023. Google offers a Map API, but it does not seem to provide a straightforward way to track arrivals at a specific bus stop, for a specific route.

The TFL API offers everything I was looking for, including ETAs for a bus on-route to my chosen stop. It also offers a generous amount of free usage, which seemed (and later proved) more than sufficient for my needs.

I also chose to add weather data to my application

Prototyping

I already had an Inky Frame sitting around, so I figured I could try to use it to prototype the project. My first goal was to build something that just displays the most current bus information specific to us.

The Inky Frame includes a Raspberry Pi Pico W, which, while quite capable, simply lacks sufficient RAM to call the various APIs directly without running into overflows and malloc failures.

I realised early on that I had to host the actual processing elsewhere, and use the Frame to call a simple, efficient endpoint which would return all the data it needed. To control infrastructure complexity and cost, I chose to deliver this data from an AWS Lambda function. With this architecture, I could have the powerful Lambda function handle API complexities, and also include features such as caching weather responses to reduce runtime.

The programming language was an easy choice: I had been wanting to build projects in Go for a while, and something involving external APIs, parallel queries, and serverless, was just calling for Go.