Graphing car metrics into the cloud with Raspberry Pi, OBD and Graphite19 Apr 2015
In this post we’ll see how you can grab car sensors data and turn them into some good loking and easy to watch graphs.
I’ve recently changed my car’s stock air filter with a performance one which really improved the car’s responsiveness. While driving back from Romania to Czech Republic I was thinking that this can’t just come for free and I wanted to see how it impacts the car’s working parameters. First thing I noticed has changed was the fuel consumption. Since the car board computer only provides instantaneous and average fuel consumption numbers I can’t really get to do an analysis of how it changed in time. Numbers are good but, at least for me, it’s hard to interpret them as absolute values and I need to get the whole picture where they stand. The first thought that came to mind was to turn metrics like rpm, speed and instantaneous fuel consumption into easy to read graphs. This would at least get me some more insight with historical data of the car’s working parameters.
So there kicked my doer spirit and I started thinking of ways of doing it. What did I need:
- Data source
I knew most of the cars have a diagnosis port called OBD which is used for reading data from most of the existing sensors in your car.
- Data destination
Once I got all the sensor data I needed to graph it somehow. This would be the easiest task since I had already used Graphite before and knew how easy sending the data and getting the graphs done was.
- Data processor
Now that I have the data source and destination I also needed the device that processes/forwards it. I had a Raspberry Pi standing on my desk for 2 or more years without turning it on so I thought that would be the ideal time to start using it.
- Put everything together
At this point we have the system’s individual components but we need to connect them somehow to get functionality out of it. After doing some searches I found out that there were some cheap Bluetooth OBD readers on the market and decided to go with that. Since I was going to use Bluetooth for connecting the Raspberry Pi to the OBD reader I also needed a USB Bluetooth dongle. The last step in getting the system done would be to get the Raspberry Pi connected to Graphite. Since I’m a cloudy guy I’m going to run Graphite on my Openstack lab so this means I’m going to need an Internet connection on the Pi. First thing that came to mind was getting a USB 3G modem. After doing some reading I found out that most of these modems require external power. I wanted to keep cabling as clean as possible by powering the Pi from the car’s USB port so I went for another approach. The solution I came up was to use my phone’s tethering capabilities and get the Pi connected via WiFi. By doing this I also required a USB WiFi dongle.
Diagram of how this is going to work:
Bill of materials:
- Raspberry Pi Model B
- Kingston 32GB SDHC Memory Card Class 10
- MicroUSB cable
- Asus USB-BT400 Bluetooth dongle
- Edimax EW-7811Un WiFi dongle
- Elm327 OBDII Bluetooth Scanner
- 3G Tethering capable phone
Before getting started:
- Get your Raspberry Pi installed.
- Make sure it’s connected via WiFi to the mobile phone
- Find its IP address and connect to it via SSH
- Install graphite and grafana. You can use these Ansible roles here: https://github.com/remoteur/ansible-graphs
TL;DR. Let’s get started:
- Connect the OBDII reader to your car
- Log in by SSH to the Pi
- Discover the OBDII mac address or read it from the case:
- Add the MAC address to the Bluetooth conf file.
- Write init script that will manage the Bluetooth connection through the /dev/rfcomm99 device.
- Create the device by running the init script
- Install obd python module via pip
- Write a script that reads sensor values and sends them to the graphite instance:
- Run the script and you should start seeing the metrics graphed by Graphite. I’m using Grafana as a Graphite frontend and here’s how the graphs look like after a ride:
You can see that I only captured the RPM and speed sensor. The equation for calculating the instantaneous fuel consumptions includes a sensor that seems to be missing from my car or at least I don’t know how to read it. I need to dig further to see how I can get it.
I think this is a great example that demonstrates how easily you can leverage a physical measurement by software today. I really like it mostly because I have a general feeling that during our lifetime we could be missing important bits just because we’re not analyzing enough the world around us. As humans we have a limited set of receptors(sensors) and I guess making use of the available compute power on a general scale might at least show us some unknown patterns in the world arounds us.
- Live demo: