Motivation

My mom has been privately sharing a car for the last years. Until now this requires each user to document every trip in a small logbook. It is kept in the glovebox and therefore is not used as intended. Not every trip is documented since the users are lazy, in a hurry or simply forget to make an entry.
In consequence, when trying to split the cost of the car as fair as possible, based on the use of it per user, this is hard, since the logbook usually has a lot of unfilled spaces.
So I decided to throw some technology at the problem and hope to solve it thereby.

Design Goals

How the device is supposed to work

Every user gets an RFID token. When starting the trip, he puts it on the device. The device automatically counts the travelled distance and saves this data. When doing the billing, this data can be used to split the bills in a straightforward manner.

My current solution (Hardware)

As it can be seen in the picture, this car-sharing system consists of multiple modules:

  1. MCU 
  2. GPS - for tracking the travelled distance
  3. RFID - for identifying the user
  4. µSD - for saving the data permanently
  5. UI - a simple LED to show the device status
  6. Power Supply

A detailed schematic is available on my Github.

My current solution (Software)

The software running on the MCU has to do the following things:

To achieve this, a lot of very good open source libraries are used - thanks to everybody who contributes to open-source projects - you're awesome!

All code is available on my Github, so feel free to look around, use and improve it to your liking.

Data logging and privacy

At the end of every trip a log entry is generated and saved to the sd card. It looks like this:

ID,Distance,Date,Time,lat,lng
  1. ID - the RFID token id of the user
  2. Distance - travelled distance of this trip in km
  3. Date - date of end of trip
  4. Time - time of end of trip
  5. lat - latitude of last position
  6. lng - longitude of last position

ID and distance are obviously required. Date and time are not strictly necessary but since the car's usage is coordinated via a messenger group, this rises little privacy issues. The last know position is of course a very private thing. Unfortunately, the GPS module sometimes takes several minutes to get a new fix. Distances travelled during this time would be lost. That's why the last position is saved and used as a first starting point for the calculation at the beginning of the next trip.

All users know of this issue and are fine with saving this data. However, if changing the GPS module fixes this issue, removing this data from the logs and the calculations is straightforward.

Data analysis

At the moment a very easy python script is available in the project repo. It uses the pandas module and calculates the summarized travel distance of every user. This easy and functional, yet not very sophisticated approach leads me to the next point:

Improvements and TODOs

Regarding the data analysis, removing the SD card and manually running the data log through a python script seems odd if the ESP32 used as the main MCU features wifi and Bluetooth functionality. So in one of the next steps, it would be nice to use the ESP to do the calculations and show the users statistics on request via a slick web interface.

Regarding the hardware, a PCB is currently in the design stage. It allows the ESP32 to control the power supply of all other devices. This has to be one since the ESP can be sent to deep sleep, consuming very little current, but this doesn't work for the other modules.

When the PCB is done, the case can be designed and built/printed.

Other ideas, learnings and failures

I had several other ideas, for example using the OBD Interface to get the travelled distance. This would have been nice but unfortunately, the trip distance is not available in the standard IDs which can be read by the cheap Bluetooth dongles (Yeah I know - current speed is available and the travel distance is only an integral away). Bespoke devices also have the annoying tendency to drain the battery as well, so this was no option.

My first plan (the perfboard prototype) was to connect the device to a cigarette lighter socket and monitor the voltage. If it drops below 13V it's safe to assume the engine is off and the trip is over. The modern Golf 6 this system shall live in, cuts the power to the socket completely and immediately. To my frustration, a 1F Capacitor on the 3V3 rail failed to provide enough time to detect the power down and successfully write the log on the SD card.

This issue led to connecting the system to a constant 12V fuse as well as monitoring the ignition signal on the socket. This in turn also means that there must be a way to cut power to all modules except for the MCU to reduce current draw while not in use. That is the reason, why I decided to do a proper PCB instead of keeping my hand-wired perfboard prototype despite my early goal of keeping it simple.