Reardar: Show Me The Data.

We picked some of our fastest employees :) to best simulate an approaching car and used a cookie sheet to give us a nice radar-reflective surface. Using the FreqMeasure library for the Teensy, we were quickly able to see frequency data from the module, but there were a few issues.

• The data had intermittent, very high-amplitude noise spikes, even during no-movement-in-the-vicinity times. This was most likely due to the quickly-breadboarded amplifier/comparator circuitry and/or the non-shielded wires running from the radar module to the amplifier.
• During times with movement in the vicinity, there was a generous amount of lower-amplitude, relatively high-frequency noise in the signal. This was probably due in part to the reasons above, but it was also apparent that a human running with a cookie sheet does not make for a constant-speed output.

The most robust solution to these problems is fairly straightforward; reduce potential Electromagnetic Interference (EMI) by using a PCB instead of a bread-boarded circuitry and adding shielding to the signal wires. Additionally, a low-pass filter on the unamplified signal would reduce amplified noise making it’s way into the data. We designed a tunable band-pass filter and sent the PCB out, but, we wanted to see if we could use digital filtering (software) to get a “close-enough” answer.

Unfortunately, the data from the FreqMeasure library isn’t output at a constant rate; it uses a buffer to collect clock-time between interrupts on the input line, and when enough have been captured, it averages them and reports out the average frequency. Digital filters generally require a constant sample rate, so a work-around was constructed. When it’s time for a sample to be acquired, the latest frequency value is used, if one is available. If not, an exponentially-decaying value based on the previous value is reported. This ensures that the output speed returns to zero after a few samples are requested but no new data is available, and prevents the very high-amplitude noise measurements from being reported out. A moving average filter is applied to each reading to smooth the final signal with a minimal temporal shift.

We could see rather clearly the difference in speeds between our two test subjects, and could also discern a fairly clean signal of the test subject entering and being within the radar’s field-of-view (FOV). We could also discern the difference between running directly at the radar and running parallel to the radar, offset about 12 feet away (simulating a car coming up one lane away from the cyclist).

Time to hit the streets.

We decided to take the next step and acquire some nearly-real-world data by heading out the door to the street corner. I held the radar module stationary in my hand pointed at oncoming traffic, as my colleague Tim videoed the traffic and my laptop for post-test analyses.

Outcomes were about what we’d predicted. In general, there was a lot more noise in the signal out on the street than in our office. The median data value was about 560 Hz (7.8 mph) vs. about 5 Hz (~0 mph) in our office, or 100x more noise. You can see in the plots above that during testing in our office, the radar signal was essentially zero except when the test subject was running at it. In the plot below of test data obtained on the street, you’ll see the value rarely dips below 100 Hz, or 1.4 mph. This is due to:

• Traffic. Four lanes of downtown Seattle traffic in the afternoon means many radar-reflectors (cars) are in near-constant motion in and out of the radar’s FOV.
• People. One block away from Pike’s Place Market in July is a fairly people-dense environment, so there’s always a human-moving within a 30-foot radius.

Looking at the data side-by-side with the video, the following conclusions were drawn:

• Finding the time when a car enters the radar’s FOV just by looking at the data seems possible (with a small degree of uncertainty), with some time spent tuning parameters. Filtering the signal, both in analog and digital, would help the signal stand out from the noise. Additionally, finding a narrow-beam antenna would reduce the radar’s FOV, thereby increasing the signal-to-noise ratio (as it wouldn’t be bouncing microwaves off of so many moving targets all at once).

• Discerning when a car is in the lane immediately next to the radar module and when it is one lane away is not as clear-cut as in our human-testing experiments. To be fair, that was more of a stretch-goal. Having reardar tell the cyclist, “Watch out, I think that you’re about to get hit!” would mean that the cyclist might start to put too much trust into the device’s warnings and let their guard down, which could be deadly in the case of a false-negative (reardar failing to recognize a car about to hit the cyclist).
• The range of these cheap Doppler radar modules in an application like this out in the real-world is lower than we’d hoped.

The fastest car captured was travelling at 35.4 mph, according to the radar. Zooming in on that slice of data, you can see that if the device considered any signal above the median value (the red dashed line) as worthy of being reported to the cyclist, then the cyclist would have had about 1.0 second to react before the car passed immediately beside them. This isn’t horrible, but considering that best-case human reaction times are roughly 0.15 seconds to 0.25 seconds (depending on the what you are reacting to), that doesn’t leave a lot of time to process the data, make a decision, and re-position your bike, before the car passes too close to you.

If you want a feel for how fast you can react, see this website for a visual stimuli test. This isn’t vibratory haptic stimuli like we’re planning for reardar, but it should still give you a rough feeling for how much advanced notice you’d want for a car rapidly-approaching your bicycle from behind you.

What's next?

The general consensus is that a bit more time between reardar sensing that something is coming up behind you and that thing passing you is necessary to make it be valuable. To that end, we are researching other inexpensive, low-profile radar antennas with a higher-gain and/or narrower beam to increase the range of the device. With a narrower beam, it may be even more important to keep the source as close to stationary as is possible, so alternative methods to attach the module to the bike are being looked at. Finally, and perhaps most importantly, we’re starting to investigate the Human Machine Interaction of reardar. We hope to prototype a few different alert algorithms (vibratory and auditory) and test them to determine how to best convey speed data in a way that it becomes a sort of “sixth-sense” for cyclists riding in traffic.