What if we can forcast train arrivals? Well, why would anyone want to do that...?
Currently, I live in a somewhat densely populated area of Houston, TX (within the "loop" for those in-the-loop). The location where I first lived bothered me in some ways. I'd blame most of that frustration on a particular train system that ran through town and - in both a seemingly unpredictable and usually delayed manner - cut people off from getting to/from work or for anywhere else for that matter. Using this device and other tech, I intend to mitigate this ongoing problem with data and tool
In order to accomplish this project's objective, I'll develop and incorporate the following tools:
1] IoT (via AWS) (not being used currently...)
3] Apache NiFi (not being used currently...)
5] Raspberry Shake 1-D
6] Python (obspy & boto3)
8] BalenaCloud (not being used currently...)
10] DynamoDB (via AWS) (not being used currently...)
11] AWS S3
12] AWS RDS
13] InfluxDB (being tested as a better option compared to TimescaleDB...)
It's important to note that the so-called "moonshot" objective is far away from achieving. RIght now, my concern is with developing and testing the sensor streaming time-series data to cloud DB and then piping
that info to a publically available dashboard for viewing. Once that is done, I can start testing real-time analytics of seismic waveforms and creating alarms/notifications if train waveforms are detected. After this, preliminary field tests will be conducted after rugidizing the sensor for autonomous development and environmental conditions. This is indeed a rough draft but it's a manageable plan.
The videos above show a system that is collective referred to as a "Raspberry Shake." There's a variety of such devices - if you're curious to learn more them, click the link below.
***[01/15/2020] >>> ]It's odd it use a geophone for this particular kind of application. I'd imagine that some kind of laser or optical system would perform much better. Regardless, I'd like to develop and apply what I know to address the problem listed above. Now, if the device/sensor is sensitive enough - which has yet to reliably determined - then perhaps it can outperform things like cameras or lasers in terms of better forecasting train arrivals from greater distances.
***[02/01/2020] >>> As a benchmark for this project, time-series seismic data will be sent to a PostgreSQL DB in AWS RDS (via Python's psycopg2 module). From there, those data will be read real-time and visualized via a Grafana dashboard. Data are currently loading into the DB, but I have yet to connect Grafana to the table. Note that once this benchmark has been achieved, I'll start actively developing and incorporating more a best-practice approach.
***[02/02/2020] >>> Today the first version of the train-track single sensor DB upload script has been made available via GiiHub here: https://github.com/nate-benton90/train_track.git . Note that you need to have a PostgreSQL DB to use as well as all the necessary Python modules. Also, this script uses Python 2.7 (for now). This is because the template script provided the RaspberryShake group developed was/is built this way. I may change it to Python 3.7 later on.
***[02/04/2020] >>> Finally managed to connect both Grafana and the simple time-series data stored via AWS RDS PostgreSQL table. See images below for more insight. Although no analytics are being conducted yet (i.e. for train arrival forecasting), after resolving this stage, doing so will be made possible. Here's something really important to note: add the port at the END of the Host string. This is something that held my progress up for a while - simple I know - but that's perhaps the only "gotcha" part of hooking the DB up to Grafana.
[02/17/2020] Although data are now being actively stored and subsequently retrieved for dashboard viewing (this also is a seperate challenge as the Grafana one above is snapshot. I'll eventually make one real-time and public facing), I'm now planning what needs to be done in order to effectively gather and analyze the recorded time-series seismic data. What's the point of all that? Remember, we're trying to detect incoming trains and thereby forecast their arrivals further down the track.
As I see it now, there are two obstacles to this: 1) train signal discernment and 2) wavefront direction/orientation. The first involves accurately evaluating signal (trains) from noise (literally everything else) - this will likely be done with functions from the Python package ObsPy Overcoming the second issue will eventually involve acquiring another sensor and then synchronizing both in order to discern in which direction the train is traveling (yes, it can arrive/leave going from East to West and vice-versa). Work is being conducted now to resolve these upcoming issues.
[02/19/2020] A lot of work for this project has been delayed - unfortunately - by other activities that I'm involved with. Check back in regularly to see if anything has changed here - otherwise, reach out if you'd like access to data or code from my work.