第二讲：数据采集基础——毫米波雷达原始数据结构解析
大家好，我是你们的老朋友。今天咱们聊聊雷达数据采集中最基础、也最绕不开的话题——原始数据结构。
说实话，我刚入行那会儿，拿到第一份雷达数据时，整个人是懵的。一堆十六进制数，完全不知道从哪下手。后来踩了不少坑，才慢慢摸清楚门道。今天我就把这些经验掰开揉碎了讲给你听。
一、雷达数据到底长什么样？
毫米波雷达输出的数据，按处理深度可以分为三个层次：ADC数据、点云数据、目标列表。这三个层次，说白了就是「原始信号→中间结果→最终结论」的递进关系。
核心观点：ADC数据是「原材料」，点云数据是「半成品」，目标列表是「成品」。做数据回放和复现，你至少得懂前两层。
我习惯用一张图来理解它们的关系。你看下面这个流程：
二、ADC数据——最原始的「原材料」
ADC数据，就是模数转换器直接采出来的原始信号。你想想看，雷达发射一个调频连续波（FMCW），遇到目标反射回来，混频后得到中频信号，再经过ADC采样——这就是ADC数据的来源。
ADC数据的特点：
- 复数形式：通常包含I（同相）和Q（正交）两路，每个采样点是一个复数
- 数据量大：一帧数据可能有几十万到上百万个采样点
- 无意义的外观：直接看就是一堆数字，必须经过处理才能解读
我的经验：我在调试某款77GHz雷达时，发现ADC数据里总有周期性毛刺。后来查了半天，原来是电源纹波耦合进了模拟前端。所以，ADC数据质量直接决定了后续处理的成败——这个坑我替你们踩过了。
ADC数据的典型存储格式如下：
// 假设每帧有 N 个chirp，每个chirp有 M 个采样点
// 数据排列方式（常见的一种）：
// [chirp1_I0, chirp1_Q0, chirp1_I1, chirp1_Q1, ..., chirp1_IM-1, chirp1_QM-1,
// chirp2_I0, chirp2_Q0, ...]
// 用Python读取的示例：
import numpy as np
def read_adc_data(file_path, num_chirps, num_samples):
raw = np.fromfile(file_path, dtype=np.int16)
# 交错排列：I, Q, I, Q, ...
iq = raw[0::2] + 1j * raw[1::2]
# 重塑为 [chirp, sample] 矩阵
return iq.reshape(num_chirps, num_samples)
嗯，这里要注意：不同厂商的雷达，ADC数据的排列方式可能不一样。有的先存所有chirp的I路，再存Q路；有的按chirp交错存储。拿到数据后，第一件事就是搞清楚排列格式。
三、点云数据——从信号到「点」的蜕变
ADC数据经过1D FFT（距离维）、2D FFT（速度维）、CFAR检测、角度估计等一系列处理后，就得到了点云数据。
点云数据里每个点通常包含：
| 字段 | 含义 | 典型范围 | 备注 |
|---|---|---|---|
| 距离 (Range) | 目标到雷达的径向距离 | 0.1 ~ 200 m | 分辨率取决于带宽 |
| 速度 (Velocity) | 目标的径向速度 | -40 ~ +40 m/s | 正号表示靠近 |
| 方位角 (Azimuth) | 水平方向角度 | -60° ~ +60° | 取决于天线布局 |
| 俯仰角 (Elevation) | 垂直方向角度 | -15° ~ +15° | 部分雷达不支持 |
| 信噪比 (SNR) | 信号强度指标 | 0 ~ 60 dB | 越高越可靠 |
点云数据比ADC数据「友好」多了。每个点都有物理意义，你可以直接画在二维或三维坐标里。但要注意——点云不是目标，它只是「疑似目标的信号峰值」。
避坑指南：我曾经在高速场景测试时，发现点云里有一堆「鬼点」——明明路上没车，却检测出几十个点。后来排查发现，是路边的护栏产生了多径反射。所以，点云数据一定要结合场景理解，别盲目相信。
四、目标列表——雷达的「最终答案」
目标列表是雷达处理器对点云进行聚类、跟踪后输出的结果。每个目标代表一个「真实存在的物体」，通常包含：
- 目标ID：用于跨帧跟踪的唯一标识
- 位置信息：距离、角度（有时直接给x/y坐标）
- 运动状态：速度、加速度
- 属性标签：如「行人」、「车辆」、「静止物」
- 置信度：该目标的可信程度
目标列表的数据量很小——一帧可能只有几个到几十个目标。但信息密度最高，是上层应用（如AEB、ACC）直接使用的数据。
举个例子，目标列表的JSON格式大概长这样：
{
"frame_id": 1024,
"timestamp_us": 1234567890,
"targets": [
{
"id": 1,
"range_m": 25.3,
"azimuth_deg": -2.1,
"velocity_mps": -5.2,
"snr_db": 28.5,
"type": "vehicle",
"confidence": 0.95
},
{
"id": 2,
"range_m": 12.8,
"azimuth_deg": 1.5,
"velocity_mps": 0.3,
"snr_db": 18.2,
"type": "pedestrian",
"confidence": 0.78
}
]
}
五、三种数据怎么用？
做数据回放与复现，我建议你按这个思路来：
- 调试算法时：用ADC数据，从头跑一遍信号处理链，验证每个环节是否正确
- 分析场景时：用点云数据，可视化观察目标分布，发现异常检测结果
- 验证系统时：用目标列表，对比雷达输出与真值（如激光雷达或GPS）的差异
我的习惯：我会把三种数据同时保存下来。ADC数据占空间大，但最「原汁原味」；点云数据是调试的主力；目标列表方便做自动化测试。三者配合，才能把问题彻底搞清楚。
六、数据采集的注意事项
最后，分享几个我在数据采集中总结的要点：
- 时间戳必须精准：不同数据源的时间同步是复现的基础，差1毫秒都可能对不上
- 记录环境信息：温度、湿度、雷达安装位置——这些看似无关，但出问题时就是关键线索
- 数据完整性校验：采集过程中加CRC校验，避免文件损坏导致白忙一场
- 标注异常场景：遇到特殊场景（如隧道、强雨雪）时，在日志里做标记，方便后续分析
好了，这一讲的内容就是这些。三种数据结构——ADC、点云、目标列表——是雷达数据处理的基石。你只有把它们彻底搞懂了，后面的回放和复现才能得心应手。
可可精品资料库