Saw this headline and thought “Someone beat me to it!”, but alas it has more to do with a HUD and Alexa-like features in your car. What I’m going to experiment with soon is Amazon’s recently released Amazon Echo API using their Lambda service so that you can access your Black Box Pi stats via your Amazon Echo. After all, the birthright of this project is the sheer volume of data your car generates for you as you drive around with the Raspberry Pi inside. Whether it’s OBDII, GPS, accelerometers or anything else. My goal is to start with the basics like:
Alexa, how many miles did I drive last week?
Alexa, what was my average mileage for last week?
This project has always had 2 halves: the Raspberry Pi in your car gathering up data, and the cloud service that the data gets uploaded to that then provides you with analytics. That second half, the cloud service, has been in a MySQL database with a REST API in JSON through PHP. This is going to change, at least as a test. Given that my day job involves working with a full Microsoft stack, I’d like to try out moving the cloud part of the project to Azure. Azure will host the database in SQL Server, and the REST API in JSON through ASP.NET Web API.
Another factor for me is cost. Right now I have sunk costs in Linux servers with Linode and Rackspace. So with using LAMP like I am now, it’s no additional cost. Moving the cloud half of this project to Azure means I’ll be spending about $15 – $20 per month on hosting that, as of now, I have no other uses for. But what this shift does is allow me to take my Microsoft development skills over from work into my personal hobbies. It doesn’t mean I’m giving up Ubuntu any time soon, nor open source in general. It means I’m adding Satya Nadella’s new Microsoft into my personal life.
Seeing as how I’m really taking to drawing on my new Surface Pro 4, here’s a rough sketch of the proposed new architecture. Yes, I have the drawing skills of a 4 year old.
None of this will change anything about the Raspberry Pi source code. It is as of now, and will continue to be, free and open sourced and Linux based. 90% of this project is the code running on the Pi itself managing sensor data in the car. That will continue to be on GitHub as the OBD2 Python SDK for logging vehicular OBD2 and GPS data.
This post by Pangea says it better than I can:
Although we built Pangea’s platform using .NET, we are not a Microsoft shop. We’re a technology shop and that means our tech stack is quite diverse.
They’ve done it again, the Raspberry Pi now has an edition at only $5 that’s more than capable for this project. I have been using a Model B and the new 2 for a while now. The project specs were built on it. However, the data logging and transfer could easily run on the lower spec’d Zero.
Startup costs on this project just got cheaper. You’ll still want a USB GPS for logging vehicle travel, and a OBDII reader to read engine diagnostics. But with a cheaper Pi, overall project cost just went down significantly. And it’s already cheap to turn your car into a Fitbit.
The geek Mecca, Microcenter, in Cambridge, MA is sold out of Zeros. As soon as they’re back in stock I’ll be getting some to use for this project.
Rear facing camera
With a Zero being only $5, it’s possible to use a dedicated computer just for having a rear facing camera in your car without having to run wires to the main Pi. You can keep it all together in one package and record a rear facing dash cam every time you drive.
As I get ready to add a USB webcam to the Pi to use as a dash camera I have to ask: How should the dash camera recording be stored? The textbook definition of recording for a dash camera is to overwrite the oldest footage as storage space fills up. That way you get continuous recording while keeping the storage maxed out. In the Pi’s case, I’ve got ‘motion’ running continuously while a cron job deletes the oldest video in order to keep the SD card from filling up. The cron job removes video files based on last modified time. This is easy for a home security situation where the recording is constant so you can do the math to predict growth and determine hold far back in modified time from current time you need to delete files. But with a car, you might have a lot of video in a few days or none.
The next level in complexity for managing disk usage is to have a daemon running that continuously checks the amount of free disk space and appropriately removes the oldest files until the target amount of free space is reached. For example:
SD card = 16 GB
Free space after installing OS and needed software = 14 GB
Free space to maintain for OS and other tasks = 1 GB
That means we’re allowing ourselves 13 GB of space for videos. A daemon would check any time there’s less than 1 GB of free space and delete the oldest video file until that 1 GB is available.
Archiving dash camera footage permanently
The simple solution is to keep dash cam footage on the Pi. Ideally I’d like it if footage could be synced to the cloud service at www.blackboxpi.com for archival. The existing syncing daemon that syncs GPS data could also sync video files. But the daemon syncs data by grabbing local DB data via SQL and uploading it via a web API. For file upload and sync we’ll need something else. BTSync is great, but we can also use FTP or something more custom. Is this feasible? Disk usage can grow outlandishly. Plus you’d have to take the Pi inside and plug it into a network cable (or use a USB wifi adapter to make it easier). Then the sync happens in the background.
For retrieval, users could enter their API key and gets a listing of video files to download. Archive can go back X days depending on available resources. Maybe a premium feature is to go back further?
This will only make sense if user syncs before the Pi fills up and starts overwriting old files. Otherwise you’re only getting what’s on the Pi at that moment. That might still be helpful if something happened that the user wants to store online.
There are a few different directions I can take the dash camera functionality next. I’ll start with keeping it on the Pi and consider upgrading to allow for syncing to the website for long term archival. How would you like dash camera footage stored? Do you want to keep it archived for long term storage? Or is it enough to keep it on the Pi for access as needed if anything happens during your drive?
The day that the new Raspberry Pi 2 came out, I ordered one from the official distributor. It’s been in my server closet ever since, preparing it as a test platform for black box duty with added dash cam responsibilities. I’m still configuring and tweaking Motion so we can have a more stable dash camera platform. The Raspberry Pi Model B+ would occassionaly hang after running Motion for too long. With much beefier specs, I’m going to push this one a lot harder with higher frame rates and higher resolution.
For a related application as a home security server, I’ve experimented using the Pi w/ Motion and immediate live backup to another server. To do this I’m using BTSync. It’s not a stable version yet, but it works amazingly well. The problem is that the version available for the Pi tends to crash it sometimes. So it’s useless as a standalone dedicated system. With the Pi 2, I’m going to set that up again and see how it fairs running BTSync.
A Kickstarter for the Spark Electron will release a small component that provides 2G and 3G cellular networking to DIY projects like Black Box Pi. For just $29 and $49, that means the vehicular black box I’ve been building an entire system around can finally sync to the cloud without a smartphone or home WiFi.
A huge portion of my efforts on this project have been around solving the problem of how to get the data off the Pi in the car and into the cloud (that’s the API based web service that stores the data). My first attempts were at using a smartphone app to act as a bridge between the Pi and the cloud. The architecture was simple. The smartphone uses Bluetooth to talk to the Pi, then it’s own data plan to sync that data to the cloud. That means building an iOS app and an Android app for syncing. It’s not a trivial undertaking for a hobby project. Option number 2 is to add a tiny WiFi USB dongle to the Pi so it can sync via your home WiFi when you park your car. That alone is fraught with problems: when you get home and it starts syncing, you shut the car off which kills the Pi.
There are alternative projects which use cellular chips to achieve this, but they are either proprietary or have a high price to match. The ethos behind the Black Box Pi project is to use cheap and freely available COTS (common off the shelf) components and open source software. Commercial solutions have their place along open source alternatives.
This module can finally allow the Black Box Pi to act as a completely standalone device without any need for a computer, home network, or smartphone. It can act fully silently and behind the scenes.
Here in the Boston area we’ve been pounded by some of the worst snow storms in decades. The snow keeps coming down and piling up. The problem? There’s nowhere to put the stuff. Roads are narrow and slippery.
The most dangerous aspect of this is that you can’t see in either direction of the street you are pulling out onto. Hell, I can’t even see my street as I pull out of my driveway. My only option is to pull out SLOWLY and hope any oncoming cars see me and either swerve or stop for me.
In too many cases I’ve had to break suddenly because a moron pulled all the way out into my lane before seeing if there was a car there or not. Having a dash cam in these scenarios is critical.
The latest Raspberry Pi 2 Model B is out, and with it comes some new testing on my part for use as a dash cam.
Raspberry Pi 2 Model B (1GB)
The original Model B would sometimes lock up when running motion for too long. Granted, that’s stress testing and I kept it running longer than you ever would during driving. But I like to put things through their paces.
One of the most useful features of the Black Box Pi is hooking different sensors to it, like a dash cam. I left this feature out initially as I was focused on GPS and OBDII data. However, you can easily plug in a webcam and set it up on the Pi to record. Motion is the most popular program in Linux to do this. The trick is getting the configuration just right to optimize the recording as a dash camera.
I’ve setup a Pi with Motion and had it running for a couple of weeks now non-stop as a stress test. As before, the Pi tends to crash after a few days of recording. It’s good to have this as a baseline. For our purposes, this won’t be an issue as the Pi will only be running while your car is; no more than an hour at a time or whatever your commute normally is.
The key is the Motion config file. I’ll post this up soon as well as install instructions.
The Black Box Pi car black box computer will now automatically sync GPS data any time it has an internet connection. This is a big step in usability and ease of use.
The prior method involved taking the Pi out of your car, plugging it in at home, connecting to it via SSH, and finally running a Python script to sync the data.
That sync script is now running in the background. Any time there’s an active internet connection then data is being uploaded to the server. You’ll still have to take the Pi home and plug it in, but that’s all. No more SSH’ing into the Pi. It silently syncs up all the data in the background.
The constant syncing takes up very little bandwidth. Here’s a speedometer readout. You can get this by typing:
speedometer -tx eth0
Add a USB WiFi adapter to the Pi so it constantly looks for open WiFi access points to get a connection. It can be configured to look for open APs or pre-defined APs such as your phone’s hotspot, home WiFi, or MiFi.
This discussion gives plenty of easy to setup options. They’ll be included in the Pi’s setup.
With the WiFi adapter, the Pi will much more easily sync it’s data off the local SD card and onto the server.
Recently I attended MongoDB Boston, a conference dedicated to the uses of MongoDB, a NoSQL database. The talks included Mongo’s use for developers, DBAs, architects, and operations professionals.
Here at BlackBoxPi the vehicle data is stored in MySQL, but I’m always looking to experiment with MongoDB. One of the important talks at the conference was the use of MatPlotLib to visualize data. MatPlotLib is an open source graphing toolkit in Python. There’s a gallery of dozens if not hundreds of graph types it can produce. I’ve put together demo code that outputs GPS data into a graph. The script is available in GitHub as part of the server side of the project.
Conceptually, the data is in MySQL on the server. A Python script is fed data from an HTML web form on this site in WordPress. The Python script takes the inputs from a form such as user’s ID and start and end date. It connects to MySQL, runs a query to download summary GPS data such as number of records per day or the N last days of data, then puts this together into a tuple. The tuple stores all the output which is given to a graph created in MatPlotLib. That graph is then saved as a PNG file.
This Python/MatPlotLib proof of concept is now functional. The next step is to come up with some examples, create the HTML forms and DB queries, then allow you to view the graphs it generates. If you have any ideas on what you’d like to see, I’m open to it. Just let me know.