August 5th, 2013 by Todd Anderson
Prior to moving to our beautiful new office here at Infrared5, we were located just off Centre Street in Jamaica Plain. The location was not only convenient for delicious food choices, but also for being located along the MBTA 39 Bus Route.
I prefer to ride my bike into work, but if for some reason that is not possible, I take public transportation. One reason that would prevent me from riding my bike is weather. If you are familiar with winters here in Boston it’s not particularly fun to stand outside in freezing wind and snow waiting for a bus that – let’s face it – doesn’t run on a schedule. In fact, we have a little pet name for the buses that run around here: we call them ‘Banana Buses’ because they come in bunches, leap frogging down Centre in sets of 3.
MBTA scheduling concerns aside, we are fortunate enough to be provided with real-time data from Massachusetts Department of Transportation which, I must say, is quite accurate.
We had been playing around with the real-time bus data for a bit, making various apps and even just using the service as a jumping off point for learning more about a language or library through data integration. Due to a recent fascination with microcontrollers and circuitry, I thought it was about time we have some physical indicator within the office that would notify us of the next approaching bus so we didn’t have to keep checking one of the several apps we built. As such, a project we call MassROUTE was born.
MassROUTE has internally become an all encompassing term for the evolution of how to physically display arrival times for both inbound and outbound buses generally at the intersection of Seaverns and Centre Street here in Jamaica Plain.
First Iteration: Arduino + LCD Module
When thinking about how to display bus information physically, our initial thought naturally was to display the next arrival times on a screen. As such, we went out and grabbed an 16×2 LCD Module (specifically this one by SparkFun available at MicroCenter) and dusted off one of the Arduinos we had lying about since our last fascination of making LEDs blink.
We settled on duino at the time because of its simplicity in serial communication and being able to easily modify the Arduino script to fit our needs. However, we strongly recommend giving johnny-five a try on your next project as it is more active and has several examples to get you started.
Armed with a 16×2 LCD module and a node server consuming real-time bus data, we started pushing arrival times serially to the Arduino over USB:
We were thrilled with our incarnation! … or at least those of us within 2 feet of the LCD screen and could read the times. In the very least it fostered some good discussion.
“What does it say now?”
“Still got 5 minutes. Jeez… I need to make one for you so you quit asking me.”
The tiny 16×2 screen was a great start, but it became apparent that we needed to move away from such a small physical format; we had gone from a mobile app to town crier, basically. We needed to visually present bus arrival times in a simpler – and brighter – context.
Second Iteration: Arduino + Bi-Color LEDs
You gotta bring in LEDs. Typically you start with LEDs, but we were initially fixated on replicating what many cities with real-time data do: display arrival times on a screen. Not being able to convince the higher-ups to spring for a wrap-around ticker, the 16×2 LCD was great for personal use but didn’t fit well in an office environment where multiple people rely on the MBTA.
In conversing with all-around great guy and former colleague Keith Peters, the concept of representing stops as LEDs was bandied about. It actually made a lot of sense. As mentioned previously, the busses have a tendency to forget about a schedule and bunch up. This means that even though the next bus may be 2 minutes away from a specific spot, there may be one or more buses only 5 minutes away from the same spot. We could – in theory – not rush to pack up and run out the door with such valuable information.
With that in mind we set out in displaying arrival times using LEDs representing stops along the route. We even chose bi-color LEDs to denote proximity: Green signifying that the bus is within 5 minutes away and Red signifying ‘PACK UP AND RUN‘.
In this iteration we are displaying 3 stops along the inbound 39 route leading to the one outside our office.
This proved a little more useful in the office; people can derive arrival times via bright LEDs visible from across the room.
But we couldn’t stop there – it only showed the inbound arrivals… plus we had some shift registers lying around and who doesn’t love minimizing output pins on the Arduino by adding more LEDs and shift registers?
Now we had real-time arrival data being displayed for the inbound and outbound buses 3 stops in either direction from the intersection of Seaverns and Centre Street here in Jamaica Plain. And because I can’t stand seeing an unlit LCD screen sit on my desk, I had to hook it back up.
Third Iteration: Cutting the (USB) Cord
We had made some great progress in displaying real-time bus data in a useful way physically that was “readable” by anyone in the office and within eye shot. There was one big drawback, however – the communication of data to the Arduino was coming from a NodeJS server running locally on one laptop – my laptop.
In other words, I had became keeper of the data in its current physical form. If I wasn’t present and didn’t have the Arduino hooked up and the server running on my laptop, their was no cool, funky display and everyone went back to either using an app on their phone or just trying their luck by – GASP – walking outside!
This had to be remedied.
An order was made and a Raspberry Pi and extra goodies showed up on our desks (not pictured is an accompanying Wifi dongle).
With the combination of a standalone device and wifi access, more responsibility comes into play when thinking about MassROUTE‘s physical and electrical presence within a space. Soon it will be “unmanned”, meaning no one is going to come in every day at a certain time, hook it all up and run some servers as we had been doing with the Arduino prototype. It should subsist on its own and hopefully report any errors as to its health. As such, care has to be taken with regards to its lifecycle:
- sequences to relay startup, shutdown and errors (either in connection or communication to service)
- fault recovery and proper restart from a power outage
- cron jobs and management of data requests so as not unnecessarily hit the server at times when data is not relevant
… just to name a few, in addition to the requirement to have a blast programming in Python again!
Transferral and Context
Bringing a Raspberry Pi into the picture brings a whole new set of challenges outside of simply selecting an LCD or LED display, and we have been up to the task. We started from scratch not only with the device, but also the language – removing any NodeJS library dependencies and moving to Python and the RPi.GPIO library. Additionally, we gathered our designers around to bring some more eye-pleasing presentation.
But we can’t give everything away all in one post. You’ll have to stay tuned.
To tide you over we present a short video of the initial transfer of the MassROUTE concept to the Raspberry Pi with 14 LEDs and 2 shift registers (plus some resistors and capacitors):
To Be Continued…