Sunday, March 10, 2013

Data capture application for car speed, accelerometer, compass and gyro fusion experiments

In my previous post I wrote about my enthusiasm of integrating car sensors with the mobile device's own sensors. The first step was to implement a data capture application that saves sensor data into a file. This time I decided to save the gyro, accelerometer and compass sensor data from the phone and the speed as measured by the car's speedometer. The most interesting aspect here is how we obtain the speed data.

There are two levels of interfaces playing role here. OBD2 interface and the protocols accessible over it is the first level offered by the car's on-board electronics. This interface is not trivial to talk to but fortunately all the complexity of OBD2-related protocols is implemented by the super-popular ELM327 microcontroller from ELM Electronics (or its compatible copies). On one side the ELM327 chip talks to the car's ECU using the OBD2 interface. On the other side, it offers a modem-like serial interface. Popular connection option is USB but for our Android client, Bluetooth is a better option. ELM327-compatible adapters are available at a low cost, for example I bought the very basic version below.

ELM327 has a very simple, yet powerful interface. In the first phase the chip is set up by issuing a series of AT commands reminiscent of the Hayes modem commands. The best place for reference is the ELM327 specification. The most important command is the ATS0 command. This instructs the chip to auto-detect the protocol used on the OBD2 interface. Once this auto-detection is successful, the car sensors can be queried by sending the PID code of the sensor in question. For example for the car's speed one sends:


The ELM327 chip then talks to the car's ECU, obtains the sensor data and returns a response like this:


Where "4" is the ID for response, 10D is the PID of the sensor and 0C is the value. Some OBD2 PIDs have complex coding but fortunately for the speed sensor 0C simply means 12 km/h.

Click here to download the example program.

Before you start using this test application, make the Bluetooth pairing of your device with the sensor from the Android Bluetooth settings. Either you can use the real thing (ELM327 interface connected to a real car) or you can use Ryan C. Gordon's great OBDSim application that can run on a Linux box and can simulate a Bluetooth-connected ELM327. In theory, OBDSim can also run on Windows, I tested only on Linux. Setting it up is not trivial but it saves a great deal of time if you develop for the ELM327 interface.

Then you can start the test application. First connect to your ELM327 device from the menu ("Connect a device - secure"). If the connection works properly, you should see a series of AT commands and responses flashing on the screen then the speed appears (e.g. 0 km/h if you do it on a real car). This time you can start the sampling ("Sampling" check box) and the application will save all the sensor information into a file in the SDCARD in CSV format. The name of the file is gyrocarcapture_<date>.csv and its format is very simple. One warning here: sadly the timestamp format used for the speed sensor and the device's own sensor are different: the sensor timestamps are coming from the SensorEvent object and the time stamp for the speed data comes from System.currentTimeMillis(). As device sensor events are very frequent, I use the last device sensor timestamp for the speed sensor too when processing these files. The speed sensor sampling frequency is approximately 1 Hz.

The application can be extended easily to sample other car sensors too. However, in its present form it is good enough to detect if the driver slows down in front of a speed bump (accelerometer-car speed sensor fusion).

Or to figure whether the driver takes the bend too quickly (gyroscope-car speed sensor fusion).

Friday, March 1, 2013

Call for papers for Droidcon Tunis 2013

Last year I had a presentation at Droidcon Tunis. The conference was inspiring with a clever and enthusiastic audience and the presentation became a success with over 16000 views since the end of the conference. Not bad for a sensor processing topic with some scary math in it. Plus my name became a landmark in Tunis which was pretty much a new sensation for me.

Call for papers for Droidcon Tunis 2013 is now open but sadly, I can't submit anything. My presentation material is not ready because some topics I could speak about are not public, others are not mature enough. But you out there, you should consider submitting papers to this conference. Last year's conference was fun - also my first time in Africa. I am sure that this year will be just better.