Friday, February 22, 2013

Car sensors

My conclusion from the speed bump post was that the built-in accelerometer in the Android phone is probably not enough to detect the obstacle. Alexander Kosenkov commented that maybe the accelerometer vector can be processed in a more sophisticated way but my experience is that the car generates such an amount of vibrations that makes extracting relatively faint signals from the accelerometer rather hard if not impossible.

While I was contemplating on this issue, I got a mail from Edward Pultar, president of Valarm, a start-up based in Los Angeles. These guys created an Android application and associated web services that started as a theft-prevention tool and is being repositioned as a general platform for all sorts of sensor data acquisition and processing. Read their press kit about the exact features of their products.

The most fascinating idea in their product is the use of OBD2 interface to connect to the car's own sensors. OBD2 with a Bluetooth plug is widely used by car fanatics to obtain diagnostic data including speedometer, tachometer, engine temperature, on-board GPS (if the car is equipped with it) and many other sensors. Valarm's idea was to use this wealth of data for use cases other than car diagnostics, e.g. monitoring whether the car is driven recklessly. They do sensor fusion with the car sensors and with the phone's own sensors. For example cars don't normally have accelerometers that can detect excessive vehicle vibration caused by bumpy roads or faulty tires but a smartphone has. The phone is also equipped with a wealth of communication options, large memory and is an application platform. It is therefore an ideal device to aggregate data from different sensors (internal and external) and to send the data to web services.

This may sound like a futuristic research paper but to my utter surprise, even my own car which is well in its teenager years has the OBD2 interface. All I need is a commercially available Bluetooth plug (connection by cable is also possible but is less practical) and the car will talk to my Android phone. This makes Alexander's idea about incorporating the speed profile for the speed bump detection pretty easy to implement.

Tuesday, February 19, 2013

Detecting speed bumps with accelerometer

Somebody came in from the internet some months ago and asked whether speed bumps (also called sleeping policemen) can be detected with an Android phone. You know, speed bumps like this:

I was cautious because there's a lot of traps here. Obviously the detected signal will differ depending on the form factor of the speed bump, the type of the car and even the way the phone is fixed to the car (or the lack of fixing). But I was also curious and as car-related phone applications are very fashionable today, I took the challenge. Meanwhile the guy who brought up the problem disappeared so I feel free to share what I achieved during the last one and half months.

The solution that I produced is far from perfect. First and foremost, I did not make any effort to target other phones than my trusty Nexus S. Phones which have sampling frequency of around 50 Hz in SENSOR_DELAY_FASTEST mode will work fine, significantly different sampling frequencies are not supported. It is more important, however, that I was not able to create a foolproof algorithm for the problem.

Initially I thought that some sort of rotation could be measured when the front of the car is lifted by the speed bump but I was not able to detect this rotation from the sensor signal. The car generates all sorts of vibrations and it is not easy to extract this relatively small rotation from the noisy background. So I went back to the acceleration spike which is generated when the car hits the bump and I used just the acceleration's absolute value as described in this presentation. The trouble is that this spike is pretty reminiscent of a class of other spikes like knocks, etc. For example here is a beautiful double street bump somewhere in Budapest.

One would think that signals like these could be easily detected. Now comes, however, a bumpy road with potholes, also typical in Budapest.

There are no street bumps in the second signal but the potholes generate "knocks" that are hard to distinguish from the "knocks" caused by street bumps.

There is no perfect solution to this problem, at least I could not find any. Eventually I obtained the best result by calculating the cross-correlation between the acceleration signal and a pre-recorded speed bump signal. I re-sampled this representative signal for +/- 10% of its initial frequency and calculated the cross-correlation with all the three variants (initial, +10% frequency, -10% frequency). Then I used a sliding window to calculate the power of the cross-correlation signal. This is the pre-recorded sample I used for cross-correlation:

Cross-correlating then calculating the power in a sliding window yields this signal for the double speed bump (different colors show the power of the 3 variants of the re-sampled signal):

And this is the result of the same calculation for the bumpy road:

Using a limit of about 150, the two signals can be separated and no fake bumps are detected even on the bumpy road.

Click here to download the example program.

There are a lot of problems with this approach. First, speed bumps come in all shapes and sizes and this method can detect speed bumps that are similar to the one used to generate the reference signal. Then there is the problem of the car itself. I did not have the chance to test with a lot of different cars but I bet the different suspension systems will yield drastically different signals in different car types. Anyway, I thought somebody may find this post and this post can start some thinking.