bus notifier for NYC MTA
for raspberry pi
lights up green when it's time to get ready to go, red when it's time to go.
uses OMG BIG DATA to predict when the bus is gonna come
TODO: ask for stop two ahead of actual target stop, to get better arrival times (at actual target stop)
- ssh to your pi
- git clone https://github.com/jeremybmerrill/bigappleserialbus.git
pip install -r requirements.txt
- get a BusTime API key from the MTA here
- create a file called apikey.txt that contains your API key, optionally followed by a newline.
- create a file called config.yaml, modeled after config-example.yaml.
- get the GTFS stop identifier for your line from the VehicleMonitoring API. (Literally watch the feed until a bus is at your stop, then record the stop identifier); paste that into the config file.
- sudo python bigappleserialbus.py
- to run on startup, add this line to
(sleep 10; python /home/pi/bigappleserialbus/bigappleserialbus)&
- optional (TODO:): set a cron to restart every day at midnight (or 4 am or whatever), since there's some unstable-ness around the wifi hardware
for each bus line, wire up: a GPIO pin -> 300ishΩ LED -> 560Ω resistor -> gnd
when do lights go on?
Imagine a timeline:
|---------------------------------------------|------------------|------| A b C d E f G
a) Bus is 7 minutes away, plus walking time. Time to get think about leaving.
b) Green light on
c) Bus is 3 minutes away, plus walking time. Get your stuff and go.
d) Red light on
e) Time to leave. Go now!
f) Red light off. You might not be able to make it, unless you run faster than your walking time.
g) Bus passes your stop.
Walking time is the sum of the time it takes to get out of your apartment to the street (constant per stop), and the amount of time it takes to get to any specific stop (which varies per stop, since some stops are farther from you than others).
Bus arrival times are predicted using k-means clustering -- that is, BIG DATA ANALYTICS AND MACHINE LEARNING -- to based on previous, similar bus trajectories collected while the script runs. Inspired by this academic paper. The way that dates/times are parameterized could probably be improved.
All trajectories are used except those where any single segment took longer than 300 seconds, on the theory that a bus that waits 5 minutes at a stop has suffered some sort of exception (sick passenger? fight? breakdown?) that makes it unsuitable for prediction.
will this work in my city?
I dunno, maybe!
It'll probably work fine if your city uses the SIRI data standard. If you're not in New York and want to use bigappleserialbus, please send me a note, I'd be happy to work with you to extend the code to support your city.
can I help?
Yes. I would love to hear from you. Send me a note, open an issue or send a pull request. :)
ideas for later:
- Use the light sensor to dim/brighten the LEDs based on ambient light (so they're dim if the light is off).
- Use the variable resistor/potentiometer to calibrate walking speed (e.g. it's easier to leave the house in the summer, or when no friends are here)
- Blink the green LED to indicate time until next bus. (E.g. once per 20 seconds if bus is 20 minutes away, when bus is TimeToGo, turn on continuously)
- Blink for 20 secs when it's really time to run.
- use a shift register to support > 4 bus routes or use fewer GPIO ports
- ubuntu unity taskbar widget?
- test various ways to come up with similarity by keeping track of data over an entire test run.
all code except bigappleserialbus/kmodes.py is copyrighted, but licensed to you under the terms of the Apache license (see LICENSE). bigappleserialbus/kmodes.py is licensed under the MIT license (see bigappleserialbus/KMODES_LICENSE)