毫米波雷达的点云数据是如何构建出来的？

在详细总结毫米波雷达FMCW的工作原理与计算过程 和毫米波雷达是如何测量和计算角度信息的？ 这两篇文章中分别详细总结了毫米波雷达测量、推导和计算毫米波雷达距离、速度以及角度方位信息的完整流程，本文从使用毫米波雷达芯片和模块的角度，总结雷达输出的点云数据究竟是如何构建出来的。

毫米波雷达输出的点云数据

简单来说，毫米波雷达所输出的点云数据，是指雷达接收天线收到的回波射频信号经过底层数字信号处理（DSP或硬件加速器）后，从中提取出的一组代表空间中有效反射目标的数据集合。

image.png

对于一个典型的4D毫米波雷达芯片或者模块而言，其每一帧输出的点云由多个点组成，每个点的数据通常是一个包含多个维度信息的向量：$P = [x, y, z, v, \text{SNR}]$。

  • 空间坐标位置 ($x, y, z$)：检测目标相对于雷达传感器的三维空间位置。这是通过计算信号的飞行时间（距离）和不同接收天线之间的相位差（水平角和俯仰角）解算出来的。在详细总结毫米波雷达FMCW的工作原理与计算过程 和毫米波雷达是如何测量和计算角度信息的？ 这两篇文章中已经对雷达如何测试出来这些数据进行了非常详细的总结和说明.
  • 径向速度 ($v$)：这是毫米波雷达的竞争优势所在。依靠多普勒效应，雷达可以在底层相对比较精确地测出该点相对于传感器的瞬时靠近或远离的速度。不需要像视觉算法那样通过前后帧比对来估算速度。
  • 信噪比/反射强度 ($\text{SNR}$ 或 $\text{Intensity}$，可选项)：表示该点反射回来的信号强度。其中金属物体的反射强度更高，而人体、布料等的反射较弱。

而对于 3D 毫米波雷达而言，因为只具备水平方向上的多发多收（MIMO）天线阵列，缺乏垂直方向的天线布局。因此，3D 雷达只能测出距离 (Range)、速度 (Velocity) 和水平角 (Azimuth)。对应于直角坐标系中，它输出的是数据就只有 $(x, y, v)$。

雷达芯片和模块数据输出的格式

对于雷达芯片和模块的输出数据格式而言，目前尚无跨品牌跨行业的通用数据协议和格式。因此，不同的芯片原厂（如TI、NXP、Infineon）或模块封装厂（如森思泰克、纵目等），其通过串口或CAN总线输出的具体报文结构是私有的。

但无论如何，雷达芯片和模块要输出的数据和信息内容无法也就是以上章节所提到的那些内容。因此，其输出数据的核心信息结构在业界是高度一致的：绝大多数消费类和车规级雷达模块，都会采用 TLV（Type-Length-Value，类型-长度-值） 的数据结构来打包点云帧。

下面以参考资料2给出的 TI mmWave传感器通过 UART 输出检测数据的组织格式为例，对雷达的输出数据状况进行说明。

雷达每处理完一帧（Frame）射频信号，就会向外发送一个数据包（Packet）。这个数据包采用了非常经典的定长帧头 + TLV 变长数据块的设计。

d84769d5-6ac8-4f1c-8000-5dff98fbb5dc.png

每一帧数据输出都会以一个40字节长度的定长结构 Frame Header 开头，这是解析雷达数据输出的锚点：整个数据帧的大小、以及这个数据帧包含的TLV结构的数量都在Frame Header中定义。

72144cc0-7681-4e3a-87cb-ae50f9ecaf8b.png

注意其中的 Num TLVs 描述的是这个帧数据包里装了几种不同类型的数据块，可通过 TI 的 guiMonitor 指令要求雷达在一个数据输出帧中同时输出多种数据，如点云数据 (Type 1)、目标追踪列表 (Type 1010)、系统状态信息 (Type 6)等，每一种类型的数据对应一个TLV结构体。

而 Num Detected Obj 代表的是雷达在当前这一帧的物理空间中，真正检测到的有效反射点的数量。这个变量主要是为解析 Type = 1 (Detected Points) 或类似的点云 TLV 数据准备的。在程序中对点云数据所在的TLV结构进行解析时，可以通过这个变量快速获取到所有检测点的点云数据。

对于每一个TLV结构而言，其开头首先是一个定长的8字节，其中包含有这个结构的Type和Length信息：

3815ec78-ee1c-4b05-a4ab-1f77faab2a98.png

对于点云数据的TLV结构而言，Type部分固定是1，Length则代表了这个TLV结构不含TLV Header的Data Length。

TLV结构的Data部分就是连续的点云数据，每个点云数据结构代表了一个有效检测点，定长16字节，对于雷达针对一个检测点的 4 个核心物理量，全部采用标准的单精度浮点数（IEEE 754 标准）。所以这部分的长度就是 4 Bytes * Num Detected Obj

7e1c6452-7075-4d1d-a761-99e1c75795d3.png

雷达点云信息的构建

在真实的物理世界中，雷达发射出的调频连续波（FMCW）会打在汽车、行人、树木、地面，甚至是雨滴上，然后同时反射回来。雷达的接收天线（Rx）最终收到的，是一个把所有这些反射信号全部混杂在一起的复杂的模拟电磁波。

那么，雷达芯片内部究竟是如何从这个复杂的混合信号中，提取出来一个个清晰的 $(x, y, z, v)$ 点云数据的呢？

其实，大致的计算过程，在详细总结毫米波雷达FMCW的工作原理与计算过程 和毫米波雷达是如何测量和计算角度信息的？ 这两篇文章中已经详细的总结过了。

这里再从完整点云信息构造的角度上，对点云数据的构造过程进行总结：

  • 1D FFT（距离维度）：当混杂着各种回波的模拟信号通过雷达的 ADC 采样变成数字信号后，DSP 做的第一件事就是做一次快速傅里叶变换（Range FFT）。因为 FMCW 雷达的回波频率差直接对应物理距离，所以这一步实际上是在把空间按距离切片，这就初步可以把不同距离的物体分开了。
  • 2D FFT（速度维度）：为了能够准确测量速度信息，雷达会连续发射一排 Chirp（比如 128 个组成一帧）。然后针对这 128 个结果，在时间维度上再做一次傅里叶变换（即所谓的Doppler FFT）。因为移动物体在连续 Chirp 之间会产生微小的相位差，2D FFT 能把这些相位差转化为速度信息。经过 2D FFT 后，数据变成了一张二维热力图。

image.png

  • CFAR（恒虚警率检测）：以上第二步得到的充满能量高低起伏的二维热力图中，不仅有目标，还有大量的环境底噪、地面的杂波反射。雷达必须决定哪些是真正的检测目标，哪些是只是噪声？这就是 CFAR（Constant False Alarm Rate）算法的用武之地：当它检查某一个格子（被测单元 CUT）时，会先去评估这个格子周围一圈格子的平均噪声水平。只有当这个格子的能量，显著高于它周围环境的平均噪声加上一个提前设定的阈值时，雷达才认定这是一个真实的检测点。
    • 经过这个CFAR算法的处理之后，雷达的检测结过就变成了离散的、有独立坐标的检测点。这就是毫米波雷达点云输出数据的起源。

image.png

  • 3D FFT（角度解算）：通过以上三步的计算，得到了离散检测点（点云）的距离和速度信息。最后一步，雷达只需要针对那些通过了 CFAR 检测的极少数点，提取不同接收天线（Rx）之间的信号相位差，进行第三次傅里叶变换，计算出该点在水平和俯仰方向的角度。

最终，每个孤立的检测点和能量峰，都拥有了完整的距离、速度、角度（方位角和俯仰角）以及反射强度等信息，这些信息会被打包成标准的 TLV Type 1 数据，通过串口按照上面描述的协议格式发送出来。

image.png

参考资料