## Friday, April 4, 2014

### simulating vehicle speeding detection algorithm

Last time I proposed an algorithm for detecting speeding vehicles. In summary, the algorithm was to set an actual speed limit 5% over the nominal speed limit, then compare the car's position to a "virtual pace car" going that speed limit, where the pace car would slow to avoid getting behind the car in question. If the driver got 50 meters ahead of this virtual pace car, he'd be fined proportional to how far ahead he got. If he kept pulling away, the fine would keep increasing.

I tried various approaches, but I think the best one is relatively simple. I assume a car starts at rest, then accelerates at 3 m/s2 (0.31g, or 0-60 in 8.94 seconds) to some final speed, then holds that speed. There's a posted speed limit of 20 meters/second (72 kph), implying an enforced speed limit of 21 meters/second (75.6 kph) which the driver reaches in 7.00 seconds, having traveled 73.5 meters.

If the peak speed is no more than 21 mps, the driver is never cited. But if the peak speed is in excess of this, he will eventually be cited. The key question is how quickly this happens, given my 50 meters-ahead-of-pace distance criterion.

Here's a plot of the time taken for the speeding indicator to trigger. For the 22 mps peak speed, only 10% over the nominal speed limit, it takes 53 seconds before the 50 meter threshold is reached. For the highest speeds more of the time is taken by the acceleration phase after the 21 mps threshold is crossed, and the time hits a limit of approximately 8 seconds.

The other statistic of interest is how much distance was covered before the threshold was reached. This is easy to estimate from the time: the "virtual pacer" goes 21 meters each second, so add to that distance the 50 meter threshold and you have the distance covered by the perpetrator. The result isn't exact because of the requirement three points in a row are over the distance threshold, so the final margin may well be more than 50 meters, increasing the net travel distance.

Here's that plot, with distances taken from the simulation, not the estimated calculation:

It's around 1180 meters in the case of the 22 mph speed, decreasing to around 250 meters at the highest speeds.

200 meters is typical for a city block, so the algorithm won't catch a violator in a single block for this 20 mps (72 kph) speed limit. But a more typical urban speed limit is 40 kph or even 30 mph. With the "virtual pacer" going slower, it's possible the 50 meter threshold could be reached in a single block. But more likely is to get caught traveling over a longer distance, for example two blocks connected by a green traffic signal.

Here's an example of a randomized speed schedule, where the driver is averaging 20 mph, equal to the assumed speed limit:

It takes around 20 seconds for the driver to go from the 20 mps speed limit to 25 mps, at which point he triggers the speeding threshold. Then the speed decreases, eventually back below the speedlimit, and the "excess distance" decreases, eventually back below the 50 meter limit.

So the criteria I propose are fairly strict, yet only marginally strict enough to catch someone speeding along a single city block. Yet I stand by the strictness. If you don't want to be fined don't go over the speed limit. When you do could be the time you kill someone.

The one key point here is when the speed limit changes. A way around this is to extend the boundaries of the higher speed limit somewhat, to give drivers a safety margin, relative to where the higher speed limit is marked on the roadway.