PLFM_RADAR是我维护了大半年的一个毫米波雷达数据处理与可视化平台，名字取Platform和Radar拼在一起，直译就是“雷达平台”。做这个项目的起因特别简单：我手头有一块毫米波雷达模块，它能通过网口源源不断把原始点云和中间结果丢出来，但厂商自带的上位机只能看个大概，我想把数据接进自己的算法、批量录数据、调参数，几乎没法用。PLFM_RADAR就是把这段“最后一公里”打通——雷达数据进来，完成解码、信号处理、目标检测、实时显示，最后把干净的目标列表吐给下游应用。

这套东西适合三类人来参考：正在做雷达应用开发但受困于闭源上位机的工程师，想在PC端快速看RD图、调CFAR阈值的研究人员，以及刚接触毫米波雷达、想搞清楚一帧数据从网口到屏幕到底经历了什么的同学。下面我按从设计到落地的顺序，把这个平台的思路、核心算法、实操过程和一些真正踩过的坑完整写出来。

1. 项目概述：PLFM_RADAR在解决什么问题

1.1 从“裸数据”到“目标列表”：雷达调试的最后一公里

雷达开发的链路其实很长。天线收到回波之后，经过混频、滤波、ADC采样，得到的是IF信号，这是最原始的阶段；接着要做距离FFT、多普勒FFT，得到Range-Doppler图；再做CFAR检测，从噪声背景里挑出真正的目标；然后通过多天线相位差估计角度，形成点云；最后把点云关联成航迹，输出给应用层。这个链路里，厂商一般会提供一个上位机软件，能显示点云和简单的目标信息，但问题是：它不开放数据接口、不能改算法的任何参数、也不方便录原始数据做离线分析。

我当时的需求很现实。雷达已经装在一个测试场景里了，我需要实时看到每一帧的点云长什么样，需要把数据落盘成文件，方便第二天离线调算法，更需要把检测结果喂给另一个行为识别模块做联动。厂商上位机一条都满足不了。市面上也有几款开源的雷达处理工具，但要么只适配特定硬件，要么界面太简陋，要么对实时流支持很差。与其迁就，不如自己写一个。PLFM_RADAR就这么立项了，目标很明确：接收雷达的网络数据流，在PC上实时显示RD图和点云，支持录放数据，能独立调CFAR、角度估计、跟踪这几个核心环节的参数。

1.2 PLFM_RADAR的能力边界：能做什么，不做什么

先说说平台覆盖的范围。PLFM_RADAR从L1层开始接数据，也就是雷达已经完成ADC采样和基础FFT之后输出的频域数据或点云数据。我自己在项目里把链路分成四段：

• L0：硬件回波采集，这是雷达模组自己的事，平台不碰。
• L1：数据解码与预处理，把UDP包里的字节流还原成有用的矩阵或点云结构。
• L2：目标检测，主要是CFAR和聚类，产出点云。
• L3：目标跟踪，用卡尔曼滤波把点云关联成稳定航迹。

平台的能力集中在L1到L3，以及配套的可视化、录制回放、参数调优界面。它不做波形设计，不控制雷达发射，也不替代硬件驱动，因为在大多数实际项目里，雷达模组本身已经有固定的工作模式，你拿到的是它吐出来的数据流，真正的价值在于怎么把这些数据变成可信的、实时的、可编程的目标信息。

平台有两种接收模式。第一种是点云模式，雷达SDK已经把检测做完，把目标位置、速度、信噪比打包发出来，平台负责解码、显示、录数据和做上层跟踪。第二种是原始数据模式，雷达把Range-Doppler中间结果或原始ADC数据传上来，平台自己跑FFT和CFAR，这种模式下你可以亲手调每一个检测参数，适合做算法研究和恶劣场景下的性能优化。后面我会重点讲第二种模式的处理流程，因为这正是这个平台最有价值的部分。

2. 系统总体设计与技术选型：为什么是Python + PyQtGraph

2.1 数据链路总览：回波、点云、航迹是怎么流到界面上的

整个系统的数据流是一条单向管道，我尽量让每一层只管一件事。雷达模块通过千兆网口发送UDP数据帧，PC端有一个常驻的接收线程负责收包和解析。解析出来的帧进入一个有界队列，工作线程从队列里取帧，做信号处理和检测，把RD图和点云结果分别发到两个渲染通道。界面主线程只负责绘图，不参与计算。

我画过很多版设计图，最后沉淀下来的核心思路是：线程往下拆，数据往上抛。接收线程永不阻塞，工作线程不碰网络，渲染线程不碰计算。这条链路看上简单，但第一次实现时我踩了不少坑，比如直接在接收线程里做FFT，结果一帧没处理完，后面连续丢了几百个包；又比如在UI线程里跑CFAR，界面直接卡成PPT。后来强制规定了每个线程的职责边界，问题才消失。

具体来说，数据流是这样的：

• 接收线程：绑定网卡和端口，recvfrom收原始字节包，拆帧后放入队列。
• 处理线程：从队列取帧，做距离维FFT、多普勒维FFT、CFAR、角度估计，生成点云。
• 渲染通道A：RD图热力图，直接交给PyQtGraph的ImageItem刷新。
• 渲染通道B：点云散点图和目标航迹，用ScatterPlotItem快速绘制。
• 录制模块：按时间戳把原始帧落盘成二进制文件，供离线回放和算法调试。

2.2 技术栈选择：为什么不用C++和Matlab

选型的时候我认真对比过几个方案。C++加Qt性能肯定最好，但这意味着每个算法改完都要重新编译，调试效率太低，而且我需要经常跟Python生态里的数据分析和机器学习库配合，C++包一圈SO库太折腾。Matlab信号处理工具箱确实好用，但实时刷图能力太弱，处理UDP流也不是强项，更别说要部署到目标机器上还得买授权。

最后选了Python加PyQtGraph。PyQtGraph底层用了OpenGL和numpy的快速操作，画热力图和散点图的速度足够快，实测在1080p窗口下刷新30帧没有问题。numpy负责FFT和矩阵运算，scipy的信号处理函数做窗函数、滤波也顺手。整套代码跑在一台普通的i5工控机上，CPU占用控制在50%以内，这个表现已经能满足大多数实时应用场景。

有人会担心Python的GIL影响多线程效率。我的做法是让每个线程自己持有numpy对象，线程之间只传递队列和缓冲区引用，不做全局共享变量。numpy在大部分运算时会释放GIL，所以实际多线程效果并没有想象中那么差。只要不把计算逻辑写进Qt的信号槽里，性能就不是瓶颈。

2.3 硬件接入与数据格式：拿到雷达的什么数据

我用的雷达模组是某厂商基于TI方案做的毫米波雷达评估板，77GHz频段，发射4个chirp序列，接收天线有4路，通过LVDS接口接到一块采集板上，采集板再通过千兆网口用UDP把数据传出来。雷达端通过串口CLI配置chirp参数，本地上位机负责启动采集和配置IP。

通信协议上，雷达厂家定义了一套帧格式：每帧起始是同步头，然后是帧号、时间戳、目标数量，接着是每个目标的距离、角度、速度、信噪比，尾部是CRC校验。我拿到协议文档后，第一步就是做帧解析和CRC校验，确保数据完整性。点云模式下，UDP包不大，一帧也就几百个字节；原始数据模式下，一帧可能包含128个chirp、每chirp采样点256个，打包成字节流后有几十KB，需要按序重组。

有一点特别容易踩坑：不同厂家的数据字节序不一定一致，有的用大端，有的用小端，有的头字段和负载字段端序还不一样。解析前一定要先确认好，否则你会看到距离值忽大忽小、速度正负乱跳，到那时再排查浪费的时间可不少。我在项目里专门写了一个字段配置JSON，把偏移量、字节序、缩放系数全部抽离出来，换一个雷达型号时只改配置文件，不怕污染逻辑代码。

3. 核心算法拆解：距离、多普勒、CFAR和角度估计

3.1 距离FFT和多普勒FFT：一张Range-Doppler图的诞生

雷达用的是FMCW体制，发射信号频率随时间线性上升，回波信号和本振信号混频后得到一个差频信号，差频大小直接和目标距离成正比。设chirp扫频带宽为B，周期为Tc，那么调频斜率S等于B除以Tc，回波延时tau等于2R除以光速c，差频f_IF就等于S乘以tau。距离R就可以通过差频反推出来，关系式是R等于f_IF乘c再除以2S。

距离分辨率取决于扫频带宽，delta_R等于c除以2B。举个例子，带宽设为240MHz，距离分辨率大约0.625米；如果雷达带宽能做到1GHz，距离分辨率就能到0.15米。这也是为什么高分辨率雷达越来越往宽带方向走。

但单靠一个chirp的差频只能得到目标距离，测速度要靠多个chirp之间的相位差。同一距离单元上，目标径向移动会让相邻chirp产生一个相位增量，这个相位增量对应多普勒频率。所以标准的处理流程是两步FFT：先对每个chirp的采样点做距离维FFT，得到一个距离频谱；再对同一距离bin上跨chirp的序列做速度维FFT，就得到距离-多普勒二维图。

实现时我用numpy的fft接口，一次性对二维数组做操作。假设一帧数据是(N_chirp, N_samples)的复数矩阵，先沿着样品轴做距离FFT，再转置后沿chirp轴做速度FFT，最后取对数幅度送到显示。这里有个细节：做FFT之前要给数据加窗，否则距离维会出现明显的频谱泄漏。我默认加汉明窗，主瓣稍宽但旁瓣抑制好，适合检测场景。如果追求更高分辨率，可以用切比雪夫窗，需要现场权衡。

3.2 CA-CFAR检测：目标阈值是怎么定的

RD图上有目标也有噪声，直接用固定阈值会把近处强目标旁边的微弱目标丢掉，也会把远处噪声误判成目标。CFAR（恒虚警率检测）的好处是每个检测单元的阈值都由周围噪声水平动态决定，背景噪底抬升时阈值跟着抬，背景安静时阈值跟着降。

我实现的是CA-CFAR，也就是单元平均CFAR。检测单元左右各取几个保护单元和训练单元，保护单元紧挨着检测单元，目的是防止目标本身能量溢出污染噪声估计；训练单元再往外扩展，用于计算噪声平均值。判定条件很简单，检测单元功率超过噪声均值乘以阈值因子alpha，就认为这里有目标。

参数上，距离维和速度维需要单独配。我常用的起点是距离维训练单元8个、保护单元4个，速度维训练单元12个、保护单元6个。alpha值很关键，工程上一般落在0.8到1.5之间。alpha太大，弱目标被滤掉，漏检率上升；alpha太小，杂波和噪声尖峰大量通过，虚警率飙升，点云图上全是雪花。我自己的调法是：先固定在RD图上两个已知目标，把alpha从1.5往下降，看到目标稳定出现在点云里就停，然后再看有没有明显虚警，有就往上加0.1，反复几次就能找到当前场景的合适值。

CFAR有个容易被忽略的坑：它假设噪声均匀分布，但实际场景里近距地面的强反射会让某个区域噪底整体抬高，导致此处的弱目标被压制。后来我在CFAR前加了一个距离维的高通滤波，把地面静止杂波的拖尾滤掉一部分，弱目标提取效果明显改善。

3.3 角度估计、点云生成与目标跟踪

RD图和CFAR给了我们距离和速度，但雷达还要告诉你在哪个方位。这就要用到多天线。不同天线收到同一目标的回波存在波程差，反映到相位上就是相位差。通过比较天线间的相位差，就能估算目标角度。工程上最常用的是角度FFT，在虚拟阵列维度上再做一次FFT，峰值位置对应角度。

角度分辨率取决于天线孔径和波长，虚拟孔径越长分辨率越高。我用的是4发4收MIMO，等效虚拟阵元16个，做完角度FFT后方位分辨率大概能到14度左右，用于检测行人、车辆这种尺度目标是够用的。实际输出点云时，每个点包含距离、方位角、俯仰角、径向速度、信噪比五个字段。

点云之后还有一步是目标跟踪。单帧CFAR可能检测到噪声点，也可能把目标拆成多点，直接用单帧点云做应用判断会抖得很厉害。我写了一个轻量级的最近邻关联加卡尔曼滤波跟踪器，状态向量取距离、距离变化率、角度、角度变化率，预测模型用匀速模型。每帧点云先跟已有航迹做最近邻匹配，匹配上的点更新航迹，没匹配上的点开新航迹；航迹连续多帧没有关联就删除。这样输出到应用层的目标列表就稳定多了，帧与帧之间的位置跳变明显变小。卡尔曼滤波里我特别在意过程噪声和量测噪声两个矩阵的配比，过程噪声太大航迹会跟丢，量测噪声太大位置更新会滞后，实际调试时我都是录制一段数据，离线和实时两条路同时跑，对着曲线调协方差。

4. 实操记录：把PLFM_RADAR完整跑起来

4.1 环境准备与项目骨架

先说运行环境。我的开发机是Ubuntu 20.04，Python版本3.8，主要依赖就四个：numpy、scipy、PyQt5、pyqtgraph。安装命令很简单，用pip一次性装上即可。Windows下也能跑，但要注意PyQtGraph在高DPI缩放下偶尔会有显示小问题，需要设置Qt的AA_EnableHighDpiScaling属性。

项目骨架我按功能切分目录，避免一个文件堆两千行：

• plfm_radar/：主包
  • receive/：UDP接收与帧解析
  • process/：信号处理与检测算法
  • track/：目标跟踪
  • ui/：界面与绘图组件
  • record/：数据落盘与回放
• tools/：配置文件、脚本

我强烈建议把信号处理和UI彻底分开。早期我的UI类里直接写了FFT和CFAR函数，代码耦合严重，后来一改界面就动算法，一调算法又怕碰坏界面。重构成独立模块之后，信号处理部分可以直接跑单元测试，不依赖任何UI环境。

4.2 UDP接收与雷达数据解码

雷达模组通过网口把数据发到PC，PC端必须把IP和端口配好。我手头雷达的默认配置是发到PC的IP 192.168.1.100，端口4098，雷达自身是192.168.1.102。在Ubuntu上要用netplan或ifconfig把网卡配成静态IP，Windows下就是网卡适配器设置里改IPv4。如果发现收不到包，先ping一下雷达IP，能通再查端口。

接收线程的核心代码很短，但有几个关键细节。socket缓冲区必须调大，我之前用默认缓冲区，雷达以100Hz帧率发送时，稍微一卡就丢包。所以初始化的第一件事就是设置SO_RCVBUF，我设为4MB，实测丢包率从偶尔抽风降到几乎为零。

import socket import numpy as np def create_receiver(ip, port): s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.bind((ip, port)) # 关键是调大缓冲区，默认值太小，高帧率下必丢包 s.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 4 * 1024 * 1024) s.setblocking(False) return s

帧解析这步最考验耐心。雷达帧通常有固定同步头，我用0xAA 0x55之类的模式做帧头校验。读帧头时先校验同步头，再读数据长度字段，如果长度和协议不符，就丢弃这帧并记录错误计数。解析目标点时注意字段缩放，协议里经常用固定整数表示浮点数，比如距离字段实际值是原始整数乘以0.01米，角度是乘以0.1度，忘了缩放的话，界面上所有数字都会差一个数量级。

def parse_frame(data): # 自定义帧结构：同步头2字节 + 帧号4字节 + 目标数2字节 + 目标数据区 + CRC if data[0] != 0xAA or data[1] != 0x55: return None frame_id = int.from_bytes(data[2:6], byteorder='big') obj_num = int.from_bytes(data[6:8], byteorder='big') objs = [] offset = 8 for _ in range(obj_num): # 每个目标：距离2字节 + 角度2字节 + 速度2字节 + 信噪比1字节 r = int.from_bytes(data[offset:offset+2], byteorder='big') * 0.01 a = int.from_bytes(data[offset+2:offset+4], byteorder='big', signed=True) * 0.1 v = int.from_bytes(data[offset+4:offset+6], byteorder='big', signed=True) * 0.05 snr = data[offset+6] offset += 7 objs.append((r, a, v, snr)) return frame_id, objs

因为不同设备协议不同，我把解析函数做成了策略模式，每种协议的解析器实现同一个接口，通过配置文件切换。这样就算换一套雷达，也不用动接收线程的代码。

4.3 多线程流水线与PyQtGraph实时刷新

接收、处理、显示三者的节奏要匹配。我的雷达一帧周期大约10毫秒，也就是100Hz。接收线程只做recv和拆帧，处理线程每一帧要做两次FFT加CFAR，原始数据模式下耗时大概15毫秒左右，加了跟踪之后会更慢一些。如果处理速度跟不上帧率，唯一的办法是丢帧而不是阻塞接收线程，所以我用了一个有界队列，队列满时直接丢弃旧帧，保证显示永远是最新数据。

核心结构是三段式线程协作：

import queue import threading frame_queue = queue.Queue(maxsize=4) point_queue = queue.Queue(maxsize=2) def receiver_worker(sock): while running: data, addr = sock.recvfrom(65535) frame = parse_frame(data) if frame is None: continue if frame_queue.full(): try: frame_queue.get_nowait() except queue.Empty: pass frame_queue.put(frame) def processor_worker(): while running: frame = frame_queue.get() rd_map, points = process_frame(frame) if point_queue.full(): try: point_queue.get_nowait() except queue.Empty: pass point_queue.put((rd_map, points))

UI线程用QTimer按照可显示的帧率取point_queue中的结果。绘图核心是PyQtGraph的ImageItem和ScatterPlotItem，ImageItem更新RD图时用setImage，并在autoLevels=False的情况下手动指定显示亮暗范围，否则每一帧自动调整level会导致图像亮度不断闪烁。点云图直接用ScatterPlotItem的setData，传入点的坐标和速度对应的颜色映射，几百到上千个点的刷新毫秒级完成。

这条流水线跑起来之后，界面上能看到三个视图联动：RD热力图实时滚动、点云俯视图不断累积、目标航迹表持续刷新。录数据功能也挂在这条链路上，收到原始帧后除了送处理线程，还会写一份到二进制文件，文件头记录雷达参数配置，离线回放时只要读文件并按原帧率送入处理线程即可，完全复用在线处理逻辑。

5. 参数配置与调优经验：让雷达和算法对上节奏

5.1 chirp参数与信号处理参数的匹配关系

雷达端配置chirp参数会直接决定算法端能看到什么，脱离chirp配置去调算法参数据完全没有意义。我整理了常用的参数关系表，真实调试时我就是拿着这张表算数值的。

从这些参数能推导出几个关键性能指标。距离分辨率约等于c除以2B，B是240MHz时大约0.625米。速度分辨率约等于波长除以2倍的帧内总时长，77GHz频段波长约3.9毫米，128个chirp乘以80微秒，算下来速度分辨率大约0.19米每秒。最大不模糊速度约等于波长除以4倍的Tc，算下来大约12.2米每秒，如果被测目标速度超过这个值，就会发生多普勒模糊，出现的速度要么接近零要么反向，这就是6.2节要讲的坑。

调参时还有一个容易被忽略的点：距离窗和速度窗的选择会互相影响检测效果。距离维我习惯加汉明窗，速度维加布莱克曼窗，后者旁瓣更低，适合分离两个速度相近的目标。代价是主瓣稍宽，会让速度维度分辨率轻微下降，但这个损失对应用层来说可以接受。

5.2 实时性、分辨率与虚警率的平衡

调参的实质就是在这三者之间找平衡。分辨率要够，处理速度要快，虚警率还要低，不可能同时做到最好。我建议先在性能上定下限，再优化分辨率，最后压虚警率。

举个实际例子。最开始我把每帧chirp数设成256，速度分辨率确实提高了一倍，但处理线程每帧要多做一次128点FFT，在普通工控机上直接把帧处理时间从15毫秒拉到30毫秒，显示帧率掉到30Hz以下。后来我把chirp数降回128，速度分辨率0.19米每秒已经足够分辨行人和车辆的相对运动，处理时间回到15毫秒以内，界面重新流畅起来。这个案例说明一个道理：参数不是越大越好，必须跟应用需求和处理能力匹配。

CFAR的alpha值是虚警率最直接的旋钮。我在项目里做了一个参数滑杆面板，把alpha、训练单元、保护单元都暴露在界面上，改动后下一帧就能看到效果，调参效率比改代码重新运行高得多。不过暴露参数也带来一个风险，任何一个参数改动都可能让点云质量变差，所以我在界面里加了一个“恢复场景默认值”的按钮，把一套经过验证的默认参数固化在配置文件里，方便调试时随时回退。

6. 常见问题与排查技巧实录

6.1 UDP丢包导致画面闪烁和点云断帧

这是上线第一天就撞上的问题。雷达100Hz发送，PC端界面偶尔卡一下，点云就缺几帧，RD图上的热区也跟着闪烁。一开始以为是算法处理慢，后来把接收线程打上时间戳才发现，UDP丢包发生在接收环节，不是处理环节。

排查方法很简单：在接收线程里维护一个帧号序列，统计缺失的帧号。雷达每一帧都会递增帧号，理论上应该连续，一旦发现帧号跳变，说明UDP包在传输或接收环节丢了。我通过分别记录网卡驱动层和应用层的帧号比对，确认是应用层接收不及时导致的。解决措施有三步：第一，把SO_RCVBUF从默认值调到4MB；第二，把接收线程绑定到一个独占CPU核心，减少调度抖动；第三，在有界队列阻塞时直接丢旧帧，而不是让接收线程等待。三步做完，100Hz接收稳定跑一下午，统计丢包率低于0.01%。

另外想提醒一句，如果你是用笔记本的无线网卡接收雷达数据，丢包率会高得离谱，因为Wi-Fi本身的实时性就没有保证。千万要用有线千兆网口直连，中间不要过交换机，即便过了交换机也要确认是千兆且没有广播风暴干扰。

6.2 多普勒模糊和镜像目标

有一次测试，一个明显的目标在雷达正前方匀速靠近，界面上却同时出现了两个点，一个位置对的，另一个位置也对但速度符号是反的，而且两个点的速度绝对值一模一样。这就是典型的多普勒模糊。

原因之前提过，最大不模糊速度v_max等于波长除以4倍的chirp周期，目标是靠近还是远离会产生一个多普勒频率，当目标实际速度超过了v_max，它的多普勒频率会折叠进可测范围内，看起来像是反向运动的目标。解决办法有两个方向。第一，雷达端降低chirp周期Tc，比如从80微秒降到50微秒，v_max从12.2米每秒提升到19.5米每秒，但代价是同等chirp数下帧内总时长变短，速度分辨率变差。第二，处理端在多目标场景下做速度解模糊，利用不同chirp周期的两次测量结果联合解算，这个算法实现复杂一些，但效果更好。

我在平台里做了一个开关，启用“多普勒解模糊”选项后，算法会把当前帧的测量和上一帧的跟踪预测做一致性校验，如果一条航迹在速度上出现跳变，就尝试补偿一个整数倍的模糊速度，恢复真实速度。经过几个月的测试，这个补偿逻辑在行人、自行车、汽车混合场景下表现稳定。

6.3 界面卡顿与内存持续增长

PyQtGraph用起来顺手，但不注意使用方式就有性能坑。我最初实现RD图时，每次更新都重新构造一个新的numpy数组，再setImage给ImageItem，跑一会儿就发现内存悄悄上涨。原因是numpy临时数组不断创建，Qt内部又持有旧图像数据的引用，旧数据没法及时释放。

改法是把缓冲区复用的思路用上：预先分配两个RD图大小的numpy数组，一个当前帧，一个上一帧，新数据算完直接拷贝进当前帧缓冲区，setImage时传入缓冲区对象而不是新建数组，这样旧的缓冲区对象被Qt替换后可以立即回收。点云数据同理，ScatterPlotItem内部有符号管理，频繁setData大量点时会重建缓冲，我把每帧最多显示的点数限制在2000个以内，超出的点按距离优先丢弃，既保住了近处关键目标，又控制了刷新开销。

内存问题还有一个隐藏来源：录制模块。如果每帧数据都往Python list里追加，list会不断扩容，且Python对象本身开销很大。改成预分配二进制缓冲再写入文件后，问题彻底解决。

7. 我踩过这些坑之后的一些体会

圈子里很多人觉得雷达处理平台就是“凑合能看就行”，但实际项目里，恰恰是这些“凑合”会让后续算法调试变成猜谜。PLFM_RADAR做得最值的一件事，是把所有中间结果都可视化了：RD图、CFAR门限、点云、航迹，每一层都能单独开关，每一帧都能暂停查看。调试到后半程，我几乎不在代码里加打印，全靠界面上的中间变量定位问题，效率高得多。

最后再分享一个小技巧。开发这种数据流系统时，一定要尽早加一个客户端模拟器，也就是用程序按照真实雷达的协议往平台发数据，速度和内容可控。有了它，调试CFAR时你不用整天蹲在雷达旁边，随手就能构造一个包含多人、多车、强杂波的测试场景。这个模拟器后来成了我每次版本更新之后回归测试的标配工具，省下来的时间远比写它花掉的时间多。后续我打算给平台加上目标类型分类和简单的场景语义输出，让上层应用不再需要自己处理原始点云，这个方向还在打磨中。