OBD Buddy

Expanding navigation app capabilities with automotive on board diagnostics data

Comment

Inspiration

The inspiration for this project is two fold, both from an interest from one of our group members, and from the API's provided at HackCU. One of our members had purchased an OBD (on board diagnostics) sensor to play around with the diagnostics on his car, and was somewhat interested in playing around with it further. By combining the idea of getting useful, unique data from the car, and API's provided by MapQuest, OBD Buddy was born.

What it does

This application takes data from the on board diagnostics system from a vehicle such as a car or motorcycle. We use this data, layered over a directions application, to provide drivers and riders with contextual information and suggestions based on their location and car data. For example, say a user is on a road trip, and their car is running low on fuel. Because we know their destination, and how much fuel they have left in their car, a piece of data most apps wouldn't have, we can quickly warn them and suggest the nearest gas stations. From there, the user has the opportunity to add the nearest station as a way point, and be redirected for a refuel.

How we built it

We started with an Arduino microcontroller, a wifi shield, and an OBDII-to-UART board. We hooked this into a Pontiac G6, and started collecting the data as the user drives. From there, the data is transmitted via an HTTP request using the Arduino and wifi shield. This data is captured by a Flask server, and stored in a SQLite3 database. Then, using the MapQuest directions API and leaflet.js, we provide simple directions to a desired location in a modern, intuitive user interface. In addition, our front end is polling our back end server checking for alerts based on the data being received. If one is found, our front end receives the necessary information, and informs the user with options to continue.

Challenges we ran into

  • Soldering Wifi Board
  • Connection with Wifi Board
  • String Parsing from OBD Board
  • Docker Container Setup
  • Geolocation and HTTPS
  • Cordova/Phonegap
  • Malformed Raw HTTP Requests
  • Difficulty Debugging in Car at Night
  • Callback Hell
  • Leaflet.js Map Interfacing

Accomplishments that we're proud of

  • Successfully communicating data from car to OBD to Arduino to Flask to Sqlite3 to front end display
  • Decoupled architecture
  • Front end user interface
  • Dedication to completion of project

What we learned

Jake: The items I was really focused on were the data communication and general architecture of the application. Besides the vast amount of interdisciplinary knowledge such as the idea behind OBD and how it interfaces with an Arduino, I learned some hard lessons about the tradeoffs with decoupled architectures. I had been itching to design a system like this, and jumped at the opportunity to implement it. However, the work spent bouncing between different members of the team, helping to define precisely how the communication structure was going to go was eye opening. I felt as though at least a quarter of my time was spent bouncing around playing this middle man role, and it really showed me that defining this communication as early as possible is an important step for next time. In terms of technologies, the biggest new technology that I worked with was Docker. I had never used Docker before, and was impressed at how easily we were able to quickly deploy to different VPS's as we were trying to resolved our issues with HTTPS.

Boskin: I learned that it is very important to carefully analyze the exact byte responses of the OBDII to UART board to the Arduino so that data is properly extracted. I learned how to form basic HTTP GET requests and send them via the ESP8266 WIFI shield through a hotspot to a final HTTP server. I also learned that in complicated systems with multiple microprocessors with their own firmware running, it is important to be able to reset all of the systems to make sure they do not go out of sync.

Brent: Through the course of this project, I’ve gained perspective on things to consider before developing a product. For example, choosing the correct technologies for a particular problem is an important part in ensuring a pleasant development experience for the team. Some specific things I’ve learned is how to configure sqlite3 and why it can be more beneficial to use a more lightweight database than a full-fledged database such as Cassandra. I’ve also gained experience in developing REST API’s for other developers to utilize, and things to communicate to the front-end to ensure a fluid workflow.

Ryan: I designed and developed the web front end for OBD Buddy by utilizing MapQuest’s and leaflet.js’s APIs. Due to constraints of phone usage while driving, I determined several goals that we must meet in the design process: the interface must be easy to glance at to receive information, it must be quick and simple to navigate, the user’s focus must be centered on the map and their personal directions, and finally, user’s must be able to understand prompts quickly, make a decision about the prompt quickly, and take the appropriate action quickly. By keeping these goals in mind, we have developed a user interface that works extremely well for our data and user’s needs.

On the tech side I was spending most of my time utilizing MapQuest’s API in conjunction with the map API from leaflet.js to get directions, search for points of interest, add waypoints to routes, construct markers on the map, plot the user’s current location, and so on. After using the Google Map API at my last hackathon, I was blown away with how straightforward MapQuest’s and leaflet.js’s API’s were to use, understand, and write for; though that does not mean I never encountered any issues; far from it. Due to a number of functions being asynchronous and the existence of a large amount of data dependencies between functions, I found it became difficult to deal with all the callbacks and keeping the flow of data under control. I’ll be the first to admit I do not have a great amount of experience with async programming, and as a result, keeping things simple became one of the most difficult parts of the project. With a little help from others and Google, I learned how to write code effectively in this style and learned a lot about javascript in the process. On a closing note, I also utilized SASS for the first time to simplify my CSS. I will be using it in every one of my web based projects in the future. It really helped to ensure a good structure of CSS, something that I always struggle with.

What's next for OBD Buddy

The next steps we would like to take with OBD Buddy, is to add more features surrounding the valuable data being collected by the OBD board. This could be things like monitoring fuel consumption or giving more details about the severity of any error codes collected by the car.

In addition, the idea of using some kind of adapter to start getting data from motorcycles is a very interesting prospect for us. After talking to the guys at Rever, it seems like this kind of data, specifically the fuel levels in context, are very valuable to motorcyclists.

Share this project:

Updates