Welcome back. As you may recall, we’ve been digging into how we might use an inexpensive Doppler radar module to help cyclists detect cars approaching from behind. Last time, Josh explained the project’s origin, the radar module itself, and the circuitry necessary to get “microcontroller-ready” data out of the module.
In this post, I’ll give a quick run-down on what we think we can glean from that data, what the data looks like (before and after all of the digital signal processing we had to use to make it useful), and the testing we’ve done thus far.
Data. Data everywhere.
Some of our first thoughts were “what can we do with the data?” We aren’t radar-experts, per say, but enough of us stayed awake through a physics lesson or two :) to answer some of the questions that came up, such as:
- Can we detect how far away the car is? (no, not directly)
- Can we figure out if it is coming at us or going the opposite direction? (not directly with this module, but maybe indirectly?)
- What’s the range? (it varies…so let’s test)
- Can we tell if the car will hit us, or pass by safely one lane away? (not directly, but maybe indirectly?)
We did a quick refresh on the theory of Doppler radar (there is a nice explanatory piece HERE) and then set out to try and quickly answer a few of these questions.
The question that intrigued me (and encapsulates the rest, in a way) was if you could determine if the car would hit you or pass by safely one lane away. If there is a lane between my bike and the car, then I’m not as concerned if it’s coming up quickly; if it’s moving fast AND will pass within a foot of my handlebar, I am concerned. A few key points about Doppler radar will help answer this:
- Only a speed is obtained, not velocity. Velocity is a vector (magnitude and direction) while speed is a scalar (just magnitude). That means that you don’t know whether that object is coming towards you, going away from you, or something in-between. Some radar modules have a quadrature encoder-style output from which you can determine relative direction, but this inexpensive model does not.
- The speed that the radar reports is a relative speed; in other words, the speed of the target (car) minus the speed of the source (cyclist). The radar doesn’t care if the cyclist is moving or standing still; it will report the difference in speed (otherwise known as relative speed) either way.
- The speed reported is dependent on the angle between the paths of the radar source and target. In other words, if a car is approaching the cyclist directly at a constant velocity, the radar-reported speed won’t change as the car gets closer to the cyclist. But, if the car approaches the cyclist offset some distance, the speed will appear to drop off as the angle between two increases (by a factor of the cosine of that angle). The simulation below demonstrates this.
With those points in mind, it seemed that by looking at the radar-reported speed over time, the microcontroller might be able to predict the distance between the car and bike as the car passed using the rate of change of the radar-reported speed. In the simulation, note how the red curve for the second car (which passes very close to the cyclist) doesn’t drop off as gradually as the green curve (a safe distance away) does.
Enough theory. Let's test!
Looking at those relatively smooth, easy-to-discern lines on the plot above reminds me of a favorite quote: “In theory, theory and practice are the same. In practice, they are not.” Knowing that real data would be “messier” than that predicted with theory, we set out to generate some test data from which we could validate the passing distance idea discussed above, test smoothing algorithms, and judge the relative performance and range of the module.