雷达测速这活儿听着挺硬核其实动手做起来比想象中接地气。我前后折腾了大半个月从只知道“雷达测速是警察用的”到能自己搭一套实时监测路上车辆速度的小系统中间踩了不少坑也把原本模糊的原理彻底搞透了。这篇就把整个项目从原理、选型到代码、实测的完整过程复盘一遍如果你也想做一套可以直接照着抄作业。先说这项目能干什么实时检测指定区域内移动目标的径向速度显示在屏幕上可以设定超速阈值并触发声光报警。应用场景挺广比如家门口车道来车提醒、小区限速监测、运动训练里的球速/车速测量甚至做一个简易的交通流量统计点。适合玩单片机的、搞嵌入式开发的、还有对雷达感知感兴趣的爱好者参考。1. 项目定位与整体架构先想清楚“测什么速度”再动手1.1 三种常见雷达测速方案怎么选我在选型前先梳理了一下市面上能搞到的雷达测速方案主要就三条路线多普勒连续波雷达、24GHz微波感应模块、真正带距离-多普勒处理的毫米波雷达TI为代表。三条路线的技术栈和开发成本差异极大。多普勒连续波雷达如HB100是我最终选的主力方案。10.525GHz的微波头成本和功耗都很低大概二十来块钱输出信号是和目标径向速度成正比的低频多普勒信号。它能测速度但测不了距离无法分辨目标具体在哪。这足够满足测速需求。24GHz微波感应模块如RCWL-0516、HW-MS03常用于人体存在感应和智能灯具。这类模块分两种一种是纯存在感应的内部做了信号处理直接输出高低电平这种压根拿不到原始多普勒信号不适合做测速另一种有I/Q中频输出比如HW-MS03能拿到原始信号并还原速度方向可以做测速但信号幅度往往很微弱且对电源噪声极其敏感调试起来比较费心。TI毫米波雷达IWR1443/AWR1642等是真正能“测距测速多目标”的方案。FMCW体制通过线性调频连续波一发多收的阵列可以同时得到目标的距离、速度和角度信息。TI提供了完整的mmWave SDK和可视化工具上手路径清晰但硬件成本上千而且需要理解距离FFT和多普勒FFT等信号处理基础。对于只想测个速度的项目来说属于杀鸡用牛刀但如果你想往自动驾驶感知方向深入这套方案很有学习价值。我最后采用“HB100多普勒雷达头 ESP32 信号调理电路”的组合。模块成本不超过50元采样和处理能力足够最重要的是多普勒原理简单直观方便把每个环节讲明白。1.2 系统级架构与信号流向设计整个系统的信号流是这样的雷达头发射微波并接收目标反射回波混频后输出一个中频信号。这个中频信号的频率就是“多普勒频移”它和目标的径向速度成正比。信号经过运放放大、滤波、整形之后进入ESP32的ADC采样然后在程序里做FFT算出频谱峰值对应的频率再换算成速度最后推送到OLED屏幕显示、蜂鸣器报警。搭建架构时最需要注意的一个点信号链路是层层递进的前一级处理不好后级再怎么优化也没用。雷达头原始输出幅度只有毫伏级别甚至更低如果直接用ADC采样几乎什么都看不到信号放大器如果带宽不够又会导致高频目标信号直接丢失。所以每一级都得单独测试过再往下走别一口气全焊完再调出了故障根本没法定位。我给这套系统定的性能目标并不激进能检测1km/h到120km/h的径向速度响应时间不超过200ms探测距离在5到10米范围HB100在合理增益下对车辆这个体量的目标能到这个水平。对于车辆测速场景来说这已经够用了。2. 从原理到公式多普勒频移和TI FMCW雷达的测速逻辑2.1 多普勒效应速度藏在频率差里雷达测速的根本是物理学里高频声波和电磁波都适用的多普勒效应。雷达头发射一个固定频率的微波信号比如HB100发射10.525GHz。微波遇到运动目标时被反射回来如果目标在靠近雷达运动反射波的频率会升高如果目标在远离频率会降低。这个频率变化量就叫多普勒频移。设发射频率为f0目标径向速度为v光速为c多普勒频移Fd满足Fd 2 × v × f0 / c注意这里的v是径向速度也就是目标相对雷达天线的速度在雷达视线方向上的分量。如果车辆从雷达正前方斜着经过实测的多普勒频率会小于其真实车速对应的频率因为斜向运动时径向速度打了折扣。这点在安装测速雷达时非常关键雷达要尽量正对车辆行驶方向角度偏差越大测出来的速度越偏低。HB100的发射频率是10.525GHz代进去可以简化换算关系。光速取3×10^8 m/s那么Fd 2 × v × 10.525×10^9 / (3×10^8) 70.17 × v这里的Fd单位是Hzv单位是m/s。换算成常用的km/h得到Fd(Hz) ≈ 19.49 × V(km/h)也就是说一个速度100km/h的车辆产生的多普勒频移大约是1949Hz。反过来想算速度就用检测到的频率除以19.49。2.2 如果换TI方案FMCW雷达是怎么测速的既然我认真研究过TI的mmWave雷达也把原理捋明白了这里分享一下。TI的毫米波雷达IWR1443、AWR1642用的是FMCW体制发射频率随时间线性变化也就是“调频连续波”。发射信号频率从F0开始随时间线性爬到F0BW带宽这个周期叫一个chirp。回波信号相对于发射信号会延迟一个时间τ2R/c其中R是目标距离。把这个延迟信号和当前发射信号混频得到的差频拍频f_b S × τ其中S是频率爬升斜率。这个拍频包含了距离信息。如果要测速度就连续发射多个chirp构成一个“帧”对同一距离门上的相位变化做FFT也就是多普勒FFT相位随chirp的变化率就对应多普勒频率。由于FMCW雷达同时能测距离和速度它能实现真正的多目标识别距离-多普勒图上的每个峰都是一个目标。TI的SDK已经把这些做成了现成的库函数调一下参数就能拿到目标列表开发体验比纯自己搭信号链轻松得多。但代价是需要理解距离分辨率c/2B、速度分辨率λ/2Tf这些设计参数以及如何处理杂波和静态目标滤除。如果只是想做个简单的测速监测器多普勒雷达的性价比最高如果你做的是需要区分多个车道、同时测距测速的交通监测节点那FMCW方案值得认真研究。2.3 关键指标计算我的速度换算系数从哪来为了让后面的代码能直接用我把换算关系算得明明白白。HB100的工作频率f010.525GHz代入公式Fd 2 × v / λ 2 × v × f0 / cλ c/f0 ≈ 3×10^8 / 10.525×10^9 ≈ 0.02849m那么v(m/s) Fd × λ/2 Fd × 0.014245转成km/hv(km/h) Fd × 0.014245 × 3.6 Fd × 0.05128这个系数留到代码里用。实际调试时这个计算值和真实车速差多少我在第五章的实测环节做了对比结果还算满意。需要注意的是这个系数在理论上是精确的实际误差主要来自安装角度的cos分量和仪器本身测速的误差。如果雷达和车辆行驶方向存在夹角θ真实车速 v_径向 / cosθ。10度夹角会引入1.5%的偏低误差30度夹角则会偏低13.4%安装时要尽量对准。3. 硬件搭建从雷达头到ESP32的信号调理链路3.1 元件清单和连接逻辑我用的核心元件和物料清单如下器件型号/规格作用雷达头HB10010.525GHz发射微波并输出多普勒中频信号微控制器ESP32 DevKitCADC采样、FFT运算、显示与报警控制运放LM358/LM324两级放大把毫伏级信号抬到ADC可分辨范围显示器SSD1306 OLED128×64I2C实时显示速度和报警状态报警有源蜂鸣器 红色LED超速提示电源5V 2A USB供电加100uF0.1uF去耦电容供电稳定降低干扰电阻电容若干配合运放搭建放大滤波网络信号调理HB100一共四个引脚GND、VCC5V、IF中频信号输出、另外一个IF是地有些模块称AGND。IF输出的是模拟信号必须接到运放不能直接接MCU GPIO。3.2 信号调理电路的设计心得别忽略偏置和滤波HB100的输出信号是几十赫兹到几千赫兹的微弱交流信号幅度大约在100uV到几mV的级别取决于目标大小、距离和反射角度。如果直接给ESP32的ADC信号的幅度完全淹没在噪声里128ms的采样窗口里几乎什么都提取不出来。所以必须做放大。我采用的放大结构是两级同相放大第一级放大100倍第二级放大约75倍总增益约7500倍。这个增益量级对普通车辆目标在5-8米范围内合适但现场要根据实际情况调。如果目标太近太强运放会饱和削顶目标太远太弱FFT峰值又不够明显。运放电路里还要注意直流偏置。ESP32的ADC输入范围是0-3.3V而交流信号是双极性的正负都有所以需要用电阻分压把信号中心电平抬到1.65V左右。我用两个10k电阻从3.3V分压得到1.65V接到第二级运放的同相输入端做参考偏置这样交流信号就变成以1.65V为中心的波动ADC才能完整采集。滤波也很关键。HB100的IF输出带外的干扰挺多的尤其是数字电路切换带来的高频毛刺、电源纹波等。我加了一阶RC低通滤波器在第二级之后截止频率设在2kHz左右。2kHz对应大约103km/h足够覆盖测速需求又滤掉了大部分高频干扰。实际测下来这个滤波对FFT结果的干净度提升非常明显。4. 软件实现FFT采样、速度计算和报警逻辑4.1 ADC采样参数怎么定先明确一下需要什么频率分辨率和测量范围。HB100输出的多普勒频率对应车速1km/h时约19.5Hz120km/h时约2339Hz。我要同时兼顾低低速分辨能力和高速上限。采样率用FS4096Hz。根据奈奎斯特定理最大可测频率是2048Hz对应约105km/h。稍微超出105km/h的目标会混叠但作为监测器够用。如果你要测更高速就把采样率提高比如8192Hz最大测速约210km/h。做FFT之前先采集512点对应采样时长为125ms。FFT的频率分辨率是FS/N 4096/512 8Hz对应速度精度约为0.41km/h。125ms的响应时间对车辆测速来说很快人眼还没反应过来数据就更新了。一个细节ESP32的ADC值得做多次采样求平均降低随机噪声。我每次读取ADC后连续采样16次求平均等效于一个简易的低通滤波实测波形变得平滑很多FFT结果也稳定了。4.2 核心代码实现和关键逻辑代码分四大块FFT库、采样、峰值搜索和速度换算、显示和报警。FFT我用的是开源的arduinoFFT库这个库很成熟ESP32跑512点FFT毫无压力。下面是采样加FFT加测速的简化核心代码我用C语言风格的伪代码来写方便说明逻辑#include arduinoFFT.h #define ADC_PIN 34 #define SAMPLE_RATE 4096 #define SAMPLES 512 #define SPEED_COEF 0.05128 // Hz - km/h double real[SAMPLES]; double imag[SAMPLES]; arduinoFFT FFT arduinoFFT(real, imag, SAMPLES, SAMPLE_RATE); void loop() { // 采集512个点每个点做16次平均 for (int i 0; i SAMPLES; i) { uint32_t sum 0; for (int j 0; j 16; j) { sum analogRead(ADC_PIN); } real[i] (double)sum / 16.0; imag[i] 0.0; delayMicroseconds(1000000 / SAMPLE_RATE); } // FFT并求幅值 FFT.Windowing(FFT_WIN_TYP_HAMMING, FFT_FORWARD); FFT.Compute(FFT_REVERSE); // arduinoFFT库的接口实际做的是FFT FFT.ComplexToMagnitude(); // 寻找峰值谱线跳过DC分量 double maxVal 0; int maxIndex 0; for (int i 1; i SAMPLES / 2; i) { if (real[i] maxVal) { maxVal real[i]; maxIndex i; } } // 滤除幅度过低的噪声峰 if (maxVal 300) { displaySpeed(-1); // 无目标 delay(50); return; } // 由谱线索引换算频率 double freq (double)maxIndex * SAMPLE_RATE / SAMPLES; double speedKmh freq * SPEED_COEF; if (speedKmh SPEED_THRESHOLD) { triggerAlarm(speedKmh); } displaySpeed(speedKmh); delay(50); }实现过程中有几个坑值得说。第一直流分量要处理干净。频谱第0根谱线是直流偏置信号本身也在1.65V左右。如果不先减去直流分量或者不跳过第0根谱线FFT后直流分量会特别大压制其他峰的辨识度。我直接在搜索峰值时从i1开始绕开第0根谱线。第二幅值阈值要设置合理。无目标时ADC输出的“静默底噪”FFT幅值通常在几十到一百多之间有目标时峰值往往上千。阈值设300可以滤掉大部分虚警但环境变化后这个值可能要重新校准。比较好的做法是在程序里做个简单的动态底噪估计但作为固定式监测器我直接固定下来也没出过问题。第三不要忘了Hann窗或Hamming窗。矩形窗的频谱泄漏严重弱目标可能被旁边的强峰掩盖。加窗后主瓣变宽但旁瓣压低实测检测成功率明显提升。代价是频率分辨率略有下降但对测速来说完全能接受。5. 实测过程与结果分析把雷达架到路边看数据5.1 安装和初始标定实测地点选在小区出入口的一条直道路边有路灯杆可以固定雷达。我把它安装在距离路面约1.2米高的灯杆上雷达头正对来车方向大致和行车方向平行。供电用移动电源加USB线信号线尽量远离电源线减少工频干扰。开机后先做静置测试在路面没有车辆通过时观察OLED读数并串口打印FFT峰值确认无目标时读数不乱跳。这一步很重要因为如果静置时就乱出数字说明电路噪声没处理好必须先解决再继续。然后我开始人工标定。让一个朋友骑电动车以大约20km/h、30km/h的速度两次通过我记录雷达读数。电动车的仪表盘车速虽然不太准但趋势和量级可以对比。实测20km/h的电动车读数是19.2km/h30km/h读数28.5km/h都在合理误差范围内说明速度换算系数和信号链没问题。5.2 车辆数据记录和分析接下来记录了几组真实车辆的通过数据拿手机上的GPS测速软件做参照虽然GPS低俗时也不太准但作为参考足够了序号雷达读数 (km/h)参照值 (km/h)偏差备注124.626-5.4%小型轿车进入方向235.136-2.5%小型轿车312.813-1.5%电动自行车448.350-3.4%SUV561.263-2.8%中型客车整体上看雷达读数普遍比参照值低2%到5%。这个偏差主要来自安装角度雷达不可能和车辆行驶方向完全平行只要有一点点夹角径向速度就小于实际车速低几个百分点是正常的。如果你需要精确的执法级数据安装时最好用激光测距仪打一下光轴和车道的夹角来做软件补偿。对监测用途来说这个精度完全可以接受。5.3 误触发问题和持续改进测试过程中最突出的问题是有时会在没有车的时候突然跳出一个十几公里的速度值观察下来来源是骑自行车的人和近距离行人。HB100的波束比较宽波束内任何移动目标都会产生多普勒信号。而且目标反射截面积RCS差异很大行人的反射虽然弱但在5-8米距离上依然能被我的高增益电路捕捉到。解决方向有两个。一个是机械方法加装喇叭口或者用金属屏蔽罩限制雷达波束照射范围。但我手头没有现成的波导喇叭而且这样会改变天线方向图需要重新测试比较麻烦。另一个是软件方法如果目标是车辆信号在时间上是连续增强再连续减弱的而行人快速走动产生的多普勒信号更零碎可以在程序里加入一个“目标出现持续时间”的确认逻辑连续超过3个FFT帧约400ms都检测到有效速度才判定为目标否则忽略。我采用软件方案后误报率大幅下降。实测三个小时内单车/行人经过再也没有触发额外的速度显示只有车辆通过时才会稳定显示数据。这给后续迭代留下一个可以继续打磨的方向做多帧能量累计和运动轨迹判定进一步提高目标分类准确度。6. 常见问题与调试建议这些坑我替你踩过了6.1 雷达测速项目常见故障速查表现象可能原因排查方法完全无输出雷达头供电问题或IF接线错误万用表测VCC是否为4.9-5.1V检查IF和AGND是否接反有输出但ADC读不到明显波形信号增益不足或偏置不对示波器测运放输出确认静态电压是否在1.65V附近频谱杂乱无显著单峰电源纹波太多或滤波不足加强电源去耦检查低通滤波截止频率是否过高速度读数明显偏低安装角过大或参照车速不准重新摆正雷达朝向用GPS对比复核静止时偶发速度显示强反射物晃动树枝或电磁干扰检查周边干扰源提高峰值幅度阈值低速目标检测不到采样时间太短或带外滤波太狠降低采样率提升低频分辨率检查高通滤波参数6.2 从项目里学到的三点核心经验第一多普勒雷达测速项目的最大难点不在原理而在把微弱的模拟信号调理到ADC能可靠识别的水平。系统设计的重心应该放在运放选型、滤波参数和供电去耦上这些模拟前端的功夫直接影响最终精度。第二FFT参数没有一个放之四海而皆准的组合。采样率、采样点数、窗口函数和阈值要根据实际场景反复调优。我在护栏边、小区出入口和地下车库都测过三个场景的最优阈值和增益都不完全一样。做产品化迭代的话建议把阈值做成软件可配置的甚至做自适应校准。第三TI的方案虽然贵但确实省了很多模拟前端的麻烦。AWR1642这类雷达把调频、混频、ADC甚至FFT加速都集成好了能直接输出目标列表。我理解TI radar的FMCW原理之后再看多普勒方案两者互洽多普勒是恒频波下的速度近似FMCW是调频波下的距离-速度联合估计。想短时间内快速出原型并摸清原理HB100是不二之选想做多目标、高精度的系统直接切TI的mmWave平台学习曲线虽然陡峭但上限高得多。用这套雷达测速监测器跑了几周最直接的体会是一个看似平时接触不到的技术真正动手做下来并不需要火箭级的知识储备。多普勒公式就一行FFT库一个函数硬件模块几十块钱关键是每一步都踏实验证。如果你也玩这类感知设备我建议从HB100入门把信号链吃透再去碰FMCW就会觉得TI那些SDK里的术语没那么玄乎了。最后再分享一个小技巧调试时一定开着串口把FFT的峰值数据打出来光看OLED上的数字根本不知道系统内部发生了什么串口曲线才是你判断问题最快的工具。