OBD-II Bluetooth Chip

Photo Credit: Quintin Kimberling
Duration	Fall 2020 - Spring 2021
Sponsor	SMART Technologies ULC
Faculty Adviser	Bruce Bolden
Client	Hasan Jamil
Team Members	Austin Penelerick Caleb Seely Damien Spencer Hunter Hawkins

Problem Definition[edit | edit source]

The goal of the project is to create an app that efficiently plans trips in any given vehicle that has an electronic fuel gauge sensor. Trips will be planned with data retrieved from a device interfacing with the vehicle along with data from a navigation app.

Background[edit | edit source]

In many states it is a legal liability to use your phone while driving. Even in the places where it isn't a legal liability it leaves you at an elevated level of risk for getting into an accident. Let's say you are running low on gas and want to locate the cheapest gas station nearby. Apps like GasBuddy will allow you to do this. However, you will have to either pull over to use the app or drive at an elevated risk level. You shouldn't be inconvenienced by having to pull over or drive at an elevated risk level to get the information you need. Also, you may not even be able to get this information when you need it if you end up somewhere without a connection. Navigation apps exist which only need your auditory attention to navigate you to your destination. Modern Vehicles have the sensors to provide data needed to predict vehicle range. So, with all of this information you should be able to take a trip without having to inconvenience yourself when this information is needed.

Deliverables[edit | edit source]

Application Objectives:

1) Compute the Range of Vehicle Using Any Means Listed Below
- a) Consumption Rate
- b) Vehicle Payload
2) Locate Available Gas Stations Along Route
3) Recommend Stations Most Efficient to the User
4) Continuously Update Recommendations Based on Current Information

Design Considerations[edit | edit source]

Build off a basic fuel calculation with information we receive from Google Maps and vehicle.
Store all gas stations within reach if our predictions in case predictions are incorrect.
Be able to navigate to any stored gas station.

Project Learning[edit | edit source]

GitHub is very useful for finding projects that have features we need, so we don't have to reinvent the wheel.
- Android OBD Reader
- Android Google Maps API

Fuel consumption should be the focus for predicting rather than fuel level
- Values received from the fuel level sensor fluctuate too much over the course of a trip to be reliable
- For fuel level sensor data to be reliable quite a lot of money would have to be spent on an aftermarket sensor
- Fuel consumption is more reliable because it is calculated using the vehicle's Mass Air Flow sensor
- If a vehicle has a bad Mass Air Flow sensor then that will show since it determines how much air needs to be pulled in by how much fuel is being used

There are no comprehensive databases for gas station prices
- A service could be created that combines the data from what price databases to exist to create a more comprehensive one
- The service could also rely upon users to crowd source gas station prices like GasBuddy does
- Efforts being made to push already existing databases to become more comprehensive would most likely be the best bet or to incentivize gas station owners to report the data
- If gas station owners were to report it users should be able to report and post reviews for gas stations to mitigate misreporting
- In the case of gas station price data being nonexistent worst case price from the region could be used as a placeholder value for calculations
- To avoid brute force calculation of routes with different gas stations along the way a dynamic programming solution could be warranted where something like a radius around the gas station would already be calculated and if the user is within that radius that would be the gas station they navigated to
- Sliding scales could be used to determine the necessary price difference to navigate to a different gas station if the radius calculation isn't up to date with the latest price

Google Maps reporting
- Can query nearby gas stations
- Can query steps for speed limits
- For trip data reports steps which are separated by turns, exits, and entrances
- Steps only have their starting points and endpoints reported without making URL requests to Google
- When making URL requests for steps with long distances the points might not be the most accurate, but repeating the request with the newly generated points may mitigate this

Final Design[edit | edit source]

With the time and resources we had we were able to get two main features into the final design. The first being collection of data from the vehicle through the ELM 327 chip. The other feature that we were able to add in is Google Maps navigation. However, these two features will be very crucial to continuing this project. The main challenge now is going to be closely and accurately predicting fuel consumption because without being able to do this the project won’t be possible. Our plan was to create a very primitive fuel consumption estimation that would have been optimized for a single vehicle. This would have been the only method we could have completed with the time and resources we had. However, with the features we did add future teams working on the project will be able to create datasets using data collected from multiple vehicles. These datasets could be used to train a machine learning model that would predict gas consumption for vehicles. This method would be much better than an algorithm optimized for only one vehicle.

Validation[edit | edit source]

Mass Airflow can capture the consumption difference between the A/C on or off.

Test 1 A/C On		Test 1 A/C Off
3 Independent A/C Tests MAF Chart		3 Independent A/C Tests Consumption Chart

Tested idling and driving fuel consumption totals against fuel percentages and found there was a 0.02% difference and a 0.12632787 Liter difference. Test involved idling ten minutes to get the most accurate starting and final readout with a trip made in between.

Tests were ran on an ELM 327 chip and a COB access port to verify that the values reported by the chip were within expectations for accuracy

Team Members[edit | edit source]

	Austin Penelerick Major: Computer Science Hometown: Rathdrum, ID Responsibilities: Team Leader, Data Science Lead Email: pene9604@vandals.uidaho.edu
	Caleb Seely Major: Computer Science Hometown: Portland,OR Responsibilities: Meeting Minutes, Google Maps API Lead Email: seel3482@vandals.uidaho.edu
	Damien Spencer Major: Computer Science Hometown: Kellogg, ID Responsibilities: Client Communication, Wiki Admininstration Email: spen8026@vandals.uidaho.edu
	Hunter Hawkins Major: Computer Science & Computational Mathematics Hometown: Hayden, ID Responsibilities: Budget Management, Meeting Circulation Email: hawk5052@vandals.uidaho.edu