By: Rohan Mendon
One of the ways TrueCar fosters its culture of creativity and innovation in the automotive marketplace is through our annual Hackathon. This 48-hour social coding event allows our Product and Technology teams to come together and build out-of-the-box ideas in a very short time. Fueled by DJs, coffee, and seated massages, 15 teams worked tirelessly over two days to produce some amazing results. Here’s a look at one of those projects.
TrueCar has been always been a one-stop site for in-market consumers looking to buy their next car, where they research cars and their prices, and connect with TrueCar Certified Dealers to make their purchase. Once consumers finish purchasing their car they typically don’t revisit the site until their next purchasing cycle, which can be 3 to 5 years in the future. Inspired by health trackers like FitBit®, this project aims to provide a valuable service to returning consumers even after they purchase their vehicles.
We built a consumer dashboard (web application) by collecting real-time driving stats from a specific vehicle and displaying the following information:
- Vehicle Information, like Year/Make/Model/Trim
- Car Health
- Fuel Level
- Average Daily Miles
- Average Speed
- Average RPM
- Timestamp (when the data was last synced)
The Implementation Details
We used a 2013 Honda Civic Sedan.
We purchased a Bluetooth-enabled OBD-II reader device.
We installed the reader device in the car by connecting it to the OBD-II port.
We paired the Bluetooth OBD-II device with the Google Pixel 2 XL phone running Android 9 Pie, using the phone’s native Bluetooth connectivity capability.
We then built an Android app that connected to the OBD-II reader device via Bluetooth, and collected driving stats:
For example, executing the OBD-II command 010C0D2F
01 => ‘Show current data’
0C => ‘Engine RPM’
0D => ‘Vehicle Speed’
2F => ‘Fuel Tank Level’
Raw response from Device:
Calculations to convert from Hex to Integer:
During the course of this project, we realized that the odometer reading from the vehicle is protected and not exposed through the OBD-II port, hence we pivoted to computing the distance traveled by collecting the phone’s GPS coordinates at frequent regular intervals.
NOTE: These OBD-II devices are slow and not very sophisticated, in the sense that they don’t have memory nor contain a web server, and hence don’t do multithreading. We ended up executing commands in sequence and adding sleep in between two successive command executions.
We stream-collected the stats and persisted to a database, as you can see from the snapshot below of the data from CloudWatch Logs.
In order to transfer the data from the phone to our AWS infrastructure, we used the following AWS resources:
AWS Cognito: We used Cognito’s identity pools to provide AWS credentials to grant users access to AWS services. With an identity pool, users can obtain temporary AWS credentials to access AWS services, such as AWS Kinesis, S3, and DynamoDB. Identity pools also support anonymous guest users, which we used to get the connectivity going. We set up one identity pool called “test_kinesis_identity_pool”
We also linked the identity pool to Kinesis Stream from the next step.
AWS Kinesis: We used Amazon Kinesis to collect and process data streams in real time. We set up one Kinesis stream with one shard:
AWS Lambda: We used Lambda to process the data stream from Kinesis in real time. We set up one Lambda function called “test_kinesis_data_stream_ruby” and linked a trigger from Kinesis. We also wrote the Lambda function in Ruby, which is a very recent offering from the 2018 AWS re:Invent conference.
From CloudWatch Logs, you can see the data stream from Kinesis, containing speed, RPM, fuel, and so on.
AWS S3: We used S3 as a store, for all data from Kinesis.
AWS Redshift: We wrote some ETL to read the data from S3 and persist it to a database table.
AWS IAM: We set up permissions along the way, in order for each of the AWS resources to communicate with each other. Here is the sample Android code using the Android AWS SDK to post data to the Kinesis stream we set up in the previous steps:
Using our consumer-facing frontend and backend applications, we built the following dashboard:
- Our consumer-facing frontend application is the React.js based app running on Node, which was built using our open-source project called GlueStick.
- Our backend is a Rails application backed by a Postgres database.
- We built a JSON GET API, which accepted a VIN, and returned the data to power the page.
In the end, our team won the Hackathon’s Most Creative award.
Pictures from Our Booth
This provided an interesting technical challenge for us here at TrueCar. Once we got past the hurdles of figuring out the AWS plumbing and the Bluetooth connectivity, we were surprised at the ease of creating an Android app, since it was the first time for all of us. Once we had the app up and running, it was very exciting to watch the real-time data streaming from the car to the phone to AWS, and the journey was worth it.
As always, a shout-out to Stack Overflow for solving everything.