LemonAid

Hardware Setup:

Connect the PEAK CAN-USB cable to the OBD II port of the car and the other end to the USB hub connected to the BeagleBone. 

Also connect the wifi dongle to the USB hub.

Quick Start:

If you already have your beaglebone setup, you only need to run the following commands to run the programs:

sudo ./cansniffer/canmonitor -f=/dev/pcanXX > /dev/null 2>&1 & (depends on the pcan device name)

node server.js (depends on the file name)

SD Card Setup:

If you have a blank or unused SD card that are ready for LemonAid project, simply insert the SD card into your laptop(Ubuntu required), and then clone our project by running this command:git clone git://github.com/ESE519/LemonAid, and finally runcd ./LemonAid && sh ./tools/install_lemonaid.sh. And the "install_lemonaid.sh" will do everything for you.

Beaglebone Setup:

After running the install-lemonaid script, you will have an customized Ubuntu with our pcandriver on board. After plugging the SD card into your Beaglebone, power up your Beaglebone with a separate power cord, and connect the board to your laptop through USB cable. And runscreen /dev/ttyUSBX 115200 If you see no output, just type Enter, it will take 1 to 5 minutes to have the board bootup the operating system. When you see the login prompt, login with username: "ubuntu", password: "temppwd". Then you will be logged in onto the "home" path, and then runsh ./setup_lemonaid.shto do the final setup.

Run Program:

After setup of everything, run the following commands to start the standard program:sudo ./cansniffer/canmonitor -f=/dev/pcanXX > /dev/null 2>&1 &(depends on the pcan device name) node server.js(depends on the file name)

Project Experience

One of the procedures that must be taken after car accident is to describe in detail what happened during the accident. This information is one of the most wanted data from both police officer, because of the police accident report, and the auto insurance companies, because of the claims that depends on the sequence of events during the accidents.

The information is asked to be filled out in a section of a form where there are just several blank lines to be filled out by the driver or police officer depending on the kinds of the form. The important point is that the information is asked in such way where there could be much personal bias, or even incorrect memory involved.

Not only LemonAid can provide help in describing accurate accident scene description, the information of the car attributes before, during, and after the car accident opens new perspective of looking at the accident scene. Detailed car attributes provided by LemonAid and the Analysis Platform that allows the user of LemonAid to see the relations between the attributes are very useful when checking to see if the accident description is indeed correct.

The iPad application provides the visual interface to view live trip data and analyze all the stored trips. The app also serves as a backup database and locally stores all the trip information retrieved from the server. The application is divided into three main components:

Virtual Dashboard - displays live values on a speedometer and also shows certain warning lights, doors and gear positions

Trip Observer - shows all the key parameters in live mode, live oscilloscope for important parameters and trip route on a map

Analysis Platform - helps investigate accidents and improve driving patterns by showing data accumulated from all trips on graphs along with key events

To implement a live virtual dashboard, we need to send data over to the iPad application with very less latency. 

Attempt 1:

We hosted an HTTP server on the BeagleBone to send data to the application. The app polled for 'new data' every 300ms. Also, every time the connection is establish the http header takes 200ms. This approach is not useful because of this overhead and more importantly the battery gets drained very soon due to constant polling. 

To solve this problem, we needed some mechanism to keep the connection open and asynchronously send data when available. 

Node JS and Socket IO to the rescue:

The main purpose of our system is to provide a platform to analyze all the trip made by the car. Also, we are scaling the system to work for more than one car. Therefore, we need to store all the key events that can be used to analyze possible car crash or trips made by the car in general. 

To backup all the data, we store all values in a MySQL database on the BeagleBone and replicate the database on the iPad application as well. Key parameters stored are the following:

Car ID -  ID of the car

Trip ID - Trip counter for a particular car

Engine status - engine ON / OFF

Speed - speed of the vehicle

Rpm - rpm of the vehicle

Throttle position - position of throttle in %

Steering angle - Angle of steering wheel to detect turns

Gear position - postion of gear 

Light - status of head lamps

Door - status of doors

Turn light indicator - turn light and parking light indicator

Brake position - brake pedal detection

Fuel level indicator - level of fuel tank

Engine temperature - temperature of engine

Trip co-ordinates - latitude and longitude of trip path

LemonAid consists of two main components:

Hardware (BeagleBone connected to the car)

iPad Application (which also has the analysis platform)

As shown in the figure above, we loaded Ubuntu on BeagleBone and set up a MySQL database to store all the important information retrieved from the car. To get the data out of the car, we used a program written in C++ to continuously monitor the CAN bus through the PEAK CAN-USB cable connected to the OBD II port of the car and the BeagleBone. 

The retrieval of new data from the CAN bus is asynchronous. So we used a node JS server with socket IO to communicated seamlessly with the iPad Application. The node server also ran on the BeagleBone and transmitted newly formed JSON objects to the iPad app via the wifi-dongle connected to the BeagleBone in host mode.

After switching from ELM cable to the PEAK CAN-USB cable, we installed necessary drivers an ran a sample monitor test to observe all CAN IDs. On the screen, we saw various values updating and it goes on forever!

After reading more about CAN, we realized that the lines we saw on screen had a specific CAN id followed by 8 bytes of data for that particular id. So far so good, but what does all that mean? No idea! There are hundreds of CAN ids and all seem to keep changing in some random manner - something like those in the movie Matrix.

Example: 

010 8 00 00 00 00 ff 34 00 03

First 3 digits denote the CAN id, the number 8 means there are 8 bytes for that particular CAN id, and the following numbers are the values of those 8 bytes. Now if we open a door, one bit from these 8 bytes from hundreds of CAN ids will change! Whoa - right?

OBD-II PIDs (On-board diagnostics Parameter IDs) are codes used to request data from a vehicle, used as a diagnostic tool. (wiki: http://en.wikipedia.org/wiki/OBD-II_PIDs). 

There are ten modes of operation but the mode we are currently interested is Mode 01 - Show Current Data. Using this mode, we can send a query to the CAN bus and the bus will respond with appropriate response. We can parse the response packet and extract required data. In the query, the mode has to be specified along with a parameter ID. There are hundreds of parameters and all are not supported by every car manufacturer. On top of this, each car manufacturer has a secret mode to pass critical parameters. 

To get these values, we connected the OBD cable to a linux machine and recorded the port it is connected to. Once we had the port, we wrote a Python script to open a serial connection to that port. To send a query to get current speed, use serial.write('01 0D'). Here, 01 is Mode 01 and the parameter ID for vehicle speed is 0D. The list of all parameter IDs is given in the wiki link above. After sending the query, the CAN bus will respond by filling the buffer. To read the response, use serial.read(). The output will contain: 41 0D 00. Here, 41 means that this is in response to Mode 01. In response, 40 is always added to the mode. 0D is the parameter ID we requested and 00 is the speed of the vehicle as the car was not in motion. 

Now that we have the value, we put this logic in an infinite loop and the result was continuous speed of the vehicle. So far, it is pretty straight-forward. 

BIG Problem 1:

As we were getting more parameter values out of the CAN bus, we realized that the system was getting very slow. The reason for latency was that the program had to explicitly request data and the CAN bus would responds accordingly. Each request took about 200ms! So, if we needed 10 parameter values, a particular values would only be updated after 2 seconds!!! That is too slow as we could miss a critical event.

BIG Problem 2:

There are no OBD PIDs for body and chassis of the car. So we do not get any data for doors, gear position, lights, etc. Without these parameters, our analysis does not show the clear scenario in case of an accident. 

Solution:

Once we had a basic idea of what we were supposed to do, the first thing that needed to be addressed is how do we actually get data out of the car. We have a CAN - USB cable (PEAK systems) and a OBD - USB cable with an ELM chip.

After reading various articles and discussing the project with Professor and the TAs, we now know that all automobiles have an OBD (On-Board Diagnostics) port. This port is located somewhere underneath the steering wheel. Our goal is to try and extract meaningful data using this port. Once we get the data, we store it in a database. An application on a tablet will interact with this database to show live values of key parameters (speed, rpm, etc.) and also store these values for analysis. So the general architecture of the system is as follows:

Server: 

Reads values of the OBD II port in the car and stores it in a database

Alerts the application about the new data

Client: