Lookup the RPLidar family of devices. Cheap 1D, easy to work with. By 1D I mean that it measures ranges in 360degrees around the plane that it is spinning in.
My mother was in the 2nd (? early...) class of AT&T programmers hired. Nobody knew any programming, so the identified pre-requisites to getting hired were:
1) College degree
2) Typing 60 WPM
She and basically everyone else had been pushed to learn to type in high-school, so they'd have something better than waitressing to fall back on.
Not widely publicized, but the benchmarking code is in the source. At one point I was running it on my specific target machines to get performance estimates in support of porting some large-ish CPU stuff from Matlab into C++.
The max performance was in Eigen-calling Intel MKL, but it was a big plus to not need MKL licenses on every development machine.
The GPS can easily wobble by 50ns back and forth as the constellation changes. That's a lot! And, it is not random on a short time scale.
Folks often think "Oh, +/- 50ns, 20ns RMS, easy to filter...", but that's totally wrong.
The GPS will report -30ns from stable for minutes on end, then slew to +10ns, then -5ns, etc. Any high-precision oscillator (such as for radar) that's being jerked around like that isn't going to be as stable as high performance needs.
Even for just handoff of handsets at 2.2-2.3GHz, having the radio network (aka cell towers) all locked to an oven-controlled oscillator that was aligned-to, but far smoother-than, GPS, made a huge difference.
Now, improvements to GPS/GNSS that track 12 satellites instead of 6, and across multiple constellations, can result in more stable radio-based time. But then you get into urban canyons, and can only see 5 instead of 12, and you're right back into the jumpy situation.
I want this tied to a crude speed estimation algorithm, from a stationary camera.
Even with ALPR retention restrictions, I could trigger a video save and send the police a video of the idiots doing 50mph through the residential neighborhood.