Make your own overtaking sensor!
I have had several queries from people wanting to collect their own data on the proximities of passing vehicles to test out ideas about what might lead to drivers giving more or less space. I therefore decided to make a cheap data recording package that almost anybody could build for themselves and put it out as an open-source project. You're free to use or modify anything you find here under a Creative Commons BY-NC-SA licence.
At the heart of this device is one of the amazing Arduino computers. When connected to an ultrasonic distance sensor and a few other bits, you end up with a customized hardware device that will sit in a box on your bicycle rack and measure, 10 times per second, the space to the side of your bicycle. The data will be written to a comma-separated values (CSV) file on an SD card, which you can later analyse to record how close passing vehicles came. Because the device is pretty 'dumb', in order to make it cheap and simple, you need to indicate whilst riding which data points are good ones. All this means is that, when a car passes you and you want to mark this as a data point to include in your analysis, you briefly press a button on your handlebars and this is noted in the data file.
The computer/sensor box and the handlebar button (click for bigger)
To say a little more about this, the idea is that a small cable will run from the unit to an illuminated button mounted on your handlebars. This button is used to put a mark in the datafile saying "The vehicle that just passed is one that I want to count". When you examine the datafile later, it's just a question of scanning down the "button" column to find moments when you pressed the button. You can then find the smallest distance reading for the vehicle that had just passed and note this as the overtaking proximity for that vehicle.
One of the really interesting challenges I had when designing this device and its software was how to communicate multiple messages and accept multiple commands with only a one-bit input and a one-bit output user interface. The way it works is as follows. When you power up your device, the light on the button will do 5 rapid flashes, two slow flashes then 5 more rapid flashes. If it doesn't do this, there was a problem with either the real-time clock or the SD card and the unit will simply stall, flashing an SOS signal on the button. It won't work until you fix whatever is causing the problem.
The prototype device with its clothes off (click for bigger)
Assuming the boot-up went okay, the unit will go into "ready" mode, indicated by 2 rapid pulses of the light, repeated about once per second. When you are ready to start collecting data, press the button for a moment and you should see six flashes, which indicates a new data file has been successfully created on the SD card. The lamp will then stay on. The steady lamp means data are being recorded to the SD card. The lamp will go off momentarily when you press the button, to indicate your button-press is being noted. When you finish your ride, simply hold down the button for 10 seconds until the double-blink starts again, indicating that the unit is back in "ready" mode. That's all there is to it! The device can now be safely powered down, or a new session of recording can be begun by pressing the button again.
Building your own unit
Let's be honest, this probably isn't going to to be suitable for your very first home electronics project. If you've never done any electronics before in your life, you're probably better finding somebody who has. But I was able to design and build this entire thing with only the knowledge I learnt in GCSE Technology, so frankly it can't be all that demanding. The programming was slightly more advanced, but I've now done all that for you, so all you have to do is download the software provided below to your Arduino
Key parts list
I can't tell you exactly where to buy all these things, but you should be able to find them online easily enough
Things to note
Calibration According to the MaxSonix datasheet, the pulse-width reading from Pin 2 on the distance sensor should give a value which is divided by 58 to get the distance in cm. For some reason, when I tested my circuit I found that all the distance readings were out by a factor of exactly 1.24. So in the code linked above, I've included (somewhere near the bottom) an empirical correction in which the measurements are divided by 1.24. Be sure to check this is working for you and adjust it if necessary, if the measurements are not accurate. There is also a second correction built into the code, defined near the top of the code as CORRECTION. This is used to add or subtract a certain number of centimetres to allow for your sensor protruding or being recessed into its case. In the unit I built, I needed to add 2 cm to all the readings so that an object at, say, 30 cm from the outside of the case gave a reading of 30 cm.